[OpenBIOS] [commit] r832 - in trunk/openbios-devel: arch/sparc32 drivers

[Blue Swirl]

On Mon, Aug 9, 2010 at 8:50 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Tarl Neustaedter wrote:
>
>>> The problem is that some images don't have a bootable partition in
>>> 'd', but 'a', any of these fail because only the first device is
>>> attempted in boot-device list. The automagic partition change hack may
>>> mask this.
>>>
>>> [...]
>>> In the NetBSD case, 'a' is not bootable but 'd' is. Aurora 1.0, Zoot
>>> (Red Hat Linux 4.0) and SuSE 7.3 only boot from 'a'. In some images
>>> (for example Debian 4.0R5) 'a' and 'd' are equivalent
>>
>> Some history behind the boot partitions - if you look at the man page for
>> mkisofs, under the -sparc-boot switch, you'll see the various partitions
>> which were reserved for particular architectures. My recollection is that
>> partition ":d" was for the "dragon" architecture, from about 15-20 years
>> ago. The current generation of SPARCs use partition ":f" (and have for at
>> least a decade), although we may be changing that to ":a" fairly soon.

'd' was for sun4m (ss-5, -10, -20 etc.). 'Dragon' was a codename for
sc-2000, which was sun4d.

>> Current Sun/Oracle release DVDs are created such that all eight partitions
>> point to the same physical blocks. You can boot from any of ":a" through
>> ":h", and Openboot will be equally happy.
>>
>> Solaris itself isn't quite as flexible. The common label parsing code does
>> a bunch of geometry checks on the partitions, and unless it identifies the
>> disk as a read-only removable media, will completely discard the label and
>> return a "default" VTOC where only partitions 0 and 2 (:a and :c) exist, and
>> they occupy the entire disk. This will matter to you only if you get pretty
>> far into booting Solaris.
>
> Wow, I think I start to understand this now. As I mentioned in my previous
> email, the Forth is very simple for parsing boot-device - it simple opens
> each device in turn and returns the first one that returns a valid ihandle
> (as per the spec).
>
> My guess is that the bug Blue is seeing is that actually
> packages/sun-parts.c is somehow returning a valid ihandle for a slice when
> it shouldn't (as Blue suggests it is perhaps related to the automagic
> partition hack).

Yes, that was the problem, partition check never failed. I'll commit a fix.

BTW, it looks like Sparc64 boot has been broken at some point.