Re: Emulating Solaris 10 on SPARC64 sun4u

[Artyom Tarasenko]

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