Author: blueswirl Date: Tue Aug 3 22:48:23 2010 New Revision: 832 URL: http://tracker.coreboot.org/trac/openbios/changeset/832
Log: sparc32: fix pre-loaded kernel command line
Fix more breakage from r828:
For some reason, QEMU/Sparc32 does not set FW_CFG_CMDLINE_SIZE, so we have to use FW_CFG_KERNEL_CMDLINE instead.
Setup romvec obp_arg.argv[1] and "boot-file" property.
Remove obsolete command line setup code from obio.c.
Signed-off-by: Blue Swirl blauwirbel@gmail.com
Modified: trunk/openbios-devel/arch/sparc32/openbios.c trunk/openbios-devel/drivers/obio.c
Modified: trunk/openbios-devel/arch/sparc32/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/openbios.c Tue Aug 3 20:39:27 2010 (r831) +++ trunk/openbios-devel/arch/sparc32/openbios.c Tue Aug 3 22:48:23 2010 (r832) @@ -20,6 +20,7 @@ #include "libopenbios/sys_info.h" #include "openbios.h" #include "boot.h" +#include "openprom.h" #include "packages/video.h" #define NO_QEMU_PROTOS #include "arch/common/fw_cfg.h" @@ -134,7 +135,8 @@ arch_init( void ) { static char cmdline[128]; - int size; + int size = 0; + const char *kernel_cmdline;
openbios_init(); modules_init(); @@ -154,25 +156,31 @@ #endif device_end();
+ /* Initialiase openprom romvec */ + romvec = init_openprom(); + kernel_size = fw_cfg_read_i32(FW_CFG_KERNEL_SIZE); if (kernel_size) kernel_image = fw_cfg_read_i32(FW_CFG_KERNEL_ADDR);
- size = fw_cfg_read_i32(FW_CFG_CMDLINE_SIZE); - if (size) { - fw_cfg_read(FW_CFG_CMDLINE_DATA, cmdline, size); - } + kernel_cmdline = (const char *) fw_cfg_read_i32(FW_CFG_KERNEL_CMDLINE); + if (kernel_cmdline) { + size = strlen(kernel_cmdline); + memcpy(cmdline, kernel_cmdline, size); + obp_arg.argv[1] = cmdline; + } cmdline[size] = '\0'; qemu_cmdline = (uint32_t)cmdline;
- boot_device = fw_cfg_read_i16(FW_CFG_BOOT_DEVICE); - - /* Initialiase openprom romvec */ - romvec = init_openprom(); + /* Setup nvram variables */ + push_str("/options"); + fword("find-device"); + push_str(cmdline); + fword("encode-string"); + push_str("boot-file"); + fword("property");
- /* Setup nvram variables */ - push_str("/options"); - fword("find-device"); + boot_device = fw_cfg_read_i16(FW_CFG_BOOT_DEVICE);
switch (boot_device) { case 'a': @@ -194,11 +202,6 @@ push_str("boot-device"); fword("property");
- push_str(""); - fword("encode-string"); - push_str("boot-file"); - fword("property"); - /* Set up other properties */ push_str("/chosen"); fword("find-device");
Modified: trunk/openbios-devel/drivers/obio.c ============================================================================== --- trunk/openbios-devel/drivers/obio.c Tue Aug 3 20:39:27 2010 (r831) +++ trunk/openbios-devel/drivers/obio.c Tue Aug 3 22:48:23 2010 (r832) @@ -38,12 +38,6 @@ */ #define SUN4M_NCPU 4
-/* The kernel may want to examine the arguments, so hold a copy in OBP's - * mapped memory. - */ -#define OBIO_CMDLINE_MAX 256 -static char obio_cmdline[OBIO_CMDLINE_MAX]; - /* DECLARE data structures for the nodes. */ DECLARE_UNNAMED_NODE( ob_obio, INSTALL_OPEN, sizeof(int) );
@@ -651,14 +645,12 @@ const char *stdin, *stdout; unsigned int i; char nographic; - uint32_t size = 0; uint16_t machine_id; const struct cpudef *cpu; const struct machdef *mach; char buf[256]; uint32_t temp; phandle_t chosen; - const char *kernel_cmdline;
ob_new_obio_device("eeprom", NULL);
@@ -691,21 +683,6 @@ for(;;); }
- kernel_size = fw_cfg_read_i32(FW_CFG_KERNEL_SIZE); - if (kernel_size) - kernel_image = fw_cfg_read_i32(FW_CFG_KERNEL_ADDR); - kernel_cmdline = (const char *) fw_cfg_read_i32(FW_CFG_KERNEL_CMDLINE); - if (kernel_cmdline) { - size = strlen(kernel_cmdline); - if (size > OBIO_CMDLINE_MAX - 1) - size = OBIO_CMDLINE_MAX - 1; - memcpy(&obio_cmdline, kernel_cmdline, size); - } - obio_cmdline[size] = '\0'; - qemu_cmdline = (uint32_t) &obio_cmdline; - cmdline_size = size; - boot_device = fw_cfg_read_i16(FW_CFG_BOOT_DEVICE); - fw_cfg_read(FW_CFG_NOGRAPHIC, &nographic, 1); graphic_depth = fw_cfg_read_i16(FW_CFG_SUN4M_DEPTH);
repository service wrote:
Log: sparc32: fix pre-loaded kernel command line
Fix more breakage from r828:
For some reason, QEMU/Sparc32 does not set FW_CFG_CMDLINE_SIZE, so we have to use FW_CFG_KERNEL_CMDLINE instead.
Setup romvec obp_arg.argv[1] and "boot-file" property.
Remove obsolete command line setup code from obio.c.
Looks good to me.
Just for the record, with r828 the way that bootpath/bootargs should now work is as follows:
- All Qemu configuration should now take place in the arch_init() (or equivalent) function only
- arch_init() should read the Qemu firmware device and setup the NVRAM variables boot-device and boot-file (boot-device can now take a list of space-separated devices to search - see ppc/qemu for an example of this)
- Everything else is now magically handled by Forth in (encode-bootpath) based upon the following rules from the IEEE-1275 spec:
- If either "load" or "boot" are issued on their own, search through each boot-device in order until open returns a valid ihandle, then load/boot from this. bootargs is set to the contents of boot-file.
- If either "load <device>" or "boot <device>" are specified then only attempt to use the device specified on the command line. bootargs is set to the contents of boot-file.
- If either "load <device> <cmdline>" or "boot <device> <cmdline>" are specified then only attempt to use the device specified on the command line. bootargs is set to <cmdline>.
Incidentally, I've just realised that this fixes "boot cdrom -H" on SPARC64 too :)
HTH,
Mark.
On Wed, Aug 4, 2010 at 10:32 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
repository service wrote:
Log: sparc32: fix pre-loaded kernel command line
Fix more breakage from r828:
For some reason, QEMU/Sparc32 does not set FW_CFG_CMDLINE_SIZE, so we have to use FW_CFG_KERNEL_CMDLINE instead.
Setup romvec obp_arg.argv[1] and "boot-file" property.
Remove obsolete command line setup code from obio.c.
Looks good to me.
Just for the record, with r828 the way that bootpath/bootargs should now work is as follows:
- All Qemu configuration should now take place in the arch_init() (or
equivalent) function only
- arch_init() should read the Qemu firmware device and setup the NVRAM
variables boot-device and boot-file (boot-device can now take a list of space-separated devices to search - see ppc/qemu for an example of this)
- Everything else is now magically handled by Forth in (encode-bootpath)
based upon the following rules from the IEEE-1275 spec:
- If either "load" or "boot" are issued on their own, search through each boot-device in order until open returns a valid ihandle, then load/boot from this. bootargs is set to the contents of boot-file.
Does not work: Trying cdrom... Not a bootable ELF image Not a bootable a.out image No valid state has been set by load or init-program
0 > printenv name "options" boot-from "disk" boot-args "" boot-device "cdrom cdrom:d" use-generic? "false" boot-script "" boot-screen "" ttyb-rts-dtr-off "false" ttyb-ignore-cd "true" ttyb-mode "9600,8,n,1,-" ttya-rts-dtr-off "false" ttya-ignore-cd "true" ttya-mode "9600,8,n,1,-" tpe-link-test? "true" load-base "4000" scroll-lock "true" skip-netboot? "false" default-mac-address "false" pci-probe-mask "-1" selftest-#megs "0" screen-#rows "24" screen-#columns "80" output-device "ttya" input-device "ttya" use-nvramrc? "false" oem-logo? "false" oem-banner "" oem-banner? "false" nvramrc "" fcode-debug? "false" diag-switch? "false" boot-file "" boot-command "boot" auto-boot? "true" ok 0 > boot Trying cdrom... Not a bootable ELF image Not a bootable a.out image No valid state has been set by load or init-program ok 0 > boot cdrom:d Not a bootable ELF image Loading a.out image... Loaded 65536 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context:
NetBSD/sparc Secondary Boot, Revision 1.12 (autobuild@tgm.daemon.org, Wed Apr 9 02:46:11 UTC 2003)
Booting netbsd
I changed the boot-device like this: diff --git a/arch/sparc32/openbios.c b/arch/sparc32/openbios.c index 60ee180..3624269 100644 --- a/arch/sparc32/openbios.c +++ b/arch/sparc32/openbios.c @@ -187,11 +187,11 @@ arch_init( void ) push_str("floppy"); break; case 'c': - push_str("disk"); + push_str("disk disk:d"); break; default: case 'd': - push_str("cdrom"); + push_str("cdrom cdrom:d"); break; case 'n': push_str("net");
Blue Swirl wrote:
Does not work: Trying cdrom... Not a bootable ELF image Not a bootable a.out image No valid state has been set by load or init-program
0 > printenv name "options" boot-from "disk" boot-args "" boot-device "cdrom cdrom:d" use-generic? "false" boot-script "" boot-screen "" ttyb-rts-dtr-off "false" ttyb-ignore-cd "true" ttyb-mode "9600,8,n,1,-" ttya-rts-dtr-off "false" ttya-ignore-cd "true" ttya-mode "9600,8,n,1,-" tpe-link-test? "true" load-base "4000" scroll-lock "true" skip-netboot? "false" default-mac-address "false" pci-probe-mask "-1" selftest-#megs "0" screen-#rows "24" screen-#columns "80" output-device "ttya" input-device "ttya" use-nvramrc? "false" oem-logo? "false" oem-banner "" oem-banner? "false" nvramrc "" fcode-debug? "false" diag-switch? "false" boot-file "" boot-command "boot" auto-boot? "true" ok 0 > boot Trying cdrom... Not a bootable ELF image Not a bootable a.out image No valid state has been set by load or init-program ok 0 > boot cdrom:d Not a bootable ELF image Loading a.out image... Loaded 65536 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context:
NetBSD/sparc Secondary Boot, Revision 1.12 (autobuild@tgm.daemon.org, Wed Apr 9 02:46:11 UTC 2003)
Booting netbsd
I changed the boot-device like this: diff --git a/arch/sparc32/openbios.c b/arch/sparc32/openbios.c index 60ee180..3624269 100644 --- a/arch/sparc32/openbios.c +++ b/arch/sparc32/openbios.c @@ -187,11 +187,11 @@ arch_init( void ) push_str("floppy"); break; case 'c':
push_str("disk");
push_str("disk disk:d"); break; default: case 'd':
push_str("cdrom");
push_str("cdrom cdrom:d"); break; case 'n': push_str("net");
Hmmm that should work. I'm just about to head home now, but can take a look later this evening. What's the filename of the ISO image you are using so I can use it for testing?
ATB,
Mark.
On Wed, Aug 4, 2010 at 4:45 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
Does not work: Trying cdrom... Not a bootable ELF image Not a bootable a.out image No valid state has been set by load or init-program
0 > printenv name "options" boot-from "disk" boot-args "" boot-device "cdrom cdrom:d" use-generic? "false" boot-script "" boot-screen "" ttyb-rts-dtr-off "false" ttyb-ignore-cd "true" ttyb-mode "9600,8,n,1,-" ttya-rts-dtr-off "false" ttya-ignore-cd "true" ttya-mode "9600,8,n,1,-" tpe-link-test? "true" load-base "4000" scroll-lock "true" skip-netboot? "false" default-mac-address "false" pci-probe-mask "-1" selftest-#megs "0" screen-#rows "24" screen-#columns "80" output-device "ttya" input-device "ttya" use-nvramrc? "false" oem-logo? "false" oem-banner "" oem-banner? "false" nvramrc "" fcode-debug? "false" diag-switch? "false" boot-file "" boot-command "boot" auto-boot? "true" ok 0 > boot Trying cdrom... Not a bootable ELF image Not a bootable a.out image No valid state has been set by load or init-program ok 0 > boot cdrom:d Not a bootable ELF image Loading a.out image... Loaded 65536 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context:
NetBSD/sparc Secondary Boot, Revision 1.12 (autobuild@tgm.daemon.org, Wed Apr 9 02:46:11 UTC 2003)
Booting netbsd
I changed the boot-device like this: diff --git a/arch/sparc32/openbios.c b/arch/sparc32/openbios.c index 60ee180..3624269 100644 --- a/arch/sparc32/openbios.c +++ b/arch/sparc32/openbios.c @@ -187,11 +187,11 @@ arch_init( void ) push_str("floppy"); break; case 'c':
- push_str("disk");
- push_str("disk disk:d");
break; default: case 'd':
- push_str("cdrom");
- push_str("cdrom cdrom:d");
break; case 'n': push_str("net");
Hmmm that should work. I'm just about to head home now, but can take a look later this evening. What's the filename of the ISO image you are using so I can use it for testing?
This is NetBSD, they boot from 'd' partition.
Mark Cave-Ayland wrote:
I changed the boot-device like this: diff --git a/arch/sparc32/openbios.c b/arch/sparc32/openbios.c index 60ee180..3624269 100644 --- a/arch/sparc32/openbios.c +++ b/arch/sparc32/openbios.c @@ -187,11 +187,11 @@ arch_init( void ) push_str("floppy"); break; case 'c':
push_str("disk");
push_str("disk disk:d"); break; default: case 'd':
push_str("cdrom");
push_str("cdrom cdrom:d"); break; case 'n': push_str("net");Hmmm that should work. I'm just about to head home now, but can take a look later this evening. What's the filename of the ISO image you are using so I can use it for testing?
Ah wait a sec - according to the IEEE-1275 spec, the device chosen from boot-device is the first one that can be successfully opened, i.e. returns a valid ihandle with open-dev. Since the cdrom device is first in the list (and can always be successfully opened), it will never try the next option.
So what you need to do is swap the order over from "cdrom cdrom:d" to "cdrom:d cdrom" which should give the desired behaviour.
HTH,
Mark.
On Wed, Aug 4, 2010 at 7:08 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Mark Cave-Ayland wrote:
I changed the boot-device like this: diff --git a/arch/sparc32/openbios.c b/arch/sparc32/openbios.c index 60ee180..3624269 100644 --- a/arch/sparc32/openbios.c +++ b/arch/sparc32/openbios.c @@ -187,11 +187,11 @@ arch_init( void ) push_str("floppy"); break; case 'c':
- push_str("disk");
- push_str("disk disk:d");
break; default: case 'd':
- push_str("cdrom");
- push_str("cdrom cdrom:d");
break; case 'n': push_str("net");
Hmmm that should work. I'm just about to head home now, but can take a look later this evening. What's the filename of the ISO image you are using so I can use it for testing?
Ah wait a sec - according to the IEEE-1275 spec, the device chosen from boot-device is the first one that can be successfully opened, i.e. returns a valid ihandle with open-dev. Since the cdrom device is first in the list (and can always be successfully opened), it will never try the next option.
So what you need to do is swap the order over from "cdrom cdrom:d" to "cdrom:d cdrom" which should give the desired behaviour.
The problem which prevented NetBSD boot was actually open_ih() return value check, fixed in r839. R840 is only cosmetic.
I could now change 'cdrom' to point to 'd' partition. One place for the change is obviously in openbios.c, but a change there doesn't affect the other variant aliases like 'sd(0,2,0)' which should also be adjusted. These are added in esp.c.
There's also automatic partition selection code in sun-parts.c which is a bit ugly. With ':d' appended to 'cdrom', that may actually force the selected partition to be the first ('a') partition.
I think it's better to postpone these changes until multiple boot devices can be used in openbios.c.
Blue Swirl wrote:
Ah wait a sec - according to the IEEE-1275 spec, the device chosen from boot-device is the first one that can be successfully opened, i.e. returns a valid ihandle with open-dev. Since the cdrom device is first in the list (and can always be successfully opened), it will never try the next option.
So what you need to do is swap the order over from "cdrom cdrom:d" to "cdrom:d cdrom" which should give the desired behaviour.
The problem which prevented NetBSD boot was actually open_ih() return value check, fixed in r839. R840 is only cosmetic.
Ah I see. Looks like the return value is different between open_io() and open_ih() :(
I could now change 'cdrom' to point to 'd' partition. One place for the change is obviously in openbios.c, but a change there doesn't affect the other variant aliases like 'sd(0,2,0)' which should also be adjusted. These are added in esp.c.
I think esp.c is probably the right place for the change to be made if you're simply wanting "cdrom" to become "sd(0,2,0):d".
There's also automatic partition selection code in sun-parts.c which is a bit ugly. With ':d' appended to 'cdrom', that may actually force the selected partition to be the first ('a') partition.
I think it's better to postpone these changes until multiple boot devices can be used in openbios.c.
I'm confused. Surely if the "cdrom" alias is fixed, then once it is changed then it doesn't matter anymore as you would specify -boot d on the qemu command line? Or do you mean there is something still not right with the multiple boot-device code?
ATB,
Mark.
On Sat, Aug 7, 2010 at 1:28 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
Ah wait a sec - according to the IEEE-1275 spec, the device chosen from boot-device is the first one that can be successfully opened, i.e. returns a valid ihandle with open-dev. Since the cdrom device is first in the list (and can always be successfully opened), it will never try the next option.
So what you need to do is swap the order over from "cdrom cdrom:d" to "cdrom:d cdrom" which should give the desired behaviour.
The problem which prevented NetBSD boot was actually open_ih() return value check, fixed in r839. R840 is only cosmetic.
Ah I see. Looks like the return value is different between open_io() and open_ih() :(
Not really. ;-)
I could now change 'cdrom' to point to 'd' partition. One place for the change is obviously in openbios.c, but a change there doesn't affect the other variant aliases like 'sd(0,2,0)' which should also be adjusted. These are added in esp.c.
I think esp.c is probably the right place for the change to be made if you're simply wanting "cdrom" to become "sd(0,2,0):d".
There's also automatic partition selection code in sun-parts.c which is a bit ugly. With ':d' appended to 'cdrom', that may actually force the selected partition to be the first ('a') partition.
I think it's better to postpone these changes until multiple boot devices can be used in openbios.c.
I'm confused. Surely if the "cdrom" alias is fixed, then once it is changed then it doesn't matter anymore as you would specify -boot d on the qemu command line? Or do you mean there is something still not right with the multiple boot-device code?
Yes, it doesn't work with reversed list either.
Blue Swirl wrote:
Ah I see. Looks like the return value is different between open_io() and open_ih() :(
Not really. ;-)
Hmmm I seem to remember based on existing code that the return value was wrong - obviously I changed the wrong end, so there may be some other breakage somewhere else.
I think it's better to postpone these changes until multiple boot devices can be used in openbios.c.
I'm confused. Surely if the "cdrom" alias is fixed, then once it is changed then it doesn't matter anymore as you would specify -boot d on the qemu command line? Or do you mean there is something still not right with the multiple boot-device code?
Yes, it doesn't work with reversed list either.
I've just tried adding a "cdrom:d" prefix to the cdrom boot-device list in arch/sparc32/openbios.c and it boots fine for me. Can you give me an example of where the code is not working as expected?
ATB,
Mark.
On Sun, Aug 8, 2010 at 11:56 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
Ah I see. Looks like the return value is different between open_io() and open_ih() :(
Not really. ;-)
Hmmm I seem to remember based on existing code that the return value was wrong - obviously I changed the wrong end, so there may be some other breakage somewhere else.
I think it's better to postpone these changes until multiple boot devices can be used in openbios.c.
I'm confused. Surely if the "cdrom" alias is fixed, then once it is changed then it doesn't matter anymore as you would specify -boot d on the qemu command line? Or do you mean there is something still not right with the multiple boot-device code?
Yes, it doesn't work with reversed list either.
I've just tried adding a "cdrom:d" prefix to the cdrom boot-device list in arch/sparc32/openbios.c and it boots fine for me. Can you give me an example of where the code is not working as expected?
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.
fdisk -l aurora-1.0-sparc-disc1.iso aurora-2.0-sparc-boot.iso debian-40r5-sparc-businesscard.iso NetBSD_5.0.1_sparccd.iso suse-sparc-7.3-CD1.iso zoot-sparc.iso OpenBSD-4.4.iso
Disk aurora-1.0-sparc-disc1.iso (Sun disk label): 1 heads, 640 sectors, 2024 cylinders Units = cylinders of 640 * 512 bytes
Device Flag Start End Blocks Id System aurora-1.0-sparc-disc1.iso1 r 0 2024 647616 83 Linux native
Disk aurora-2.0-sparc-boot.iso (Sun disk label): 1 heads, 640 sectors, 2048 cylinders Units = cylinders of 640 * 512 bytes
Device Flag Start End Blocks Id System aurora-2.0-sparc-boot.iso1 r 0 63 20160 4 SunOS usr aurora-2.0-sparc-boot.iso2 r 0 63 20160 2 SunOS root aurora-2.0-sparc-boot.iso3 r 0 63 20160 2 SunOS root aurora-2.0-sparc-boot.iso4 r 0 63 20160 2 SunOS root aurora-2.0-sparc-boot.iso5 r 0 63 20160 2 SunOS root aurora-2.0-sparc-boot.iso6 r 0 63 20160 2 SunOS root aurora-2.0-sparc-boot.iso7 r 0 63 20160 2 SunOS root aurora-2.0-sparc-boot.iso8 r 0 63 20160 2 SunOS root
Disk debian-40r5-sparc-businesscard.iso (Sun disk label): 1 heads, 640 sectors, 2048 cylinders Units = cylinders of 640 * 512 bytes
Device Flag Start End Blocks Id System debian-40r5-sparc-businesscard.iso1 r 0 77 24640 4 SunOS usr debian-40r5-sparc-businesscard.iso2 r 0 77 24640 2 SunOS root debian-40r5-sparc-businesscard.iso3 r 0 77 24640 2 SunOS root debian-40r5-sparc-businesscard.iso4 r 0 77 24640 2 SunOS root debian-40r5-sparc-businesscard.iso5 r 0 77 24640 2 SunOS root debian-40r5-sparc-businesscard.iso6 r 0 77 24640 2 SunOS root debian-40r5-sparc-businesscard.iso7 r 0 77 24640 2 SunOS root debian-40r5-sparc-businesscard.iso8 r 0 77 24640 2 SunOS root Detected sun disklabel with wrong version [0x00000000]. Detected sun disklabel with wrong sanity [0x00000000]. Detected sun disklabel with wrong num_partitions [0]. Warning: Wrong values need to be fixed up and will be corrected by w(rite)
Disk NetBSD_5.0.1_sparccd.iso (Sun disk label): 1 heads, 640 sectors, 599 cylinders Units = cylinders of 640 * 512 bytes
Device Flag Start End Blocks Id System NetBSD_5.0.1_sparccd.iso1 0 594 190080 0 Unassigned NetBSD_5.0.1_sparccd.iso2 594 599 1600 0 Unassigned NetBSD_5.0.1_sparccd.iso3 594 599 1600 0 Unassigned NetBSD_5.0.1_sparccd.iso4 594 599 1600 0 Unassigned
Disk suse-sparc-7.3-CD1.iso (Sun disk label): 1 heads, 640 sectors, 2035 cylinders Units = cylinders of 640 * 512 bytes
Device Flag Start End Blocks Id System suse-sparc-7.3-CD1.iso1 r 0 2035 651104 83 Linux native
Disk zoot-sparc.iso (Sun disk label): 1 heads, 640 sectors, 1904 cylinders Units = cylinders of 640 * 512 bytes
Device Flag Start End Blocks Id System zoot-sparc.iso1 r 0 1904 609152 83 Linux native
Disk OpenBSD-4.4.iso (Sun disk label): 1 heads, 640 sectors, 2048 cylinders Units = cylinders of 640 * 512 bytes
Device Flag Start End Blocks Id System OpenBSD-4.4.iso1 0 2048 655360 0 Unassigned OpenBSD-4.4.iso2 0 2048 655360 0 Unassigned OpenBSD-4.4.iso3 0 2048 655360 0 Unassigned OpenBSD-4.4.iso4 0 2048 655360 0 Unassigned
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.
On 2010-8-8 2:24 PM, Blue Swirl 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.
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.
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.
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).
ATB,
Mark.
On Mon, Aug 9, 2010 at 8:50 AM, Mark Cave-Ayland mark.cave-ayland@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.
2010/8/4 Blue Swirl blauwirbel@gmail.com:
On Wed, Aug 4, 2010 at 10:32 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
repository service wrote:
Log: sparc32: fix pre-loaded kernel command line
Fix more breakage from r828:
For some reason, QEMU/Sparc32 does not set FW_CFG_CMDLINE_SIZE, so we have to use FW_CFG_KERNEL_CMDLINE instead.
Setup romvec obp_arg.argv[1] and "boot-file" property.
Remove obsolete command line setup code from obio.c.
Looks good to me.
Just for the record, with r828 the way that bootpath/bootargs should now work is as follows:
- All Qemu configuration should now take place in the arch_init() (or
equivalent) function only
- arch_init() should read the Qemu firmware device and setup the NVRAM
variables boot-device and boot-file (boot-device can now take a list of space-separated devices to search - see ppc/qemu for an example of this)
- Everything else is now magically handled by Forth in (encode-bootpath)
based upon the following rules from the IEEE-1275 spec:
- If either "load" or "boot" are issued on their own, search through each boot-device in order until open returns a valid ihandle, then load/boot from this. bootargs is set to the contents of boot-file.
Does not work: Trying cdrom... Not a bootable ELF image Not a bootable a.out image No valid state has been set by load or init-program
0 > printenv name "options" boot-from "disk" boot-args "" boot-device "cdrom cdrom:d" use-generic? "false" boot-script "" boot-screen "" ttyb-rts-dtr-off "false" ttyb-ignore-cd "true" ttyb-mode "9600,8,n,1,-" ttya-rts-dtr-off "false" ttya-ignore-cd "true" ttya-mode "9600,8,n,1,-" tpe-link-test? "true" load-base "4000" scroll-lock "true" skip-netboot? "false" default-mac-address "false" pci-probe-mask "-1" selftest-#megs "0" screen-#rows "24" screen-#columns "80" output-device "ttya" input-device "ttya" use-nvramrc? "false" oem-logo? "false" oem-banner "" oem-banner? "false" nvramrc "" fcode-debug? "false" diag-switch? "false" boot-file "" boot-command "boot" auto-boot? "true" ok 0 > boot Trying cdrom... Not a bootable ELF image Not a bootable a.out image No valid state has been set by load or init-program ok 0 > boot cdrom:d Not a bootable ELF image Loading a.out image... Loaded 65536 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context:
NetBSD/sparc Secondary Boot, Revision 1.12 (autobuild@tgm.daemon.org, Wed Apr 9 02:46:11 UTC 2003)
Booting netbsd
I changed the boot-device like this: diff --git a/arch/sparc32/openbios.c b/arch/sparc32/openbios.c index 60ee180..3624269 100644 --- a/arch/sparc32/openbios.c +++ b/arch/sparc32/openbios.c @@ -187,11 +187,11 @@ arch_init( void ) push_str("floppy"); break; case 'c':
- push_str("disk");
- push_str("disk disk:d");
break; default: case 'd':
- push_str("cdrom");
- push_str("cdrom cdrom:d");
Why not make cdrom an alias to the slice d, as OBP does?
break; case 'n': push_str("net");
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On Wed, Aug 4, 2010 at 4:47 PM, Artyom Tarasenko atar4qemu@googlemail.com wrote:
2010/8/4 Blue Swirl blauwirbel@gmail.com:
On Wed, Aug 4, 2010 at 10:32 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
repository service wrote:
Log: sparc32: fix pre-loaded kernel command line
Fix more breakage from r828:
For some reason, QEMU/Sparc32 does not set FW_CFG_CMDLINE_SIZE, so we have to use FW_CFG_KERNEL_CMDLINE instead.
Setup romvec obp_arg.argv[1] and "boot-file" property.
Remove obsolete command line setup code from obio.c.
Looks good to me.
Just for the record, with r828 the way that bootpath/bootargs should now work is as follows:
- All Qemu configuration should now take place in the arch_init() (or
equivalent) function only
- arch_init() should read the Qemu firmware device and setup the NVRAM
variables boot-device and boot-file (boot-device can now take a list of space-separated devices to search - see ppc/qemu for an example of this)
- Everything else is now magically handled by Forth in (encode-bootpath)
based upon the following rules from the IEEE-1275 spec:
- If either "load" or "boot" are issued on their own, search through each boot-device in order until open returns a valid ihandle, then load/boot from this. bootargs is set to the contents of boot-file.
Does not work: Trying cdrom... Not a bootable ELF image Not a bootable a.out image No valid state has been set by load or init-program
0 > printenv name "options" boot-from "disk" boot-args "" boot-device "cdrom cdrom:d" use-generic? "false" boot-script "" boot-screen "" ttyb-rts-dtr-off "false" ttyb-ignore-cd "true" ttyb-mode "9600,8,n,1,-" ttya-rts-dtr-off "false" ttya-ignore-cd "true" ttya-mode "9600,8,n,1,-" tpe-link-test? "true" load-base "4000" scroll-lock "true" skip-netboot? "false" default-mac-address "false" pci-probe-mask "-1" selftest-#megs "0" screen-#rows "24" screen-#columns "80" output-device "ttya" input-device "ttya" use-nvramrc? "false" oem-logo? "false" oem-banner "" oem-banner? "false" nvramrc "" fcode-debug? "false" diag-switch? "false" boot-file "" boot-command "boot" auto-boot? "true" ok 0 > boot Trying cdrom... Not a bootable ELF image Not a bootable a.out image No valid state has been set by load or init-program ok 0 > boot cdrom:d Not a bootable ELF image Loading a.out image... Loaded 65536 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context:
NetBSD/sparc Secondary Boot, Revision 1.12 (autobuild@tgm.daemon.org, Wed Apr 9 02:46:11 UTC 2003)
Booting netbsd
I changed the boot-device like this: diff --git a/arch/sparc32/openbios.c b/arch/sparc32/openbios.c index 60ee180..3624269 100644 --- a/arch/sparc32/openbios.c +++ b/arch/sparc32/openbios.c @@ -187,11 +187,11 @@ arch_init( void ) push_str("floppy"); break; case 'c':
- push_str("disk");
- push_str("disk disk:d");
break; default: case 'd':
- push_str("cdrom");
- push_str("cdrom cdrom:d");
Why not make cdrom an alias to the slice d, as OBP does?
IIRC that approach had other problems. I'll try if this is no longer the case.
On Wed, Aug 4, 2010 at 4:58 PM, Blue Swirl blauwirbel@gmail.com wrote:
On Wed, Aug 4, 2010 at 4:47 PM, Artyom Tarasenko atar4qemu@googlemail.com wrote:
2010/8/4 Blue Swirl blauwirbel@gmail.com:
On Wed, Aug 4, 2010 at 10:32 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
repository service wrote:
Log: sparc32: fix pre-loaded kernel command line
Fix more breakage from r828:
For some reason, QEMU/Sparc32 does not set FW_CFG_CMDLINE_SIZE, so we have to use FW_CFG_KERNEL_CMDLINE instead.
Setup romvec obp_arg.argv[1] and "boot-file" property.
Remove obsolete command line setup code from obio.c.
Looks good to me.
Just for the record, with r828 the way that bootpath/bootargs should now work is as follows:
- All Qemu configuration should now take place in the arch_init() (or
equivalent) function only
- arch_init() should read the Qemu firmware device and setup the NVRAM
variables boot-device and boot-file (boot-device can now take a list of space-separated devices to search - see ppc/qemu for an example of this)
- Everything else is now magically handled by Forth in (encode-bootpath)
based upon the following rules from the IEEE-1275 spec:
- If either "load" or "boot" are issued on their own, search through each boot-device in order until open returns a valid ihandle, then load/boot from this. bootargs is set to the contents of boot-file.
Does not work: Trying cdrom... Not a bootable ELF image Not a bootable a.out image No valid state has been set by load or init-program
0 > printenv name "options" boot-from "disk" boot-args "" boot-device "cdrom cdrom:d" use-generic? "false" boot-script "" boot-screen "" ttyb-rts-dtr-off "false" ttyb-ignore-cd "true" ttyb-mode "9600,8,n,1,-" ttya-rts-dtr-off "false" ttya-ignore-cd "true" ttya-mode "9600,8,n,1,-" tpe-link-test? "true" load-base "4000" scroll-lock "true" skip-netboot? "false" default-mac-address "false" pci-probe-mask "-1" selftest-#megs "0" screen-#rows "24" screen-#columns "80" output-device "ttya" input-device "ttya" use-nvramrc? "false" oem-logo? "false" oem-banner "" oem-banner? "false" nvramrc "" fcode-debug? "false" diag-switch? "false" boot-file "" boot-command "boot" auto-boot? "true" ok 0 > boot Trying cdrom... Not a bootable ELF image Not a bootable a.out image No valid state has been set by load or init-program ok 0 > boot cdrom:d Not a bootable ELF image Loading a.out image... Loaded 65536 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context:
NetBSD/sparc Secondary Boot, Revision 1.12 (autobuild@tgm.daemon.org, Wed Apr 9 02:46:11 UTC 2003)
Booting netbsd
I changed the boot-device like this: diff --git a/arch/sparc32/openbios.c b/arch/sparc32/openbios.c index 60ee180..3624269 100644 --- a/arch/sparc32/openbios.c +++ b/arch/sparc32/openbios.c @@ -187,11 +187,11 @@ arch_init( void ) push_str("floppy"); break; case 'c':
- push_str("disk");
- push_str("disk disk:d");
break; default: case 'd':
- push_str("cdrom");
- push_str("cdrom cdrom:d");
Why not make cdrom an alias to the slice d, as OBP does?
IIRC that approach had other problems. I'll try if this is no longer the case.
When I changed 'cdrom' to 'cdrom:d', several images couldn't boot, strangely including some of the NetBSD ones which don't want ':d'. Maybe our Sun partition logic is not correct or we are ignoring some kind of bootability flag.
Blue Swirl wrote:
When I changed 'cdrom' to 'cdrom:d', several images couldn't boot, strangely including some of the NetBSD ones which don't want ':d'. Maybe our Sun partition logic is not correct or we are ignoring some kind of bootability flag.
Maybe. The Sun partition handling is one of the parts I haven't really touched, and I can't say that I've seen a specification for it either, so the behaviour is probably unknown.
Interestingly enough, I was testing with netbsd on ppc before I committed the last patch, and it appears to load the kernel but then hang early during execution. A couple of error messages on the console seem to indicate that it wants an implementation of dma-alloc, although it seems a bit strange that it locks the machine up...
ATB,
Mark.
-
Artyom Tarasenko -
Blue Swirl -
Mark Cave-Ayland -
repository service -
Tarl Neustaedter