Re: [OpenBIOS] SunOS 5.8 64bit emulate SUNW, Ultra 2

[Mark Cave-Ayland]

On 14/02/18 10:57, Weidemann, Maik (M-SO) wrote:
> Hello Mark,
>
> thanks for your answer.
>
> The tip with the bios binary from git was good. It’s look like my own 
> build is faulty.
>
> Now I get this error messages:
>
> #qemu-system-sparc64 -uuid 0120b64e-5d86-41a9-8763-07f8d64f9f9c 
> -nographic -drive unit=1,file=sun14_disk.raw,format=raw -L . -bios 
> pc-bios_openbios-sparc64
>
> OpenBIOS for Sparc64
>
> Configuration device id QEMU version 1 machine id 0
>
> kernel cmdline
>
> CPUs: 1 x SUNW,UltraSPARC-IIi
>
> UUID: 0120b64e-5d86-41a9-8763-07f8d64f9f9c
>
> Welcome to OpenBIOS v1.1 built on Jan 26 2018 07:53
>
> Type 'help' for detailed information
>
> Trying disk:a...
>
> Not a bootable ELF image
>
> Not a bootable a.out image
>
> Loading FCode image...
>
> Loaded 5936 bytes
>
> entry point is 0x4000
>
> Evaluating FCode...
>
> open isn't unique.
>
> Alloc of 0x2000 bytes at 0x16000 refused.
>
> panic[cpu0]/thread=10408000: BOP_ALLOC failed
>
> 0000000010406e90 unix:boot_alloc+44 (2000, 2000, 1000, 30000016000, 
> 10775860, 30000014000)
>
> %l0-3: 000000001041aac0 0000030ffffff138 0000000000000001 
> 000000001044a9c8
>
> %l4-7: 0000000010449b20 0000000010449b00 000000001044a928 
> 000000000000000b
>
> 0000000010406f40 unix:segkmem_alloc+30 (30000016000, 2000, 0, 0, 
> 1044dbe8, 10449f08)
>
> %l0-3: 0000030ffffff5c0 ffffffffffffe000 0000000000000000 
> 000000001044a9c8
>
> %l4-7: 0000000010449b20 0000000010449b00 000000001044e448 
> 0000000010045d68
>
> 0000000010407000 genunix:vmem_xalloc+3d8 (1044d620, 1044da28, 
> ffffffffffffffff, ffffffffffffffff, 0, 0)
>
> %l0-3: 0000000010045ce4 ffffffffffffe000 000000001044d620 
> 0000000000002000
>
> %l4-7: 0000000000000000 0000000000000000 0000000000002000 
> 000000001044d640
>
> 0000000010407130 genunix:kmem_slab_create+8c (0, 0, 2000, 300000043c0, 
> 0, 1044d620)
>
> %l0-3: 0000000000000000 0000030ffffff220 0000000000000000 
> 000000001044a9c8
>
> %l4-7: 0000000010449b20 00000300000043c0 000000001044e448 
> 00000000ffecb1d0
>
> 0000000010407220 genunix:kmem_cache_alloc+180 (0, 0, 0, 300000043c0, 0, 0)
>
> %l0-3: 0000030000004740 ffffffffffffe000 000000001044d620 0000000000002000
>
> %l4-7: 0000030ffffff220 0000000000000000 0000000000002000 
> 000000001044d640
>
> 00000000104072d0 genunix:kmem_slab_create+130 (200, 30000014000, 2000, 
> 3000000da40, 0, 200)
>
> %l0-3: 0000000000000000 ffffffffffffe000 000000001044d620 
> 0000000000002000
>
> %l4-7: 0000030fffffef68 000003000000da40 0000000000002000 
> 000000001044d640
>
> 00000000104073c0 genunix:kmem_cache_alloc+180 (0, 0, 0, 3000000da40, 0, 0)
>
> %l0-3: 000003000000ddc0 0000000000000000 0000000000010000 
> ffffffffffffffff
>
> %l4-7: 0000030000013fc8 00000300000052c0 0000030000013fc8 
> 0000030000013fc0
>
> 0000000010407470 genunix:kmem_alloc+2c (2000, 0, 2000, 3000000da40, 0, 
> 30000013fb8)
>
> %l0-3: 0000030000005640 000000001013671a 0000000000000000 0000000000000020
>
> %l4-7: 0000000010445280 000000001045114b 0000000000000000 
> 0000000000000000
>
> 0000000010407520 krtld:kobj_zalloc+c (2000, 1000, 2000, 300000052c0, f0, 0)
>
> %l0-3: 000003000000e740 ffffffffffffffc0 000000001044e4e8 00000000000003c0
>
> %l4-7: 0000000010449678 0000000000000000 0000000000000000 
> 000000000000000b
>
> 00000000104075d0 krtld:kobj_open_file+38 (2000, 30000011f88, 10438418, 
> 0, 0, 1)
>
> %l0-3: 0000000000000008 0000000000000000 0000000000000000 
> 0000000000000000
>
> %l4-7: 0000000000000008 0000000010045ce4 0000000010451140 
> 0000000010045d68
>
> 0000000010407680 genunix:mod_read_system_file+70 (10436800, 2000, 1, 0, 
> 26, 10438d20)
>
> %l0-3: 0000000000004000 0000000000000008 0000000000004008 
> 0000000000000000
>
> %l4-7: 0000000000002000 0000000010045ce4 0000000010450278 
> 0000000010045d68
>
> 00000000104077a0 genunix:kmem_init+1b8 (10460470, 0, 0, 10614bd0, 
> 10775c80, 30000016160)
>
> %l0-3: 000000001041d000 0000000000002000 0000000010045ce4 
> 0000000010045d68
>
> %l4-7: 0000000010417ea8 0000000000001fff 000000001040d920 
> 00000000ffecb1d0
>
> 0000000010407870 unix:startup_memlist+99c (10417c00, 300000160a0, 
> 10417ee0, 10417eb0, 10417ec8, 30000016000)
>
> %l0-3: 0000000000000103 0000030000000000 0000000010423000 
> 0000000010424190
>
> %l4-7: 0000000000000000 0000000000002000 0000030000016000 
> 000000001041c800
>
> 0000000010407970 unix:startup+c (10428000, 0, 0, 7e7c000, 2000, 
> ffffffffffffffff)
>
> %l0-3: 00000000100243b8 000000000000cbec 000000000000114c 
> 0000000000000000
>
> %l4-7: 00000000104619b8 00000000002de9d8 00000000000b514c 
> 000000000000114c
>
> 0000000010407a20 genunix:main+4 (1040d400, 2000, 10407ec0, 10408030, 
> fff2, 1004df8c)
>
> %l0-3: 0000000010408000 0000000000000001 0000000000000015 
> 0000000000000e69
>
> %l4-7: 00000000104287b0 00000000104619b8 00000000000ca6a0 
> 0000000000000540
>
> skipping system dump - no dump device configured
>
> rebooting...
>
> BOOTpanic - kernel: prom_reboot: reboot call returned!
>
> EXIT
>
> 0 >   ok
>
> 0 >   ok
>
> 0 >   ok
>
> 0 >   ok
>
> 0 >   ok
>
> 0 >   ok
>
> 0 > boot disk
>
> Not a Linux kernel image
>
> Not a bootable ELF image
>
> Not a bootable a.out image
>
> Loading FCode image...
>
> Loaded 5936 bytes
>
> entry point is 0x6000
>
> Evaluating FCode...
>
> open isn't unique.
>
> Boot load failed.
>
> Do the error messages come from the Bios or already from the booting OS?

Those are from the Solaris kernel so that's a good start. This looks 
similar to what I get from my Solaris 9 test ISO and I suspect it's 
related to memory initialisation. Solaris 11 gets all the way to 
userspace, but still needs the MMU IE support added to QEMU.
> When I try to start the vm with the define of the disk, who it described 
> in the current documentation 
> (https://wiki.qemu.org/Documentation/Platforms/SPARC#All_PCI_devices_are_atta...),
>
> then I get this notification:
>
> #qemu-system-sparc64
>
> -uuid 0120b64e-5d86-41a9-8763-07f8d64f9f9c \
>
> -nographic \
>
> -drive 
> id=hd,if=none,file=/var/lib/libvirt/images/sun14_disk.raw,format=raw \
>
> -device virtio-blk-pci,bus=pciB,drive=hd \
>
> -L . \
>
> -bios pc-bios_openbios-sparc64 \
>
> -m 256
>
> OpenBIOS for Sparc64
>
> Configuration device id QEMU version 1 machine id 0
>
> kernel cmdline
>
> CPUs: 1 x SUNW,UltraSPARC-IIi
>
> UUID: 0120b64e-5d86-41a9-8763-07f8d64f9f9c
>
> Welcome to OpenBIOS v1.1 built on Jan 26 2018 07:53
>
> Type 'help' for detailed information
>
> Trying disk:a...
>
> No valid state has been set by load or init-program
>
> What mean the message “No valid state has been set by load or 
> init-program”? Wrong disk? Or try to boot form wrong / faulty partion?

Yeah, that means that "load" couldn't locate a supported binary format 
to execute from the boot device. Sadly OpenBIOS doesn't (yet) boot from 
virtio devices, but you can boot from the CDROM in Linux and add a 
separate virtio drive to get extra speed if you really want to.

Also I believe that Solaris has doesn't have virtio drivers anyway, so I 
don't think you'd manage to get far there either. To the best of my 
knowledge, only Linux and NetBSD support virtio devices on 
qemu-system-sparc64 to date.

ATB,

Mark.