On 2009/11/14 at 12:33, Tarl Neustaedter Tarl.Neustaedter@Sun.COM wrote:
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.
Hmm. That's interesting. I wonder if we're getting a conflict between packages in openbios and what the boot blocks are creating. You might find it easier to debug the Solaris Nevada version, depending on just how old it is. Among other things, under OpenSolaris you can find the code for the boot blocks (which changed drastically from Solaris 10 to Nevada), so you aren't quite struggling in the dark.
Also, the Nevada version of the bootblocks responds to the "-H" argument, indicating that after loading the filesystem into /packages, it returns to the OK prompt rather than immediately trying to do the boot itself. That lets you set up breakpoints in the filesystem code before executing them.
I grabbed the newest Nevada ISO (b127) and tried to boot off that - the error is the same as Solaris 10:
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 Loading FCode image... Loaded 7120 bytes entry point is 0x4000 Evaluating FCode...
seek failed
Can't mount root
byte-load: exception caught! ok
I also tried the "boot -H" option and I get the following: 0 > boot -H cdrom [sparc64] Booting file '-H' with parameters 'cdrom' ok
I assume this is the point where I really need the debugger and the breakpoints so that I can step through the rest of the boot process piece-by-piece.
-Nick
I'm pretty new to Qemu and OpenBIOS - what's the best way to go about
debugging this? GDB? Qemu's built-in debugging?
Probably best to wait for the forth debugger that is being discussed. Without breakpoints, you need to basically patch in breakpoints, which is doable but time-consuming.
-------- 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 wrote:
I assume this is the point where I really need the debugger and the breakpoints so that I can step through the rest of the boot process piece-by-piece.
-Nick
Yeah. I actually started on trying to get a Solaris 9 image to boot under Qemu at the beginning of the year, which resulted in several fixes to the Fcode evaluator so that it can now load the Forth bytecode successfully. At this point, I realised that I then needed a Forth debugger before I could continue any further, hence the recent debugging patches to the list.
So, I took a deep breath and used the debugger to step through the boot process of a SPARC64 Milax CD image to see what was happening:
: read-disk ( 8002000 800 8000 ffe4adc8 ) 00000000ffe32458: dup ( 8002000 800 8000 ffe4adc8 ffe4adc8 ) 00000000ffe32460: >r ( 8002000 800 8000 ffe4adc8 ) 00000000ffe32468: 0 ( 8002000 800 8000 ffe4adc8 0 ) 00000000ffe32470: swap ( 8002000 800 8000 0 ffe4adc8 ) 00000000ffe32478: cif-seek ( 8002000 800 ffffffffffffffff ) 00000000ffe32480: do?branch ( 8002000 800 ) 00000000ffe32490: (") ( 8002000 800 ffe324a0 b ) 00000000ffe324b0: die seek failed
Can't mount root Aborted.
It's fairly obvious to see that the seek is failing since it returns -1. But which device is it failing on?
0 > dev-ih ihandle>phandle u. ffe2b830 ok 0 > show-devs ... ffe2b830 /packages/misc-files ...
This implies that it is the seek in /packages/misc-files which is failing, although I'm not really sure at the moment why the read-disk word (which is part of the Milax bootloader) isn't trying to seek on /packages/hsfs-file-system instead?
ATB,
Mark.
Nick Couchman wrote:
[...] I also tried the "boot -H" option and I get the following: 0 > boot -H cdrom [sparc64] Booting file '-H' with parameters 'cdrom' ok
I assume this is the point where I really need the debugger and the breakpoints so that I can step through the rest of the boot process piece-by-piece.
Ah - cool. What I'd suggest doing is, right after getting to the ok prompt on boot -H:
ok see do-boot
What you should see is something like what's in the boot.fth from opensolaris: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/psm/stand/boot...
657 : do-boot ( -- ) 658 parse-bootargs 659 halt? if 660 ." Halted with -H flag. " cr 661 exit 662 then 663 get-bootdev 664 load-pkg 665 mount-root 666 zflag? nested? invert and if 667 fs-name$ open-zfs-fs 668 then 669 load-file ( virt ) 670 setup-props 671 exec-file ( ) 672 ;
So, we've already parsed bootargs, let's do the rest of the method manually (skipping zflag stuff, because I presume on a cdrom you don't have zfs).
ok false to halt? \ undo the -H flag just for the heck of it ok get-bootdev ok load-pkg ok mount-root ok load-file ok setup-props ok exec-file
Somewhere in there you'll see failures, which will give you a better feel for what's going wrong. Once you figure out which one it is, repeat the process, but manually executing the method which caused problems. This would be easier with a debugger, but it's still possible without it.
-
Mark Cave-Ayland -
Nick Couchman -
Tarl Neustaedter