> Great progress! Are you planning to contribute your escc2 to the
> upstream?
I would like to. While it didn't solve the console difficulties on
OpenSolaris variants, it's probably still a good idea to increment
Sun4u emulation towards being more faithful to hardware. It will take
me a few weeks
I've written up a basic implementation of the SAB 82532 ESCC2 device
and have written a patch for OpenBIOS to add it to the device tree. I
still have the 16550A UART acting as ttya to avoid having to write an
OpenBIOS device driver.
OpenBSD and Solaris both identify the device correctly and attach
Good idea.
The ESCC device looks like it's written as a sysbus device. I think the
Ultra 5 has no devices on the root sabre bus. The serial controller is
behind the ebus (essentially isa). I'm guessing I would need to write a
wrapper device around the memory io functions so that it can be used
und
> I don't know anything about this chip so don't know if it helps but
> if
> it's any way similar to ESCC (and the ESCC2 name is not just
> marketing)
> then there's some emulation of that in hw/char/escc.c that you may
> want to
> look at.
From what I can tell, the SAB 82532 is a bit more comp
There are two different drivers for the 16550A in OpenSolaris.
There is a generic driver in /usr/src/uts/common/io/asy.c. This driver
clearly states in comments that it is assigning the device to tty[a-d].
It's really obvious to me that there is support in this driver for
using the device for a t
Just thought I'd chime in with an update.
We are currently emulating a 16550A UART. The guest sees this as the SU
device, referring to the SuperIO port (a pair of 16550A UARTs). On the
Ultra 5, the machine that Sun4u is modelled against, SuperIO was used
for the keyboard and mouse. The Ultra 5 als
> Yes, that's correct. However I'm quite confident from booting other
> non-Solaris OSs
> under qemu-system-sparc64 that PCI native mode is being used,
> particularly as it is
> possible to see the related PCI sabre IRQ routing configuration
> changes.
Considering that Solaris 10 is accessing CFR
> cmd646_update_irq() only seems to raise PCI interrupt, should it also
> have
> an option to use INT 14 and 15 in legacy mode similar to what my
> patch
> does for via-ide?
Looking through /qemu/hw/ide/cmd646.c it doesn't look like QEMU has
support for legacy mode. At the very least, it looks l
I'm happy to do this. It will take a while for me to collect the
results though. I'll chime in once I have the results.
> That should give the ultimate answer to our guessing.
Agreed.
Thanks,
Jasper Lowell.
On Thu, 2020-02-27 at 12:38 +0100, BALATON Zoltan wrote:
> On Thu, 27 Feb 2020, jasper.lo
I haven't.
I did a pull this morning on master and everything seems to be working
again. The problem was likely the same.
Thanks,
Jasper Lowell.
On Thu, 2020-02-27 at 12:35 +0100, BALATON Zoltan wrote:
> On Thu, 27 Feb 2020, jasper.low...@bt.com wrote:
> > > I'll submit a RFC V2 patch with a pro
> I'll submit a RFC V2 patch with a proposed fix.
This will have to wait.
Recent commits have caused Solaris 10 to error out of booting much
earlier than previously.
Jasper Lowell.
On Thu, 2020-02-27 at 05:10 +, jasper.low...@bt.com wrote:
> I've since looked at a Ultra 5 board and can conf
I've since looked at a Ultra 5 board and can confirm that it shipped
with a CMD646U chip like the Ultra 10.
> Since both the generic PCI IDE and CMD646 Linux drivers mention irq
> is
> cleared on reading status I think using ide_ioport_read in
> hw/ide/pci.c
> may be correct for the generic case
> Problem with that patch is that it removes this clearing from the
> func
> that's also used to emulate ISA IDE ioports which according to their
> spec
> should clear irq on read so that function should be OK but maybe
> should
> not be called by PCI IDE code?
This might be it.
The patch I pr
> > ide_exec_cmd 0.461 pid=147030 bus=0x55b77f922d10
> > state=0x55b77f922d98 cmd=0xef
> The command is run here if I'm not mistaken Does this set the irq
> right
> away on QEMU where on real hadware this may take some time? Not sure
> if
> that's a problem but trying to understand what's happen
I'm having another look at the SET_FEATURE Solaris 10 error. I've
enabled tracing and I see the following. The pci_cfg_read that shows up
at the end continues a few thousand times(?) but I've omitted it. This
appears to time out or something and then Solaris gives up on the
device.
ide_ioport_read
> The chip docs don't mention any side effect, they only say that the
> DMA
> IRQ and Error bits in the bus master IDE status reg (bits 2 and 1)
> are
> write 1 to clear
I haven't found any documentation that mention that side effect either.
As you say, it only mentions that you should set the b
The Linux libATA API documentation mentions that on some hardware,
reading the status register has the side effect of clearing the
interrupt condition. When emulating the generic Sun4u machine running
Solaris 10, the Solaris 10 CMD646 driver exits fatally because of this
emulated side effect. This
Excuse the delay. I believe the reason why I am unable to locate the error
string "Interrupt not seen after set_features" in the OpenSolaris source code
is because it belongs to a proprietary driver that was not distributed with
OpenSolaris. Rather than rely on source code I've had to debug this
I haven't figured out where that is coming from.
The error doesn't look like it's in the OpenSolaris source code so I don't have
any context behind it.
The error does show up here:
https://docs.oracle.com/cd/E23824_01/html/821-1475/uata-7d.html so it might be
related to the IDE controller.
The b
I'm currently working towards emulating Solaris 10 on sun4u.
The Solaris 10 ISO image I am attempting to boot is the one from the Oracle
download page at
https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html.
Image: sol-10-u11-ga-sparc-dvd.iso
MD5: 53e8b066f7f250ce
20 matches
Mail list logo
