Hi Nick,
Thanks again for testing this. The issue with Solaris not detecting the disks is a known one - the following guide should point you in the right direction:
http://virtuallyfun.blogspot.com/2010/10/formatting-disks-for-solaris.html
Also don't forget the "set scsi_options" part from Artyom's SPARC/QEMU howto here: http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html
I think it may actually be possible to come up with a patch for OpenBIOS so that the scsi_options change isn't required - let me know how you get on with the above links, and if it all seems to work I'll look at creating the patch for you.
Okay, I got passed the issue with formatting the root filesystem. Apparently there are some limitations on the C/H/S parameters you use for the disk that correspond with how UFS wants to format a new filesystem. I'm not sure what exactly those limitations are at this point, but, by adjusting a couple of the C/H/S settings when using format to set up the disk I was able to get it to work correctly. So, I now have Solaris 9 installed on qemu-system-sparc with OpenBIOS! I'll probably go back to Solaris 8 as that one has a free binary license while Solaris 9 is a commercial license, IIRC. I do own a Solaris 9 commercial license, but I like the free idea, better.
Anyway, now I'm on to an issue with networking - I've used the following two qemu network parameter combinations: -net nic -net tap,ifname=tap0 -net nic -net user
In the first instance, tap0 was configured on my Linux box and added to my bridge br0. In both cases the Solaris system is unable to obtain a DHCP address - the DHCP client times out. Not sure if I should be using a different parameter set, or if this is another area that needs some work either for OpenBIOS or qemu?
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
On 24/04/11 00:17, Nick Couchman wrote:
Okay, I got passed the issue with formatting the root filesystem. Apparently there are some limitations on the C/H/S parameters you use for the disk that correspond with how UFS wants to format a new filesystem. I'm not sure what exactly those limitations are at this point, but, by adjusting a couple of the C/H/S settings when using format to set up the disk I was able to get it to work correctly. So, I now have Solaris 9 installed on qemu-system-sparc with OpenBIOS! I'll probably go back to Solaris 8 as that one has a free binary license while Solaris 9 is a commercial license, IIRC. I do own a Solaris 9 commercial license, but I like the free idea, better.
Awesome! If you can make a note of what you had to do in order to get it to work and post it to the list, I'm sure lots of people will be very grateful :)
Anyway, now I'm on to an issue with networking - I've used the following two qemu network parameter combinations: -net nic -net tap,ifname=tap0 -net nic -net user
In the first instance, tap0 was configured on my Linux box and added to my bridge br0. In both cases the Solaris system is unable to obtain a DHCP address - the DHCP client times out. Not sure if I should be using a different parameter set, or if this is another area that needs some work either for OpenBIOS or qemu?
Okay - I missed this as when I was stepping through the installer I didn't bother with any of the networking stuff. However there is definitely a bug here - running tcpdump on the bridge interface shows data packets with junk in them rather than a proper DHCP request, so I'm wondering if OpenBIOS doesn't initialise something in the NIC correctly? Or maybe it's another alignment issue with the the LANCE buffers?
Anyway, I'll take a look but it may take me a little time to figure out what's going on.
ATB,
Mark.
On Sun, Apr 24, 2011 at 4:39 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
On 24/04/11 00:17, Nick Couchman wrote:
Okay, I got passed the issue with formatting the root filesystem. Apparently there are some limitations on the C/H/S parameters you use for the disk that correspond with how UFS wants to format a new filesystem. I'm not sure what exactly those limitations are at this point, but, by adjusting a couple of the C/H/S settings when using format to set up the disk I was able to get it to work correctly. So, I now have Solaris 9 installed on qemu-system-sparc with OpenBIOS! I'll probably go back to Solaris 8 as that one has a free binary license while Solaris 9 is a commercial license, IIRC. I do own a Solaris 9 commercial license, but I like the free idea, better.
Awesome! If you can make a note of what you had to do in order to get it to work and post it to the list, I'm sure lots of people will be very grateful :)
Anyway, now I'm on to an issue with networking - I've used the following two qemu network parameter combinations: -net nic -net tap,ifname=tap0 -net nic -net user
Never used the tap device, but -net nic -net user definitely works with OBP.
In the first instance, tap0 was configured on my Linux box and added to my bridge br0. In both cases the Solaris system is unable to obtain a DHCP address - the DHCP client times out. Not sure if I should be using a different parameter set, or if this is another area that needs some work either for OpenBIOS or qemu?
Okay - I missed this as when I was stepping through the installer I didn't bother with any of the networking stuff. However there is definitely a bug here - running tcpdump on the bridge interface shows data packets with junk in them rather than a proper DHCP request, so I'm wondering if OpenBIOS doesn't initialise something in the NIC correctly? Or maybe it's another alignment issue with the the LANCE buffers?
What about properties/attributes? Are they the same as in OBP?
Anyway, I'll take a look but it may take me a little time to figure out what's going on.
On Sun, Apr 24, 2011 at 1:17 AM, Nick Couchman Nick.Couchman@seakr.com wrote:
So, I now have Solaris 9 installed on qemu-system-sparc with OpenBIOS!
Can you tell what Solaris 9 version did you use (CD/DVD and the patch level in the greeting message) and what is your host? I tried a Solaris 9 DVD on a Linux x86_64 host, but it hangs after the serial ports initialization.
On 11/05/11 19:48, Artyom Tarasenko wrote:
Can you tell what Solaris 9 version did you use (CD/DVD and the patch level in the greeting message) and what is your host? I tried a Solaris 9 DVD on a Linux x86_64 host, but it hangs after the serial ports initialization.
Just a total stab in the dark but does the following OpenBIOS image solve the issue with Solaris 9 at all?
http://www.siriusit.co.uk/tmp/openbios-sparc32.artyom
ATB,
Mark.
On Fri, May 13, 2011 at 9:14 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
On 11/05/11 19:48, Artyom Tarasenko wrote:
Can you tell what Solaris 9 version did you use (CD/DVD and the patch level in the greeting message) and what is your host? I tried a Solaris 9 DVD on a Linux x86_64 host, but it hangs after the serial ports initialization.
Just a total stab in the dark but does the following OpenBIOS image solve the issue with Solaris 9 at all?
No difference, sorry. After talking to Nick it looks like
- the very first Solaris 9 release (Generic) can be installed - the last Solaris 9 release (Generic_118558-34) hangs under OpenBIOS.
HTH Artyom
On 13/05/11 23:10, Artyom Tarasenko wrote:
Just a total stab in the dark but does the following OpenBIOS image solve the issue with Solaris 9 at all?
No difference, sorry. After talking to Nick it looks like
- the very first Solaris 9 release (Generic) can be installed
- the last Solaris 9 release (Generic_118558-34) hangs under OpenBIOS.
That's a shame. I don't have a suitable copy of 32-bit Solaris around to look into this :(
ATB,
Mark.
On 05/13/11 05:10 PM, Artyom Tarasenko wrote:
On Fri, May 13, 2011 at 9:14 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
On 11/05/11 19:48, Artyom Tarasenko wrote:
Can you tell what Solaris 9 version did you use (CD/DVD and the patch level in the greeting message) and what is your host? I tried a Solaris 9 DVD on a Linux x86_64 host, but it hangs after the serial ports initialization.
Just a total stab in the dark but does the following OpenBIOS image solve the issue with Solaris 9 at all?
No difference, sorry. After talking to Nick it looks like
- the very first Solaris 9 release (Generic) can be installed
- the last Solaris 9 release (Generic_118558-34) hangs under OpenBIOS.
HTH Artyom
My Solaris 9 04/04 image seems to hang in the same spot:
Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 30 2011 02:11 Type 'help' for detailed information Trying disk... No valid state has been set by load or init-program
0 > boot cd:d -k -v -s Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 0x45c9f+0xdaf1+0x1d6a7 Bytes SunOS Release 5.9 Version Generic_112233-12 32-bit Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Ethernet address = 52:54:0:12:34:56 Using default device instance data vac: enabled in write through mode mem = 131072K (0x8000000) avail mem = 108797952 root nexus = SUNW,SPARCstation-5 iommu0 at root: obio 0x10000000 sbus0 at iommu0: obio 0x10001000 dma0 at sbus0: SBus slot 5 0x8400000 dma0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 (esp0): esp-options=0x46 esp0 at dma0: SBus slot 5 0x8800000 sparc ipl 4 esp0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 sd2 at esp0: target 2 lun 0 sd2 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0 root on /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:b fstype ufs obio0 at root obio0 at obio0: obio 0x100000, sparc ipl 12 zs0 is /obio/zs@0,100000 obio1 at obio0: obio 0x0, sparc ipl 12 zs1 is /obio/zs@0,0 cpu0: FMI,MB86904 (mid 0 impl 0x0 ver 0x5 clock 170 MHz) Configuring /dev and /devices pseudo-device: devinfo0 devinfo0 is /pseudo/devinfo@0 tcx0 at sbus0: SBus slot 3 0x800000 and SBus slot 3 0x2000000 and SBus slot 3 0x4000000 and SBus slot 3 0x6000000 and SBus slot 3 0xa000000 and SBus slot 3 0xc000000 and SBus slot 3 0xe000000 and SBus slot 3 0x700000 and SBus slot 3 0x200000 and SBus slot 3 0x300000 and SBus slot 3 0x0 and SBus slot 3 0x240000 and SBus slot 3 0x280000 SBus level 5 sparc ipl 9 tcx0 is /iommu@0,10000000/sbus@0,10001000/SUNW,tcx@3,800000 tcx0: revision 0, screen 1024x768 ledma0 at sbus0: SBus slot 5 0x8400010 le0 at ledma0: SBus slot 5 0x8c00000 sparc ipl 6 le0 is /iommu@0,10000000/sbus@0,10001000/ledma@5,8400010/le@5,8c00000 pseudo-device: fssnap0 fssnap0 is /pseudo/fssnap@0 sbusmem0 at sbus0: SBus slot 0 0x0 sbusmem0 is /iommu@0,10000000/sbus@0,10001000/sbusmem@0,0 sbusmem1 at sbus0: SBus slot 1 0x0 sbusmem1 is /iommu@0,10000000/sbus@0,10001000/sbusmem@1,0 sbusmem2 at sbus0: SBus slot 2 0x0 sbusmem2 is /iommu@0,10000000/sbus@0,10001000/sbusmem@2,0 sbusmem3 at sbus0: SBus slot 3 0x0 sbusmem3 is /iommu@0,10000000/sbus@0,10001000/sbusmem@3,0 sbusmem4 at sbus0: SBus slot 4 0x0 sbusmem4 is /iommu@0,10000000/sbus@0,10001000/sbusmem@4,0 sbusmem5 at sbus0: SBus slot 5 0x0 sbusmem5 is /iommu@0,10000000/sbus@0,10001000/sbusmem@5,0 pseudo-device: ramdisk1024 ramdisk1024 is /pseudo/ramdisk@1024 pseudo-device: winlock0 winlock0 is /pseudo/winlock@0 pseudo-device: lockstat0 lockstat0 is /pseudo/lockstat@0 pseudo-device: llc10 llc10 is /pseudo/llc1@0 pseudo-device: lofi0 lofi0 is /pseudo/lofi@0 pseudo-device: fcp0 fcp0 is /pseudo/fcp@0 NOTICE: Couldn't set value (../../sun/io/audio/sada/drv/audiocs/audio_4231.c, Line #1759 0x00 0x88) audio may not work correctly until it is stopped and restarted audiocs0 at sbus0: SBus slot 4 0xc000000 SBus level 5 sparc ipl 9 audiocs0 is /iommu@0,10000000/sbus@0,10001000/SUNW,CS4231@4,c000000
Not having anything to compare to, are the tcx0 and sbusmem entries correct?
Nathan
On 06/06/11 04:37, Nathan Kunkee wrote:
My Solaris 9 04/04 image seems to hang in the same spot:
Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 30 2011 02:11 Type 'help' for detailed information Trying disk... No valid state has been set by load or init-program
0 > boot cd:d -k -v -s Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 0x45c9f+0xdaf1+0x1d6a7 Bytes SunOS Release 5.9 Version Generic_112233-12 32-bit Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Ethernet address = 52:54:0:12:34:56 Using default device instance data vac: enabled in write through mode mem = 131072K (0x8000000) avail mem = 108797952 root nexus = SUNW,SPARCstation-5 iommu0 at root: obio 0x10000000 sbus0 at iommu0: obio 0x10001000 dma0 at sbus0: SBus slot 5 0x8400000 dma0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 (esp0): esp-options=0x46 esp0 at dma0: SBus slot 5 0x8800000 sparc ipl 4 esp0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 sd2 at esp0: target 2 lun 0 sd2 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0 root on /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:b fstype ufs obio0 at root obio0 at obio0: obio 0x100000, sparc ipl 12 zs0 is /obio/zs@0,100000 obio1 at obio0: obio 0x0, sparc ipl 12 zs1 is /obio/zs@0,0 cpu0: FMI,MB86904 (mid 0 impl 0x0 ver 0x5 clock 170 MHz) Configuring /dev and /devices pseudo-device: devinfo0 devinfo0 is /pseudo/devinfo@0 tcx0 at sbus0: SBus slot 3 0x800000 and SBus slot 3 0x2000000 and SBus slot 3 0x4000000 and SBus slot 3 0x6000000 and SBus slot 3 0xa000000 and SBus slot 3 0xc000000 and SBus slot 3 0xe000000 and SBus slot 3 0x700000 and SBus slot 3 0x200000 and SBus slot 3 0x300000 and SBus slot 3 0x0 and SBus slot 3 0x240000 and SBus slot 3 0x280000 SBus level 5 sparc ipl 9 tcx0 is /iommu@0,10000000/sbus@0,10001000/SUNW,tcx@3,800000 tcx0: revision 0, screen 1024x768 ledma0 at sbus0: SBus slot 5 0x8400010 le0 at ledma0: SBus slot 5 0x8c00000 sparc ipl 6 le0 is /iommu@0,10000000/sbus@0,10001000/ledma@5,8400010/le@5,8c00000 pseudo-device: fssnap0 fssnap0 is /pseudo/fssnap@0 sbusmem0 at sbus0: SBus slot 0 0x0 sbusmem0 is /iommu@0,10000000/sbus@0,10001000/sbusmem@0,0 sbusmem1 at sbus0: SBus slot 1 0x0 sbusmem1 is /iommu@0,10000000/sbus@0,10001000/sbusmem@1,0 sbusmem2 at sbus0: SBus slot 2 0x0 sbusmem2 is /iommu@0,10000000/sbus@0,10001000/sbusmem@2,0 sbusmem3 at sbus0: SBus slot 3 0x0 sbusmem3 is /iommu@0,10000000/sbus@0,10001000/sbusmem@3,0 sbusmem4 at sbus0: SBus slot 4 0x0 sbusmem4 is /iommu@0,10000000/sbus@0,10001000/sbusmem@4,0 sbusmem5 at sbus0: SBus slot 5 0x0 sbusmem5 is /iommu@0,10000000/sbus@0,10001000/sbusmem@5,0 pseudo-device: ramdisk1024 ramdisk1024 is /pseudo/ramdisk@1024 pseudo-device: winlock0 winlock0 is /pseudo/winlock@0 pseudo-device: lockstat0 lockstat0 is /pseudo/lockstat@0 pseudo-device: llc10 llc10 is /pseudo/llc1@0 pseudo-device: lofi0 lofi0 is /pseudo/lofi@0 pseudo-device: fcp0 fcp0 is /pseudo/fcp@0 NOTICE: Couldn't set value (../../sun/io/audio/sada/drv/audiocs/audio_4231.c, Line #1759 0x00 0x88) audio may not work correctly until it is stopped and restarted audiocs0 at sbus0: SBus slot 4 0xc000000 SBus level 5 sparc ipl 9 audiocs0 is /iommu@0,10000000/sbus@0,10001000/SUNW,CS4231@4,c000000
Not having anything to compare to, are the tcx0 and sbusmem entries correct?
Oh that's interesting - I always thought that the hangs were being caused by OpenBIOS reporting 4 CPUs by default whilst QEMU only provides 1. But this trace strongly points towards the audio driver being the culprit instead.
(goes and reads the QEMU source)
Hmmm it looks from reading the source code that QEMU doesn't actually implement a proper audio device for SS-5 at all but merely provides a dummy device with an empty mapped region. In that case it may be possible to provide a simple mapping in OpenBIOS to match the one in QEMU which may be enough to persuade Solaris to boot.
ATB,
Mark.
Hmmm it looks from reading the source code that QEMU doesn't actually implement a proper audio device for SS-5 at all but merely provides a dummy device with an empty mapped region. In that case it may be possible to provide a simple mapping in OpenBIOS to match the one in QEMU which may be enough to persuade Solaris to boot.
Ugh. I recall that audio chip being non-trivial...
It might be worth deleting that audio device from the device tree and see if Solaris really does get further.
Date: Mon, 6 Jun 2011 15:54:39 -0400 From: tarl-b2@tarl.net To: openbios@openbios.org Subject: Re: [OpenBIOS] Solaris anyone?
Hmmm it looks from reading the source code that QEMU doesn't actually implement a proper audio device for SS-5 at all but merely provides a dummy device with an empty mapped region. In that case it may be possible to provide a simple mapping in OpenBIOS to match the one in QEMU which may be enough to persuade Solaris to boot.
Ugh. I recall that audio chip being non-trivial...
It might be worth deleting that audio device from the device tree and see if Solaris really does get further.
I've tried the same CD image with the SS-10 QEMU machine, which seems to lack the audio device, and I still hang. I get the first part of the kernel, no extra logging, and then the spinner to infinity...
nathan@xanth:/usr/local/build/qemu$ sparc-softmmu/qemu-system-sparc -bios openbios-builtin.elf -M SS-10 -cdrom /local/storage/ISO/solaris-9-sparc-d1.iso -nographic
Configuration device id QEMU version 1 machine id 64 CPUs: 1 x TI,TMS390Z55 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 30 2011 02:11 Type 'help' for detailed information Trying disk... No valid state has been set by load or init-program
0 > boot cd:d -k -v Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 0x45c9f+0xdaf1+0x1d6a7 Bytes SunOS Release 5.9 Version Generic_112233-12 32-bit Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Ethernet address = 52:54:0:12:34:56 Using default device instance data \
Does anyone know what loads on a real SS after the audio device?
Nathan
Nathan Kunkee wrote:
Date: Mon, 6 Jun 2011 15:54:39 -0400 From: tarl-b2@tarl.net To: openbios@openbios.org Subject: Re: [OpenBIOS] Solaris anyone?
Hmmm it looks from reading the source code that QEMU doesn't actually implement a proper audio device for SS-5 at all but merely provides a dummy device with an empty mapped region. In that case it may be possible to provide a simple mapping in OpenBIOS to match the one in QEMU which may be enough to persuade Solaris to boot.
Ugh. I recall that audio chip being non-trivial...
It might be worth deleting that audio device from the device tree and see if Solaris really does get further.
I've tried the same CD image with the SS-10 QEMU machine, which seems to lack the audio device, and I still hang. I get the first part of the kernel, no extra logging, and then the spinner to infinity...
nathan@xanth:/usr/local/build/qemu$ sparc-softmmu/qemu-system-sparc -bios openbios-builtin.elf -M SS-10 -cdrom /local/storage/ISO/solaris-9-sparc-d1.iso -nographic
Configuration device id QEMU version 1 machine id 64 CPUs: 1 x TI,TMS390Z55 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 30 2011 02:11 Type 'help' for detailed information Trying disk... No valid state has been set by load or init-program
0 > boot cd:d -k -v Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 0x45c9f+0xdaf1+0x1d6a7 Bytes SunOS Release 5.9 Version Generic_112233-12 32-bit Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Ethernet address = 52:54:0:12:34:56 Using default device instance data \
Does anyone know what loads on a real SS after the audio device?
Nathan
For this hang, Solaris is stuck trying to set and verify a bit which is currently un-settable in qemu. It's the MMU breakpoint action register (asi 0x4c), and if bit 12 is set, then it should continue on just like with SS-5. After fcp0, the next thing Solaris should initialize is the network:
pseudo-device: fcp0 fcp0 is /pseudo/fcp@0 Using RPC Bootparams for network configuration information. le0: No carrier - cable disconnected or hub link test disabled? le0: No carrier - cable disconnected or hub link test disabled? Skipping interface le0
Bob
On Mon, Jun 13, 2011 at 2:06 AM, Bob Breuer breuerr@mc.net wrote:
Nathan Kunkee wrote:
Date: Mon, 6 Jun 2011 15:54:39 -0400 From: tarl-b2@tarl.net To: openbios@openbios.org Subject: Re: [OpenBIOS] Solaris anyone?
Hmmm it looks from reading the source code that QEMU doesn't actually implement a proper audio device for SS-5 at all but merely provides a dummy device with an empty mapped region. In that case it may be possible to provide a simple mapping in OpenBIOS to match the one in QEMU which may be enough to persuade Solaris to boot.
Ugh. I recall that audio chip being non-trivial...
It might be worth deleting that audio device from the device tree and see if Solaris really does get further.
I've tried the same CD image with the SS-10 QEMU machine, which seems to lack the audio device, and I still hang. I get the first part of the kernel, no extra logging, and then the spinner to infinity...
nathan@xanth:/usr/local/build/qemu$ sparc-softmmu/qemu-system-sparc -bios openbios-builtin.elf -M SS-10 -cdrom /local/storage/ISO/solaris-9-sparc-d1.iso -nographic
Configuration device id QEMU version 1 machine id 64 CPUs: 1 x TI,TMS390Z55 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 30 2011 02:11 Type 'help' for detailed information Trying disk... No valid state has been set by load or init-program
0 > boot cd:d -k -v Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 0x45c9f+0xdaf1+0x1d6a7 Bytes SunOS Release 5.9 Version Generic_112233-12 32-bit Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Ethernet address = 52:54:0:12:34:56 Using default device instance data \
Does anyone know what loads on a real SS after the audio device?
Nathan
For this hang, Solaris is stuck trying to set and verify a bit which is currently un-settable in qemu. It's the MMU breakpoint action register (asi 0x4c), and if bit 12 is set, then it should continue on just like with SS-5. After fcp0, the next thing Solaris should initialize is the network:
pseudo-device: fcp0 fcp0 is /pseudo/fcp@0 Using RPC Bootparams for network configuration information. le0: No carrier - cable disconnected or hub link test disabled? le0: No carrier - cable disconnected or hub link test disabled? Skipping interface le0
Would this (untested) patch to QEMU help?
diff --git a/target-sparc/cpu.h b/target-sparc/cpu.h index 320530e..b93fdfd 100644 --- a/target-sparc/cpu.h +++ b/target-sparc/cpu.h @@ -403,6 +403,7 @@ typedef struct CPUSPARCState { uint32_t mmuregs[32]; uint64_t mxccdata[4]; uint64_t mxccregs[8]; + uint64_t mmubpaction; uint64_t mmubpregs[4]; uint64_t prom_addr; #endif diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c index b38691e..1023870 100644 --- a/target-sparc/op_helper.c +++ b/target-sparc/op_helper.c @@ -1941,7 +1941,7 @@ uint64_t helper_ld_asi(target_ulong addr, int asi, int size, int sign) case 0x32: // Turbosparc page table descriptor diagnostic case 0x39: /* data cache diagnostic register */ case 0x4c: /* SuperSPARC MMU Breakpoint Action register */ - ret = 0; + ret = env->mmubpaction; break; case 0x38: /* SuperSPARC MMU Breakpoint Control Registers */ { @@ -2304,7 +2304,9 @@ void helper_st_asi(target_ulong addr, uint64_t val, int asi, int size) // descriptor diagnostic case 0x36: /* I-cache flash clear */ case 0x37: /* D-cache flash clear */ + break; case 0x4c: /* breakpoint action */ + env->mmubpaction = val; break; case 0x38: /* SuperSPARC MMU Breakpoint Control Registers*/ {
Blue Swirl wrote:
On Mon, Jun 13, 2011 at 2:06 AM, Bob Breuer breuerr@mc.net wrote:
Nathan Kunkee wrote:
Date: Mon, 6 Jun 2011 15:54:39 -0400 From: tarl-b2@tarl.net To: openbios@openbios.org Subject: Re: [OpenBIOS] Solaris anyone?
Hmmm it looks from reading the source code that QEMU doesn't actually implement a proper audio device for SS-5 at all but merely provides a dummy device with an empty mapped region. In that case it may be possible to provide a simple mapping in OpenBIOS to match the one in QEMU which may be enough to persuade Solaris to boot.
Ugh. I recall that audio chip being non-trivial...
It might be worth deleting that audio device from the device tree and see if Solaris really does get further.
I've tried the same CD image with the SS-10 QEMU machine, which seems to lack the audio device, and I still hang. I get the first part of the kernel, no extra logging, and then the spinner to infinity...
nathan@xanth:/usr/local/build/qemu$ sparc-softmmu/qemu-system-sparc -bios openbios-builtin.elf -M SS-10 -cdrom /local/storage/ISO/solaris-9-sparc-d1.iso -nographic
Configuration device id QEMU version 1 machine id 64 CPUs: 1 x TI,TMS390Z55 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 30 2011 02:11 Type 'help' for detailed information Trying disk... No valid state has been set by load or init-program
0 > boot cd:d -k -v Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 0x45c9f+0xdaf1+0x1d6a7 Bytes SunOS Release 5.9 Version Generic_112233-12 32-bit Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Ethernet address = 52:54:0:12:34:56 Using default device instance data \
Does anyone know what loads on a real SS after the audio device?
Nathan
For this hang, Solaris is stuck trying to set and verify a bit which is currently un-settable in qemu. It's the MMU breakpoint action register (asi 0x4c), and if bit 12 is set, then it should continue on just like with SS-5. After fcp0, the next thing Solaris should initialize is the network:
pseudo-device: fcp0 fcp0 is /pseudo/fcp@0 Using RPC Bootparams for network configuration information. le0: No carrier - cable disconnected or hub link test disabled? le0: No carrier - cable disconnected or hub link test disabled? Skipping interface le0
Would this (untested) patch to QEMU help?
It does work, but ...
diff --git a/target-sparc/cpu.h b/target-sparc/cpu.h index 320530e..b93fdfd 100644 --- a/target-sparc/cpu.h +++ b/target-sparc/cpu.h @@ -403,6 +403,7 @@ typedef struct CPUSPARCState { uint32_t mmuregs[32]; uint64_t mxccdata[4]; uint64_t mxccregs[8];
- uint64_t mmubpaction;
Looks like it's less than 64 bits:
ok 0 0 0 4c spaced! ok 0 4c spaced@ . . 0 0 ok 0 not dup 0 4c spaced! ok 0 4c spaced@ . . 0 1fff ok 0 4c spacel@ . 4 4c spacel@ . 1fff 1fff
Would it make sense to declare it as 32-bit, or just mask out the extra bits? or not even care since almost nobody writes to that register?
uint64_t mmubpregs[4]; uint64_t prom_addr;#endif diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c index b38691e..1023870 100644 --- a/target-sparc/op_helper.c +++ b/target-sparc/op_helper.c @@ -1941,7 +1941,7 @@ uint64_t helper_ld_asi(target_ulong addr, int asi, int size, int sign) case 0x32: // Turbosparc page table descriptor diagnostic case 0x39: /* data cache diagnostic register */ case 0x4c: /* SuperSPARC MMU Breakpoint Action register */
ret = 0;
ret = env->mmubpaction; break;
And here, 0x39 and above should still have the ret = 0.
case 0x38: /* SuperSPARC MMU Breakpoint Control Registers */ {@@ -2304,7 +2304,9 @@ void helper_st_asi(target_ulong addr, uint64_t val, int asi, int size) // descriptor diagnostic case 0x36: /* I-cache flash clear */ case 0x37: /* D-cache flash clear */
break;env->mmubpaction = val; break;
By the way, what would it take to get the space[cwLd] commands in OpenBIOS? They come in handy for verifying these asi accesses.
Bob
The Breakpoint ACTION Register ASI=0x4c is 64 bits wide but only 13 bits are used. The remainder are ignored on write and read as 0.
See page 15-11 of the SuperSPARC and MultiCache Controller User's Manual.
This manual was available on the sun website prior to the Oracle buy out. I have a paper copy and I may still have the PDF if someone really need it.
Robert Reif wrote:
The Breakpoint ACTION Register ASI=0x4c is 64 bits wide but only 13 bits are used. The remainder are ignored on write and read as 0.
See page 15-11 of the SuperSPARC and MultiCache Controller User's Manual.
This manual was available on the sun website prior to the Oracle buy out. I have a paper copy and I may still have the PDF if someone really need it.
Okay and it's also documented as 64 bits in the SuperSPARC II Addendum page A-45 (google for STP1021UG) with a similar 13 valid bits.
Still doesn't mean that we need to carry around about 50 bits of zeros just to match the documentation, when zero extending from a lower precision number will give the same result. In QEMU, the value will be correctly zero-extended, so it doesn't matter what is used internally.
Bob
On Tue, Jun 14, 2011 at 8:19 AM, Bob Breuer breuerr@mc.net wrote:
Blue Swirl wrote:
On Mon, Jun 13, 2011 at 2:06 AM, Bob Breuer breuerr@mc.net wrote:
Nathan Kunkee wrote:
Date: Mon, 6 Jun 2011 15:54:39 -0400 From: tarl-b2@tarl.net To: openbios@openbios.org Subject: Re: [OpenBIOS] Solaris anyone?
Hmmm it looks from reading the source code that QEMU doesn't actually implement a proper audio device for SS-5 at all but merely provides a dummy device with an empty mapped region. In that case it may be possible to provide a simple mapping in OpenBIOS to match the one in QEMU which may be enough to persuade Solaris to boot.
Ugh. I recall that audio chip being non-trivial...
It might be worth deleting that audio device from the device tree and see if Solaris really does get further.
I've tried the same CD image with the SS-10 QEMU machine, which seems to lack the audio device, and I still hang. I get the first part of the kernel, no extra logging, and then the spinner to infinity...
nathan@xanth:/usr/local/build/qemu$ sparc-softmmu/qemu-system-sparc -bios openbios-builtin.elf -M SS-10 -cdrom /local/storage/ISO/solaris-9-sparc-d1.iso -nographic
Configuration device id QEMU version 1 machine id 64 CPUs: 1 x TI,TMS390Z55 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 30 2011 02:11 Type 'help' for detailed information Trying disk... No valid state has been set by load or init-program
0 > boot cd:d -k -v Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 0x45c9f+0xdaf1+0x1d6a7 Bytes SunOS Release 5.9 Version Generic_112233-12 32-bit Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Ethernet address = 52:54:0:12:34:56 Using default device instance data \
Does anyone know what loads on a real SS after the audio device?
Nathan
For this hang, Solaris is stuck trying to set and verify a bit which is currently un-settable in qemu. It's the MMU breakpoint action register (asi 0x4c), and if bit 12 is set, then it should continue on just like with SS-5. After fcp0, the next thing Solaris should initialize is the network:
pseudo-device: fcp0 fcp0 is /pseudo/fcp@0 Using RPC Bootparams for network configuration information. le0: No carrier - cable disconnected or hub link test disabled? le0: No carrier - cable disconnected or hub link test disabled? Skipping interface le0
Would this (untested) patch to QEMU help?
It does work, but ...
diff --git a/target-sparc/cpu.h b/target-sparc/cpu.h index 320530e..b93fdfd 100644 --- a/target-sparc/cpu.h +++ b/target-sparc/cpu.h @@ -403,6 +403,7 @@ typedef struct CPUSPARCState { uint32_t mmuregs[32]; uint64_t mxccdata[4]; uint64_t mxccregs[8];
- uint64_t mmubpaction;
Looks like it's less than 64 bits:
ok 0 0 0 4c spaced! ok 0 4c spaced@ . . 0 0 ok 0 not dup 0 4c spaced! ok 0 4c spaced@ . . 0 1fff ok 0 4c spacel@ . 4 4c spacel@ . 1fff 1fff
Would it make sense to declare it as 32-bit, or just mask out the extra bits? or not even care since almost nobody writes to that register?
Better use the correct size.
uint64_t mmubpregs[4]; uint64_t prom_addr; #endif diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c index b38691e..1023870 100644 --- a/target-sparc/op_helper.c +++ b/target-sparc/op_helper.c @@ -1941,7 +1941,7 @@ uint64_t helper_ld_asi(target_ulong addr, int asi, int size, int sign) case 0x32: // Turbosparc page table descriptor diagnostic case 0x39: /* data cache diagnostic register */ case 0x4c: /* SuperSPARC MMU Breakpoint Action register */
- ret = 0;
- ret = env->mmubpaction;
break;
And here, 0x39 and above should still have the ret = 0.
OK.
case 0x38: /* SuperSPARC MMU Breakpoint Control Registers */ { @@ -2304,7 +2304,9 @@ void helper_st_asi(target_ulong addr, uint64_t val, int asi, int size) // descriptor diagnostic case 0x36: /* I-cache flash clear */ case 0x37: /* D-cache flash clear */
- break;
case 0x4c: /* breakpoint action */
- env->mmubpaction = val;
break; case 0x38: /* SuperSPARC MMU Breakpoint Control Registers*/ {
By the way, what would it take to get the space[cwLd] commands in OpenBIOS? They come in handy for verifying these asi accesses.
Shouldn't be very difficult. Since on Sparc32 it's not possible to give ASI in a register, a switch or hand assembly would be needed.
On 15/06/11 19:48, Blue Swirl wrote:
By the way, what would it take to get the space[cwLd] commands in OpenBIOS? They come in handy for verifying these asi accesses.
Shouldn't be very difficult. Since on Sparc32 it's not possible to give ASI in a register, a switch or hand assembly would be needed.
+1 this is a fairly easy job - handcraft some assembly into C and then bind it into Forth. I'm happy to give you some pointers and help review the patch if you can write it (especially as I know some of the space* words are used in the SPARC64 loader too).
ATB,
Mark.
Mark Cave-Ayland wrote:
On 15/06/11 19:48, Blue Swirl wrote:
By the way, what would it take to get the space[cwLd] commands in OpenBIOS? They come in handy for verifying these asi accesses.
Shouldn't be very difficult. Since on Sparc32 it's not possible to give ASI in a register, a switch or hand assembly would be needed.
+1 this is a fairly easy job - handcraft some assembly into C and then bind it into Forth. I'm happy to give you some pointers and help review the patch if you can write it (especially as I know some of the space* words are used in the SPARC64 loader too).
Based off of http://forums.oracle.com/forums/thread.jspa?threadID=1905000&tstart=90 , using the branch in a delay slot trick, here's a (untested) snippet of inline assembly to start from: __asm__("set 1f, %%g2\n\t" "sll %1, 2, %1\n\t" "jmp %1, %%g2, %%g0\n\t" " ba 2f\n" "1:\n\t" "lda [%2] 0, %0\n\t" "lda [%2] 4, %0\n\t" ... "2:\n" : "=r" (result) : "r" (asi), "r" (address) : "g2");
I'm not that familiar with the OpenBIOS source tree layout, so where would this best be placed? How far to unroll the list of lda's? I'm not even sure if the asi's are 7 or 8 bit, and it looks like nothing above 0x4c is defined for sparc32. Maybe add some CPP magic to help with unrolling the list.
Bob
On 20/06/11 16:40, Bob Breuer wrote:
+1 this is a fairly easy job - handcraft some assembly into C and then bind it into Forth. I'm happy to give you some pointers and help review the patch if you can write it (especially as I know some of the space* words are used in the SPARC64 loader too).
Based off of http://forums.oracle.com/forums/thread.jspa?threadID=1905000&tstart=90 , using the branch in a delay slot trick, here's a (untested) snippet of inline assembly to start from: __asm__("set 1f, %%g2\n\t" "sll %1, 2, %1\n\t" "jmp %1, %%g2, %%g0\n\t" " ba 2f\n" "1:\n\t" "lda [%2] 0, %0\n\t" "lda [%2] 4, %0\n\t" ... "2:\n" : "=r" (result) : "r" (asi), "r" (address) : "g2");
I'm not that familiar with the OpenBIOS source tree layout, so where would this best be placed? How far to unroll the list of lda's? I'm not even sure if the asi's are 7 or 8 bit, and it looks like nothing above 0x4c is defined for sparc32. Maybe add some CPP magic to help with unrolling the list.
Hi Bob,
As a starting point, take a quick look at arch/sparc64/lib.c. I'd create a space* function in a similar way to the itlb_load2/itlb_load3 functions and then in order to make the function visible to Forth as a word, add a bind_func() call within a suitable initialisation function. I'd suggest putting these both in arch/sparc32/lib.c as a starting point.
You should also use ASI_ defines from include/arch/sparc32/asi.h in order to aid readability, and in fact it seems many more of them are defined within include/arch/sparc64/asi.h so you may be able to cut/paste from there.
HTH,
Mark.
On Mon, Jun 20, 2011 at 6:53 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
On 20/06/11 16:40, Bob Breuer wrote:
+1 this is a fairly easy job - handcraft some assembly into C and then bind it into Forth. I'm happy to give you some pointers and help review the patch if you can write it (especially as I know some of the space* words are used in the SPARC64 loader too).
Based off of http://forums.oracle.com/forums/thread.jspa?threadID=1905000&tstart=90 , using the branch in a delay slot trick, here's a (untested) snippet of inline assembly to start from: __asm__("set 1f, %%g2\n\t" "sll %1, 2, %1\n\t" "jmp %1, %%g2, %%g0\n\t" " ba 2f\n" "1:\n\t" "lda [%2] 0, %0\n\t" "lda [%2] 4, %0\n\t" ... "2:\n" : "=r" (result) : "r" (asi), "r" (address) : "g2");
I'm not that familiar with the OpenBIOS source tree layout, so where would this best be placed? How far to unroll the list of lda's? I'm not even sure if the asi's are 7 or 8 bit, and it looks like nothing above 0x4c is defined for sparc32. Maybe add some CPP magic to help with unrolling the list.
Hi Bob,
As a starting point, take a quick look at arch/sparc64/lib.c. I'd create a space* function in a similar way to the itlb_load2/itlb_load3 functions and then in order to make the function visible to Forth as a word, add a bind_func() call within a suitable initialisation function. I'd suggest putting these both in arch/sparc32/lib.c as a starting point.
You should also use ASI_ defines from include/arch/sparc32/asi.h in order to aid readability, and in fact it seems many more of them are defined within include/arch/sparc64/asi.h so you may be able to cut/paste from there.
No, Sparc64 ASIs are very different from Sparc32 ones.
On Sparc64 it's possible to use %asi register.
On Mon, Jun 20, 2011 at 6:40 PM, Bob Breuer breuerr@mc.net wrote:
Mark Cave-Ayland wrote:
On 15/06/11 19:48, Blue Swirl wrote:
By the way, what would it take to get the space[cwLd] commands in OpenBIOS? They come in handy for verifying these asi accesses.
Shouldn't be very difficult. Since on Sparc32 it's not possible to give ASI in a register, a switch or hand assembly would be needed.
+1 this is a fairly easy job - handcraft some assembly into C and then bind it into Forth. I'm happy to give you some pointers and help review the patch if you can write it (especially as I know some of the space* words are used in the SPARC64 loader too).
Based off of http://forums.oracle.com/forums/thread.jspa?threadID=1905000&tstart=90 , using the branch in a delay slot trick, here's a (untested) snippet of inline assembly to start from: __asm__("set 1f, %%g2\n\t" "sll %1, 2, %1\n\t" "jmp %1, %%g2, %%g0\n\t" " ba 2f\n" "1:\n\t" "lda [%2] 0, %0\n\t" "lda [%2] 4, %0\n\t" ... "2:\n" : "=r" (result) : "r" (asi), "r" (address) : "g2");
IIRC there is some way to let GCC pick the register instead of fixing it to g2.
I'm not that familiar with the OpenBIOS source tree layout, so where would this best be placed? How far to unroll the list of lda's? I'm not even sure if the asi's are 7 or 8 bit, and it looks like nothing above 0x4c is defined for sparc32. Maybe add some CPP magic to help with unrolling the list.
I'd add all of them.
On 06/15/11 01:48 PM, Blue Swirl wrote:
[...snip...] Shouldn't be very difficult. Since on Sparc32 it's not possible to give ASI in a register, a switch or hand assembly would be needed.
I've had occasion to rebuild both openbios and QEMU-0.15 on my new machine :-), and can now follow up on this: the additions for the MMU breakpoint action register that Bob talked about have not made a difference for where my boot stalls. For an added bonus, I turned on the DEBUG_ASI in QEMU and so have more information about where it is looping. When I try and boot now, I get the following in an infinite loop:
ASI: read 00000400 asi 0x04 = f5901000 ASI: read 00000300 asi 0x04 = 000003a6 ASI: read f5901400 asi 0x03 = 00000000 ASI: read 00000300 asi 0x04 = 00000000 ASI: read 00000400 asi 0x04 = f5901000 ASI: read 00000300 asi 0x04 = 000003a6 ASI: read f5901400 asi 0x03 = 00000000 ASI: read 00000300 asi 0x04 = 00000000 ASI: read 00000400 asi 0x04 = f5901000
I don't know enough about SPARC32 architecture to know if that gives more useful information... I don't see the 0x4c value in my log file. I tried turning on DEBUG_MMU, but stopped when my log file hit 4GB and I hadn't hit the stopping point yet.
Any ideas for other things to try or set for more debugging?
Nathan
On Fri, Sep 9, 2011 at 2:16 AM, Nathan Kunkee nkunkee42@hotmail.com wrote:
On 06/15/11 01:48 PM, Blue Swirl wrote:
[...snip...] Shouldn't be very difficult. Since on Sparc32 it's not possible to give ASI in a register, a switch or hand assembly would be needed.
I've had occasion to rebuild both openbios and QEMU-0.15 on my new machine :-), and can now follow up on this: the additions for the MMU breakpoint action register that Bob talked about have not made a difference for where my boot stalls. For an added bonus, I turned on the DEBUG_ASI in QEMU and so have more information about where it is looping. When I try and boot now, I get the following in an infinite loop:
ASI: read 00000400 asi 0x04 = f5901000 ASI: read 00000300 asi 0x04 = 000003a6 ASI: read f5901400 asi 0x03 = 00000000 ASI: read 00000300 asi 0x04 = 00000000 ASI: read 00000400 asi 0x04 = f5901000 ASI: read 00000300 asi 0x04 = 000003a6 ASI: read f5901400 asi 0x03 = 00000000 ASI: read 00000300 asi 0x04 = 00000000 ASI: read 00000400 asi 0x04 = f5901000
The OS reads MMU fault status and address registers and then performs MMU probe for the address. The address is not found, so maybe a mapping is missing.
I don't know enough about SPARC32 architecture to know if that gives more useful information... I don't see the 0x4c value in my log file. I tried turning on DEBUG_MMU, but stopped when my log file hit 4GB and I hadn't hit the stopping point yet.
Any ideas for other things to try or set for more debugging?
Since this is repeatable, you could try something like this (untested): diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c index d1a8dd9..2594bbd 100644 --- a/target-sparc/op_helper.c +++ b/target-sparc/op_helper.c @@ -1836,6 +1836,11 @@ uint64_t helper_ld_asi(target_ulong addr, int asi, int size, int sign) ret = mmu_probe(env, addr, mmulev); DPRINTF_MMU("mmu_probe: 0x%08x (lev %d) -> 0x%08" PRIx64 "\n", addr, mmulev, ret); + if (addr == 0xf5901400) { + printf("mmu_probe: 0x%08x (lev %d) -> 0x%08" PRIx64 "\n", + addr, mmulev, ret); + dump_mmu(stdout, fprintf, env); + } } break; case 4: /* read MMU regs */
On 06/06/11 20:42, Mark Cave-Ayland wrote:
Hmmm it looks from reading the source code that QEMU doesn't actually implement a proper audio device for SS-5 at all but merely provides a dummy device with an empty mapped region. In that case it may be possible to provide a simple mapping in OpenBIOS to match the one in QEMU which may be enough to persuade Solaris to boot.
Okay - I've installed a simple memory mapping to a virtual address which is not used, and also tweaked the "intr" property which looked wrong compared to the sample prtconf output (0x5 instead of 0x39 high cell).
Does the OpenBIOS ROM at http://www.siriusit.co.uk/tmp/openbios-sparc32.emptysndmap help get you any further with Solaris 9?
ATB,
Mark.
Date: Mon, 6 Jun 2011 22:43:23 +0100 From: mark.cave-ayland@siriusit.co.uk To: openbios@openbios.org CC: nkunkee42@hotmail.com Subject: Re: [OpenBIOS] Solaris anyone?
On 06/06/11 20:42, Mark Cave-Ayland wrote:
Hmmm it looks from reading the source code that QEMU doesn't actually implement a proper audio device for SS-5 at all but merely provides a dummy device with an empty mapped region. In that case it may be possible to provide a simple mapping in OpenBIOS to match the one in QEMU which may be enough to persuade Solaris to boot.
Okay - I've installed a simple memory mapping to a virtual address which is not used, and also tweaked the "intr" property which looked wrong compared to the sample prtconf output (0x5 instead of 0x39 high cell).
Does the OpenBIOS ROM at http://www.siriusit.co.uk/tmp/openbios-sparc32.emptysndmap help get you any further with Solaris 9?
It seems to spin one time more, but still hang:
Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Jun 6 2011 21:31 Type 'help' for detailed information Trying disk... No valid state has been set by load or init-program
0 > boot cd:d -k -v Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 0x45c9f+0xdaf1+0x1d6a7 Bytes SunOS Release 5.9 Version Generic_112233-12 32-bit Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Ethernet address = 52:54:0:12:34:56 Using default device instance data vac: enabled in write through mode mem = 262144K (0x10000000) avail mem = 240328704 root nexus = SUNW,SPARCstation-5 iommu0 at root: obio 0x10000000 sbus0 at iommu0: obio 0x10001000 dma0 at sbus0: SBus slot 5 0x8400000 dma0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 (esp0): esp-options=0x46 esp0 at dma0: SBus slot 5 0x8800000 sparc ipl 4 esp0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 sd2 at esp0: target 2 lun 0 sd2 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0 root on /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:b fstype ufs obio0 at root obio0 at obio0: obio 0x100000, sparc ipl 12 zs0 is /obio/zs@0,100000 obio1 at obio0: obio 0x0, sparc ipl 12 zs1 is /obio/zs@0,0 cpu0: FMI,MB86904 (mid 0 impl 0x0 ver 0x5 clock 170 MHz) Configuring /dev and /devices pseudo-device: devinfo0 devinfo0 is /pseudo/devinfo@0 tcx0 at sbus0: SBus slot 3 0x800000 and SBus slot 3 0x2000000 and SBus slot 3 0x4000000 and SBus slot 3 0x6000000 and SBus slot 3 0xa000000 and SBus slot 3 0xc000000 and SBus slot 3 0xe000000 and SBus slot 3 0x700000 and SBus slot 3 0x200000 and SBus slot 3 0x300000 and SBus slot 3 0x0 and SBus slot 3 0x240000 and SBus slot 3 0x280000 SBus level 5 sparc ipl 9 tcx0 is /iommu@0,10000000/sbus@0,10001000/SUNW,tcx@3,800000 tcx0: revision 0, screen 1024x768 ledma0 at sbus0: SBus slot 5 0x8400010 le0 at ledma0: SBus slot 5 0x8c00000 sparc ipl 6 le0 is /iommu@0,10000000/sbus@0,10001000/ledma@5,8400010/le@5,8c00000 pseudo-device: fssnap0 fssnap0 is /pseudo/fssnap@0 sbusmem0 at sbus0: SBus slot 0 0x0 sbusmem0 is /iommu@0,10000000/sbus@0,10001000/sbusmem@0,0 sbusmem1 at sbus0: SBus slot 1 0x0 sbusmem1 is /iommu@0,10000000/sbus@0,10001000/sbusmem@1,0 sbusmem2 at sbus0: SBus slot 2 0x0 sbusmem2 is /iommu@0,10000000/sbus@0,10001000/sbusmem@2,0 sbusmem3 at sbus0: SBus slot 3 0x0 sbusmem3 is /iommu@0,10000000/sbus@0,10001000/sbusmem@3,0 sbusmem4 at sbus0: SBus slot 4 0x0 sbusmem4 is /iommu@0,10000000/sbus@0,10001000/sbusmem@4,0 sbusmem5 at sbus0: SBus slot 5 0x0 sbusmem5 is /iommu@0,10000000/sbus@0,10001000/sbusmem@5,0 pseudo-device: ramdisk1024 ramdisk1024 is /pseudo/ramdisk@1024 pseudo-device: winlock0 winlock0 is /pseudo/winlock@0 pseudo-device: lockstat0 lockstat0 is /pseudo/lockstat@0 pseudo-device: llc10 llc10 is /pseudo/llc1@0 pseudo-device: lofi0 lofi0 is /pseudo/lofi@0 pseudo-device: fcp0 fcp0 is /pseudo/fcp@0 NOTICE: Couldn't set value (../../sun/io/audio/sada/drv/audiocs/audio_4231.c, Line #1759 0x00 0x88) audio may not work correctly until it is stopped and restarted audiocs0 at sbus0: SBus slot 4 0xc000000 SBus level 5 sparc ipl 9 audiocs0 is /iommu@0,10000000/sbus@0,10001000/SUNW,CS4231@4,c000000 |
On Mon, Jun 6, 2011 at 9:42 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
On 06/06/11 04:37, Nathan Kunkee wrote:
My Solaris 9 04/04 image seems to hang in the same spot:
Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 30 2011 02:11 Type 'help' for detailed information Trying disk... No valid state has been set by load or init-program
0 > boot cd:d -k -v -s Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 0x45c9f+0xdaf1+0x1d6a7 Bytes SunOS Release 5.9 Version Generic_112233-12 32-bit Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Ethernet address = 52:54:0:12:34:56 Using default device instance data vac: enabled in write through mode mem = 131072K (0x8000000) avail mem = 108797952 root nexus = SUNW,SPARCstation-5 iommu0 at root: obio 0x10000000 sbus0 at iommu0: obio 0x10001000 dma0 at sbus0: SBus slot 5 0x8400000 dma0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 (esp0): esp-options=0x46 esp0 at dma0: SBus slot 5 0x8800000 sparc ipl 4 esp0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 sd2 at esp0: target 2 lun 0 sd2 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0 root on /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:b fstype ufs obio0 at root obio0 at obio0: obio 0x100000, sparc ipl 12 zs0 is /obio/zs@0,100000 obio1 at obio0: obio 0x0, sparc ipl 12 zs1 is /obio/zs@0,0 cpu0: FMI,MB86904 (mid 0 impl 0x0 ver 0x5 clock 170 MHz) Configuring /dev and /devices pseudo-device: devinfo0 devinfo0 is /pseudo/devinfo@0 tcx0 at sbus0: SBus slot 3 0x800000 and SBus slot 3 0x2000000 and SBus slot 3 0x4000000 and SBus slot 3 0x6000000 and SBus slot 3 0xa000000 and SBus slot 3 0xc000000 and SBus slot 3 0xe000000 and SBus slot 3 0x700000 and SBus slot 3 0x200000 and SBus slot 3 0x300000 and SBus slot 3 0x0 and SBus slot 3 0x240000 and SBus slot 3 0x280000 SBus level 5 sparc ipl 9 tcx0 is /iommu@0,10000000/sbus@0,10001000/SUNW,tcx@3,800000 tcx0: revision 0, screen 1024x768 ledma0 at sbus0: SBus slot 5 0x8400010 le0 at ledma0: SBus slot 5 0x8c00000 sparc ipl 6 le0 is /iommu@0,10000000/sbus@0,10001000/ledma@5,8400010/le@5,8c00000 pseudo-device: fssnap0 fssnap0 is /pseudo/fssnap@0 sbusmem0 at sbus0: SBus slot 0 0x0 sbusmem0 is /iommu@0,10000000/sbus@0,10001000/sbusmem@0,0 sbusmem1 at sbus0: SBus slot 1 0x0 sbusmem1 is /iommu@0,10000000/sbus@0,10001000/sbusmem@1,0 sbusmem2 at sbus0: SBus slot 2 0x0 sbusmem2 is /iommu@0,10000000/sbus@0,10001000/sbusmem@2,0 sbusmem3 at sbus0: SBus slot 3 0x0 sbusmem3 is /iommu@0,10000000/sbus@0,10001000/sbusmem@3,0 sbusmem4 at sbus0: SBus slot 4 0x0 sbusmem4 is /iommu@0,10000000/sbus@0,10001000/sbusmem@4,0 sbusmem5 at sbus0: SBus slot 5 0x0 sbusmem5 is /iommu@0,10000000/sbus@0,10001000/sbusmem@5,0 pseudo-device: ramdisk1024 ramdisk1024 is /pseudo/ramdisk@1024 pseudo-device: winlock0 winlock0 is /pseudo/winlock@0 pseudo-device: lockstat0 lockstat0 is /pseudo/lockstat@0 pseudo-device: llc10 llc10 is /pseudo/llc1@0 pseudo-device: lofi0 lofi0 is /pseudo/lofi@0 pseudo-device: fcp0 fcp0 is /pseudo/fcp@0 NOTICE: Couldn't set value (../../sun/io/audio/sada/drv/audiocs/audio_4231.c, Line #1759 0x00 0x88) audio may not work correctly until it is stopped and restarted audiocs0 at sbus0: SBus slot 4 0xc000000 SBus level 5 sparc ipl 9 audiocs0 is /iommu@0,10000000/sbus@0,10001000/SUNW,CS4231@4,c000000
Not having anything to compare to, are the tcx0 and sbusmem entries correct?
Oh that's interesting - I always thought that the hangs were being caused by OpenBIOS reporting 4 CPUs by default whilst QEMU only provides 1.
Where does it report 4 CPUs? I see only one in the device tree.
But this trace strongly points towards the audio driver being the culprit instead.
To be honest I doubt it. I'd rather suspect networking problem with le (aka pcnet), which might be improperly initialized either in qemu or in OpenBIOS. OBP under qemu tries netboot first, so it initializes the le card before Solaris gets it. So the fact that the card is properly initialised under OBP may be just a co-incidence.
Anyway it should be easy to check - just kick the audio out of the device tree. No recompilation of OpenBIOS should be necessary, something like
cd /iommu@0,10000000/sbus@0,10001000/SUNW,CS4231@4,c000000 " name" delete-property device-end boot cdrom:d -vs
should do it. Nathan, can you check?
Artyom
pseudo-device: fcp0 fcp0 is /pseudo/fcp@0 NOTICE: Couldn't set value (../../sun/io/audio/sada/drv/audiocs/audio_4231.c, Line #1759 0x00 0x88) audio may not work correctly until it is stopped and restarted audiocs0 at sbus0: SBus slot 4 0xc000000 SBus level 5 sparc ipl 9 audiocs0 is /iommu@0,10000000/sbus@0,10001000/SUNW,CS4231@4,c000000
Not having anything to compare to, are the tcx0 and sbusmem entries correct?
Oh that's interesting - I always thought that the hangs were being caused by OpenBIOS reporting 4 CPUs by default whilst QEMU only provides 1.
Where does it report 4 CPUs? I see only one in the device tree.
But this trace strongly points towards the audio driver being the culprit instead.
To be honest I doubt it. I'd rather suspect networking problem with le (aka pcnet), which might be improperly initialized either in qemu or in OpenBIOS. OBP under qemu tries netboot first, so it initializes the le card before Solaris gets it. So the fact that the card is properly initialised under OBP may be just a co-incidence.
Anyway it should be easy to check - just kick the audio out of the device tree. No recompilation of OpenBIOS should be necessary, something like
cd /iommu@0,10000000/sbus@0,10001000/SUNW,CS4231@4,c000000 " name" delete-property device-end boot cdrom:d -vs
should do it. Nathan, can you check?
I regret to report that disabling as above neither the audio, nor the ledma and le, nor both, allow me to finish the boot.
On 08/06/11 04:00, Nathan Kunkee wrote:
I regret to report that disabling as above neither the audio, nor the ledma and le, nor both, allow me to finish the boot.
That's a shame - it's obviously going to need some investigation, but I'm not sure there is much else I can do unless someone can donate me a copy of 32-bit Solaris 9 :(
ATB,
Mark.
On 07/06/11 22:28, Artyom Tarasenko wrote:
Where does it report 4 CPUs? I see only one in the device tree.
Yeah - there is only device, but the size of the various properties indicate there is more than one CPU present which may confuse some things.
boot cdrom:d -vs
should do it. Nathan, can you check?
I don't suppose you could supply the complete output from above under OBP for comparison? It would be interesting to see if it is the next module which is failing, exactly which module it is.
ATB,
Mark.
boot cdrom:d -vs
should do it. Nathan, can you check?
I don't suppose you could supply the complete output from above under OBP for comparison? It would be interesting to see if it is the next module which is failing, exactly which module it is.
I'll work on getting the full listing for each combination for comparison, but what I recall from last night is that each one stopped in the same place, after fcp0 or audiocs0, depending.
Nathan
On 2011-Jun-8 11:42 , Nathan Kunkee wrote:
I don't suppose you could supply the complete output from above under OBP for comparison? It would be interesting to see if it is the next module which is failing, exactly which module it is.
I'll work on getting the full listing for each combination for comparison, but what I recall from last night is that each one stopped in the same place, after fcp0 or audiocs0, depending.
I don't know if this will work, but see if you can boot kadb ("boot cdrom:d kadb -s"), and then break into Solaris when it's stuck.
The potential problems with this: - I don't know if the cdrom has kadb on it - I don't know if Solaris will respond to a <break> that early in the game
If it does, a "$c" will show you the stack and probably tell us where we're getting stuck. You may have to issue a ":c" (continue) early in the boot process to get kadb to finish loading Solaris.
On 08/06/11 18:26, Tarl Neustaedter wrote:
I don't know if this will work, but see if you can boot kadb ("boot cdrom:d kadb -s"), and then break into Solaris when it's stuck.
The potential problems with this:
- I don't know if the cdrom has kadb on it
- I don't know if Solaris will respond to a <break> that early in the game
If it does, a "$c" will show you the stack and probably tell us where we're getting stuck. You may have to issue a ":c" (continue) early in the boot process to get kadb to finish loading Solaris.
kadb now works on SPARC32, however I wasn't aware that you could manually initiate a break. What key combination do you use in order to do this?
ATB,
Mark.
On 06/ 8/11 12:26 PM, Tarl Neustaedter wrote:
On 2011-Jun-8 11:42 , Nathan Kunkee wrote:
I don't suppose you could supply the complete output from above under OBP for comparison? It would be interesting to see if it is the next module which is failing, exactly which module it is.
I'll work on getting the full listing for each combination for comparison, but what I recall from last night is that each one stopped in the same place, after fcp0 or audiocs0, depending.
I don't know if this will work, but see if you can boot kadb ("boot cdrom:d kadb -s"), and then break into Solaris when it's stuck.
The potential problems with this:
- I don't know if the cdrom has kadb on it
- I don't know if Solaris will respond to a <break> that early in the
game
If it does, a "$c" will show you the stack and probably tell us where we're getting stuck. You may have to issue a ":c" (continue) early in the boot process to get kadb to finish loading Solaris.
kadb is available on the cdrom, however, it stops at the same place as a regular boot. Also, I've had no luck interrupting the boot process.
Nathan
On 09/09/11 03:20, Nathan Kunkee wrote:
I'll work on getting the full listing for each combination for comparison, but what I recall from last night is that each one stopped in the same place, after fcp0 or audiocs0, depending.
Yes please. In fact, I don't believe I've seen the full output of "boot cdrom:d -v" from your Solaris copy anywhere? That would be useful to see how far you are getting.
I don't know if this will work, but see if you can boot kadb ("boot cdrom:d kadb -s"), and then break into Solaris when it's stuck.
The potential problems with this:
- I don't know if the cdrom has kadb on it
- I don't know if Solaris will respond to a <break> that early in the
game
If it does, a "$c" will show you the stack and probably tell us where we're getting stuck. You may have to issue a ":c" (continue) early in the boot process to get kadb to finish loading Solaris.
kadb is available on the cdrom, however, it stops at the same place as a regular boot. Also, I've had no luck interrupting the boot process.
Yeah I'm guessing that this is to do with QEMU not having an equivalent of the STOP-A/L1-A break sequence? Once you can find out which module is causing the issue, then you can set breakpoints using the module#symbol notation in kadb although my knowledge (and documentation I can find anywhere on kadb) is very weak :(
ATB,
Mark.
-
Artyom Tarasenko -
Blue Swirl -
Bob Breuer -
Mark Cave-Ayland -
Nathan Kunkee -
Nick Couchman -
Robert Reif -
Tarl Neustaedter