[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[repository service]

Author: blueswirl
Date: Thu Jun 10 20:35:25 2010
New Revision: 793
URL: http://tracker.coreboot.org/trac/openbios/changeset/793

Log:
Fix PPC target build

Fix errors like this:
../fs/hfs/volume.c:612:2: error: no newline at end of file

Signed-off-by: Blue Swirl

Modified:
   trunk/openbios-devel/fs/hfs/hfs_fs.c
   trunk/openbios-devel/fs/hfs/volume.c
   trunk/openbios-devel/fs/hfsplus/hfsp_fs.c
   trunk/openbios-devel/fs/hfsplus/volume.c

Modified: trunk/openbios-devel/fs/hfs/hfs_fs.c
==============================================================================
--- trunk/openbios-devel/fs/hfs/hfs_fs.c	Thu Jun 10 00:30:32 2010	(r792)
+++ trunk/openbios-devel/fs/hfs/hfs_fs.c	Thu Jun 10 20:35:25 2010	(r793)
@@ -466,4 +466,4 @@
    	return -1;

return 0;
-}
\ No newline at end of file
+}

Modified: trunk/openbios-devel/fs/hfs/volume.c
==============================================================================
--- trunk/openbios-devel/fs/hfs/volume.c	Thu Jun 10 00:30:32 2010	(r792)
+++ trunk/openbios-devel/fs/hfs/volume.c	Thu Jun 10 20:35:25 2010	(r793)
@@ -609,4 +609,4 @@

free(mdb);
    return -1;
-}
\ No newline at end of file
+}

Modified: trunk/openbios-devel/fs/hfsplus/hfsp_fs.c
==============================================================================
--- trunk/openbios-devel/fs/hfsplus/hfsp_fs.c	Thu Jun 10 00:30:32 2010	(r792)
+++ trunk/openbios-devel/fs/hfsplus/hfsp_fs.c	Thu Jun 10 20:35:25 2010	(r793)
@@ -405,4 +405,4 @@
    	return -1;

return 0;
-}
\ No newline at end of file
+}

Modified: trunk/openbios-devel/fs/hfsplus/volume.c
==============================================================================
--- trunk/openbios-devel/fs/hfsplus/volume.c	Thu Jun 10 00:30:32 2010	(r792)
+++ trunk/openbios-devel/fs/hfsplus/volume.c	Thu Jun 10 20:35:25 2010	(r793)
@@ -307,4 +307,4 @@

free(vol);
    return -1;
-}
\ No newline at end of file
+}

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Mark Cave-Ayland]

repository service wrote:
> \ No newline at end of file
> +}

Damn - I've missed this a couple of times in the past :(  Is there a gcc 
flag I can use to force this option when testing?

Incidentally, I know I haven't added a suitable probe function for 
iso9660 w/o grubfs yet - I haven't forgotten, just busy, but I'm away 
for a few days now. I promise to commit a suitable update when I get 
back though.

ATB,

Mark.

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Blue Swirl]

On Fri, Jun 11, 2010 at 4:59 PM, Mark Cave-Ayland
 wrote:
> repository service wrote:
> > \ No newline at end of file
> > +}
>
> Damn - I've missed this a couple of times in the past :(  Is there a gcc
> flag I can use to force this option when testing?

Not that I know of. I get the errors with gcc 4.2.4.
> Incidentally, I know I haven't added a suitable probe function for iso9660
> w/o grubfs yet - I haven't forgotten, just busy, but I'm away for a few days
> now. I promise to commit a suitable update when I get back though.

It looks like PPC is broken:

qemu-system-ppc -boot d -m 128 -cdrom  openSUSE-11.1-NET-ppc.iso -L . -nographic
qemu: warning: could not load VGA bios 'video.x'
Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory
> > =============================================================
> > OpenBIOS 1.0 [Jun 10 2010 20:15]
> > Configuration device id QEMU version 1 machine id 2
> > CPUs: 1
> > Memory: 128M
> > UUID: 00000000-0000-0000-0000-000000000000
> > CPU type PowerPC,750

Welcome to OpenBIOS v1.0 built on Jun 10 2010 20:15

Unable to open path ,\suseboot\yaboot
No valid state has been set by load or init-program
No valid state has been set by load or init-program

No valid state has been set by load or init-program
No valid state has been set by load or init-program
No valid state has been set by load or init-program
> > *** Boot failure! No secondary bootloader specified ***

No valid state has been set by load or init-program
> > *** Boot failure! No secondary bootloader specified ***

0 > QEMU 0.12.50 monitor - type 'help' for more information
(qemu) q

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Mark Cave-Ayland]

Blue Swirl wrote:
> Not that I know of. I get the errors with gcc 4.2.4.

I'm currently on 4.5.0 for SPARC64 and 4.3.2 for PPC.
> It looks like PPC is broken:
>
> qemu-system-ppc -boot d -m 128 -cdrom  openSUSE-11.1-NET-ppc.iso -L . -nographic
> qemu: warning: could not load VGA bios 'video.x'
> Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory
> > > =============================================================
> > > OpenBIOS 1.0 [Jun 10 2010 20:15]
> > > Configuration device id QEMU version 1 machine id 2
> > > CPUs: 1
> > > Memory: 128M
> > > UUID: 00000000-0000-0000-0000-000000000000
> > > CPU type PowerPC,750
>
> Welcome to OpenBIOS v1.0 built on Jun 10 2010 20:15
>
> Unable to open path ,\suseboot\yaboot
> No valid state has been set by load or init-program
> No valid state has been set by load or init-program
>
> No valid state has been set by load or init-program
> No valid state has been set by load or init-program
> No valid state has been set by load or init-program
> > > *** Boot failure! No secondary bootloader specified ***
>
> No valid state has been set by load or init-program
> > > *** Boot failure! No secondary bootloader specified ***
>
> 0 > QEMU 0.12.50 monitor - type 'help' for more information
> (qemu) q

I bet that's due to the parsing of the load argument. I took a hint from 
the CHRP spec which says that the partition id should be parsed from the 
load argument so that just the filename is passed down to the next 
level, which in this case is misc-files.

My assumption is that load arguments are based upon the following form:

- single digit partition id (0-9, a-f)
- comma
- path

where the partition id and comma are optional. My first guess would be 
that this assumption is somehow wrong...

ATB,

Mark.

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Tarl Neustaedter]

On 2010-6-14 7:18 AM, Mark Cave-Ayland wrote:
> Blue Swirl wrote:
> > Not that I know of. I get the errors with gcc 4.2.4.
>
> I'm currently on 4.5.0 for SPARC64 and 4.3.2 for PPC.
> > It looks like PPC is broken:
> >
> > qemu-system-ppc -boot d -m 128 -cdrom  openSUSE-11.1-NET-ppc.iso -L . 
> > -nographic
> > qemu: warning: could not load VGA bios 'video.x'
> > Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory
> > > > =============================================================
> > > > OpenBIOS 1.0 [Jun 10 2010 20:15]
> > > > Configuration device id QEMU version 1 machine id 2
> > > > CPUs: 1
> > > > Memory: 128M
> > > > UUID: 00000000-0000-0000-0000-000000000000
> > > > CPU type PowerPC,750
> >
> > Welcome to OpenBIOS v1.0 built on Jun 10 2010 20:15
> >
> > Unable to open path ,\suseboot\yaboot
> > No valid state has been set by load or init-program
> > No valid state has been set by load or init-program
> >
> > No valid state has been set by load or init-program
> > No valid state has been set by load or init-program
> > No valid state has been set by load or init-program
> > > > *** Boot failure! No secondary bootloader specified ***
> >
> > No valid state has been set by load or init-program
> > > > *** Boot failure! No secondary bootloader specified ***
> >
> > 0 > QEMU 0.12.50 monitor - type 'help' for more information
> > (qemu) q
>
> I bet that's due to the parsing of the load argument. I took a hint 
> from the CHRP spec which says that the partition id should be parsed 
> from the load argument so that just the filename is passed down to the 
> next level, which in this case is misc-files.
>
> My assumption is that load arguments are based upon the following form:
> single digit partition id (0-9, a-f)
> comma
> path
>
> where the partition id and comma are optional. My first guess would be 
> that this assumption is somehow wrong...

It looks like the comma should be peeled off from the above path (that 
you should be feeding \suseboot\yaboot to your booter, and that comma is 
almost certainly mistaken).

Normally we see boot command of the form:

boot /pci@400/.../scsi@0/disk@3:a kernel/misc/kadb

There is a space between the :a (specifying the partition), and 
"kernel/misc/kadb" is the debugging form of unix. I know the above 
command gets translated into a bootpath where the "/" are replaced with 
"|" and somehow attached to the path, but I don't have access to the 
sources right now to see how. I'll followup in a few hours with that 
information.

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Blue Swirl]

On Mon, Jun 14, 2010 at 11:18 AM, Mark Cave-Ayland
 wrote:
> Blue Swirl wrote:
> > Not that I know of. I get the errors with gcc 4.2.4.
>
> I'm currently on 4.5.0 for SPARC64 and 4.3.2 for PPC.
> > It looks like PPC is broken:
> >
> > qemu-system-ppc -boot d -m 128 -cdrom  openSUSE-11.1-NET-ppc.iso -L .
> > -nographic
> > qemu: warning: could not load VGA bios 'video.x'
> > Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory
> > > > =============================================================
> > > > OpenBIOS 1.0 [Jun 10 2010 20:15]
> > > > Configuration device id QEMU version 1 machine id 2
> > > > CPUs: 1
> > > > Memory: 128M
> > > > UUID: 00000000-0000-0000-0000-000000000000
> > > > CPU type PowerPC,750
> >
> > Welcome to OpenBIOS v1.0 built on Jun 10 2010 20:15
> >
> > Unable to open path ,\suseboot\yaboot
> > No valid state has been set by load or init-program
> > No valid state has been set by load or init-program
> >
> > No valid state has been set by load or init-program
> > No valid state has been set by load or init-program
> > No valid state has been set by load or init-program
> > > > *** Boot failure! No secondary bootloader specified ***
> >
> > No valid state has been set by load or init-program
> > > > *** Boot failure! No secondary bootloader specified ***
> >
> > 0 > QEMU 0.12.50 monitor - type 'help' for more information
> > (qemu) q
>
> I bet that's due to the parsing of the load argument. I took a hint from the
> CHRP spec which says that the partition id should be parsed from the load
> argument so that just the filename is passed down to the next level, which
> in this case is misc-files.
>
> My assumption is that load arguments are based upon the following form:
> single digit partition id (0-9, a-f)
> comma
> path
>
> where the partition id and comma are optional. My first guess would be that
> this assumption is somehow wrong...

bootinfo.txt contains the following:
<chrp-boot>
<description>openSuSE 11.1</description>
<os-name>openSuSE 11.1</os-name>
<boot-script>boot &device;:1,\suseboot\yaboot.ibm</boot-script>
</chrp-boot>

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Tarl Neustaedter]

On 2010-6-14 2:15 PM, Blue Swirl wrote:
> [...]
> bootinfo.txt contains the following:
>
> <chrp-boot>
> <description>openSuSE 11.1</description>
> <os-name>openSuSE 11.1</os-name>
> <boot-script>boot&device;:1,\suseboot\yaboot.ibm</boot-script>
> </chrp-boot>

You might try replacing that comma with a space. The "boot" command 
takes two arguments; the device and the arguments, where "arguments" is 
frequently the filespec to be booted (it's passed to the secondary 
booter in "/chosen:bootargs").

The case I knew of replacing "/" with "|" and appending with a comma was 
in the network boot code, a special case not relevant for here.

Either way, it appears that the comma before the \suseboot was being 
passed as part of the filespec, so no surprise things got confused.

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Blue Swirl]

On Mon, Jun 14, 2010 at 6:25 PM, Tarl Neustaedter  wrote:
> On 2010-6-14 2:15 PM, Blue Swirl wrote:
> > [...]
> > bootinfo.txt contains the following:
> >
> > <chrp-boot>
> > <description>openSuSE 11.1</description>
> > <os-name>openSuSE 11.1</os-name>
> > <boot-script>boot&device;:1,\suseboot\yaboot.ibm</boot-script>
> > </chrp-boot>
>
> You might try replacing that comma with a space. The "boot" command takes
> two arguments; the device and the arguments, where "arguments" is frequently
> the filespec to be booted (it's passed to the secondary booter in
> "/chosen:bootargs").
>
> The case I knew of replacing "/" with "|" and appending with a comma was in
> the network boot code, a special case not relevant for here.
>
> Either way, it appears that the comma before the \suseboot was being passed
> as part of the filespec, so no surprise things got confused.

I don't think that is the case, because the element specifies the boot
script (actually executable), not boot args. After the conversions,
the path should be cdrom:1,\suseboot\yaboot.ibm, where 1 is the
partition number.

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Tarl Neustaedter]

> I don't think that is the case, because the element specifies the boot
> script (actually executable), not boot args. After the conversions,
> the path should be cdrom:1,\suseboot\yaboot.ibm, where 1 is the
> partition number.

Right. But you were getting an error message of "Unable to open path 
,\suseboot\yaboot", which suggests to me that either the parser that was 
peeling off arguments failed to discard the comma, or it was expected 
somewhere else.

The exact parsing of the elements of the path after the ":" is 
device-specific, and entirely up to that device driver. In general disk 
devices will have a partition number/name for the first argument, but 
that's about the only commonality.

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Mark Cave-Ayland]

Blue Swirl wrote:
> It looks like PPC is broken:
>
> qemu-system-ppc -boot d -m 128 -cdrom  openSUSE-11.1-NET-ppc.iso -L . -nographic
> qemu: warning: could not load VGA bios 'video.x'
> Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory
> > > =============================================================
> > > OpenBIOS 1.0 [Jun 10 2010 20:15]
> > > Configuration device id QEMU version 1 machine id 2
> > > CPUs: 1
> > > Memory: 128M
> > > UUID: 00000000-0000-0000-0000-000000000000
> > > CPU type PowerPC,750
>
> Welcome to OpenBIOS v1.0 built on Jun 10 2010 20:15
>
> Unable to open path ,\suseboot\yaboot
> No valid state has been set by load or init-program
> No valid state has been set by load or init-program
>
> No valid state has been set by load or init-program
> No valid state has been set by load or init-program
> No valid state has been set by load or init-program
> > > *** Boot failure! No secondary bootloader specified ***
>
> No valid state has been set by load or init-program
> > > *** Boot failure! No secondary bootloader specified ***
>
> 0 > QEMU 0.12.50 monitor - type 'help' for more information
> (qemu) q

Okay. I've fixed a couple of bugs related to this (and OpenSUSE works, 
although still suffers from the initial incorrect argument parsing) but 
now I find that my old Fedora iso fails to boot.

It seems as if Fedora expects the CDROM HFS filesystem to be partition 
0, whereas OpenSUSE wants it to be partition 1. In packages/mac-parts.c 
I can see that there is an Apple_partition_map slice of the disk 
occupying slice 0 of the volume - can anyone with a PPC Mac confirm 
whether or not this is or is not included in the OpenBoot partition 
numbering?

ATB,

Mark.

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Mark Cave-Ayland]

Mark Cave-Ayland wrote:
> It seems as if Fedora expects the CDROM HFS filesystem to be partition 
> 0, whereas OpenSUSE wants it to be partition 1. In packages/mac-parts.c 
> I can see that there is an Apple_partition_map slice of the disk 
> occupying slice 0 of the volume - can anyone with a PPC Mac confirm 
> whether or not this is or is not included in the OpenBoot partition 
> numbering?

Okay - I've just committed a fix for the package argument handling for 
file arguments with no partition identifier, and this seems to have 
fixed PPC so that both your openSUSE and Fedora PPC images boot once 
again - can you confirm at your end?

Incidentally, I think there may be another low-level device emulation 
bug in qemu ppc somewhere. If I boot the openSUSE image here then it 
segfaults the qemu host binary during boot before reaching the installer 
- perhaps another PCI device-related issue?

ATB,

Mark.

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Alexander Graf]

Am 15.06.2010 um 19:01 schrieb Mark Cave-Ayland <[e-mail]
> :
> Blue Swirl wrote:
> > It looks like PPC is broken:
> > qemu-system-ppc -boot d -m 128 -cdrom  openSUSE-11.1-NET-ppc.iso - 
> > L . -nographic
> > qemu: warning: could not load VGA bios 'video.x'
> > Could not open option rom 'pxe-ne2k_pci.bin': No such file or  
> > directory
> > > > =============================================================
> > > > OpenBIOS 1.0 [Jun 10 2010 20:15]
> > > > Configuration device id QEMU version 1 machine id 2
> > > > CPUs: 1
> > > > Memory: 128M
> > > > UUID: 00000000-0000-0000-0000-000000000000
> > > > CPU type PowerPC,750
> >
> > Welcome to OpenBIOS v1.0 built on Jun 10 2010 20:15
> > Unable to open path ,\suseboot\yaboot
> > No valid state has been set by load or init-program
> > No valid state has been set by load or init-program
> > No valid state has been set by load or init-program
> > No valid state has been set by load or init-program
> > No valid state has been set by load or init-program
> > > > *** Boot failure! No secondary bootloader specified ***
> >
> > No valid state has been set by load or init-program
> > > > *** Boot failure! No secondary bootloader specified ***
> >
> > 0 > QEMU 0.12.50 monitor - type 'help' for more information
> > (qemu) q
>
> Okay. I've fixed a couple of bugs related to this (and OpenSUSE  
> works, although still suffers from the initial incorrect argument  
> parsing) but now I find that my old Fedora iso fails to boot.
>
> It seems as if Fedora expects the CDROM HFS filesystem to be  
> partition 0, whereas OpenSUSE wants it to be partition 1. In  
> packages/mac-parts.c I can see that there is an Apple_partition_map  
> slice of the disk occupying slice 0 of the volume - can anyone with  
> a PPC Mac confirm whether or not this is or is not included in the  
> OpenBoot partition numbering?

If you could be slightly more precise on what exactly I'd type in, I  
can certainly give it a try on my iBook. Also, please give me exact  
links to the isos you're referring to (preferrably netinstall) so  
we're on the same page.

Alex
>

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Mark Cave-Ayland]

Alexander Graf wrote:
> If you could be slightly more precise on what exactly I'd type in, I can 
> certainly give it a try on my iBook. Also, please give me exact links to 
> the isos you're referring to (preferrably netinstall) so we're on the 
> same page.
>
> Alex

Sure, that would be great :)

I'm currently working with openSUSE-11.1-NET-ppc.iso. Rather than 
autobooting the CD, can you go directly into OpenBoot and then try the 
following to see which one is the HFS partition containing the main 
filesystem image (and hence will boot the openSUSE CD):

boot cd:0
boot cd:1

I suspect it may be the latter, since the first entry is labelled 
Apple_partition_map as opposed to Apple_HFS - but I'd like to check to 
be sure.

TIA,

Mark.

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Mark Cave-Ayland]

Mark Cave-Ayland wrote:
> Incidentally, I think there may be another low-level device emulation 
> bug in qemu ppc somewhere. If I boot the openSUSE image here then it 
> segfaults the qemu host binary during boot before reaching the installer
> perhaps another PCI device-related issue?

FWIW updating to qemu git head seems to resolve the crash, however the 
openSUSE installer now fails when trying to read the driver update 
(disk:/?device-*usb*). I'll do a quick check to see if this works 
without my latest changes, and also wait to hear back from Alex.

ATB,

Mark.

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Mark Cave-Ayland]

Mark Cave-Ayland wrote:
> FWIW updating to qemu git head seems to resolve the crash, however the 
> openSUSE installer now fails when trying to read the driver update 
> (disk:/?device-*usb*). I'll do a quick check to see if this works 
> without my latest changes, and also wait to hear back from Alex.

Reverting to OpenBIOS r790 before my disk package changes shows the same 
bug with the OpenSUSE installer. So at least this isn't a regression ;)

ATB,

Mark.

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Blue Swirl]

On Tue, Jun 15, 2010 at 8:08 PM, Mark Cave-Ayland
 wrote:
> Mark Cave-Ayland wrote:
> > It seems as if Fedora expects the CDROM HFS filesystem to be partition 0,
> > whereas OpenSUSE wants it to be partition 1. In packages/mac-parts.c I can
> > see that there is an Apple_partition_map slice of the disk occupying slice 0
> > of the volume - can anyone with a PPC Mac confirm whether or not this is or
> > is not included in the OpenBoot partition numbering?
>
> Okay - I've just committed a fix for the package argument handling for file
> arguments with no partition identifier, and this seems to have fixed PPC so
> that both your openSUSE and Fedora PPC images boot once again - can you
> confirm at your end?

R795 passes my PPC tests. There are some new messages about unable to
open path, but maybe the errors were just hidden before:

Unable to open path 02,\install\yaboot.conf
Unable to open path 01,\install\yaboot.conf
Config file read, 1611 bytes

Unable to open path 02,\install\boot.msg
Unable to open path 01,\install\boot.msg
Welcome to Debian GNU/Linux etch!

This is a Debian installation CDROM,
built on 20081220-23:17.

The default option is 'install'. For maximum
control, you can use the 'expert' option.

If the system fails to boot at all (the typical
symptom is a white screen which doesn't go away),
use 'install video=ofonly' or 'expert video=ofonly'.

The plain options are for the powerpc family of
processors (from 601 to G4). The *64 options are for
64bit powerpc processors, which include the IBM
Power3, Power4, Power5, ... boxes, as well as the
Apple G5 boxes. Press the tab key for a list of
options, or type 'help' for help.

************************************
If in doubt, just choose 'install', and if that
doesn't work, try 'install video=ofonly'.
************************************
Welcome to yaboot version 1.3.13
Enter "help" to get some basic usage information
boot:
Please wait, loading kernel...
Unable to open path 02,\install\powerpc\vmlinux
Unable to open path 01,\install\powerpc\vmlinux
   Elf32 kernel loaded...
Loading ramdisk...
Unable to open path 02,\install\powerpc\initrd.gz
Unable to open path 01,\install\powerpc\initrd.gz
ramdisk loaded at 01900000, size: 3807 Kbytes

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Alexander Graf]

On 16.06.2010, at 13:34, Mark Cave-Ayland wrote:
> Alexander Graf wrote:
> > If you could be slightly more precise on what exactly I'd type in, I can certainly give it a try on my iBook. Also, please give me exact links to the isos you're referring to (preferrably netinstall) so we're on the same page.
> > Alex
>
> Sure, that would be great :)
>
> I'm currently working with openSUSE-11.1-NET-ppc.iso. Rather than autobooting the CD, can you go directly into OpenBoot and then try the following to see which one is the HFS partition containing the main filesystem image (and hence will boot the openSUSE CD):
>
> boot cd:0

0 > boot cd:0 DISK-LABEL: LOAD <noninterposed> not supportedload-size=0 adler32=1

LOAD-SIZE is too small
 ok
> boot cd:1

0 > boot cd:1 MAC-PARTS: LOAD <noninterposed> not suportedload-size=0 adler32=1

LOAD-SIZE is too small
 ok

Alex

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Mark Cave-Ayland]

Blue Swirl wrote:
> R795 passes my PPC tests. There are some new messages about unable to
> open path, but maybe the errors were just hidden before:
>
> Unable to open path 02,\install\yaboot.conf
> Unable to open path 01,\install\yaboot.conf

Yeah, those are fine - the message was one I added to files_open() in 
packages/misc-files.c to report if the open failed. Based on Alex's 
email, it seems that the correct way to do this to check load-size from 
the load word which I can do as the next part of my code rework. So at 
this point I'll just remove it again.

Now the disk/partition/file hierarchy is correct, the next step is to 
rework all of the *_load.c functions in libopenbios so that they take an 
ihandle as an argument - then OpenBIOS should be able to invoke load 
across any device automagically :)

ATB,

Mark.

[commit] r793 - in trunk/openbios-devel/fs: hfs hfsplus

[Mark Cave-Ayland]

Alexander Graf wrote:
> 0 > boot cd:0 DISK-LABEL: LOAD <noninterposed> not supportedload-size=0 adler32=1
>
> LOAD-SIZE is too small
>  ok
> > boot cd:1
>
> 0 > boot cd:1 MAC-PARTS: LOAD <noninterposed> not suportedload-size=0 adler32=1
>
> LOAD-SIZE is too small
>  ok

Thanks for that - not what I was expecting, but it's still useful 
information!

Without any documentation, it seems to imply that id 0 is the entire 
disk while id 1 is the partition map? Hmmmm...

ATB,

Mark.