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

[Mark Cave-Ayland]

Nick Couchman wrote:

> Wow, don't I feel stupid right about now.  Default memory for qemu is 128 MB, and when the boot_archive on CD is 170 MB, it's going to be hard to load, eh?  :-).  Maybe the error message it threw should have been my first hint?!
> 
> So, after running qemu with "-m 512" to throw 512MB at it, I come up with the following (this is with fcode-debug? set to true):
> 
> 0 > boot cdrom 
> 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
> doheaders isn't unique.
> fs-pkg$ isn't unique.
> fs-type$ isn't unique.
> /buf-len isn't unique.
> roundup isn't unique.
> cstrlen isn't unique.
> cscount isn't unique.
> $append isn't unique.
> $= isn't unique.
> str++ isn't unique.
> die isn't unique.
> diag-cr? isn't unique.
> find-abort isn't unique.
> get-package isn't unique.
> cif-ph isn't unique.
> cif-open isn't unique.
> cif-close isn't unique.
> cif-read isn't unique.
> cif-seek isn't unique.
> cif-release isn't unique.
> find-cif-method isn't unique.
> chosen-ph isn't unique.
> get-property isn't unique.
> get-string-prop isn't unique.
> get-int-prop isn't unique.
> mmu-ih isn't unique.
> mem-ih isn't unique.
> mmu-claim isn't unique.
> mmu-map isn't unique.
> mem-claim isn't unique.
> (mem-alloc) isn't unique.
> vmem-alloc isn't unique.
> mem-alloc isn't unique.
> mem-free isn't unique.
> /rd-fcode isn't unique.
> rd-offset isn't unique.
> open-abort isn't unique.
> open-cstr isn't unique.
> dev-open isn't unique.
> dev-close isn't unique.
> read-disk isn't unique.
> root-ph isn't unique.
> fs-ih isn't unique.
> nested? isn't unique.
> file-sz isn't unique.
> boot-dev isn't unique.
> boot-dev$ isn't unique.
> loader-base isn't unique.
> load-pkg isn't unique.
> get-bootdev isn't unique.
> mount-root isn't unique.
> vmem-alloc-prop isn't unique.
> get-file isn't unique.
> is-elf? isn't unique.
> is-archive? isn't unique.
> check-elf isn't unique.
> check-fcode isn't unique.
>> bootblk isn't unique.
> get-type isn't unique.
> fflag? isn't unique.
> boot-file isn't unique.
> boot-file$ isn't unique.
> kern? isn't unique.
> kern-file isn't unique.
> kern-file$ isn't unique.
> plat-name isn't unique.
> plat-name$ isn't unique.
> arch-name isn't unique.
> arch-name$ isn't unique.
> targ-file isn't unique.
> targ-file$ isn't unique.
> try-platname isn't unique.
> fj-check isn't unique.
> get-def-arch isn't unique.
> get-arch isn't unique.
> open-path isn't unique.
> lflag? isn't unique.
> zflag? isn't unique.
> fs-name isn't unique.
> fs-name$ isn't unique.
> open-zfs-fs isn't unique.
> next-str isn't unique.
> next-c isn't unique.
> halt? isn't unique.
> parse-bootargs isn't unique.
> rd-alloc-sz isn't unique.
> "ramdisk" isn't unique.
> setup-bootprops isn't unique.
> setup-ramdisk isn't unique.
> fix-elf-mem isn't unique.
> load-file isn't unique.
> setup-props isn't unique.
> exec-file isn't unique.
> do-boot isn't unique.
> 
> byte-load: warning stack overflow, diff 1 
> 
> byte-load: warning stack overflow, diff 1 
> 
> Jumping to entry point 00000000010071d8 for type 0000000000000001...
> switching to new context: entry point 0x10071d8 stack 0x00000000ffe02b59
> warning:interpret: exception -13 caught
> Unhandled Exception 0x0000000020016000
> PC = 0x0000000001014710 NPC = 0x0000000001014714
> Stopping execution
> 
> Can this be debugged using the OpenBIOS/forth debugging, or do I need to whip out gdb, now?  Looks like this error is after it actually switches over to the OpenSolaris kernel, so I'm guessing the OpenBIOS/fcode debugging is going to be of limited value.

Well, looking at that output I'd say that Solaris 10 is now getting as 
far as Milax does before failing which is a pretty good sign (you should 
be past the twirly baton stage by now) :)

The next step is to implement some Forth to handle the cpu register 
storage require for the sync callback if you fancy having a go.


HTH,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs