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 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
Hello guys,
It's awesome seeing you've made some progress towards emulating
Solaris/sparc64!
However trying myself, compiling on Mac OS X (after making sure that
NEED_INT128_T is defined) fails with the following error:
HOSTCC host/kernel/bootstrap.o
In file included from ../include/openbios/sysinclude.h:7,
from ../kernel/bootstrap.c:9:
/usr/include/stdlib.h:267: error: syntax error before ‘arc4random’
make[1]: *** [host/kernel/bootstrap.o] Error 1
The return type of arc4random is u_int32_t, which is defined (in my
case) in <ppc/types.h>. Not sure what goes wrong there. I thought it
could be a name clash with OpenBIOS' __TYPES_H (malc would be
furious!), but - luckily - Apple uses __TYPES_H_ for their _types.h.
Anyway, not having these functions declared by defining
_POSIX_C_SOURCE made the compilation proceed with only one warning:
HOSTCC host/kernel/bootstrap.o
../kernel/bootstrap.c: In function ‘interpret_source’:
../kernel/bootstrap.c:529: warning: implicit declaration of function
‘strcasecmp’
If I symlink .../share/qemu/openbios-sparc64 to .../obj-sparc64/
openbios-builtin.elf (or copy it over) I get this at runtime:
qemu: fatal: Trap 0x0010 while trap level (5) >= MAXTL (5), Error state
pc: 0000000000004200 npc: 0000000000004204
General Registers:
%g0: 0000000000000000 %g1: 0000000000000000 %g2: 0000000008000000 %g3:
0000000000000000
%g4: 0000000000000000 %g5: 0000000000000000 %g6: 0000000000000000 %g7:
0000000000000000
Current Register Window:
%o0: 00000000ffe00000 %o1: 00000000ffe01000 %o2: 000001fff0100000 %o3:
000001fff0000000
%o4: 0000000000000000 %o5: 0000000000000000 %o6: 0000000000000000 %o7:
000001ff00000000
%l0: 0000000007e80000 %l1: 000001ff00000000 %l2: 000001fff0080000 %l3:
0000000000000000
%l4: 0000000000000000 %l5: 0000000000000000 %l6: 0000000000000000 %l7:
0000000000000000
%i0: 0000000000000000 %i1: 0000000000000000 %i2: 0000000000000000 %i3:
0000000000000000
%i4: 0000000000000000 %i5: 0000000000000000 %i6: 0000000000000000 %i7:
0000000000000000
Floating Point Registers:
%f00: 000000000.000000 000000000.000000 000000000.000000
000000000.000000
%f04: 000000000.000000 000000000.000000 000000000.000000
000000000.000000
%f08: 000000000.000000 000000000.000000 000000000.000000
000000000.000000
%f12: 000000000.000000 000000000.000000 000000000.000000
000000000.000000
%f16: 000000000.000000 000000000.000000 000000000.000000
000000000.000000
%f20: 000000000.000000 000000000.000000 000000000.000000
000000000.000000
%f24: 000000000.000000 000000000.000000 000000000.000000
000000000.000000
%f28: 000000000.000000 000000000.000000 000000000.000000
000000000.000000
pstate: 0x00000015 ccr: 0x99 asi: 0x00 tl: 5 fprs: 0
cansave: 6 canrestore: 0 otherwin: 0 wstate 0 cleanwin 6 cwp 7
fsr: 0x00000000
../qemu-solaris-sparc.command: line 3: 3289 Abort trap /
Users/andreas/Q/latest/bin/qemu-system-sparc64 -nographic -boot d -
cdrom /Users/andreas/Q/sol-10-u3-ga-sparc-dvd.iso
This looks different from what you've posted and is identical with
QEMU's version of openbios-sparc64. Same with or without -nographic.
Any ideas?
Regards,
Andreas
Hi everyone,
Here is a second version of the patch which attempts to reverse the
argument order of the CIF Forth words so that they can be called
correctly from both Forth and C.
The patch is fairly straightforward; probably the only unexpected part
is the need to rename the existing /openprom/client-services "claim" and
"release" words to "cif-claim" and "cif-release" respectively. This is
because we need to use the "claim" and "release" words in
forth/system/ciface.fs to reverse the argument order before calling the
real underlying words.
I've tested this on a FC12 PPC CD as well as my SPARC64 Milax CD and
with this version of the patch, the CIF words are called correctly in
both cases. I'd like to apply this reasonably soon, so please can people
test on their setups to make sure it doesn't break anything?
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk>
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
On Nov 29, 2009, at 6:22 PM, openbios-request(a)openbios.org wrote:
> It's probably not an OpenBIOS build problem. I was able to execute an
> OSX-built OpenBIOS on Linux and OpenSolaris. Executing a Linux-built
> OpenBIOS on OSX/ppc failed. Using same GCC 4.4.2 and binutils 2.20.
> That still leaves OS differences, the endianness, the bitness, etc.
> etc. Maybe Blue has a hunch?
>
> Andreas
You were able to build OpenBIOS on Mac OS X? If so, how? Every
attempt I made has failed. I'm using GCC 4.0.1. Could it be a problem
with my compiler version?
Hello,
When compiling the FCode utils on Mac OS X v10.5 I got an error when
stripping. A workaround was to run `make STRIP=:`, not stripping at all.
I now figured out that it's about the -s option: -s is short for --
strip-all in GNU strip but in Apple's strip -s references a text file
with a list of symbols to preserve. I didn't spot an obvious
equivalent to --strip-all.
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPa…
Since the fcode-utils use pure Makefiles without prior art of platform-
based decisions, I am wondering how to best supply a patch...
Should the hardcoded -s be moved to a new STRIPFLAGS variable or into
STRIP itself?
And more important, how would we set either variable based on
platform? Do we assume GNU make so that we can get the platform via $
(shell sh - c 'uname -s 2>/dev/null') or similar, as seen in Git?
Creating a configure script seems like overkill for such a tiny fix.
Thanks,
Andreas
There should be a 'make' command option that builds only the qemu
target, and not the openbios-unix target. Something like this is what
I have in mind:
make -qemu_only
Whenever I try to build OpenBIOS, I receive a whole bunch of errors
with the unix target, but not with the openbios-qemu.elf target for
some reason.
Hi all,
While setting up a PPC cross-compiler environment for OpenBIOS, I
noticed that the default cross-compiler prefix is set to
'powerpc-linux-gnu-' as opposed to 'powerpc-elf-'.
Is there any particular reason that we need the linux platform version,
instead of the elf version which is used by SPARC? The reason I ask is
that the Linux platform version is much much harder to compile as you
need an extra set of glibc headers and have to bootstrap the gcc build
by hand in order to produce the working final compiler.
On my tests here everything seems to work fine with just the
'powerpc-elf-' prefix as far as I can tell.
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