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
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!
[added openbios(a)openbios.org to CC]
On Sun, Aug 30, 2009 at 2:21 AM, Artyom
> is there a generic way to find out mapped device for a virtual
> address? Or at least its physical address?
> ok see get-msecs
> value get-msecs ( Parameter field: 7680000 )
> ok 7680000 map?
> Virtual : 0768.0000
> Context : @ 0.1ffc.0000 01ff.afc1 # 0
> Region : @ 0.1ffa.fc1c 0000.0000 Invalid
> ok 7680000 iomap?
> Virtual : 0768.0000 is not a valid I/O address.
You could try to uncomment DEBUG_MMU in helper.c and op_helper.c,
maybe the MMU dump contains the address.
> Looks like the address 0x7680000 is not mapped to anything, but the
> call returns a value:
> ok get-msecs .
> ok get-msecs .
> The value is obviously wrong, but the question is, where does it come
> from? Is it a RAM or is it one of devices? Didn't see anything similar
> in prtconf dumps.
> Another related question is, are there any known issues related to
> milliseconds counter?
> In the current OpenBIOS "get-msecs" call doesn't return anything at all.
It's definition in forth/device/other.fs is simply:
: get-msecs ( -- n )
On 29.08.2009, at 17:43, svn(a)openbios.org wrote:
> Author: laurent
> Date: 2009-08-29 17:43:00 +0200 (Sat, 29 Aug 2009)
> New Revision: 571
> Replace yaboot_startup() by newworld_boot() which implements generic
> CHRP boot method.
> It finds the CHRP bootscript using the file attribute 'tbxi' and
> the blessed directory.
> This method allows to boot easily Fedora (the bitness detection is
> by the script and yaboot is called with the according yaboot.conf) but
> openSUSE is broken (you have to use "boot cd:,\suseboot\yaboot")
For the lazy readers, what's the reason it worked before but breaks now?