Re: Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

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 it.

Interestingly, it looks like Solaris entered an interrupt handler to
deal with an event for the SAB 82532 and it probed a few status
registers. Given that I couldn't encourage Solaris to do anything
outside of attach the device for the 16550A, I was thinking this might
be a good sign.

There really shouldn't be an interrupt though as the reset state of the
SAB 82532 is to have all interrupts masked. Solaris probes these
interrupt status registers while "configuring" the sunhme device.

Attempting to configure interface hme0...
140070@1589698603.268942:escc2_mem_read channel a addr 0x38 value 0x4
140070@1589698603.269011:escc2_irq_update value 0x0
140070@1589698603.269015:escc2_mem_read channel a addr 0x3a value 0x80
140070@1589698603.269017:escc2_irq_update value 0x0
140070@1589698603.269018:escc2_mem_read channel a addr 0x3b value 0x0
140070@1589698603.269076:escc2_mem_read channel a addr 0x38 value 0x0
WARNING: Power off requested from power button or SC, powering down the
system!
140070@1589698611.270845:escc2_mem_read channel a addr 0x38 value 0x0
140070@1589698619.271758:escc2_mem_read channel a addr 0x38 value 0x0

I've noticed that removing the sunhme code for sun4u.c in QEMU prevents
the spurious interrupt from happening for the serial device along with
prevent the unexpected power off request (the power off request was not
introduced by my code). I haven't investigated why the presence of
sunhme causes these events.

I modified OpenBIOS to use ttyb for stdin/stdout and assigned that to
the 16550A so that ttya could be aliased to the SAB 82532. Outside of
the spurious interrupt handler being called, I'm getting the same
behaviour where Solaris identifies, attaches, and then ignores the
device. Doesn't look like my guess was on the mark.

I'll be looking at getting an OpenSolaris-like kernel built with prom
debugging output for console/tty related files like
usr/src/uts/common/io/consconfig_dacf.c. The illumos kernel is probably
suitable for this because it's still maintained and appears to be
suffering from the same console problems. I don't have a SPARC64
machine immediately available and I'm unfamiliar with the build system
behind these distributions, so it might be a while before this happens.

I'm out of ideas.


Thanks,
Jasper Lowell.


On Sun, 2020-05-10 at 10:22 +0100, Mark Cave-Ayland wrote:
> On 10/05/2020 03:46, address@hidden wrote:
> 
> > 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
> > under the ebus - judging from the serial-isa implementation.
> > 
> > I think it might be possible to leave the ESCC as a sysbus device
> > but
> > I'm not familiar enough with OpenBIOS to expose the right
> > information
> > to Solaris and reason about what's happening confidentally. I don't
> > expect writing a wrapper for isa to be difficult so I'll give that
> > a
> > go. Do you think it would be fine to just choose an arbitrary
> > ioport
> > address for the device?
> > 
> > Thanks,
> > Jasper Lowell.
> 
> I'm not overly keen on this approach, because it's just swapping out
> one incorrect
> device for another. The existing sun4u machine is fairly close to an
> ultra5 and I'd
> prefer to move towards emulating the real machine rather than keep
> swapping out
> random bits of hardware.
> 
> The main reason I added the sunhme emulation to QEMU was because I
> found that across
> all my test images different OSs had different bugs in their NIC
> drivers/IRQ
> handling, and this was the only solution that would work for all of
> them. My fear
> with going the ESCC route is that you'll end up in exactly the same
> situation.
> 
> 
> ATB,
> 
> Mark.