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, jasper.low...@bt.com 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.
