[commit] r847 - trunk/openbios-devel/libopenbios

[repository service]

Author: blueswirl
Date: Mon Aug  9 22:41:45 2010
New Revision: 847
URL: http://tracker.coreboot.org/trac/openbios/changeset/847

Log:
Fix load breakage by r828

If a loader succeeds, don't try the others.

Signed-off-by: Blue Swirl

Modified:
   trunk/openbios-devel/libopenbios/load.c

Modified: trunk/openbios-devel/libopenbios/load.c
==============================================================================
--- trunk/openbios-devel/libopenbios/load.c	Mon Aug  9 21:21:22 2010	(r846)
+++ trunk/openbios-devel/libopenbios/load.c	Mon Aug  9 22:41:45 2010	(r847)
@@ -44,6 +44,7 @@
 {
    /* Invoke the loaders on the specified device */
    char *param;
+        ucell valid;

#ifdef CONFIG_LOADER_ELF

@@ -57,18 +58,38 @@
    param = pop_fstr_copy();

elf_load(&sys_info, dev, param, &elf_boot_notes);
+        feval("state-valid @");
+        valid = POP();
+        if (valid) {
+                return;
+        }
 #endif

#ifdef CONFIG_LOADER_AOUT
    aout_load(&sys_info, dev);
+        feval("state-valid @");
+        valid = POP();
+        if (valid) {
+                return;
+        }
 #endif

#ifdef CONFIG_LOADER_FCODE
    fcode_load(dev);
+        feval("state-valid @");
+        valid = POP();
+        if (valid) {
+                return;
+        }
 #endif

#ifdef CONFIG_LOADER_FORTH
    forth_load(dev);
+        feval("state-valid @");
+        valid = POP();
+        if (valid) {
+                return;
+        }
 #endif

}

[Nick Couchman]

After these latest changes, I get the following trying to boot Solaris 9:

Configuration device id QEMU version 1 machine id 32
CPUs: 1 x FMI,MB86904
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.0 built on Aug 9 2010 23:27
  Type 'help' for detailed information

Trying cdrom:d...
Not a bootable ELF image
Loading a.out image...
Loaded 7680 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:
bootblk: can't find the boot program
halt, power off

My boot command line looks like this:
./sparc-softmmu/qemu-system-sparc -hda disk0.img -cdrom /media/Sun-ISOs-2/solaris-9/software1.iso -bios ../openbios-devel/obj-sparc32/openbios-builtin.elf.nostrip -nographic -boot d

-Nick
> > > On 2010/08/09 at 14:41, repository service  wrote:
>
> Author: blueswirl
> Date: Mon Aug  9 22:41:45 2010
> New Revision: 847
> URL: http://tracker.coreboot.org/trac/openbios/changeset/847
>
> Log:
> Fix load breakage by r828
>
> If a loader succeeds, don't try the others.
>
> Signed-off-by: Blue Swirl
>
> Modified:
>    trunk/openbios-devel/libopenbios/load.c
> Modified: trunk/openbios-devel/libopenbios/load.c
>
> ==
> --- trunk/openbios-devel/libopenbios/load.c	Mon Aug  9 21:21:22 2010	(r846)
> +++ trunk/openbios-devel/libopenbios/load.c	Mon Aug  9 22:41:45 2010	(r847)
> @@ -44,6 +44,7 @@
>  {
>    /* Invoke the loaders on the specified device */
>    char *param;
>    ucell valid;
>
> #ifdef CONFIG_LOADER_ELF
>
> @@ -57,18 +58,38 @@
>    param = pop_fstr_copy();
>
> elf_load(&sys_info, dev, param, &elf_boot_notes);
>    feval("state-valid @");
>    valid = POP();
>    if (valid) {
>            return;
>    }
>
> #endif
>
> #ifdef CONFIG_LOADER_AOUT
>    aout_load(&sys_info, dev);
>    feval("state-valid @");
>    valid = POP();
>    if (valid) {
>            return;
>    }
>
> #endif
>
> #ifdef CONFIG_LOADER_FCODE
>    fcode_load(dev);
>    feval("state-valid @");
>    valid = POP();
>    if (valid) {
>            return;
>    }
>
> #endif
>
> #ifdef CONFIG_LOADER_FORTH
>    forth_load(dev);
>    feval("state-valid @");
>    valid = POP();
>    if (valid) {
>            return;
>    }
>
> #endif
>
> }

--------
This e-mail may contain confidential and privileged material for the sole use of the intended recipient.  If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information.  In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way.  If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox.  Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

[Mark Cave-Ayland]

Nick Couchman wrote:
> After these latest changes, I get the following trying to boot Solaris 9:
>
> Configuration device id QEMU version 1 machine id 32
> CPUs: 1 x FMI,MB86904
> UUID: 00000000-0000-0000-0000-000000000000
> Welcome to OpenBIOS v1.0 built on Aug 9 2010 23:27
>   Type 'help' for detailed information
>
> Trying cdrom:d...
> Not a bootable ELF image
> Loading a.out image...
> Loaded 7680 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:
> bootblk: can't find the boot program
> halt, power off
>
> My boot command line looks like this:
> ./sparc-softmmu/qemu-system-sparc -hda disk0.img -cdrom /media/Sun-ISOs-2/solaris-9/software1.iso -bios ../openbios-devel/obj-sparc32/openbios-builtin.elf.nostrip -nographic -boot d
>
> -Nick

Hi Nick,

I don't think I've ever tested Solaris with OpenBIOS SPARC32 (although I 
have been told we may have some Solaris 8 CDs lying around somewhere if 
they would do the job?). Is this just an update, or are you reporting a 
regression? If it's a regression, can you do an SVN bisect?

ATB,

M-D.

[Nick Couchman]

> Hi Nick,
>
> I don't think I've ever tested Solaris with OpenBIOS SPARC32 (although I 
> have been told we may have some Solaris 8 CDs lying around somewhere if 
> they would do the job?). Is this just an update, or are you reporting a 
> regression? If it's a regression, can you do an SVN bisect?

Mark,
This is not a regression, that I know of - just posting an update and wondering if this was believed to work, now, or if there are still known issues booting Solaris.  I still cannot boot Solaris under SPARC64 - looks like some recent messages between you and Blue indicate that at least some of the issues with SPARC64 boot are supposed to be cleaned up, but I still get an "out of space" error when trying to boot OpenSolaris for SPARC.  I'll have to try a few other variants and see if I get similar results.

Thanks, again, for all the work - the progress over the last couple of months has been enormous and I'm just chomping at the bit to see Solaris run under Qemu!

:-)

-Nick

--------
This e-mail may contain confidential and privileged material for the sole use of the intended recipient.  If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information.  In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way.  If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox.  Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

[Nick Couchman]

64-bit trying to boot Solaris 9 fails like so:

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 11 2010 04:15
  Type 'help' for detailed information

Trying cdrom:f...
Not a Linux kernel image
Not a bootable ELF image
Not a bootable a.out image

Loading FCode image...
Loaded 5936 bytes
entry point is 0x4000
open isn't unique.

byte-load: exception caught!

Jumping to entry point 0000000000004000 for type 0000000000000010...
Evaluating FCode...
open isn't unique.

byte-load: exception caught!
Image returned with return value 0x0

and Solaris 10 and higher:
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 11 2010 04:15
  Type 'help' for detailed information

Trying cdrom:f...
Not a Linux kernel image
Not a bootable ELF image
Not a bootable a.out image

Loading FCode image...
Loaded 7420 bytes
entry point is 0x4000
ofmem_claim_phys - out of space (failed request for 000000000b5a4000 bytes)
Unhandled Exception 0x0000000000000032
PC = 0x00000000ffd1c8a4 NPC = 0x00000000ffd1c88c
Stopping execution

-Nick
> > > On 2010/08/10 at 02:57, Mark Cave-Ayland

wrote:
> Nick Couchman wrote:
> > After these latest changes, I get the following trying to boot Solaris 9:
> >
> > Configuration device id QEMU version 1 machine id 32
> > CPUs: 1 x FMI,MB86904
> > UUID: 00000000-0000-0000-0000-000000000000
> > Welcome to OpenBIOS v1.0 built on Aug 9 2010 23:27
> >   Type 'help' for detailed information
> >
> > Trying cdrom:d...
> > Not a bootable ELF image
> > Loading a.out image...
> > Loaded 7680 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:
> > bootblk: can't find the boot program
> > halt, power off
> >
> > My boot command line looks like this:
> > ./sparc-softmmu/qemu-system-sparc -hda disk0.img -cdrom
>
> /media/Sun-ISOs-2/solaris-9/software1.iso -bios 
> ../openbios-devel/obj-sparc32/openbios-builtin.elf.nostrip -nographic -boot d
> > -Nick
>
> Hi Nick,
>
> I don't think I've ever tested Solaris with OpenBIOS SPARC32 (although I 
> have been told we may have some Solaris 8 CDs lying around somewhere if 
> they would do the job?). Is this just an update, or are you reporting a 
> regression? If it's a regression, can you do an SVN bisect?
>
> ATB,
>
> M-D.

--------
This e-mail may contain confidential and privileged material for the sole use of the intended recipient.  If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information.  In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way.  If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox.  Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

[Artyom Tarasenko]

2010/8/10 Mark Cave-Ayland :
> Nick Couchman wrote:
> > After these latest changes, I get the following trying to boot Solaris 9:
> >
> > Configuration device id QEMU version 1 machine id 32
> > CPUs: 1 x FMI,MB86904
> > UUID: 00000000-0000-0000-0000-000000000000
> > Welcome to OpenBIOS v1.0 built on Aug 9 2010 23:27
> >  Type 'help' for detailed information
> >
> > Trying cdrom:d...
> > Not a bootable ELF image
> > Loading a.out image...
> > Loaded 7680 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:
> > bootblk: can't find the boot program
> > halt, power off
> >
> > My boot command line looks like this:
> > ./sparc-softmmu/qemu-system-sparc -hda disk0.img -cdrom
> > /media/Sun-ISOs-2/solaris-9/software1.iso

Is "software1" the boot cd? I remember booting from the "install" cd.
> > -bios
> > ../openbios-devel/obj-sparc32/openbios-builtin.elf.nostrip -nographic -boot
> > d
> >
> > -Nick
>
> Hi Nick,
>
> I don't think I've ever tested Solaris with OpenBIOS SPARC32 (although I
> have been told we may have some Solaris 8 CDs lying around somewhere if they
> would do the job?).

should do.
> Is this just an update, or are you reporting a
> regression?

It must be a regression. svn.738 was able to launch ufsboot (and hang
afterwards due to a memory corruption). Didn't check the later
versions.
> If it's a regression, can you do an SVN bisect?

bisecting may be tricky because a few randomly selected versions just
don't compile in my environment (debian/sparc).

HTH

[Nick Couchman]

> Is "software1" the boot cd? I remember booting from the "install" cd.

It's one of them - software1 is one and installation is the other.  Both fail with the same set of messages.
> > > -bios
> > > ../openbios-devel/obj-sparc32/openbios-builtin.elf.nostrip -nographic -boot
> > > d
> > >
> > > -Nick
> >
> > Hi Nick,
> >
> > I don't think I've ever tested Solaris with OpenBIOS SPARC32 (although I
> > have been told we may have some Solaris 8 CDs lying around somewhere if they
> > would do the job?).
>
> should do.
> > Is this just an update, or are you reporting a
> > regression?
>
> It must be a regression. svn.738 was able to launch ufsboot (and hang
> afterwards due to a memory corruption). Didn't check the later
> versions.
> > If it's a regression, can you do an SVN bisect?
>
> bisecting may be tricky because a few randomly selected versions just
> don't compile in my environment (debian/sparc).
>
> HTH

I'm cross compiling on x86, so I may be able to go back a few versions and see if I can get it to boot.  Do you know if this is on the sparc32 or the sparc64 version, or both?

-Nick

--------
This e-mail may contain confidential and privileged material for the sole use of the intended recipient.  If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information.  In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way.  If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox.  Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

[Artyom Tarasenko]

2010/8/11 Nick Couchman :
> > It must be a regression. svn.738 was able to launch ufsboot (and hang
> > afterwards due to a memory corruption). Didn't check the later
> > versions.
> > > If it's a regression, can you do an SVN bisect?
> >
> > bisecting may be tricky because a few randomly selected versions just
> > don't compile in my environment (debian/sparc).
>
> I'm cross compiling on x86, so I may be able to go back a few versions and see if I can get it to boot.  Do you know if this is on the sparc32 or the sparc64 version, or both?

sparc32

[Mark Cave-Ayland]

Artyom Tarasenko wrote:
> > Is this just an update, or are you reporting a
> > regression?
>
> It must be a regression. svn.738 was able to launch ufsboot (and hang
> afterwards due to a memory corruption). Didn't check the later
> versions.

Okay - looks like the romvec obp_devclose() function was broken on 
SPARC32 causing a stack underflow. With latest SVN, I can now see a lot 
more romvec debug activity on kernel boot, however it still crashes :(

Artyom, can you confirm the fix in SVN works for you, and also whether 
we are failing with the same error as before or whether this is 
something new? (i.e. the boot is getting further)

ATB,

Mark.

[Nick Couchman]

Okay, here's what I'm seeing on the 64-bit version, now, trying to boot Solaris 10 and later:

0 > do-boot 
: do-boot  ( Empty ) 
00000000ffe400e8: parse-bootargs  ( Empty ) 
00000000ffe400f0: halt?  ( 0 ) 
00000000ffe400f8: do?branch  ( Empty ) 
00000000ffe40148: get-bootdev  ( Empty ) 
00000000ffe40150: load-pkg  ( Empty ) 
00000000ffe40158: mount-root  ( Empty ) 
00000000ffe40160: zflag?  ( 0 ) 
00000000ffe40168: nested?  ( 0 0 ) 
00000000ffe40170: invert  ( 0 ffffffffffffffff ) 
00000000ffe40178: and  ( 0 ) 
00000000ffe40180: do?branch  ( Empty ) 
00000000ffe401a0: load-file 
: load-file  ( Empty ) 
00000000ffe3fef8: get-arch  ( Empty ) 
00000000ffe3ff00:   ( ffe3e7c8 c ) 
00000000ffe3ff08: open-path  ( 0 ) 
00000000ffe3ff10: loader-base  ( 0 51000000 ) 
00000000ffe3ff18: over  ( 0 51000000 0 ) 
00000000ffe3ff20: get-file 
: get-file  ( 0 51000000 0 ) 
00000000ffe3d760: dup  ( 0 51000000 0 0 ) 
00000000ffe3d768: >r  ( 0 51000000 0 ) 
00000000ffe3d770:   ( 0 51000000 cabc000 ) 
00000000ffe3d778: dup  ( 0 51000000 cabc000 cabc000 ) 
00000000ffe3d780: rot  ( 0 cabc000 cabc000 51000000 ) 
00000000ffe3d788: vmem-alloc-prop 
: vmem-alloc-prop  ( 0 cabc000 cabc000 51000000 ) 
00000000ffe3d620: 2dup  ( 0 cabc000 cabc000 51000000 cabc000 51000000 ) 
00000000ffe3d628: (lit)  ( 0 cabc000 cabc000 51000000 cabc000 51000000 ffe39440 ) 
00000000ffe3d638: catch ofmem_claim_phys - out of space (failed request for 000000000cabc000 bytes)
 ( 0 cabc000 cabc000 51000000 51000000 0 ) 
00000000ffe3d640: do?branch  ( 0 cabc000 cabc000 51000000 51000000 ) 
00000000ffe3d718: nip  ( 0 cabc000 cabc000 51000000 ) 
00000000ffe3d720: nip  ( 0 cabc000 51000000 ) 
00000000ffe3d728: 0  ( 0 cabc000 51000000 0 ) 
00000000ffe3d730: swap  ( 0 cabc000 0 51000000 ) 
00000000ffe3d738: (semis) 
[ Finished vmem-alloc-prop ]  ( 0 cabc000 0 51000000 ) 
00000000ffe3d790: rot  ( 0 0 51000000 cabc000 ) 
00000000ffe3d798: 2dup  ( 0 0 51000000 cabc000 51000000 cabc000 ) 
00000000ffe3d7a0: tuck  ( 0 0 51000000 cabc000 cabc000 51000000 cabc000 ) 
00000000ffe3d7a8: r>  ( 0 0 51000000 cabc000 cabc000 51000000 cabc000 0 ) 
00000000ffe3d7b0:   ( 0 0 51000000 cabc000 cabc000 51000000 cabc000 0 ) 
00000000ffe3d7b8:  Unhandled Exception 0x0000000000000032
PC = 0x00000000ffd1c8a4 NPC = 0x00000000ffd1c88c
Stopping execution

I'm not sure what's happening where the "ofmem_claim_phys - out of space" error occurs - I can pull up gdb, if that helps, and try to track down some more information.

I can't track down any of the errors for Solaris 9 and earlier right now, as a recent change in either qemu or openbios is causing it to fail to even load the fcode image:

Configuration device id QEMU version 1 machine id 32
CPUs: 1 x FMI,MB86904
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.0 built on Aug 11 2010 23:20
  Type 'help' for detailed information

0 > boot cdrom -H 
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 
Not a bootable ELF image
Not a bootable a.out image
No valid state has been set by load or init-program
 ok

I'm happy to provide more information, do more debugging, etc.

-Nick
> > > On 2010/08/10 at 02:57, Mark Cave-Ayland

wrote:
> Nick Couchman wrote:
> > After these latest changes, I get the following trying to boot Solaris 9:
> >
> > Configuration device id QEMU version 1 machine id 32
> > CPUs: 1 x FMI,MB86904
> > UUID: 00000000-0000-0000-0000-000000000000
> > Welcome to OpenBIOS v1.0 built on Aug 9 2010 23:27
> >   Type 'help' for detailed information
> >
> > Trying cdrom:d...
> > Not a bootable ELF image
> > Loading a.out image...
> > Loaded 7680 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:
> > bootblk: can't find the boot program
> > halt, power off
> >
> > My boot command line looks like this:
> > ./sparc-softmmu/qemu-system-sparc -hda disk0.img -cdrom
>
> /media/Sun-ISOs-2/solaris-9/software1.iso -bios 
> ../openbios-devel/obj-sparc32/openbios-builtin.elf.nostrip -nographic -boot d
> > -Nick
>
> Hi Nick,
>
> I don't think I've ever tested Solaris with OpenBIOS SPARC32 (although I 
> have been told we may have some Solaris 8 CDs lying around somewhere if 
> they would do the job?). Is this just an update, or are you reporting a 
> regression? If it's a regression, can you do an SVN bisect?
>
> ATB,
>
> M-D.

--------
This e-mail may contain confidential and privileged material for the sole use of the intended recipient.  If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information.  In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way.  If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox.  Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

[Mark Cave-Ayland]

Nick Couchman wrote:
> Okay, here's what I'm seeing on the 64-bit version, now, trying to boot Solaris 10 and later:
>
> 0 > do-boot 
> : do-boot  ( Empty ) 
> 00000000ffe400e8: parse-bootargs  ( Empty ) 
> 00000000ffe400f0: halt?  ( 0 ) 
> 00000000ffe400f8: do?branch  ( Empty ) 
> 00000000ffe40148: get-bootdev  ( Empty ) 
> 00000000ffe40150: load-pkg  ( Empty ) 
> 00000000ffe40158: mount-root  ( Empty ) 
> 00000000ffe40160: zflag?  ( 0 ) 
> 00000000ffe40168: nested?  ( 0 0 ) 
> 00000000ffe40170: invert  ( 0 ffffffffffffffff ) 
> 00000000ffe40178: and  ( 0 ) 
> 00000000ffe40180: do?branch  ( Empty ) 
> 00000000ffe401a0: load-file 
> : load-file  ( Empty ) 
> 00000000ffe3fef8: get-arch  ( Empty ) 
> 00000000ffe3ff00:   ( ffe3e7c8 c ) 
> 00000000ffe3ff08: open-path  ( 0 ) 
> 00000000ffe3ff10: loader-base  ( 0 51000000 ) 
> 00000000ffe3ff18: over  ( 0 51000000 0 ) 
> 00000000ffe3ff20: get-file 
> : get-file  ( 0 51000000 0 ) 
> 00000000ffe3d760: dup  ( 0 51000000 0 0 ) 
> 00000000ffe3d768: >r  ( 0 51000000 0 ) 
> 00000000ffe3d770:   ( 0 51000000 cabc000 ) 
> 00000000ffe3d778: dup  ( 0 51000000 cabc000 cabc000 ) 
> 00000000ffe3d780: rot  ( 0 cabc000 cabc000 51000000 ) 
> 00000000ffe3d788: vmem-alloc-prop 
> : vmem-alloc-prop  ( 0 cabc000 cabc000 51000000 ) 
> 00000000ffe3d620: 2dup  ( 0 cabc000 cabc000 51000000 cabc000 51000000 ) 
> 00000000ffe3d628: (lit)  ( 0 cabc000 cabc000 51000000 cabc000 51000000 ffe39440 ) 
> 00000000ffe3d638: catch ofmem_claim_phys - out of space (failed request for 000000000cabc000 bytes)
>  ( 0 cabc000 cabc000 51000000 51000000 0 ) 
> 00000000ffe3d640: do?branch  ( 0 cabc000 cabc000 51000000 51000000 ) 
> 00000000ffe3d718: nip  ( 0 cabc000 cabc000 51000000 ) 
> 00000000ffe3d720: nip  ( 0 cabc000 51000000 ) 
> 00000000ffe3d728: 0  ( 0 cabc000 51000000 0 ) 
> 00000000ffe3d730: swap  ( 0 cabc000 0 51000000 ) 
> 00000000ffe3d738: (semis) 
> [ Finished vmem-alloc-prop ]  ( 0 cabc000 0 51000000 ) 
> 00000000ffe3d790: rot  ( 0 0 51000000 cabc000 ) 
> 00000000ffe3d798: 2dup  ( 0 0 51000000 cabc000 51000000 cabc000 ) 
> 00000000ffe3d7a0: tuck  ( 0 0 51000000 cabc000 cabc000 51000000 cabc000 ) 
> 00000000ffe3d7a8: r>  ( 0 0 51000000 cabc000 cabc000 51000000 cabc000 0 ) 
> 00000000ffe3d7b0:   ( 0 0 51000000 cabc000 cabc000 51000000 cabc000 0 ) 
> 00000000ffe3d7b8:  Unhandled Exception 0x0000000000000032
> PC = 0x00000000ffd1c8a4 NPC = 0x00000000ffd1c88c
> Stopping execution
>
> I'm not sure what's happening where the "ofmem_claim_phys - out of space" error occurs - I can pull up gdb, if that helps, and try to track down some more information.

Gosh. cabc000 ~ 212M. I'm guessing this is a large boot_archive?

ATB,

Mark.

[Mark Cave-Ayland]

repository service wrote:
> Author: blueswirl
> Date: Mon Aug  9 22:41:45 2010
> New Revision: 847
> URL: http://tracker.coreboot.org/trac/openbios/changeset/847
>
> Log:
> Fix load breakage by r828
>
> If a loader succeeds, don't try the others.
>
> Signed-off-by: Blue Swirl

I know it wasn't explicitly mentioned in your commit message, but does 
this solve the SPARC64 boot issue?

ATB,

Mark.

[Blue Swirl]

On Tue, Aug 10, 2010 at 8:38 AM, Mark Cave-Ayland
 wrote:
> repository service wrote:
> > Author: blueswirl
> > Date: Mon Aug  9 22:41:45 2010
> > New Revision: 847
> > URL: http://tracker.coreboot.org/trac/openbios/changeset/847
> >
> > Log:
> > Fix load breakage by r828
> >
> > If a loader succeeds, don't try the others.
> >
> > Signed-off-by: Blue Swirl
>
> I know it wasn't explicitly mentioned in your commit message, but does this
> solve the SPARC64 boot issue?

Yes, all my Sparc64 tests pass now. Good news is that at some point
OpenBSD boot has made some progress:

Trying cdrom:f...
Not a Linux kernel image
Not a bootable ELF image
Not a bootable a.out image

Loading FCode image...
Loaded 4893 bytes
entry point is 0x4000
OpenBSD IEEE 1275 Bootblock 1.1
..
Jumping to entry point 0000000000800000 for type 0000000000000001...
switching to new context: entry point 0x800000 stack 0x00000000ffe02b59
> > OpenBSD BOOT 1.2

Trying bsd...
Booting cdrom:f/bsd
2590536@0x1000000+3236576@0x1800000Unhandled Exception 0x0000000000000010
PC = 0x0000000000803e20 NPC = 0x0000000000803e24
Stopping execution

Before, only the line 'OpenBSD IEEE 1275 Bootblock 1.1' was shown.

[Mark Cave-Ayland]

Blue Swirl wrote:
> Yes, all my Sparc64 tests pass now. Good news is that at some point
> OpenBSD boot has made some progress:
>
> Trying cdrom:f...
> Not a Linux kernel image
> Not a bootable ELF image
> Not a bootable a.out image
>
> Loading FCode image...
> Loaded 4893 bytes
> entry point is 0x4000
> OpenBSD IEEE 1275 Bootblock 1.1
> ..
> Jumping to entry point 0000000000800000 for type 0000000000000001...
> switching to new context: entry point 0x800000 stack 0x00000000ffe02b59
> > > OpenBSD BOOT 1.2
>
> Trying bsd...
> Booting cdrom:f/bsd
> 2590536@0x1000000+3236576@0x1800000Unhandled Exception 0x0000000000000010
> PC = 0x0000000000803e20 NPC = 0x0000000000803e24
> Stopping execution
>
> Before, only the line 'OpenBSD IEEE 1275 Bootblock 1.1' was shown.

That's great news! Apologies that the fallout from r828 was a bit more 
than expected, but now that a lot more of the OpenBIOS code is 
centralised it means fixes are shared among all platforms and IMO 
decreases the code complexity substantially.

The fixing of the boot process was the final thing outstanding from my 
original email here: 
http://lists.openbios.org/pipermail/openbios/2010-March/004622.html. I'm 
probably going to take a break for a couple of weeks and then get back 
to working on the Solaris kernel boot on SPARC64.

ATB,

Mark.