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 blauwirbel@gmail.com
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 +}
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.
On Fri, Jun 11, 2010 at 4:59 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk 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
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.
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.
On Mon, Jun 14, 2010 at 11:18 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk 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>
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.
On Mon, Jun 14, 2010 at 6:25 PM, Tarl Neustaedter tarl-b2@tarl.net 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.
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.
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.
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.
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.
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.
On Tue, Jun 15, 2010 at 8:08 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk 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
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.
Am 15.06.2010 um 19:01 schrieb Mark Cave-Ayland <mark.cave-ayland@siriusit.co.uk
:
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
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.
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
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.
-
Alexander Graf -
Alexander Graf -
Blue Swirl -
Mark Cave-Ayland -
repository service -
Tarl Neustaedter