QEMU OpenBIOS booting?
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
8 years, 12 months
- 13
- 55
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
10 years
- 2
- 1
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
10 years
- 1
- 0
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
10 years
- 5
- 5
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
10 years
- 2
- 2
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
10 years
- 1
- 0
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
10 years, 1 month
- 2
- 1
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
10 years, 1 month
- 2
- 1
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
;
10 years, 1 month
- 1
- 0
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
10 years, 1 month
- 2
- 1