[OpenBIOS] Sparc64 OpenBIOS

Nick Couchman Nick.Couchman at seakr.com
Wed Nov 18 18:55:50 CET 2009


>>> On 2009/11/18 at 10:37, Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk>
wrote: 
> Tarl Neustaedter wrote:
> 
>> At a guess,
>> 
>> ok dev /packages/hsfs-file-system
>> ok debug open
>> ok dev
> 
> That's correct, i.e. you need to change to package you wish to debug and 
> then invoke "debug <foo>" on the word you wish to step through.
> 
> Note that one thing I have found with the debugger is that you may need 
> to manually add breakpoints for methods called during package opening 
> using the above method, rather than being able to use "U" and "D" 
> interactively.
> 
> AFAICT this is because the debugger needs to locate the start and end of 
> a word in the wordlist, and if the package open fails then the new 
> wordlist isn't set, and hence the word can't be located and added to the 
> debug word list.

(I apologize in advance - the output is kind of long, but I wanted to make sure I posted everything relevant...)

Here's the results of the effort to debug "open":

0 > boot 
[sparc64] Booting file 'cdrom' with parameters ''
Not a bootable ELF image
Not a Linux kernel image
Not a bootable a.out image
Loading FCode image...
Loaded 7120 bytes
entry point is 0x4000
Evaluating FCode...
read-file isn't unique.

: open  ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b7c0 0 0 0 0 0 ffe3a120 ) 
00000000ffe33c78: my-args  ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b7c0 0 0 0 0 0 ffe3a120 ffe493c0 7 ) 
00000000ffe33c80: dev-open  ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b7c0 0 0 0 0 0 ffe3a120 ffe4c230 ) 
00000000ffe33c88: dup  ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b7c0 0 0 0 0 0 ffe3a120 ffe4c230 ffe4c230 ) 
00000000ffe33c90: 0=  ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b7c0 0 0 0 0 0 ffe3a120 ffe4c230 0 ) 
00000000ffe33c98: do?branch  ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b7c0 0 0 0 0 0 ffe3a120 ffe4c230 ) 
00000000ffe33cb0: (lit)  ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b7c0 0 0 0 0 0 ffe3a120 ffe4c230 ffe314e0 ) 
00000000ffe33cc0: (to)  ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b7c0 0 0 0 0 0 ffe3a120 ) 
00000000ffe33cc8: initialize 
seek failed

Can't mount root

byte-load: exception caught!
 ok


So, open is failing during "initialize" - if I debug that:

0 > do-boot 
: open  ( Empty ) 
00000000ffe33c78: my-args  ( ffe493c0 7 ) 
00000000ffe33c80: dev-open  ( ffe4c7e8 ) 
00000000ffe33c88: dup  ( ffe4c7e8 ffe4c7e8 ) 
00000000ffe33c90: 0=  ( ffe4c7e8 0 ) 
00000000ffe33c98: do?branch  ( ffe4c7e8 ) 
00000000ffe33cb0: (lit)  ( ffe4c7e8 ffe314e0 ) 
00000000ffe33cc0: (to)  ( Empty ) 
00000000ffe33cc8: initialize 
: initialize  ( Empty ) 
00000000ffe33448: /sector  ( 800 ) 
00000000ffe33450: mem-alloc  ( 8004000 ) 
00000000ffe33458: (lit)  ( 8004000 ffe31508 ) 
00000000ffe33468: (to)  ( Empty ) 
00000000ffe33470: get-vol-desc 
seek failed

Can't mount root
 Aborted.

get-vol-desc now appears to be the culprit:

0 > do-boot 
: open  ( Empty ) 
00000000ffe33c78: my-args  ( ffe493c0 7 ) 
00000000ffe33c80: dev-open  ( ffe4d358 ) 
00000000ffe33c88: dup  ( ffe4d358 ffe4d358 ) 
00000000ffe33c90: 0=  ( ffe4d358 0 ) 
00000000ffe33c98: do?branch  ( ffe4d358 ) 
00000000ffe33cb0: (lit)  ( ffe4d358 ffe314e0 ) 
00000000ffe33cc0: (to)  ( Empty ) 
00000000ffe33cc8: initialize 
: initialize  ( Empty ) 
00000000ffe33448: /sector  ( 800 ) 
00000000ffe33450: mem-alloc  ( 8008000 ) 
00000000ffe33458: (lit)  ( 8008000 ffe31508 ) 
00000000ffe33468: (to)  ( Empty ) 
00000000ffe33470: get-vol-desc 
: get-vol-desc  ( Empty ) 
00000000ffe318b8: vol-desc  ( 8008000 ) 
00000000ffe318c0: /sector  ( 8008000 800 ) 
00000000ffe318c8: vol-desc-sector#  ( 8008000 800 10 ) 
00000000ffe318d0: /sector  ( 8008000 800 10 800 ) 
00000000ffe318d8: *  ( 8008000 800 8000 ) 
00000000ffe318e0: dev-ih  ( 8008000 800 8000 ffe4d358 ) 
00000000ffe318e8: read-disk 
seek failed

Can't mount root
 Aborted.

read-disk:

0 > do-boot 
: open  ( Empty ) 
00000000ffe33c78: my-args  ( ffe493c0 7 ) 
00000000ffe33c80: dev-open  ( ffe4d910 ) 
00000000ffe33c88: dup  ( ffe4d910 ffe4d910 ) 
00000000ffe33c90: 0=  ( ffe4d910 0 ) 
00000000ffe33c98: do?branch  ( ffe4d910 ) 
00000000ffe33cb0: (lit)  ( ffe4d910 ffe314e0 ) 
00000000ffe33cc0: (to)  ( Empty ) 
00000000ffe33cc8: initialize 
: initialize  ( Empty ) 
00000000ffe33448: /sector  ( 800 ) 
00000000ffe33450: mem-alloc  ( 800a000 ) 
00000000ffe33458: (lit)  ( 800a000 ffe31508 ) 
00000000ffe33468: (to)  ( Empty ) 
00000000ffe33470: get-vol-desc 
: get-vol-desc  ( Empty ) 
00000000ffe318b8: vol-desc  ( 800a000 ) 
00000000ffe318c0: /sector  ( 800a000 800 ) 
00000000ffe318c8: vol-desc-sector#  ( 800a000 800 10 ) 
00000000ffe318d0: /sector  ( 800a000 800 10 800 ) 
00000000ffe318d8: *  ( 800a000 800 8000 ) 
00000000ffe318e0: dev-ih  ( 800a000 800 8000 ffe4d910 ) 
00000000ffe318e8: read-disk 
: read-disk 
seek failed

Can't mount root
 Aborted.

So, for some reason, it cannot step into read-disk for debugging.  If I do "see read-disk":

0 > see read-disk 
: read-disk
  dup >r 0 swap cif-seek if
  " seek failed" die tuck swap r> cif-read <> if
    " read failed" die
  ;
 ok

And, all of these seem to be primitive words - e.g. swap, cif-seek, etc., cannot be debugged.  I would guess "cif-seek" is where it's failing, which looks like this:

0 > see cif-seek 
defer cif-seek
is seek

 ok

And I can't seem to go any deeper than that into debugging.  I'm guessing at this point maybe this is where it gets to be a Qemu issue - that there's something about the seek command in the hardware emulation itself that's failing?

Thanks, again, everyone, for all the help!

-Nick

> 
> 
> HTH,
> 
> Mark.



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



More information about the OpenBIOS mailing list