Re: [OpenBIOS] Sparc64 OpenBIOS

[Nick Couchman]

Here's the output from the Nevada v66 version of Solaris:

OpenBIOS for Sparc64
Configuration device id QEMU version 1 machine id 0
CPUs: 1 x SUNW,UltraSPARC-II
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.0 built on Oct 20 2009 21:00
  Type 'help' for detailed information

[sparc64] Booting file 'disk' with parameters ''
Not a bootable ELF image
Not a Linux kernel image
Not a bootable a.out image
Not a bootable FCode image
Not a bootable ELF image
Not a Linux kernel image
Not a bootable a.out image
Not a bootable FCode image
Unsupported image format

0 > boot cdrom 
[sparc64] Booting file 'cdrom' with parameters ''
Not a bootable ELF image
Not a Linux kernel image
Not a bootable a.out image
Not a bootable FCode image
Not a bootable ELF image
Not a Linux kernel image
Not a bootable a.out image
Loading FCode image...
Loaded 5936 bytes
entry point is 0x4000
Evaluating FCode...
open isn't unique.
Boot load failed.
 ok
0 >

-Nick
> > > On 2009/11/14 at 08:35, "Nick Couchman"  wrote:
>
> I have a pretty old version of the Solaris Nevada code that I tried to boot, 
> and I got a different error: open isn't unique.  I'll post actual output here 
> in a little while.
>
> I'm pretty new to Qemu and OpenBIOS - what's the best way to go about 
> debugging this?  GDB?  Qemu's built-in debugging?
>
> Thanks,
> Nick
> > > > On 2009/11/13 at 11:38, Tarl Neustaedter  wrote:
> >
> > Nick Couchman wrote:
> > > So, forgive the ignorant question, but does this look to be an OpenBIOS
> >
> > issue or a Qemu issue?
> > >
> >
> > Until you figure out why the seek is failing, you won't know.
> >
> > Minor comment about "seek"; this is in the forth engine file support, 
> > and "seek" actually translates to scsi (or atapi) reads. It will 
> > pre-load about 8k of data for future reads, so when debugging this, if 
> > you put a breakpoint in your HBA code where scsi commands get issued, 
> > you may be able to figure out what mistake it's making.
>
> 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.

--------
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.

Sparc64 OpenBIOS

[Tarl Neustaedter]

Nick Couchman wrote:
> Here's the output from the Nevada v66 version of Solaris:

[...]

Yup. Doesn't tell me anything useful. Does /packages already contain 
either ufs-file-system or hsfs-file-system before you boot? After the 
boot fails, has it been created? Do you see "do-boot" and "get-file" 
methods?

Try "boot cdrom -H" and see if that "open isn't unique" occurs before or 
after that point. Note that Solaris boot under Nevada involves several 
phases with different booters.

- primary booter from blocks 0-15
- Another version from blocks 0-15 from /kernel/<platform>/boot-archive
- reading in the entire boot archive
- Mounting the boot archive that was just read in.
- Jumping in to genunix from that boot archive.

Note that "open isn't unique" may not be an error message. It's entirely 
legal for forth to re-define methods, and it's entirely possible that at 
some point Solaris'  boot blocks do that. It's not always a reported 
error, so I wouldn't be aware of it under normal conditions.