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
This change seems to fix the problem here with silo not being able
to deal with bss data. The problem is that silo does access to an address
which is calculated from %i3 + bss offset, so %i3 must be somehow initialized.
To do this I created start_client_image() helper which initializes
clear context,
fills it with stack pointer and client interface handler pointer then
switches to it.
According to docs all registers not used to convey data to client code must be
cleared.
Since my sparc64-elf-gcc cross compiler managed to discard stores
to __context in switch_to() I had to make __context a volatile pointer.
Signed-off-by: Igor Kovalenko <igor.v.kovalenko(a)gmail.com>
--
Kind regards,
Igor V. Kovalenko
Hi everyone,
It seems that b(case)...b(of)...b(endof)...b(endcase) was broken in
exactly the same way as the b(do)...b(loop) commands during Fcode
evaluation. This patch fixes this, which now allows the Martux/Milax
CDROM images to fail gracefully rather than segfaulting:
OpenBIOS for Sparc64
Configuration device id QEMU version 1 machine id 0
CPUs: 1 x SUNW,UltraSPARC-II
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.0 built on May 24 2009 10:37
Type 'help' for detailed information
[sparc64] Booting file 'disk' with parameters ''
Not a bootable ELF image
Not a Linux kernel image
Not a bootable a.out image
Loading FCode image...
Loaded 7392 bytes
entry point is 0x4000
Evaluating FCode...
isn't unique.
isn't unique.
claim virt = ffffffffffffffff size = 0 align = 0
seek failed
Can't mount root
byte-load: exception caught!
0 >
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
Hi everyone,
This patch implements the missing push-package/pop-package words which
seem to be included in various Fcode bootloaders (even though they are
not part of the official spec). With this patch applied, I now get the
following on my Solaris image/Qemu boot:
OpenBIOS for Sparc64
Configuration device id QEMU version 1 machine id 0
CPUs: 1 x SUNW,UltraSPARC-II
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.0 built on May 24 2009 10:08
Type 'help' for detailed information
[sparc64] Booting file 'disk' with parameters ''
Not a bootable ELF image
Not a Linux kernel image
Not a bootable a.out image
Loading FCode image...
Loaded 5936 bytes
entry point is 0x4000
Evaluating FCode...
Loading package 1.4 04 Aug 1995 13:02:54.
open isn't unique.
FCode UFS Reader 1.12 00/07/17 15:48:16.
Loading: /platform//ufsboot
claim virt = 1 size = 200 align = 0
Loading: /platform/sun4u/ufsboot
Boot load failed.
ok
0 >
So it looks as if we're now at the point where we need to start
implementing the client interface claim/release functions.
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