Re: Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

> 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 to clean up and test but I'll make an RFC once I have a
patch to discuss. It's unlikely that the patch will be feature complete
but I'll aim for it to be enough to satisfy the Linux/OpenBSD drivers.

> We can use the strategy I used 10 years back for sun4m: boot the
> proprietary firmware first to reduce the number of possible emulation
> bugs. The proprietary firmware is known to boot Solaris.

Using the proprietary firmware for this would be ideal. It would also
provide reliable access to the kernel debugger which would be extremely
helpful for diagnosing what's going wrong with the console. I'm not
sure how I would go about making progress on this though. I know there
are binaries of the BIOS for Sun4m machines floating around but I'm not
aware of any for Sun4u machines.

Thanks,
Jasper Lowell.

On Sun, 2020-05-17 at 14:37 +0200, Artyom Tarasenko wrote:
> On Sun, May 17, 2020 at 9:57 AM <address@hidden> wrote:
> > 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.
> 
> Great progress! Are you planning to contribute your escc2 to the
> upstream?
> 
> > 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.
> 
> We can use the strategy I used 10 years back for sun4m: boot the
> proprietary firmware first to reduce the number of possible emulation
> bugs. The proprietary firmware is known to boot Solaris.
> 
> Regards,
> Artyom