OpenBIOS seek fails on NetBSD CD image

[Martin Husemann]

With qemu 1.3.0 it is not possible to boot a NetBSD install CD image, using a command line like:

qemu-system-sparc64 -nographic -boot d -cdrom NetBSD-6.99.19-sparc64.iso

The image used here is a custom one with a bit of bootloader debugging added (see below). It is 310968320 bytes long (hex: 12890000) and when burned to a CD boots on real Sun hardware.

The partition table on the CD is listed below, it consists of a big ISO9660 partition first (the root filesystem) and a small UFS/FFS partition only containing bootloader, kernel and a config file.

Probably what happens is: "open" is called in OF, for the "cdrom" device. Then a "seek" call on this handle to the superblock of the UFS partition fails, maybe because OpenBIOS eroneously interprets the partition table and does not consider "cdrom" the full device?

Before we get to this stage, the forth boot block opens "cdrom:f" and accesses the file system from there (without the full partition offset, of course), which works fine - this is how we get the secondary bootloader (ofwboot) loaded and executed.

Could this be simple "cdrom" vs "cdrom:a" confusion or something like that?

Here are the relevant excerpts from the boot messages - I can make the test image available, or just use a daily build HEAD image from NetBSD.org.

I can also easily try patches or try to fix the bug myself, if you could give me a hint where this open/seek openfirmware functions are implemented.

Thanks,

Martin

--8<--

OpenBIOS for Sparc64
Configuration device id QEMU version 1 machine id 0
kernel cmdline
CPUs: 1 x SUNW,UltraSPARC-IIi
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.0 built on Aug 19 2012 13:06
  Type 'help' for detailed information
Trying cdrom:f...
Not a bootable ELF image
Not a bootable a.out image
Loading FCode image...
Loaded 7478 bytes
entry point is 0x4000
NetBSD IEEE 1275 Multi-FS Bootblock
Version $NetBSD: bootblk.fth,v 1.13 2010/06/24 00:54:12 eeh Exp $
..
Jumping to entry point 0000000000100000 for type 0000000000000001...
switching to new context: entry point 0x100000 stack 0x00000000ffe86b39
>> NetBSD/sparc64 OpenFirmware Boot, Revision 1.16 (Mon Apr 15 22:11:52 CEST 20$
bootoptions: device='cdrom:f', kernel='', options=''
..
OF_open("cdrom")
... ok, handle: -3644496
devopen: cdrom is now open
devopen: trying to read disklabel
..
partition 0 start 0 size 93a80
partition 1 start 0 size 0
partition 2 start 0 size 0
partition 3 start 0 size 0
partition 4 start 0 size 0
partition 5 start 93a80 size a00
partition 6 start 0 size 0
partition 7 start 0 size 0
disklabel_sun_to_bsd: success!
devopen: setting partition 5 offset 93a80
devopen: return 0
..
strategy: block 10, partition offset 93a80, blksz 200
strategy: seek position should be: 12752000
strategy: seeking to 12752000
OF_seek(handle -3644496, pos 309665792)
OF_seek -> -1
UFS read failed with 5

[Mark Cave-Ayland (mark-cave-ayland)]

Thanks for the bug report!

This was a slight bug in the interpose logic within the OpenBIOS disk-label package - we were always interposing a partition package if we could detect a valid partition magic. In actual fact the interpose should only happen when no arguments are specified when opening the package, otherwise when opening the raw block device you "fall into" the first valid partition by mistake.

I've committed a fix for this to OpenBIOS SVN trunk as r1127 and it passes all my tests here so I am happy to close this out.