I have begun doing work with OpenBIOS. I was wondering if it is
possible to compile OpenBIOS for PowerPC on Mac OS X? If not, what
Linux distro should I use? Any advice would really help.
Hi all,
So given that the Fcode evaluator is sorted for Solaris 10, I thought
I'd try my original Solaris 9 disk image again and was surprised to find
that it didn't boot.
Further investigation seems to show that strangely encoded device names
are being passed into cif-open which is failing:
: get-file ( 6000 ffe35870 27 )
00000000ffe36378: fname>devname$
3 > 2dup type /platform/OpenBiosTeam,OpenBIOS/ufsboot ok
3 > resume ok
( 6000 ffe35870 27 )
00000000ffe36378: fname>devname$ ( 6000 ffe35ee8 2f )
00000000ffe36380: ufs-fopen
3 > 2dup type cdrom:a,|platform|OpenBiosTeam,OpenBIOS|ufsboot ok
3 > resume ok
( 6000 ffe35ee8 2f )
00000000ffe36380: ufs-fopen
: ufs-fopen ( 6000 ffe35ee8 2f )
00000000ffe360e8: drop ( 6000 ffe35ee8 )
00000000ffe360f0: cif-open ( 6000 0 )
00000000ffe360f8: (semis)
: get-file ( 6000 ffe35870 17 )
00000000ffe36378: fname>devname$
3 > 2dup type /platform/sun4u/ufsboot ok
3 > resume ok
( 6000 ffe35870 17 )
00000000ffe36378: fname>devname$ ( 6000 ffe35ee8 1f )
00000000ffe36380: ufs-fopen
3 > 2dup type cdrom:a,|platform|sun4u|ufsboot ok
3 > resume ok
( 6000 ffe35ee8 1f )
00000000ffe36380: ufs-fopen
: ufs-fopen ( 6000 ffe35ee8 1f )
00000000ffe360e8: drop ( 6000 ffe35ee8 )
00000000ffe360f0: cif-open OFMEM: ofmem_claim_virt virt=ffffffffffffffff
size=0000000000000200 align=0000000000000001
( 6000 0 )
00000000ffe360f8: (semis)
It looks as if a special type of device-specifier is being passed into
cif-open consisting of a device and argument, a comma, then the actual
filename required with /s replaced by |s.
Is this some kind of special syntax that needs to be taught to the dev
word and/or cif-open words?
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
Sirius Labs: http://www.siriusit.co.uk/labs
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
Hi,
We have run into an issue with our FCodes tokenized using FCode-utils 1.0.2 toke,
on specific SPARC (Enterprise) platforms: M4000, M9000.
Power-up device probe yields the following warning message on the console:
WARNING: /pci@20,600000/...: FCode checksum error; expected: 280d result: 2837
After looking at the OBP sources, I found that the routine:
fcode-sum-ok? : obp/dev/pci/fcode-rom.fth
calculates the checksum by adding every FCode image (excluding header) byte and doing:
lwsplit + lwsplit + h# ffff and
on the sum. The
lwsplit + lwsplit +
apparently breaks the OpenFirmware spec.
OpenFirmware-1275 section 5.2.2.5 describes the checksum algorithm as:
Checksum is the doublet size sum of the bytes of the program body (i.e.,
excluding the header), calculated using two's complement addition and
ignoring overflow.
FCode-utils 1.0.2 toke calculates the checksum in function:
finish_fcodehdr : toke/emit.c
as described in the spec.
How do we deal with this?
Any suggestions?
Thanks for any response(s)!
-Asif