Re: Emulating Solaris 10 on SPARC64 sun4u
> 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. > I haven't been able to find any of this firmware either. Not sure if this helps but someone says they've got the Ultra 1 firmware (along with cgsix and cgthree) available here: https://people.csail.mit.edu/fredette/tme/sun-u1-nbsd.html
Re: Emulating Solaris 10 on SPARC64 sun4u
> 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 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
Re: Emulating Solaris 10 on SPARC64 sun4u
On Sun, May 17, 2020 at 9:57 AM 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
Re: Emulating Solaris 10 on SPARC64 sun4u
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.
Re: Emulating Solaris 10 on SPARC64 sun4u
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.
Re: Emulating Solaris 10 on SPARC64 sun4u
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. On Fri, 2020-05-08 at 15:45 +0200, Artyom Tarasenko wrote: > On Fri, May 8, 2020 at 10:51 AM Peter Tribble < > peter.trib...@gmail.com> wrote: > > I see the same behaviour as reported here when booting current > > SPARC illumos > > (illumos is the ongoing fork of OpenSolaris) under qemu - looks > > like it's booted > > up fine, but I can't type anything on the console. > > There is one more option which can be relatively easily tested: > you can add two more ports (or replace the existing ttya/ttyb) to the > qemu's ultra5 model: the escc (aka zs) ports. > They definitely work under Solaris (Ultra-1, Ultra-2, E3000, > E3500...), I've seen it. > OpenBIOS already has a driver for them which is used for sun4m (and > some ppc) targets. So no new devices have to be implemented. > If your and Jasper's theory proofs to be correct, we can think of > replacing ttya/ttyb su with zs. > I guess the other sun4u operating systems do support zs as well. > (This > has to be tested though) > > > > While I'm an illumos developer, and maintain it on SPARC, I'm > > unfamiliar with > > most of the internals. We'll try and have a poke around, though. > > > > (The aim would be to use qemu to allow illumos developers to test > > changes on SPARC > > without requiring them to have SPARC hardware, hence my interest.) > > I think I managed booting Tribblix under the QEMU niagara target. It > has less devices than sun4u, but the console was working. > > Regards, > Artyom > > > On Fri, May 8, 2020 at 3:40 AM wrote: > > > 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 tty. > > > > > > There is another driver at /usr/src/uts/sun4/io/su_driver.c. > > > Judging > > > from the name this is specific for SuperIO. This driver is more > > > than > > > 1000 lines shorter than the other driver and contains a note at > > > the top > > > of the file that it is "modified as sparc keyboard/mouse driver." > > > I > > > don't have much experience with Solaris internals but I can't see > > > any > > > obvious signs that this can be used as a tty. I'd also question > > > why > > > there are two drivers if they have the same purpose/capability. > > > If the > > > su_driver exists to only add support for the keyboard/mouse I'm > > > not > > > sure why it would be shorter rather than longer. It would be > > > helpful if > > > someone with Solaris experience, that knows what they're doing (I > > > do > > > not), can take a look at this driver and give a better opinion. > > > > > > When emulating Sun4u, the su driver is used. If you misconfigure > > > the > > > serial device in QEMU, you can trigger errors that are unique to > > > the > > > driver. Also, Solaris attaches the device as su0. > > > > > > Solaris can access the registers, identify/attach the device, but > > > it > > > just never attempts to use it. Interrupts are explicitly disabled > > > and > > > the device is never polled. I don't think asyopen in su_driver.c > > > is > > > ever called. I've thoroughly stepped through every register > > > access for > > > the 16550A and nothing seems out of the ordinary to me. Something > > > I've > > > considered is that OpenBIOS is not setting properties for the > > > device in > > > a way that Solaris expects but I'm not familiar enough with Sun's > > > OpenBOOT to make progress here. I've read through the PROM > > > functions > > > that Solaris calls when choosing what device to use as a console > > > and > > > nothing seemed inconsistent with what OpenBIOS does. > > > Unfortunately, > > > OpenBIOS seems to crash or hang when using the kernel debugger > > > module, > > > so dynamic analysis using breakpoints isn't an option. > > > > > > I don't have any concrete explanations for the broken console but > > > rather than do nothing I figured I'd see what happens by > > > emulating the > > > SAB 82532. > > > > > > > At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to > > > > the > > > > 16550A UART. I
Re: Emulating Solaris 10 on SPARC64 sun4u
On Fri, May 8, 2020 at 10:51 AM Peter Tribble wrote: > > I see the same behaviour as reported here when booting current SPARC illumos > (illumos is the ongoing fork of OpenSolaris) under qemu - looks like it's > booted > up fine, but I can't type anything on the console. There is one more option which can be relatively easily tested: you can add two more ports (or replace the existing ttya/ttyb) to the qemu's ultra5 model: the escc (aka zs) ports. They definitely work under Solaris (Ultra-1, Ultra-2, E3000, E3500...), I've seen it. OpenBIOS already has a driver for them which is used for sun4m (and some ppc) targets. So no new devices have to be implemented. If your and Jasper's theory proofs to be correct, we can think of replacing ttya/ttyb su with zs. I guess the other sun4u operating systems do support zs as well. (This has to be tested though) > While I'm an illumos developer, and maintain it on SPARC, I'm unfamiliar with > most of the internals. We'll try and have a poke around, though. > > (The aim would be to use qemu to allow illumos developers to test changes on > SPARC > without requiring them to have SPARC hardware, hence my interest.) I think I managed booting Tribblix under the QEMU niagara target. It has less devices than sun4u, but the console was working. Regards, Artyom > On Fri, May 8, 2020 at 3:40 AM wrote: >> >> 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 tty. >> >> There is another driver at /usr/src/uts/sun4/io/su_driver.c. Judging >> from the name this is specific for SuperIO. This driver is more than >> 1000 lines shorter than the other driver and contains a note at the top >> of the file that it is "modified as sparc keyboard/mouse driver." I >> don't have much experience with Solaris internals but I can't see any >> obvious signs that this can be used as a tty. I'd also question why >> there are two drivers if they have the same purpose/capability. If the >> su_driver exists to only add support for the keyboard/mouse I'm not >> sure why it would be shorter rather than longer. It would be helpful if >> someone with Solaris experience, that knows what they're doing (I do >> not), can take a look at this driver and give a better opinion. >> >> When emulating Sun4u, the su driver is used. If you misconfigure the >> serial device in QEMU, you can trigger errors that are unique to the >> driver. Also, Solaris attaches the device as su0. >> >> Solaris can access the registers, identify/attach the device, but it >> just never attempts to use it. Interrupts are explicitly disabled and >> the device is never polled. I don't think asyopen in su_driver.c is >> ever called. I've thoroughly stepped through every register access for >> the 16550A and nothing seems out of the ordinary to me. Something I've >> considered is that OpenBIOS is not setting properties for the device in >> a way that Solaris expects but I'm not familiar enough with Sun's >> OpenBOOT to make progress here. I've read through the PROM functions >> that Solaris calls when choosing what device to use as a console and >> nothing seemed inconsistent with what OpenBIOS does. Unfortunately, >> OpenBIOS seems to crash or hang when using the kernel debugger module, >> so dynamic analysis using breakpoints isn't an option. >> >> I don't have any concrete explanations for the broken console but >> rather than do nothing I figured I'd see what happens by emulating the >> SAB 82532. >> >> > At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the >> > 16550A UART. I think there were more such machines. I don't expect >> > there is anything in the Solaris kernel which would prevent any >> > serial >> > device known to it to be used as a tty. >> >> Do you happen to know if this was over SuperIO? If this machine was >> using the same su_driver for a serial console it would rule out >> emulating the hardware-faithful SAB 82532 as being a possible >> improvement. I can't find anything online about someone using SuperIO >> for a ttya on an Ultra 5 running Solaris. >> >> > Well, theoretically yes, but practically there is just one baudrate >> > which can be specified in the OBP. I think it's perfectly safe to use >> > max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer. >> >> I'll do this while looking at whether or not the different chip fixes >> the console problems on Sun4u. I'd personally like to avoid introducing >> a device to QEMU that makes assumptions about how the guest may >> configure the chip. >> >> Thanks, >> Jasper Lowell. >> >> >> On Thu, 2020-05-07 at 17:02 +0200, Artyom Tarasenko wrote: >> > On Thu, May 7, 2020 at 4:29 PM wrote: >> > > Just thought I'd chime in with an update. >> > > >> > > We are currently emulating a 16550A
Re: Emulating Solaris 10 on SPARC64 sun4u
I see the same behaviour as reported here when booting current SPARC illumos (illumos is the ongoing fork of OpenSolaris) under qemu - looks like it's booted up fine, but I can't type anything on the console. While I'm an illumos developer, and maintain it on SPARC, I'm unfamiliar with most of the internals. We'll try and have a poke around, though. (The aim would be to use qemu to allow illumos developers to test changes on SPARC without requiring them to have SPARC hardware, hence my interest.) On Fri, May 8, 2020 at 3:40 AM wrote: > 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 tty. > > There is another driver at /usr/src/uts/sun4/io/su_driver.c. Judging > from the name this is specific for SuperIO. This driver is more than > 1000 lines shorter than the other driver and contains a note at the top > of the file that it is "modified as sparc keyboard/mouse driver." I > don't have much experience with Solaris internals but I can't see any > obvious signs that this can be used as a tty. I'd also question why > there are two drivers if they have the same purpose/capability. If the > su_driver exists to only add support for the keyboard/mouse I'm not > sure why it would be shorter rather than longer. It would be helpful if > someone with Solaris experience, that knows what they're doing (I do > not), can take a look at this driver and give a better opinion. > > When emulating Sun4u, the su driver is used. If you misconfigure the > serial device in QEMU, you can trigger errors that are unique to the > driver. Also, Solaris attaches the device as su0. > > Solaris can access the registers, identify/attach the device, but it > just never attempts to use it. Interrupts are explicitly disabled and > the device is never polled. I don't think asyopen in su_driver.c is > ever called. I've thoroughly stepped through every register access for > the 16550A and nothing seems out of the ordinary to me. Something I've > considered is that OpenBIOS is not setting properties for the device in > a way that Solaris expects but I'm not familiar enough with Sun's > OpenBOOT to make progress here. I've read through the PROM functions > that Solaris calls when choosing what device to use as a console and > nothing seemed inconsistent with what OpenBIOS does. Unfortunately, > OpenBIOS seems to crash or hang when using the kernel debugger module, > so dynamic analysis using breakpoints isn't an option. > > I don't have any concrete explanations for the broken console but > rather than do nothing I figured I'd see what happens by emulating the > SAB 82532. > > > At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the > > 16550A UART. I think there were more such machines. I don't expect > > there is anything in the Solaris kernel which would prevent any > > serial > > device known to it to be used as a tty. > > Do you happen to know if this was over SuperIO? If this machine was > using the same su_driver for a serial console it would rule out > emulating the hardware-faithful SAB 82532 as being a possible > improvement. I can't find anything online about someone using SuperIO > for a ttya on an Ultra 5 running Solaris. > > > Well, theoretically yes, but practically there is just one baudrate > > which can be specified in the OBP. I think it's perfectly safe to use > > max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer. > > I'll do this while looking at whether or not the different chip fixes > the console problems on Sun4u. I'd personally like to avoid introducing > a device to QEMU that makes assumptions about how the guest may > configure the chip. > > Thanks, > Jasper Lowell. > > > On Thu, 2020-05-07 at 17:02 +0200, Artyom Tarasenko wrote: > > On Thu, May 7, 2020 at 4:29 PM wrote: > > > 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 also had a DB25 (ttya > > > default) > > > and a DB9 (ttyb default) with a SAB82532 ESSC2. > > > > > > Using tracing, I've looked through how the 16550A UART is touched > > > and > > > it looks like Solaris 10 has no issues identifying the device. I've > > > matched register accesses with driver code in OpenSolaris and I'm > > > pretty sure the device is attached successfully. Also, if you boot > > > Solaris 10 with debugging output, you can see that the device gets > > > labelled as su0. The only time Solaris is capable of writing to the > > > console is when OpenBIOS is used as a proxy. > > > > > > Rather than Solaris deciding
Re: Emulating Solaris 10 on SPARC64 sun4u
> 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 complex than the ESCC ones. It's not difficult to implement but a complete solution will be lengthy because of the large combination of configuration options the chip supports. > Maybe you can get away with setting these to the values the driver > would > set and hard coding it for now just to get some output. Then you can > ignore the corresponding registers which could simplify initial > device > model. I'll take this approach. Thanks, Jasper Lowell. On Thu, 2020-05-07 at 20:54 +0200, BALATON Zoltan wrote: > On Thu, 7 May 2020, jasper.low...@bt.com wrote: > > I've started work on emulating the SAB 82532 ESSC2 but it's > > unfortunately way more complex than than the 16550A. For instance, > > it's > > 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. > > > possible to configure different baudrates for receiving and > > transmitting. QEMU's chardev interface doesn't appear to handle > > that. > > QEMUSerialSetParams has a single speed value that is passed to > > cfsetispeed and cfsetospeed. The chip also has support for stick > > parity > > , which aren't valid options right now either. If I'm wrong on > > either > > of those points please correct me. Unless there is an alternative, > > changes to the interface may need to be made if adding this device > > is > > to be considered. > > Maybe you can get away with setting these to the values the driver > would > set and hard coding it for now just to get some output. Then you can > ignore the corresponding registers which could simplify initial > device > model. > > Regards, > BALATON Zoltan
Re: Emulating Solaris 10 on SPARC64 sun4u
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 tty. There is another driver at /usr/src/uts/sun4/io/su_driver.c. Judging from the name this is specific for SuperIO. This driver is more than 1000 lines shorter than the other driver and contains a note at the top of the file that it is "modified as sparc keyboard/mouse driver." I don't have much experience with Solaris internals but I can't see any obvious signs that this can be used as a tty. I'd also question why there are two drivers if they have the same purpose/capability. If the su_driver exists to only add support for the keyboard/mouse I'm not sure why it would be shorter rather than longer. It would be helpful if someone with Solaris experience, that knows what they're doing (I do not), can take a look at this driver and give a better opinion. When emulating Sun4u, the su driver is used. If you misconfigure the serial device in QEMU, you can trigger errors that are unique to the driver. Also, Solaris attaches the device as su0. Solaris can access the registers, identify/attach the device, but it just never attempts to use it. Interrupts are explicitly disabled and the device is never polled. I don't think asyopen in su_driver.c is ever called. I've thoroughly stepped through every register access for the 16550A and nothing seems out of the ordinary to me. Something I've considered is that OpenBIOS is not setting properties for the device in a way that Solaris expects but I'm not familiar enough with Sun's OpenBOOT to make progress here. I've read through the PROM functions that Solaris calls when choosing what device to use as a console and nothing seemed inconsistent with what OpenBIOS does. Unfortunately, OpenBIOS seems to crash or hang when using the kernel debugger module, so dynamic analysis using breakpoints isn't an option. I don't have any concrete explanations for the broken console but rather than do nothing I figured I'd see what happens by emulating the SAB 82532. > At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the > 16550A UART. I think there were more such machines. I don't expect > there is anything in the Solaris kernel which would prevent any > serial > device known to it to be used as a tty. Do you happen to know if this was over SuperIO? If this machine was using the same su_driver for a serial console it would rule out emulating the hardware-faithful SAB 82532 as being a possible improvement. I can't find anything online about someone using SuperIO for a ttya on an Ultra 5 running Solaris. > Well, theoretically yes, but practically there is just one baudrate > which can be specified in the OBP. I think it's perfectly safe to use > max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer. I'll do this while looking at whether or not the different chip fixes the console problems on Sun4u. I'd personally like to avoid introducing a device to QEMU that makes assumptions about how the guest may configure the chip. Thanks, Jasper Lowell. On Thu, 2020-05-07 at 17:02 +0200, Artyom Tarasenko wrote: > On Thu, May 7, 2020 at 4:29 PM wrote: > > 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 also had a DB25 (ttya > > default) > > and a DB9 (ttyb default) with a SAB82532 ESSC2. > > > > Using tracing, I've looked through how the 16550A UART is touched > > and > > it looks like Solaris 10 has no issues identifying the device. I've > > matched register accesses with driver code in OpenSolaris and I'm > > pretty sure the device is attached successfully. Also, if you boot > > Solaris 10 with debugging output, you can see that the device gets > > labelled as su0. The only time Solaris is capable of writing to the > > console is when OpenBIOS is used as a proxy. > > > > Rather than Solaris deciding against using SuperIO as a tty, I > > don't > > think there was ever any support for doing so (at least on SPARC > > machines). This could be an explanation for why the system appears > > to > > be trucking along just fine despite a seemingly frozen console - > > there > > is no console. I don't think the frozen console is the fault of > > broken > > interrupt routing as the 16550A UART is never programmed to > > generate > > them. > > At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the > 16550A UART. I think there were more such machines. I don't expect > there is anything in the Solaris kernel which would prevent any > serial > device known to it to be used as a tty. > > > I've
Re: Emulating Solaris 10 on SPARC64 sun4u
On Thu, 7 May 2020, jasper.low...@bt.com wrote: I've started work on emulating the SAB 82532 ESSC2 but it's unfortunately way more complex than than the 16550A. For instance, it's 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. possible to configure different baudrates for receiving and transmitting. QEMU's chardev interface doesn't appear to handle that. QEMUSerialSetParams has a single speed value that is passed to cfsetispeed and cfsetospeed. The chip also has support for stick parity , which aren't valid options right now either. If I'm wrong on either of those points please correct me. Unless there is an alternative, changes to the interface may need to be made if adding this device is to be considered. Maybe you can get away with setting these to the values the driver would set and hard coding it for now just to get some output. Then you can ignore the corresponding registers which could simplify initial device model. Regards, BALATON Zoltan
Re: Emulating Solaris 10 on SPARC64 sun4u
On Thu, May 7, 2020 at 4:29 PM wrote: > > 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 also had a DB25 (ttya default) > and a DB9 (ttyb default) with a SAB82532 ESSC2. > > Using tracing, I've looked through how the 16550A UART is touched and > it looks like Solaris 10 has no issues identifying the device. I've > matched register accesses with driver code in OpenSolaris and I'm > pretty sure the device is attached successfully. Also, if you boot > Solaris 10 with debugging output, you can see that the device gets > labelled as su0. The only time Solaris is capable of writing to the > console is when OpenBIOS is used as a proxy. > > Rather than Solaris deciding against using SuperIO as a tty, I don't > think there was ever any support for doing so (at least on SPARC > machines). This could be an explanation for why the system appears to > be trucking along just fine despite a seemingly frozen console - there > is no console. I don't think the frozen console is the fault of broken > interrupt routing as the 16550A UART is never programmed to generate > them. At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the 16550A UART. I think there were more such machines. I don't expect there is anything in the Solaris kernel which would prevent any serial device known to it to be used as a tty. > I've started work on emulating the SAB 82532 ESSC2 but it's > unfortunately way more complex than than the 16550A. For instance, it's > possible to configure different baudrates for receiving and > transmitting. QEMU's chardev interface doesn't appear to handle that. > QEMUSerialSetParams has a single speed value that is passed to > cfsetispeed and cfsetospeed. The chip also has support for stick parity > , which aren't valid options right now either. If I'm wrong on either > of those points please correct me. Unless there is an alternative, > changes to the interface may need to be made if adding this device is > to be considered. Well, theoretically yes, but practically there is just one baudrate which can be specified in the OBP. I think it's perfectly safe to use max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer. Regards, Artyom > > On Sun, 2020-02-09 at 11:26 +, Mark Cave-Ayland wrote: > > On 05/02/2020 06:31, jasper.low...@bt.com wrote: > > > > > 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: 53e8b066f7f250ce2fd2cef063f8072b > > > > > > > > > > > > I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158. > > > > > > > > > > > > The command I am using to run QEMU is: > > > > > > ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios > > > ./openbios/obj-sparc64/openbios-builtin.elf -cdrom > > > ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G > > > > > > > > > > > > ``` > > > > > > CPUs: 1 x SUNW,UltraSPARC-IIi > > > > > > UUID: ---- > > > > > > Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15 > > > > > > Type 'help' for detailed information > > > > > > Trying cdrom:f... > > > > > > Not a bootable ELF image > > > > > > Not a bootable a.out image > > > > > > > > > > > > Loading FCode image... > > > > > > Loaded 7420 bytes > > > > > > entry point is 0x4000 > > > > > > Evaluating FCode... > > > > > > Evaluating FCode... > > > > > > Ignoring failed claim for va 100 memsz af6d6! > > > > > > Ignoring failed claim for va 1402000 memsz 4dcc8! > > > > > > Ignoring failed claim for va 180 memsz 510c8! > > > > > > SunOS Release 5.10 Version Generic_147147-26 64-bit > > > > > > Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights > > > reserved. > > > > > > could not find debugger-vocabulary-hook>threads:interpret: > > > exception -13 caught > > > > > > interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc. > > > > > > \ All rights reserved. > > > > > > \ > > > > > > \ ident "@(#)data64.fth 1.3 00/07/17 SMI" > > > > > > > > > > > > hex > > > > > > > > > > > > only forth also definitions > > > > > > vocabulary kdbg-words > > > > > > also kdbg-words definitions > > > > > > > > > > > > defer p@ > > > > > > defer p! > > > > > > ['] x@ is p@ > > > > > > ['] x! is p! > > > > > > > > > > > > 8 constant ptrsize > > > > > > > > > > > > d# 32 constant nbitsminor > > > > > > h# constant maxmin > > > > > > \ > > > > > > \ Copyright 2008 Sun Microsystems, Inc. All rights reserved. > > > > > > \ Use is subject to license terms. > > > > > > \ > > > > > > > > >
Re: Emulating Solaris 10 on SPARC64 sun4u
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 also had a DB25 (ttya default) and a DB9 (ttyb default) with a SAB82532 ESSC2. Using tracing, I've looked through how the 16550A UART is touched and it looks like Solaris 10 has no issues identifying the device. I've matched register accesses with driver code in OpenSolaris and I'm pretty sure the device is attached successfully. Also, if you boot Solaris 10 with debugging output, you can see that the device gets labelled as su0. The only time Solaris is capable of writing to the console is when OpenBIOS is used as a proxy. Rather than Solaris deciding against using SuperIO as a tty, I don't think there was ever any support for doing so (at least on SPARC machines). This could be an explanation for why the system appears to be trucking along just fine despite a seemingly frozen console - there is no console. I don't think the frozen console is the fault of broken interrupt routing as the 16550A UART is never programmed to generate them. I've started work on emulating the SAB 82532 ESSC2 but it's unfortunately way more complex than than the 16550A. For instance, it's possible to configure different baudrates for receiving and transmitting. QEMU's chardev interface doesn't appear to handle that. QEMUSerialSetParams has a single speed value that is passed to cfsetispeed and cfsetospeed. The chip also has support for stick parity , which aren't valid options right now either. If I'm wrong on either of those points please correct me. Unless there is an alternative, changes to the interface may need to be made if adding this device is to be considered. Jasper Lowell. On Sun, 2020-02-09 at 11:26 +, Mark Cave-Ayland wrote: > On 05/02/2020 06:31, jasper.low...@bt.com wrote: > > > 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: 53e8b066f7f250ce2fd2cef063f8072b > > > > > > > > I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158. > > > > > > > > The command I am using to run QEMU is: > > > > ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios > > ./openbios/obj-sparc64/openbios-builtin.elf -cdrom > > ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G > > > > > > > > ``` > > > > CPUs: 1 x SUNW,UltraSPARC-IIi > > > > UUID: ---- > > > > Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15 > > > > Type 'help' for detailed information > > > > Trying cdrom:f... > > > > Not a bootable ELF image > > > > Not a bootable a.out image > > > > > > > > Loading FCode image... > > > > Loaded 7420 bytes > > > > entry point is 0x4000 > > > > Evaluating FCode... > > > > Evaluating FCode... > > > > Ignoring failed claim for va 100 memsz af6d6! > > > > Ignoring failed claim for va 1402000 memsz 4dcc8! > > > > Ignoring failed claim for va 180 memsz 510c8! > > > > SunOS Release 5.10 Version Generic_147147-26 64-bit > > > > Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights > > reserved. > > > > could not find debugger-vocabulary-hook>threads:interpret: > > exception -13 caught > > > > interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc. > > > > \ All rights reserved. > > > > \ > > > > \ ident "@(#)data64.fth 1.3 00/07/17 SMI" > > > > > > > > hex > > > > > > > > only forth also definitions > > > > vocabulary kdbg-words > > > > also kdbg-words definitions > > > > > > > > defer p@ > > > > defer p! > > > > ['] x@ is p@ > > > > ['] x! is p! > > > > > > > > 8 constant ptrsize > > > > > > > > d# 32 constant nbitsminor > > > > h# constant maxmin > > > > \ > > > > \ Copyright 2008 Sun Microsystems, Inc. All rights reserved. > > > > \ Use is subject to license terms. > > > > \ > > > > > > > > \ #pragma ident "@(#)kdbg.fth1.2008/06/06 SMI" > > > > > > > > h# 7ff constant v9bias > > > > h# unix-tte:interpret: exception -13 caught > > > > interpret ' unix-tte is va>tte-data failed with error > > ffed > > > > WARNING: consconfig: cannot find driver for screen device /pci@1fe, > > 0/pci@1,1/QEMU,VGA@2 > > > > Configuring devices. > > > > WARNING: Interrupt not seen after set_features > > > > Using RPC Bootparams for network configuration information. > > > > Attempting to configure interface hme0... > > > > WARNING: Power off requested from power button or SC, powering down > > the system! > > > > Skipped interface hme0 > > > >
RE: Emulating Solaris 10 on SPARC64 sun4u
On Fri, 28 Feb 2020, BALATON Zoltan wrote: I think I now understand the problem with via-ide at least and the following FYI, I came up with this patch: http://patchwork.ozlabs.org/project/qemu-devel/list/?series=161714 that fixes my problem with via-ide. The first patch also touches CMD646 to allow reusing a field in PCIIDEState for flags but I did not change anything else for CMD646. Regards, BALATON Zoltan
RE: Emulating Solaris 10 on SPARC64 sun4u
On Wed, 19 Feb 2020, BALATON Zoltan wrote: On Wed, 19 Feb 2020, BALATON Zoltan wrote: faster or doing something differently? Does someone know what interrupts are generated on real hardware in DMA mode so we can compare that to what we see with QEMU? The document Programming Interface for Bus Master IDE Controller, Revision 1.0 (5/16/94) has some info on this. AFAIU it says that after DMA operation is completed an IRQ should be raised. On page 5, section 3.1. Data Synchronization it says: "Another way to view this requirement is that the first read to the controller Status register in response to the IDE device interrupt must return with the Interrupt bit set and with the guarantee that all buffered data has been written to memory." Not sure if this is relevant but how is it handled in QEMU? Is the right interrupt bit set after DMA transfer is done? If so is it the one that's checked by the OS driver? I think I now understand the problem with via-ide at least and the following is true for that case. I'm not sure about the CMD646 but it may be similar as these seem to be similar designs or maybe even related somehow. The problem in my case stems from that the device has two modes documented: legacy where it uses standard ISA ioports and INT14 and 15 for the two channels and native mode in which it uses PCI BARs for io address and an IRQ configurable via PCI_INTERRUPT_LINE (config reg 9). It seems the IRQ in native mode is still not a PCI INT line but an ISA IRQ, however it can be selected by config reg and it's a single interrupt instead of two for separate channels (Linux prints these during boot so that's a good way to check which mode it thinks it's using). That's so far is complex enough to not be easy to emulate in QEMU as we can set up legacy ISA ports with ide_init_ioport() but there's no way then to switch it off so via-ide either implemented legacy or native mode but can't correctly switch between those. This may not be a problem most of the time for Linux at least which tries to check which mode the controller is in and use that so it would work with whatever is there as long as the regs match what's emulated so we can just emulate one mode and still work. But all of the above is further complicated by that on some (most?) boards there's also a "non 100% native mode" in which the io addresses are taken from the PCI BARs but still using hardcoded INT14 and 15, ignoring the setting in PCI_INTERRUPT_LINE. So guest drivers may assume this without checking regs and not care about what's set in PCI_INTERRUPT_LINE just expect interrupts on INT14 and 15. If the emulation raises PCI INT or some other isa interrupt it won't work, even if config regs correctly describe the difference following the docs but guest drivers don't care about the chip spec only the implementation on the board they meant to run on. Unfortunately different guests use different heuristics and workarounds (even Linux does so on different archs) so it's not easy to make an emulation that works with all. The pegasos2 firmware for example sets via-ide in native mode and assigns interrupt 9 but on real hardware this reg seems to be hardcoded to 14 and Linux uses this to detect if it needs to use the half-native mode but sets the mode reg to legacy to note this despite then using PCI BARs (so we can't hardcode mode reg to always native without breaking this but have to force int reg and emulate half native mode to work with other guests). Linux would also work with 100% native mode with IRQ9 but Amiga like OSes don't seem to care and just use hardcoded half-native mode regardless of config regs and expect interrupt on IRQ14 and 15. I could make a patch to work with all these on pegasos2 but the via-ide is also used on a mips board where the corresponding Linux version also applies its own (different) workarounds corresponding to the quirks of that board and ends up either trying to use legacy mode (which is not emulated as io is only on PCI BARs) or trying to use 100% native mode which does not work with half-native interrupts. I think I'll need to add a special property to the device to set it to half-native for pegasos2 and leave it 100% native for mips, otherwise there may not be a combination which works with all these firmwares and guests on both machines. (We still can avoid having to implement native mode as well but I can imagine if some PC guests were involved we may need that too but on these ppc and mips boards and also in your case I think native and half-native modes should be enough as that's all guests use.) The CMD646 case might be similar and that's also used on a hppa board so you may need to check with that too if you make changes. To check this theory you might try forcing ide interrupts to be IRQ14 and 15 via something like: qemu_set_irq(isa_get_irq(NULL, (channel ? 15 : 14)), level); instead of using PCI interrupt or configured ISA
RE: Emulating Solaris 10 on SPARC64 sun4u
On Mon, 10 Feb 2020, BALATON Zoltan wrote: This suggests the common IDE bmdma and ide-cd code is likely OK and problem is somewhere in irq routing. What's relevant for this thread and sparc64 is that then you should also check interrupt controller and routing if an interrupt raised by the IDE controller could get to the CPU in your case as that could be where the problem is and maybe not in common code as I've suspected before. I can now confirm that my problem was related to IRQ routing as noted here: https://lists.nongnu.org/archive/html/qemu-devel/2020-02/msg07225.html so any similar problem for Solaris is not related to this and common IDE and BMDMA code are likely OK so you may want to check IRQ handling in board and chipset emulation in case the cause is similar to what I had. Regards, BALATON Zoltan
Re: IDE IRQ problem after UDMA enabled (was: Re: Emulating Solaris 10 on SPARC64 sun4u)
On Tue, 25 Feb 2020, BALATON Zoltan wrote: On Mon, 10 Feb 2020, John Snow wrote: It sounds like the real problem is either in the bmdma controller (or its unique interaction with hw/ide/core.c -- which is possible) or in the interrupt routing somewhere else. If you have any IDE traces from a hang, feel free to throw them up on a pastebin for me to take a peek at; it might help for me to see the exact sequence that causes a hang in QEMU's IDE terms to see if I can't "reverse engineer" what the guest is hoping to have happen. Maybe I can trace this to a bad register value. I've got some traces from Linux and MorphOS (both on my work in progress pegasos2 emulation using via-ide where I can most easily reproduce this) but I'm not sure what to look for in these. MorphOS starts booting, so firmware can read ide-cd connected to via-ide as well as MorphOS can before enabling UDMA 5 mode but stops after that and cannot read the drive any more. Linux works even after enabling DMA. I've gathered some logs in https://osdn.net/projects/qmiga/ticket/38949 previously but now I try to list here the part in more detail where drive is detected, enabling DMA and first command after that in case you can spot something in these that could explain why it fails with MorphOS driver. Never mind, I've found a clue in NetBSD's driver: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/viaide.c?rev=1.89=text/x-cvsweb-markup_with_tag=MAIN which has a comment that says: /* * At least under certain (mis)configurations (e.g. on the "Pegasos" board) * the VT8231-IDE's native mode only works with irq 14/15, and cannot be * programmed to use a single native PCI irq alone. So we install an interrupt * handler for each channel, as in compatibility mode. */ If I change via-ide to use ISA IRQ14 and 15 and ignore what's programmed in the PCI config reg then MorphOS works with UDMA so it expects that. This change however breaks Linux which still boots after getting some errors but maybe it downgrades to PIO mode then. I'll need to find out more about how is this broken on real hardware and how can we emulate it. So you don't need to look at the logs unless you want to check why it sees a non working ATA device after resetting the bus but logs in the ticket above may be more useful for that as I did not include that part in this email. Thank you, BALATON Zoltan
IDE IRQ problem after UDMA enabled (was: Re: Emulating Solaris 10 on SPARC64 sun4u)
Hello, On Mon, 10 Feb 2020, John Snow wrote: It sounds like the real problem is either in the bmdma controller (or its unique interaction with hw/ide/core.c -- which is possible) or in the interrupt routing somewhere else. If you have any IDE traces from a hang, feel free to throw them up on a pastebin for me to take a peek at; it might help for me to see the exact sequence that causes a hang in QEMU's IDE terms to see if I can't "reverse engineer" what the guest is hoping to have happen. Maybe I can trace this to a bad register value. I've got some traces from Linux and MorphOS (both on my work in progress pegasos2 emulation using via-ide where I can most easily reproduce this) but I'm not sure what to look for in these. MorphOS starts booting, so firmware can read ide-cd connected to via-ide as well as MorphOS can before enabling UDMA 5 mode but stops after that and cannot read the drive any more. Linux works even after enabling DMA. I've gathered some logs in https://osdn.net/projects/qmiga/ticket/38949 previously but now I try to list here the part in more detail where drive is detected, enabling DMA and first command after that in case you can spot something in these that could explain why it fails with MorphOS driver. First the working Linux case: pci_cfg_read via-ide 12:1 @0x4 -> 0x87 pci_cfg_read via-ide 12:1 @0x3d -> 0x1 pci_cfg_read via-ide 12:1 @0x4 -> 0x87 pci_cfg_read via-ide 12:1 @0x40 -> 0xb pci_cfg_read via-ide 12:1 @0x40 -> 0xb bmdma_read_via bmdma: readb 0x2 : 0x00 bmdma_read_via bmdma: readb 0x2 : 0x00 pci_cfg_read via-ide 12:1 @0x4 -> 0x87 ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x0a; bus 0x56229cb35600 ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x00; bus 0x56229cb35600 IDEState 0x56229cb35a58 bmdma_read_via bmdma: readb 0x2 : 0x00 bmdma_write_via bmdma: writeb 0x2 : 0x00 ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x0a; bus 0x56229cb35ef0 ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 bmdma_read_via bmdma: readb 0x2 : 0x00 bmdma_write_via bmdma: writeb 0x2 : 0x00 pci_cfg_read via-ide 12:1 @0x9 -> 0x8f [2.589547] scsi0 : pata_via [2.590949] scsi1 : pata_via [2.591488] ata1: PATA max UDMA/100 cmd 0x1000 ctl 0x100c bmdma 0x1020 irq 9 [2.591652] ata2: PATA max UDMA/100 cmd 0x1010 ctl 0x101c bmdma 0x1028 irq 9 [...] [2.938174] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100 pci_cfg_read via-ide 12:1 @0x4c -> 0xaa pci_cfg_write via-ide 12:1 @0x4c <- 0xa2 pci_cfg_write via-ide 12:1 @0x4e <- 0x31 pci_cfg_write via-ide 12:1 @0x49 <- 0x31 pci_cfg_read via-ide 12:1 @0x51 -> 0x17 pci_cfg_write via-ide 12:1 @0x51 <- 0x17 pci_cfg_read via-ide 12:1 @0x4c -> 0xa2 pci_cfg_write via-ide 12:1 @0x4c <- 0xa2 pci_cfg_write via-ide 12:1 @0x4e <- 0x31 pci_cfg_write via-ide 12:1 @0x49 <- 0x31 pci_cfg_read via-ide 12:1 @0x51 -> 0x17 pci_cfg_write via-ide 12:1 @0x51 <- 0xf0 ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0xa0; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_status_read IDE PIO rd @ 0x4 (Alt Status); val 0x50; bus 0x56229cb35ef0; IDEState 0x56229cb35f78 ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x0a; bus 0x56229cb35ef0 ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0xa0; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_ioport_write IDE PIO wr @ 0x1 (Features); val 0x03; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_ioport_write IDE PIO wr @ 0x2 (Sector Count); val 0x45; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_ioport_write IDE PIO wr @ 0x3 (Sector Number); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_ioport_write IDE PIO wr @ 0x4 (Cylinder Low); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_ioport_write IDE PIO wr @ 0x5 (Cylinder High); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_ioport_write IDE PIO wr @ 0x7 (Command); val 0xef; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_exec_cmd IDE exec cmd: bus 0x56229cb35ef0; state 0x56229cb35f78; cmd 0xef ide_status_read IDE PIO rd @ 0x4 (Alt Status); val 0x50; bus 0x56229cb35ef0; IDEState 0x56229cb35f78 ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x08; bus 0x56229cb35ef0 ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 bmdma_read_via bmdma: readb 0x2 : 0x00 bmdma_write_via bmdma: writeb 0x2 : 0x00 ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78 ide_ioport_read IDE PIO rd @ 0x1 (Error);
Re: Emulating Solaris 10 on SPARC64 sun4u
* BALATON Zoltan (bala...@eik.bme.hu) wrote: > On Wed, 19 Feb 2020, BALATON Zoltan wrote: > > faster or doing something differently? Does someone know what interrupts > > are generated on real hardware in DMA mode so we can compare that to > > what we see with QEMU? > > The document Programming Interface for Bus Master IDE Controller, Revision > 1.0 (5/16/94) has some info on this. AFAIU it says that after DMA operation > is completed an IRQ should be raised. On page 5, section 3.1. Data > Synchronization it says: > > "Another way to view this requirement is that the first read to the > controller Status register in response to the IDE device interrupt must > return with the Interrupt bit set and with the guarantee that all buffered > data has been written to memory." > > Not sure if this is relevant but how is it handled in QEMU? Is the right > interrupt bit set after DMA transfer is done? If so is it the one that's > checked by the OS driver? One thing to be a little careful of is I remember the 646 was always known for having a few quirks (I've not got a SPARC64 ith one, but I think my Alpha has it). So whether you're chasing a generic IDE BM problem or a 646 special is fun. Dave > Regards, > BALATON Zoltan > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
RE: Emulating Solaris 10 on SPARC64 sun4u
On Wed, 19 Feb 2020, BALATON Zoltan wrote: faster or doing something differently? Does someone know what interrupts are generated on real hardware in DMA mode so we can compare that to what we see with QEMU? The document Programming Interface for Bus Master IDE Controller, Revision 1.0 (5/16/94) has some info on this. AFAIU it says that after DMA operation is completed an IRQ should be raised. On page 5, section 3.1. Data Synchronization it says: "Another way to view this requirement is that the first read to the controller Status register in response to the IDE device interrupt must return with the Interrupt bit set and with the guarantee that all buffered data has been written to memory." Not sure if this is relevant but how is it handled in QEMU? Is the right interrupt bit set after DMA transfer is done? If so is it the one that's checked by the OS driver? Regards, BALATON Zoltan
RE: Emulating Solaris 10 on SPARC64 sun4u
On Wed, 19 Feb 2020, jasper.low...@bt.com wrote: When configuring devices, Solaris 10 uses the SET_FEATURE command on the CMD646 to set the transfer mode to MDMA mode. From what I can tell, this is successful and the emulated IDE controller raises an interrupt acknowledging that the command was completed successfully. To determine whether or not this interrupt was successfully propagated to Solaris 10, I made manual changes to ensure that the interrupt was not raised for this event at this specific time. This resulted in a new error from Solaris 10 regarding "set_features". - Solaris 10 appears to be able to see the interrupt from the completion of the SET_FEATURE command. - Solaris 10 appears to then perform two reads on the status register. From what I understand, this has the side effect of clearing interrupts. - Solaris 10 then writes to the device/head register. - Solaris 10 then spins on ARTTIM23_INTR_CH1 expecting it to be set. When it is not set, the operation times out and we are presented with the fatal error regarding set_features. I am not intimately familiar with the workings of the CMD646 or the ATA specification so I can only speculate. - If the interrupt that Solaris 10 expects is the one from the SET_FEATURE command, then Solaris 10 is not expecting reading from the status register to clear ARTTIM23_INTR_CH1. - If the interrupt that Solaris 10 expects is not the one from the SET_FEATURE command, then it must expect an interrupt to occur from writing to the device/head register. I don't have definitive answers so these are some ideas but I may be completely wrong. I don't know about Solaris but what I've seen on PPC and via-ide is that it works until switched to UDMA mode then it freezes on the first command issued after switching to UDMA so it seems like it expects an interrupt that's not generated or not routed correctly but only in DMA mode, in the initial PIO mode it works. Not sure if this is useful at all for your case though so you may just disregard it. I found it strange that Solaris 10 was spinning on ARTTIM23_INTR_CH1. Is it possible that Solaris 10 is not expecting the values of ARTTIM23_INTR_CH1 and MRDMODE_INTR_CH1 to be synced? I made changes to disable the syncing and the fatal error from Solaris 10 disappeared. Unfortunately, I can't tell whether or not this actually improved the emulation of Solaris 10 as the serial console is still unresponsive. I think the syncing was added in commit 2711 and the commit log: https://lists.gnu.org/archive/html/qemu-devel/2014-08/msg02644.html cites the data sheet for that and there were other commits around it that were changing similar things as well. I guess this was fixing some problem at the time (Mark may remember more) so maybe these are correct but I don't know what actual hardware does. I also remember this IDE controller chip had different versions with early ones having implementation bugs that could cause problems so people generally avoided it or drivers may have hacks to fix those so it's possible that this tries to work around some hardware bug? I don't remember the details but maybe Linux kernel source has some history on this. If there is a bug in the Solaris 10 driver I would expect this error to be more widely referenced online. I suspect that the emulated CMD646 is not perfectly faithful to the hardware and this is causing problems for Solaris 10. I am not convinced that this problem is related to IRQ routing as Solaris 10 appears to recognise interrupts when they happen (or don't). Because of this, I don't think this error is related to the DMA problem under MorphOS but I could be wrong. I'm not sure either because during testing I've seen two cases and in one IRQ was raised but did not reach CPU due to being masked in interrupt controller so that suggests it's not a problem with generating the IRQ in IDE code but problem is afterwards but still could not understand why it fails. (Seems to work on Linux though so maybe understanding what the working and non-working cases do differently could get closer to the answer.) Does anyone have any ideas that might explain why Solaris 10 insists that ARTTIM23_INTR_CH1 is set despite two previous reads of the status register? I can only guess. The data sheet says that in PCI native mode these bits should be checked to determine if an interrupt on PCI INTA is coming from this controller (but for PIO mode, for DMA it just refers to Intel's spec without any more info). Specifically: "When an IDE port is in PCI IDE Native Mode, the IDE task file registers may be mapped to non-standard port addresses, and IDE drive interrupts occur at PCI INTA. [As opposed to Legacy mode when it uses standard ISA IDE port numbers and IRQ14 and 15.] Therefore, if both IDE ports are in PCI IDE Native Mode, drive interrupts from both IDE ports are multiplexed into PCI INTA. In this case, the interrupt status bits must
RE: Emulating Solaris 10 on SPARC64 sun4u
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 problem by observing Solaris 10's behaviour. I previously linked https://docs.oracle.com/cd/E23824_01/html/821-1475/uata-7d.html that seems to indicate that this error is fatal. Considering that the CMD646 IDE controller driver experiences a fatal error during the bootstrapping of the system, I suspect that the file system on the CDROM might not be accessible. I'm not sure if this is directly related to the unresponsive serial console but I wouldn't be surprised. When configuring devices, Solaris 10 uses the SET_FEATURE command on the CMD646 to set the transfer mode to MDMA mode. >From what I can tell, this is successful and the emulated IDE controller >raises an interrupt acknowledging that the command was completed successfully. >To determine whether or not this interrupt was successfully propagated to >Solaris 10, I made manual changes to ensure that the interrupt was not raised >for this event at this specific time. This resulted in a new error from >Solaris 10 regarding "set_features". - Solaris 10 appears to be able to see the interrupt from the completion of the SET_FEATURE command. - Solaris 10 appears to then perform two reads on the status register. From what I understand, this has the side effect of clearing interrupts. - Solaris 10 then writes to the device/head register. - Solaris 10 then spins on ARTTIM23_INTR_CH1 expecting it to be set. When it is not set, the operation times out and we are presented with the fatal error regarding set_features. I am not intimately familiar with the workings of the CMD646 or the ATA specification so I can only speculate. - If the interrupt that Solaris 10 expects is the one from the SET_FEATURE command, then Solaris 10 is not expecting reading from the status register to clear ARTTIM23_INTR_CH1. - If the interrupt that Solaris 10 expects is not the one from the SET_FEATURE command, then it must expect an interrupt to occur from writing to the device/head register. I found it strange that Solaris 10 was spinning on ARTTIM23_INTR_CH1. Is it possible that Solaris 10 is not expecting the values of ARTTIM23_INTR_CH1 and MRDMODE_INTR_CH1 to be synced? I made changes to disable the syncing and the fatal error from Solaris 10 disappeared. Unfortunately, I can't tell whether or not this actually improved the emulation of Solaris 10 as the serial console is still unresponsive. If there is a bug in the Solaris 10 driver I would expect this error to be more widely referenced online. I suspect that the emulated CMD646 is not perfectly faithful to the hardware and this is causing problems for Solaris 10. I am not convinced that this problem is related to IRQ routing as Solaris 10 appears to recognise interrupts when they happen (or don't). Because of this, I don't think this error is related to the DMA problem under MorphOS but I could be wrong. Does anyone have any ideas that might explain why Solaris 10 insists that ARTTIM23_INTR_CH1 is set despite two previous reads of the status register? Thanks, Jasper Lowell. -Original Message- From: Mark Cave-Ayland Sent: Sunday, 9 February 2020 10:26 PM To: Lowell,J,Jasper,VIM R ; qemu-devel@nongnu.org Cc: atar4q...@gmail.com Subject: Re: Emulating Solaris 10 on SPARC64 sun4u On 05/02/2020 06:31, jasper.low...@bt.com wrote: > 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: 53e8b066f7f250ce2fd2cef063f8072b > > > > I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158. > > > > The command I am using to run QEMU is: > > ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios > ./openbios/obj-sparc64/openbios-builtin.elf -cdrom > ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G > > > > ``` > > CPUs: 1 x SUNW,UltraSPARC-IIi > > UUID: ---- > > Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15 > > Type 'help' for detailed information > > Trying cdrom:f... > > Not a bootable ELF image > > Not a bootable a.out image > > > > Loading FCode image... > > Loaded 7420 bytes > > entry point is 0x4000 > > Evaluating FCode... > > Evaluating FCode... > > Ignoring failed claim for va 100 memsz af6d6! > > Ignoring failed claim for va 1402000 me
Missing IRQ with bmdma on ppc/mips/sparc? (was: Re: Emulating Solaris 10 on SPARC64 sun4u)
I've changed title to avoid derailing the original thread as this is more about pegasos2 issue now but left cc list for now. Let me know if you don't want to be cc'd. On Mon, 10 Feb 2020, John Snow wrote: On 2/10/20 10:38 AM, BALATON Zoltan wrote: On Sat, 8 Feb 2020, BALATON Zoltan wrote: Not sure if my problem I see on other machine emulation I'm working on is related at all but there's a possibility it might be. I got this with different arch (ppc but could also reproduce something similar with mips) and ide controller emulation (via-ide) but the PCI bmdma code is shared by CMD646, via-ide and sii3112 and also the ide-cdrom emulation is the same so if there's a bug in these that could cause similar problems for different components. Or it could be that we get similar symptoms due to different reasons in which case sorry for the distracion but maybe we can learn from the experience of each other even in that case. What I get is tracked here: https://osdn.net/projects/qmiga/ticket/38949 I've updated this ticket now with more detailed AmigaOS4 logs that also contains PIO regs except ide_data* to keep it managable. I've lost some of the driver debug messages as it seems QEMU debug messages overwrite those when both are directed to stdout so I can't capture them both but added comments to explain what stage they are at. (background on emulated machine: https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 ) (There's also board schematics linked from that page in case someone is interested about how IRQs are connected, it's not impossible I've got that wrong in my model as I don't really know what real hardware does. The work in progress patches implementing pegasos2 are in the git branch also linked from above.) Originally I had both Linux and MorphOS fail after enabling BMDMA before I had interrupt controller emulation (so that means it could be a problem with that in your case as well so something to check). Now that I've implemented interrupts Linux boots with DMA from CDROM but MorphOS is still not happy. I could now also reproduce the same with AmigaOS4 on pegasos2 where I got same missing interrupt problem: ---> Port 1 IOBase 1010, AltBase 101E bmcr_base 1028 MMIOBase Config not forced, scanning ... 1 device(s) on port 0 Master : 'ATAPI' "unit 2", I assume 1 Slave : 'unknown type' "unit 3", I assume Yes, there was also a "---> Port 0" before that, checking for primary master and slave devices that were unit 0 and 1 but I did not include that for brevity. Thus secondary master and slave devices are numbered 2 and 3. So there's definitely a problem with interrupts but not sure where. Also don't know why it detects an unknown slave device which then it decides is invalid. Maybe this is normal on an IDE bus with only one device or is it a problem in emulation? I don't actually know myself. We *do* always have two IDEState objects per port, but maybe we're letting some unknown state sneak through -- filling in a register improperly, perhaps? To make it clear, the problem I have that prevents it from working is the missing interrupt after switching to UDMA. The unknown slave device is only causing a delay in detection but then it determines that the secondary device is not working and goes further so I've only reported that as a potential problem in emulation that could be investigated and fixed but it's not the main problem that prevents working. It's probably not ide_ioport_read -- but I see complaints about the reset signature too, so maybe we've gotten that wrong. You can look at ide_set_signature to see how we set the drive signatures; called from ide_reset (and many other places too) Unfortunately I don't know much about IDE so likely I would not find out much there. I think ide_init_drive is only meant to be called on devices that actually exist and are plugged in. It initializes drive_kind to one of IDE_HD, IDE_CD, or IDE_CFATA -- empty or missing isn't an option here. (Hm, this means it defaults to IDE_HD actually.) From the logs I've seen it does seem to expect an ATA device i.e. HDD as unit 3 but after trying to identify it it gets an error and finds that there's no working device there and goes with just the CD drive. MorphOS does the same but trying a few times before giving up, there are some logs showing that in the above ticket, The tricky thing is that IDEState belongs to the parent bus -- not the drive object itself -- and the bus always has two slots. We select between the two by setting bus->unit; and we don't appear to do any kind of actual guarding that the drive actually exists. (I suppose guests are free to issue commands to non-existant drives if they want to, but they're not going to be able to perform work.) ...but ide_reset_bus calls ide_reset on both slots regardless of the presence of a device or not. I remember seeing log messages from guest that said it reset the ide bus
Re: Emulating Solaris 10 on SPARC64 sun4u
On 2/10/20 10:38 AM, BALATON Zoltan wrote: > On Sat, 8 Feb 2020, BALATON Zoltan wrote: >> Not sure if my problem I see on other machine emulation I'm working on >> is related at all but there's a possibility it might be. I got this >> with different arch (ppc but could also reproduce something similar >> with mips) and ide controller emulation (via-ide) but the PCI bmdma >> code is shared by CMD646, via-ide and sii3112 and also the ide-cdrom >> emulation is the same so if there's a bug in these that could cause >> similar problems for different components. Or it could be that we get >> similar symptoms due to different reasons in which case sorry for the >> distracion but maybe we can learn from the experience of each other >> even in that case. >> >> What I get is tracked here: >> >> https://osdn.net/projects/qmiga/ticket/38949 >> >> (background on emulated machine: >> https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 ) >> >> Originally I had both Linux and MorphOS fail after enabling BMDMA >> before I had interrupt controller emulation (so that means it could be >> a problem with that in your case as well so something to check). Now >> that I've implemented interrupts Linux boots with DMA from CDROM but >> MorphOS is still not happy. > > I could now also reproduce the same with AmigaOS4 on pegasos2 where I > got same missing interrupt problem: > > ---> Port 1 > IOBase 1010, AltBase 101E > bmcr_base 1028 > MMIOBase > Config not forced, scanning ... > 1 device(s) on port > 0 Master : 'ATAPI' "unit 2", I assume > 1 Slave : 'unknown type' "unit 3", I assume > Starting 'peg2ide.device - chip 0 port 1' task > bmdma_addr_write data: 0x0229 > Trying to configure unit 2 > > Hangs here waiting for interrupt which does not seem to arrive, then: > > [peg2ide/irq_wait] timed out > [peg2ide/exec_pio_data_in_cmd] <- here > [peg2ide/ata_read_drive_properties] unit 2 returned error 255, failbits > h, timeout 0 > Trying to configure unit 3 > [peg2ide/ata_read_drive_properties] After-reset signature invalid for > unit 3 > > So there's definitely a problem with interrupts but not sure where. Also > don't know why it detects an unknown slave device which then it decides > is invalid. Maybe this is normal on an IDE bus with only one device or > is it a problem in emulation? > I don't actually know myself. We *do* always have two IDEState objects per port, but maybe we're letting some unknown state sneak through -- filling in a register improperly, perhaps? It's probably not ide_ioport_read -- but I see complaints about the reset signature too, so maybe we've gotten that wrong. You can look at ide_set_signature to see how we set the drive signatures; called from ide_reset (and many other places too) I think ide_init_drive is only meant to be called on devices that actually exist and are plugged in. It initializes drive_kind to one of IDE_HD, IDE_CD, or IDE_CFATA -- empty or missing isn't an option here. (Hm, this means it defaults to IDE_HD actually.) The tricky thing is that IDEState belongs to the parent bus -- not the drive object itself -- and the bus always has two slots. We select between the two by setting bus->unit; and we don't appear to do any kind of actual guarding that the drive actually exists. (I suppose guests are free to issue commands to non-existant drives if they want to, but they're not going to be able to perform work.) ...but ide_reset_bus calls ide_reset on both slots regardless of the presence of a device or not. (This is probably just a side effect of the interrupt getting lost and having the guest try to reset the controller, then noticing weird state after the reset.) It sounds like the real problem is either in the bmdma controller (or its unique interaction with hw/ide/core.c -- which is possible) or in the interrupt routing somewhere else. If you have any IDE traces from a hang, feel free to throw them up on a pastebin for me to take a peek at; it might help for me to see the exact sequence that causes a hang in QEMU's IDE terms to see if I can't "reverse engineer" what the guest is hoping to have happen. Maybe I can trace this to a bad register value. (Hm, it's failing on pio_in? It's using PIO on an IDE drive with a DMA controller? Is it failing to enable DMA and then failing to use PIO as a backup too? Maybe there are two bugs.) --js > To locate the problem further I've then tried the same with ide-cd > connected to the sii3112 SATA emulation that also shares the same IDE > BMDMA code with CMD646 and via-ide but as a PCI card the interrupt > routing is different. So if I don't get the problem with it then that > can prove common code is correct. If I get the problem it may come from > common code or be another interrupt routing problem. > > I did not have PCI interrupts correctly implemented in pegasos2 yet so I > had to fix that first but I'm not sure it's correct yet. I got similar > results but the interrupt
RE: Emulating Solaris 10 on SPARC64 sun4u
On Sat, 8 Feb 2020, BALATON Zoltan wrote: Not sure if my problem I see on other machine emulation I'm working on is related at all but there's a possibility it might be. I got this with different arch (ppc but could also reproduce something similar with mips) and ide controller emulation (via-ide) but the PCI bmdma code is shared by CMD646, via-ide and sii3112 and also the ide-cdrom emulation is the same so if there's a bug in these that could cause similar problems for different components. Or it could be that we get similar symptoms due to different reasons in which case sorry for the distracion but maybe we can learn from the experience of each other even in that case. What I get is tracked here: https://osdn.net/projects/qmiga/ticket/38949 (background on emulated machine: https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 ) Originally I had both Linux and MorphOS fail after enabling BMDMA before I had interrupt controller emulation (so that means it could be a problem with that in your case as well so something to check). Now that I've implemented interrupts Linux boots with DMA from CDROM but MorphOS is still not happy. I could now also reproduce the same with AmigaOS4 on pegasos2 where I got same missing interrupt problem: ---> Port 1 IOBase 1010, AltBase 101E bmcr_base 1028 MMIOBase Config not forced, scanning ... 1 device(s) on port 0 Master : 'ATAPI' 1 Slave : 'unknown type' Starting 'peg2ide.device - chip 0 port 1' task bmdma_addr_write data: 0x0229 Trying to configure unit 2 Hangs here waiting for interrupt which does not seem to arrive, then: [peg2ide/irq_wait] timed out [peg2ide/exec_pio_data_in_cmd] <- here [peg2ide/ata_read_drive_properties] unit 2 returned error 255, failbits h, timeout 0 Trying to configure unit 3 [peg2ide/ata_read_drive_properties] After-reset signature invalid for unit 3 So there's definitely a problem with interrupts but not sure where. Also don't know why it detects an unknown slave device which then it decides is invalid. Maybe this is normal on an IDE bus with only one device or is it a problem in emulation? To locate the problem further I've then tried the same with ide-cd connected to the sii3112 SATA emulation that also shares the same IDE BMDMA code with CMD646 and via-ide but as a PCI card the interrupt routing is different. So if I don't get the problem with it then that can prove common code is correct. If I get the problem it may come from common code or be another interrupt routing problem. I did not have PCI interrupts correctly implemented in pegasos2 yet so I had to fix that first but I'm not sure it's correct yet. I got similar results but the interrupt seems to fire in this case but does not get to the CPU as it does not seem to be enabled: sii3112ide.device 53.3 (05.02.2009) Found chip #0 ---> Port 0 IOBase 1030, AltBase 103A bmcr_base 1090 MMIOBase 81004000 Config not forced, scanning ... sii3112_write bmdma: write (size 1) 0x8a : 0x02 sii3112_write bmdma: write (size 1) 0x86 : 0x00 sii3112_write bmdma: write (size 1) 0x82 : 0x55 sii3112_write bmdma: write (size 1) 0x83 : 0xaa sii3112_write bmdma: write (size 1) 0x82 : 0xaa sii3112_write bmdma: write (size 1) 0x83 : 0x55 sii3112_write bmdma: write (size 1) 0x82 : 0x55 sii3112_write bmdma: write (size 1) 0x83 : 0xaa sii3112_read bmdma: read (size 1) 0x82 : 0x55 sii3112_read bmdma: read (size 1) 0x83 : 0xaa sii3112_write bmdma: write (size 1) 0x86 : 0x00 sii3112_write bmdma: write (size 1) 0x8a : 0x06 sii3112_write bmdma: write (size 1) 0x8a : 0x02 sii3112_set_irq channel 0 level 0 sii3112_read bmdma: read (size 1) 0x87 : 0x00 sii3112_write bmdma: write (size 1) 0x86 : 0x00 sii3112_write bmdma: write (size 1) 0x86 : 0x00 sii3112_write bmdma: write (size 1) 0x86 : 0x00 sii3112_read bmdma: read (size 1) 0x82 : 0x01 sii3112_read bmdma: read (size 1) 0x83 : 0x01 sii3112_read bmdma: read (size 1) 0x84 : 0x14 sii3112_read bmdma: read (size 1) 0x85 : 0xeb sii3112_set_irq channel 0 level 0 sii3112_read bmdma: read (size 1) 0x87 : 0x00 sii3112_write bmdma: write (size 1) 0x86 : 0x00 1 device(s) on port 0 Master : 'ATAPI' Starting 'sii3112ide.device - chip 0 port 0' task sii3112_write bmdma: write (size 4) 0x4 : 0x22c bmdma_addr_write data: 0x022c Installing handler for irq 25 mv64361_gpp_irq(0x5654b950c1a0, 31, 1) levels=8000 mask=8000 mv64361_update_irq(0x5654b950c1a0, 59, 1) mv64361_gpp_irq(0x5654b950c1a0, 31, 0) levels=0 mv64361_update_irq(0x5654b950c1a0, 59, 0) Unassigned mem read 810040a1 Trying to configure unit 0 sii3112_write bmdma: write (size 1) 0x86 : 0x00 sii3112_set_irq channel 0 level 0 sii3112_read bmdma: read (size 1) 0x87 : 0x00 sii3112_write bmdma: write (size 1) 0x8a : 0x00 sii3112_write bmdma: write (size 1) 0x81 : 0x00 sii3112_write bmdma: write (size 1) 0x82 : 0x00 sii3112_write bmdma: write (size 1) 0x83 : 0x00 sii3112_write bmdma: write (size 1) 0x84
Re: Emulating Solaris 10 on SPARC64 sun4u
On 05/02/2020 06:31, jasper.low...@bt.com wrote:
> 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: 53e8b066f7f250ce2fd2cef063f8072b
>
>
>
> I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
>
>
>
> The command I am using to run QEMU is:
>
> ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios
> ./openbios/obj-sparc64/openbios-builtin.elf -cdrom
> ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G
>
>
>
> ```
>
> CPUs: 1 x SUNW,UltraSPARC-IIi
>
> UUID: ----
>
> Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
>
> Type 'help' for detailed information
>
> Trying cdrom:f...
>
> Not a bootable ELF image
>
> Not a bootable a.out image
>
>
>
> Loading FCode image...
>
> Loaded 7420 bytes
>
> entry point is 0x4000
>
> Evaluating FCode...
>
> Evaluating FCode...
>
> Ignoring failed claim for va 100 memsz af6d6!
>
> Ignoring failed claim for va 1402000 memsz 4dcc8!
>
> Ignoring failed claim for va 180 memsz 510c8!
>
> SunOS Release 5.10 Version Generic_147147-26 64-bit
>
> Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
>
> could not find debugger-vocabulary-hook>threads:interpret: exception -13
> caught
>
> interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
>
> \ All rights reserved.
>
> \
>
> \ ident "@(#)data64.fth 1.3 00/07/17 SMI"
>
>
>
> hex
>
>
>
> only forth also definitions
>
> vocabulary kdbg-words
>
> also kdbg-words definitions
>
>
>
> defer p@
>
> defer p!
>
> ['] x@ is p@
>
> ['] x! is p!
>
>
>
> 8 constant ptrsize
>
>
>
> d# 32 constant nbitsminor
>
> h# constant maxmin
>
> \
>
> \ Copyright 2008 Sun Microsystems, Inc. All rights reserved.
>
> \ Use is subject to license terms.
>
> \
>
>
>
> \ #pragma ident "@(#)kdbg.fth 1.20 08/06/06 SMI"
>
>
>
> h# 7ff constant v9bias
>
> h# unix-tte:interpret: exception -13 caught
>
> interpret ' unix-tte is va>tte-data failed with error ffed
>
> WARNING: consconfig: cannot find driver for screen device
> /pci@1fe,0/pci@1,1/QEMU,VGA@2
>
> Configuring devices.
>
> WARNING: Interrupt not seen after set_features
>
> Using RPC Bootparams for network configuration information.
>
> Attempting to configure interface hme0...
>
> WARNING: Power off requested from power button or SC, powering down the
> system!
>
> Skipped interface hme0
>
> svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs mount -a failed:
> one or
> more file systems failed to mount
>
> Serial console, reverting to text install
>
> Beginning system identification...
>
> Searching for configuration file(s)...
>
> Search complete.
>
> Discovering additional network configuration...
>
> ```
>
>
>
> The installation menu is shown after but the console is unresponsive.
>
>
>
> After some debugging, it looks like the QEMU front-end is correctly filling
>
> the serial receive buffer with characters, and then starts dropping them once
>
> the number of characters in the buffer reach the interrupt level. The
> interrupt
>
> level happens to be 1 when booting Solaris 10. This looks like normal
> behaviour
>
> to me.
>
>
>
> I started looking at why the serial receive buffer might not be consumed and
>
> considered that interrupts might not be being raised correctly. I ran with
>
> tracing and there were no interrupts for IRQ 0x2b like there are when using
>
> OpenBSD. When inspecting the registers of the serial device it looks like the
>
> Interrupt Enable Register is set to zero.
>
>
>
> If Solaris 10 was using the device is polling mode, it should be reading the
> RBR
>
> or at least the LSR. When tracing serial_ioport_read and serial_ioport_write,
>
> once the menu is hit, I don't see any read or writes to the serial device
>
> registers despite me trying to send characters and use the menu.
>
>
>
> The driver Solaris 10 is using for the device appears to be similar/same as
>
> /usr/src/uts/sun4/io/su_driver.c in the OpenSolaris code found at
> https://github.com/nxmirrors/onnv.
>
>
>
> ```
>
> asy->asy_hwtype = ASY16550AF;
>
> OUTB(FIFOR, 0x00); /* clear fifo register */
>
> asy->asy_trig_level = 0x00; /* sets the fifo Threshold to 1 */
>
>
>
> /* set/Enable FIFO */
>
> OUTB(FIFOR, FIFO_ON | FIFODMA | FIFOTXFLSH | FIFORXFLSH |
>
> (asy->asy_trig_level & 0xff));
>
>
>
> if ((INB(ISR) & 0xc0) == 0xc0)
>
> asy->asy_use_fifo = FIFO_ON; /* QEMU REACHES HERE. */
>
> else {
>
> asy->asy_hwtype = ASY8250;
>
> OUTB(FIFOR, 0x00); /* NO FIFOs */
>
> asy->asy_trig_level = 0;
>
> }
>
> ```
>
>
>
> From what I can tell when tracing
RE: Emulating Solaris 10 on SPARC64 sun4u
Hello, On Fri, 7 Feb 2020, jasper.low...@bt.com wrote: 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 behaviour of Solaris 10 does make me think there is a problem with interrupts but OpenBSD works just fine on this architecture. Not sure if my problem I see on other machine emulation I'm working on is related at all but there's a possibility it might be. I got this with different arch (ppc but could also reproduce something similar with mips) and ide controller emulation (via-ide) but the PCI bmdma code is shared by CMD646, via-ide and sii3112 and also the ide-cdrom emulation is the same so if there's a bug in these that could cause similar problems for different components. Or it could be that we get similar symptoms due to different reasons in which case sorry for the distracion but maybe we can learn from the experience of each other even in that case. What I get is tracked here: https://osdn.net/projects/qmiga/ticket/38949 (background on emulated machine: https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 ) Originally I had both Linux and MorphOS fail after enabling BMDMA before I had interrupt controller emulation (so that means it could be a problem with that in your case as well so something to check). Now that I've implemented interrupts Linux boots with DMA from CDROM but MorphOS is still not happy. You saw OpenBSD work but Solaris not so that could be similar in case the drivers do something differently or one relies on something the other does not care about. It could also be that since Linux is working, BMDMA and/or ide-cdrom may not emulate something other drivers may need which could cause simlar problems on multiple archs/emulations but I could be wrong about that. An advice I got before to debug this is to try enabling ide traces: https://lists.nongnu.org/archive/html/qemu-devel/2019-03/msg05656.html I've tried that but lacking detailed knowledge about ide controllers I could not make much sense of the results so far. Not sure how much help this is but maybe if more people are looking at it we might find something out. I've cc'd the IDE maintainer in case he has something more useful to add. Regards, BALATON Zoltan I've also tried using kmdb (Solaris kernel debugger) by running using `boot cdrom -kvd` at the OpenBIOS prompt. I thought this might help diagnose the problem. After the kernel debugger prompt occurs and I type `::cont` to continue, the system hangs completely. Thanks, Lowell. -Original Message- From: Dr. David Alan Gilbert Sent: Thursday, 6 February 2020 4:33 AM To: Lowell,J,Jasper,VIM R Cc: qemu-devel@nongnu.org; mark.cave-ayl...@ilande.co.uk; atar4q...@gmail.com Subject: Re: Emulating Solaris 10 on SPARC64 sun4u * jasper.low...@bt.com (jasper.low...@bt.com) wrote: 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: 53e8b066f7f250ce2fd2cef063f8072b I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158. The command I am using to run QEMU is: ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios ./openbios/obj-sparc64/openbios-builtin.elf -cdrom ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G ``` CPUs: 1 x SUNW,UltraSPARC-IIi UUID: ---- Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15 Type 'help' for detailed information Trying cdrom:f... Not a bootable ELF image Not a bootable a.out image Loading FCode image... Loaded 7420 bytes entry point is 0x4000 Evaluating FCode... Evaluating FCode... Ignoring failed claim for va 100 memsz af6d6! Ignoring failed claim for va 1402000 memsz 4dcc8! Ignoring failed claim for va 180 memsz 510c8! SunOS Release 5.10 Version Generic_147147-26 64-bit Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved. could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc. \ All rights reserved. \ \ ident "@(#)data64.fth 1.3 00/07/17 SMI" hex only forth also definitions vocabulary kdbg-words also kdbg-words definitions defer p@ defer p! ['] x@ is p@ ['] x! is p! 8 constant ptrsize d# 32 constant nbitsminor h# constant maxmin \ \ Copyright 2008 Sun Microsystems, Inc. All rights reserved. \ Use is subject to license terms. \ \ #pragma ident "@(#)kdbg.fth1.2008/06/06 SMI" h# 7ff constant v9bias h# unix-tte:interpret: exception -13 caught interpret ' unix-tte is va>tte-data failed with erro
RE: Emulating Solaris 10 on SPARC64 sun4u
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 behaviour of Solaris 10 does make me think there is a problem with interrupts but OpenBSD works just fine on this architecture. I've also tried using kmdb (Solaris kernel debugger) by running using `boot cdrom -kvd` at the OpenBIOS prompt. I thought this might help diagnose the problem. After the kernel debugger prompt occurs and I type `::cont` to continue, the system hangs completely. Thanks, Lowell. -Original Message- From: Dr. David Alan Gilbert Sent: Thursday, 6 February 2020 4:33 AM To: Lowell,J,Jasper,VIM R Cc: qemu-devel@nongnu.org; mark.cave-ayl...@ilande.co.uk; atar4q...@gmail.com Subject: Re: Emulating Solaris 10 on SPARC64 sun4u * jasper.low...@bt.com (jasper.low...@bt.com) wrote: > 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: 53e8b066f7f250ce2fd2cef063f8072b > > I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158. > > The command I am using to run QEMU is: > ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios > ./openbios/obj-sparc64/openbios-builtin.elf -cdrom > ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G > > ``` > CPUs: 1 x SUNW,UltraSPARC-IIi > UUID: ---- > Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15 > Type 'help' for detailed information Trying cdrom:f... > Not a bootable ELF image > Not a bootable a.out image > > Loading FCode image... > Loaded 7420 bytes > entry point is 0x4000 > Evaluating FCode... > Evaluating FCode... > Ignoring failed claim for va 100 memsz af6d6! > Ignoring failed claim for va 1402000 memsz 4dcc8! > Ignoring failed claim for va 180 memsz 510c8! > SunOS Release 5.10 Version Generic_147147-26 64-bit Copyright (c) > 1983, 2013, Oracle and/or its affiliates. All rights reserved. > could not find debugger-vocabulary-hook>threads:interpret: exception > -13 caught interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc. > \ All rights reserved. > \ > \ ident "@(#)data64.fth 1.3 00/07/17 SMI" > > hex > > only forth also definitions > vocabulary kdbg-words > also kdbg-words definitions > > defer p@ > defer p! > ['] x@ is p@ > ['] x! is p! > > 8 constant ptrsize > > d# 32 constant nbitsminor > h# constant maxmin > \ > \ Copyright 2008 Sun Microsystems, Inc. All rights reserved. > \ Use is subject to license terms. > \ > > \ #pragma ident "@(#)kdbg.fth1.2008/06/06 SMI" > > h# 7ff constant v9bias > h# unix-tte:interpret: exception -13 caught interpret ' unix-tte is > va>tte-data failed with error ffed > WARNING: consconfig: cannot find driver for screen device > /pci@1fe,0/pci@1,1/QEMU,VGA@2 Configuring devices. > WARNING: Interrupt not seen after set_features GIven that your problem below is looking like an interrupt related problem, have you figured out where that's coming from? Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: Emulating Solaris 10 on SPARC64 sun4u
* jasper.low...@bt.com (jasper.low...@bt.com) wrote: > 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: 53e8b066f7f250ce2fd2cef063f8072b > > I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158. > > The command I am using to run QEMU is: > ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios > ./openbios/obj-sparc64/openbios-builtin.elf -cdrom > ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G > > ``` > CPUs: 1 x SUNW,UltraSPARC-IIi > UUID: ---- > Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15 > Type 'help' for detailed information > Trying cdrom:f... > Not a bootable ELF image > Not a bootable a.out image > > Loading FCode image... > Loaded 7420 bytes > entry point is 0x4000 > Evaluating FCode... > Evaluating FCode... > Ignoring failed claim for va 100 memsz af6d6! > Ignoring failed claim for va 1402000 memsz 4dcc8! > Ignoring failed claim for va 180 memsz 510c8! > SunOS Release 5.10 Version Generic_147147-26 64-bit > Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved. > could not find debugger-vocabulary-hook>threads:interpret: exception -13 > caught > interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc. > \ All rights reserved. > \ > \ ident "@(#)data64.fth 1.3 00/07/17 SMI" > > hex > > only forth also definitions > vocabulary kdbg-words > also kdbg-words definitions > > defer p@ > defer p! > ['] x@ is p@ > ['] x! is p! > > 8 constant ptrsize > > d# 32 constant nbitsminor > h# constant maxmin > \ > \ Copyright 2008 Sun Microsystems, Inc. All rights reserved. > \ Use is subject to license terms. > \ > > \ #pragma ident "@(#)kdbg.fth1.2008/06/06 SMI" > > h# 7ff constant v9bias > h# unix-tte:interpret: exception -13 caught > interpret ' unix-tte is va>tte-data failed with error ffed > WARNING: consconfig: cannot find driver for screen device > /pci@1fe,0/pci@1,1/QEMU,VGA@2 > Configuring devices. > WARNING: Interrupt not seen after set_features GIven that your problem below is looking like an interrupt related problem, have you figured out where that's coming from? Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Emulating Solaris 10 on SPARC64 sun4u
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: 53e8b066f7f250ce2fd2cef063f8072b
I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
The command I am using to run QEMU is:
./qemu/sparc64-softmmu/qemu-system-sparc64 -bios
./openbios/obj-sparc64/openbios-builtin.elf -cdrom
./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G
```
CPUs: 1 x SUNW,UltraSPARC-IIi
UUID: ----
Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
Type 'help' for detailed information
Trying cdrom:f...
Not a bootable ELF image
Not a bootable a.out image
Loading FCode image...
Loaded 7420 bytes
entry point is 0x4000
Evaluating FCode...
Evaluating FCode...
Ignoring failed claim for va 100 memsz af6d6!
Ignoring failed claim for va 1402000 memsz 4dcc8!
Ignoring failed claim for va 180 memsz 510c8!
SunOS Release 5.10 Version Generic_147147-26 64-bit
Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught
interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
\ All rights reserved.
\
\ ident "@(#)data64.fth 1.3 00/07/17 SMI"
hex
only forth also definitions
vocabulary kdbg-words
also kdbg-words definitions
defer p@
defer p!
['] x@ is p@
['] x! is p!
8 constant ptrsize
d# 32 constant nbitsminor
h# constant maxmin
\
\ Copyright 2008 Sun Microsystems, Inc. All rights reserved.
\ Use is subject to license terms.
\
\ #pragma ident "@(#)kdbg.fth1.2008/06/06 SMI"
h# 7ff constant v9bias
h# unix-tte:interpret: exception -13 caught
interpret ' unix-tte is va>tte-data failed with error ffed
WARNING: consconfig: cannot find driver for screen device
/pci@1fe,0/pci@1,1/QEMU,VGA@2
Configuring devices.
WARNING: Interrupt not seen after set_features
Using RPC Bootparams for network configuration information.
Attempting to configure interface hme0...
WARNING: Power off requested from power button or SC, powering down the system!
Skipped interface hme0
svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs mount -a failed:
one or more file systems failed to mount
Serial console, reverting to text install
Beginning system identification...
Searching for configuration file(s)...
Search complete.
Discovering additional network configuration...
```
The installation menu is shown after but the console is unresponsive.
After some debugging, it looks like the QEMU front-end is correctly filling
the serial receive buffer with characters, and then starts dropping them once
the number of characters in the buffer reach the interrupt level. The interrupt
level happens to be 1 when booting Solaris 10. This looks like normal behaviour
to me.
I started looking at why the serial receive buffer might not be consumed and
considered that interrupts might not be being raised correctly. I ran with
tracing and there were no interrupts for IRQ 0x2b like there are when using
OpenBSD. When inspecting the registers of the serial device it looks like the
Interrupt Enable Register is set to zero.
If Solaris 10 was using the device is polling mode, it should be reading the RBR
or at least the LSR. When tracing serial_ioport_read and serial_ioport_write,
once the menu is hit, I don't see any read or writes to the serial device
registers despite me trying to send characters and use the menu.
The driver Solaris 10 is using for the device appears to be similar/same as
/usr/src/uts/sun4/io/su_driver.c in the OpenSolaris code found at
https://github.com/nxmirrors/onnv.
```
asy->asy_hwtype = ASY16550AF;
OUTB(FIFOR, 0x00); /* clear fifo register */
asy->asy_trig_level = 0x00; /* sets the fifo Threshold to 1 */
/* set/Enable FIFO */
OUTB(FIFOR, FIFO_ON | FIFODMA | FIFOTXFLSH | FIFORXFLSH |
(asy->asy_trig_level & 0xff));
if ((INB(ISR) & 0xc0) == 0xc0)
asy->asy_use_fifo = FIFO_ON; /* QEMU REACHES HERE. */
else {
asy->asy_hwtype = ASY8250;
OUTB(FIFOR, 0x00); /* NO FIFOs */
asy->asy_trig_level = 0;
}
```
>From what I can tell when tracing serial_ioport_write and serial_ioport_read,
Solaris 10 correctly identifies the serial device and successfully attaches it.
In the asyattach function (OpenSolaris driver), interrupts are disabled by
zeroing the
Interrupt Enable Register. From what I'm reading in OpenSolaris source code,
interrupts
are reenabled when the device is "opened". This seems like consistent and
correct behaviour though I'm not sure why the device is not being opened to be
used by the serial console.
Is this an issue anyone else has tried to debug?
Are there any leads that I can follow up on for why the serial console becomes
unresponsive
on Solaris 10?
Thanks,
Lowell.
