OpenBIOS April 2009

openbios@openbios.org

17 participants
12 discussions

by Steven Noonan

Hi folks, I've been trying to use OpenBIOS with QEMU, and I've had trouble getting it to boot any PowerPC-based OS discs (Linux, Mac OS X, etc). OpenBIOS just doesn't seem to find anything bootable. If I try booting QEMU with -nographic, I get this output (I get the same with a self-built openbios-qemu.elf from the OpenBIOS SVN as well): ---- snip ---- >> ============================================================= >> OpenBIOS 1.0 [Apr 12 2009 00:55] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 128M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,970FX Welcome to OpenBIOS v1.0 built on Apr 12 2009 00:55 >> ELF - yaboot_startup: Entering boot, no path >> ELF - try_bootinfo: Trying hd:0,ppc\bootinfo.txt >> ELF - try_bootinfo: Can't open hd:0,ppc\bootinfo.txt >> ELF - try_path: Trying hd:2,\ofclient >> ELF - try_path: Can't open hd:2,\ofclient >> ELF - try_path: Trying hd:2,\yaboot conf=hd:2,\yaboot.conf >> ELF - try_path: Can't open hd:2,\yaboot >> *** Boot failure! No secondary bootloader specified *** ---- snip ---- Laurent Vivier suggested in this conversation in February (http://lists.openbios.org/pipermail/openbios/2009-February/003476.html) that there could be a bug in partition map decoding. Has such a bug been confirmed? I was trying to find the bug myself (I am an experienced C/C++ programmer), but the bug seems to be subtle, and my lack of familiarity with the code base doesn't help much. I've been trying to figure this out for 7 hours straight now... Any advice or other help would be much appreciated! - Steven

11 years, 2 months

PATCH: Fix various bugs in bbranch and b?branch implementations

by Mark Cave-Ayland

Hi folks, The attached patch fixes all of the various combinations of forwards and backwards branches for both bbranch and b?branch. With this patch applied to the latest openbios-svn, I can now run OpenBIOS to the point where it crashes out Qemu checked out a few weeks back. Nice :) A couple of the fixes in this patch are for bugs introduced in my last commit. Whilst continuing to dig deeper into various bugs, I didn't appreciate at the time that it is not necessarily the description of the branch words that matters, more how they are tokenized by the Fcode evaluator. For reference, here are the branch test cases I used to verify this behaviour: \ Testing forward b?branch/bbranch (if/else/then equivalent) \ Forth: 1 if .s else abort then here cc c, \ offset16 a6 c, \ 1 (change to a5 for 0 to pick the else clause) 14 c, 0 c, 7 c, \ b?branch (if) 13 c, 0 c, 4 c, \ bbranch (else) b2 c, \ b(>resolve) 02 c, 16 c, \ abort b2 c, \ b(>resolve) 9f c, \ show stack 00 c, \ end \ Test backwards b?branch (begin/until equivalent) \ Forth: 0 begin 1 + dup . dup 3 = until drop here cc c, \ offset16 a5 c, \ 0 b1 c, \ b(<mark) (begin) a6 c, 1e c, \ +1 47 c, \ dup 9d c, 92 c, \ display the number 47 c, \ dup a8 c, \ count to 3 3c c, \ = 14 c, ff c, f7 c, \ b?branch (until) 46 c, \ drop (clear up stack) 0 c, \ End \ Test backwards bbranch (begin/while/repeat equivalent) \ Forth: 3 begin dup . dup while 1 - repeat drop here cc c, \ offset16 a8 c, \ 3 b1 c, \ b(<mark) (begin) 47 c, \ dup 9d c, 92 c, \ display the number 47 c, \ dup 14 c, 00 c, 06 c, \ b?branch (while) a6 c, 1f c, \ -1 13 c, ff c, f6 c, \ bbranch (repeat) b2 c, \ b(>resolve) 46 c, \ drop 00 c, \ end ATB, 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

12 years, 3 months

r485 - trunk/openbios-devel/forth/device

by svn＠openbios.org

Author: blueswirl Date: 2009-04-28 18:40:49 +0200 (Tue, 28 Apr 2009) New Revision: 485 Modified: trunk/openbios-devel/forth/device/fcode.fs Log: Fix various bugs in bbranch and b?branch implementations (Mark Cave-Ayland) Modified: trunk/openbios-devel/forth/device/fcode.fs =================================================================== --- trunk/openbios-devel/forth/device/fcode.fs 2009-04-13 17:05:41 UTC (rev 484) +++ trunk/openbios-devel/forth/device/fcode.fs 2009-04-28 16:40:49 UTC (rev 485) @@ -438,22 +438,27 @@ \ Unconditional branch FCode. Followed by FCode-offset. : bbranch - ['] dobranch , fcode-offset 0< if \ if we jump backwards, we can forsee where it goes + ['] dobranch , + swap resolve-dest + execute-tmp-comp else + setup-tmp-comp ['] dobranch , here 0 , + swap then ; immediate - + \ b?branch ( continue? -- ) \ Conditional branch FCode. Followed by FCode-offset. : b?branch fcode-offset 0< if \ if we jump backwards, we can forsee where it goes - resolve-orig + ['] do?branch , + resolve-dest execute-tmp-comp else setup-tmp-comp ['] do?branch , @@ -468,10 +473,7 @@ : b(<mark) setup-tmp-comp - ['] invert , - ['] do?branch , here - 0 , ; immediate

12 years, 3 months

Tokenizer (fcode-utils 1.0.2) support for 64-bit constants.

by Asif Haswarey

Hi, I have been using the tokenizer "toke" fcode-utils version 1.0.2 from: http://www.openfirmware.info/FCODE_suite I found out recently that toke does not support 64-bit constants. It simply truncates the upper 32-bits. Do we want 64-bit constant support? - Äsif

12 years, 3 months

Re: [OpenBIOS] [Qemu-devel] Re: QEMU OpenBIOS booting?

by Laurent Vivier

>In message: <f43fc5580904191144y1fd8e4d6m3321855d0c558250(a)mail.gmail.com> > Blue Swirl <blauwirbel(a)gmail.com> writes: >: On 4/19/09, M. Warner Losh <imp(a)bsdimp.com> wrote: >: > In message: <f488382f0904190128l4383a56eu67a2f16eb338e61c(a)mail.gmail.com> >: > >: > Steven Noonan <steven(a)uplinklabs.net> writes: >: > : I eventually decided it made more >: > : sense to get QEMU working instead. I did notice that the pre-OpenBIOS >: > : version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was >: > : annoyed to find that OpenBIOS didn't have such support. So, I might as >: > : well add it. >: > >: > >: > Open Hackware was barely enough to boot older versions of Linux. >: > Other operating systems that needed more extensive properties from the >: > OpenFirmware device tree failed to boot because they weren't present. >: > I was involved in a large effort to get FreeBSD/powerpc booting on >: > QEMU only to have it fail utterly because the amount of hacking on >: > OpenHackWare needed was rather large and mysterious... >: >: This is what I get with OpenBIOS: >: >> *** Boot failure! No secondary bootloader specified *** >: >: 0 > boot cd:,\boot\loader cd:0 >: Consoles: Open Firmware console >: >: FreeBSD/Open Firmware/PowerPC bootstrap loader, Revision 0.1 >: (root(a)xserve.lan.xcllnt.net, Thu Apr 16 18:47:58 UTC 2009) >: Memory: 131072KB >: Booted from: cd >: >: Loading /boot/defaults/loader.conf >: /boot/kernel/kernel data=0x4a4ce0+0x3d4e4 syms=[0x4+0x454f0+0x4+0x5a4b9] >: / >: Hit [Enter] to boot immediately, or any other key for command prompt. >: Booting [/boot/kernel/kernel]... >: Kernel entry at 0x13dac0 ... >: panic: moea_bootstrap: no space to copy translations >: Uptime: 1s > >That's similar to the one that I've seen as well. The problem with >this one, IIRC, is that FreeBSD/powerpc is trying to setup the memory >translations for the MMU and the 'translations' property length is >zero, or something like that... > It seems there is the same problem with the Haiku bootloader, I have a patch to correct this. Laurent -- --------------------- Laurent(a)vivier.eu --------------------- "Tout ce qui est impossible reste à accomplir" Jules Verne "Things are only impossible until they're not" Jean-Luc Picard

12 years, 3 months

qemu/openbios boot failure - gcc-4.4 problem?

by Mark McLoughlin

Hi, openbios r463 built with gcc-4.4 doesn't boot: https://bugzilla.redhat.com/494075 $ qemu-system-ppc Fedora-10-ppc-DVD.iso invalid/unsupported opcode: 00 - 18 - 01 (00004070) 00000004 1 invalid/unsupported opcode: 00 - 04 - 17 (000095c8) 000095ec 0 >From https://bugzilla.redhat.com/494075#c11 it appears that r463 built with gcc-4.3 works just fine. Could someone perhaps compare the gcc-4.4 build[1] to a working build and confirm that its a mis-compilation? Thanks, Mark. [1] - http://markmc.fedorapeople.org/openbios-ppc.r463.gcc44

12 years, 3 months

make unoptimized sparc64 build usable with linux kernel

by Igor Kovalenko

Hi! After doing some homework with sparc64-elf-gcc -O0 :) I made this local change in sparc64-call-client.diff It allocates larger stack frame so unoptimized code could save arguments on stack, and then calls of_client_interface(). This at least allows me to use debugger with qemu and unoptimized sparc64 openbios build. -- Kind regards, Igor V. Kovalenko

12 years, 3 months

PATCH: Display more information when ?fcode-verbose enabled

by Mark Cave-Ayland

Hi all, Please find the enclosed patch which enhances the information displayed on the console when ?fcode-verbose is enabled and the Fcode evaluator is running. This is proving to be useful whilst trying to get Qemu to boot a SPARC64 image, and so I think it should be added to the repository. This patch adds the following information to the console display: - The current address of the Fcode evaluator - An optional (compile) prefix if in compile mode - Any strings specified by b(") with a (const) prefix - Any fcode numbers with a (fcode#) prefix - Any branch offsets with an (offset) prefix An example output from this patch gives output similar to the following when trying to boot a SPARC64 disk image: ... ... 4ff4 : named-token [ 0xb6 ] (const) get-devname (fcode#) 87f 5003 : b(:) [ 0xb7 ] 5005 : (compile) [ 0x87c ] 5006 : (compile) b(") [ 0x12 ] (const) bootpath 5011 : (compile) [ 0x87e ] 5012 : (compile) b?branch [ 0x14 ] (offset) 1b 5015 : (compile) b(") [ 0x12 ] (const) Can't find bootpath 502a : (compile) type [ 0x90 ] 502c : (compile) abort [ 0x216 ] 502d : (compile) b(>resolve) [ 0xb2 ] 502f : (compile) [ 0x87d ] 5031 : (compile) [ 0x802 ] 5032 : (compile) b(;) [ 0xc2 ] 5034 : [ 0x87f ] Can't find bootpath byte-load: exception caught! 0 > This is much more helpful when it comes to tracing the results of fcode evaluation and trying to work out why a particular piece of code is failing. ATB, 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

12 years, 3 months

r484 - trunk/openbios-devel/forth/device

by svn＠openbios.org

Author: blueswirl Date: 2009-04-13 19:05:41 +0200 (Mon, 13 Apr 2009) New Revision: 484 Modified: trunk/openbios-devel/forth/device/fcode.fs trunk/openbios-devel/forth/device/feval.fs Log: Display more information when ?fcode-verbose enabled (Mark Cave-Ayland) Modified: trunk/openbios-devel/forth/device/fcode.fs =================================================================== --- trunk/openbios-devel/forth/device/fcode.fs 2009-04-12 18:53:37 UTC (rev 483) +++ trunk/openbios-devel/forth/device/fcode.fs 2009-04-13 17:05:41 UTC (rev 484) @@ -135,6 +135,11 @@ else fcode-num8-signed then + + \ Display offset in verbose mode + ?fcode-verbose if + dup ." (offset) " . cr + then ; \ fcode-string @@ -147,6 +152,11 @@ 2dup bounds ?do fcode-num8 i c! loop + + \ Display string in verbose mode + ?fcode-verbose if + 2dup ." (const) " type cr + then ; \ fcode-header @@ -171,7 +181,13 @@ \ : fcode! ( F:FCode# -- ) - here fcode# fcode-ptr ! + here fcode# + + \ Display fcode# in verbose mode + ?fcode-verbose if + dup ." (fcode#) " . cr + then + fcode-ptr ! ; Modified: trunk/openbios-devel/forth/device/feval.fs =================================================================== --- trunk/openbios-devel/forth/device/feval.fs 2009-04-12 18:53:37 UTC (rev 483) +++ trunk/openbios-devel/forth/device/feval.fs 2009-04-13 17:05:41 UTC (rev 484) @@ -25,6 +25,13 @@ ; : (debug-feval) ( fcode# -- fcode# ) + \ Address + fcode-stream 1 - . ." : " + + \ Indicate if word is compiled + state @ 0<> if + ." (compile) " + then dup fcode>xt cell - lfa2name type dup ." [ 0x" . ." ]" cr ;

12 years, 3 months

PATCH: Correct b?branch for negative offset branches

by Mark Cave-Ayland

Hi everyone, Please find enclosed a patch against current SVN that allows b?branch to work for negative offset branches. With this patch applied, the following output can be seen under openbios-unix on x86 (32-bit): For the non-branch case (flags is set to -1): 0 > here ok 1 > 10 c, ff c, ff c, ff c, ff c, ok 1 > b1 c, ok 1 > 10 c, aa c, aa c, aa c, aa c, ok 1 > 9d c, ok 1 > 02 c, 16 c, ok 1 > 14 c, f7 c, ok 1 > 02 c, 16 c, ok 1 > 00 c, ok 1 > dup 1 byte-load byte-load: exception caught! ok For the branch case (flags is set to 0): 0 > here ok 1 > 10 c, 00 c, 00 c, 00 c, 00 c, ok 1 > b1 c, ok 1 > 10 c, aa c, aa c, aa c, aa c, ok 1 > 9d c, ok 1 > 02 c, 16 c, ok 1 > 14 c, f7 c, ok 1 > 02 c, 16 c, ok 1 > 00 c, ok 1 > dup 1 byte-load -55555556 byte-load: exception caught! ok Note that in terms of docbranch, the branch action being taken is actually the opposite to what you may expect due to the use of setup-tmp-comp (hence the extra invert is required). So as an example, if flags is set to 0 then docbranch does not change the PC, and so we execute the contents of the temporary buffer which contains everything from b(<mark) to b(>resolve). On the other hand, if flags is non-zero then docbranch will branch back to the b(>resolve), and so the temporary buffer contents are ignored. AFAICT the behaviour is correct from the above examples, but again I'd suggest that someone with more OpenBIOS experience should verify to make sure that this is the right approach. ATB, 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

12 years, 3 months