On Mon, 21 Nov 2016, Michael wrote:
On Mon, Nov 21, 2016 at 07:15:21PM +0100, BALATON
talking about Open Firmware: the standard or the
implementation with the
One thing is left which confuses me: In wikipedia and you say, that you
use the name "Open Firmware" (also, besides as name for a standard) for
an implementation. OK.
But the website gives the impression (and G 3 says), that the implementation
has the name "OpenBIOS"...
I think this is likely because the only somewhat actively maintained
implementation now is OpenBIOS so that's the default page. (I haven't
lived through its history either, only occasionally contributed to it for
the last years.)
running OpenBIOS on real hardware is not something that is well
tested (I'm not sure if it was ever tried but I think it wasn't done
recently) so if you try to do that be prepared for likely needing some
The OLPC project did it, e.g.
I think they used the Open Firmware implementation not OpenBIOS and ran it
on x86 based hardware not PPC. OF and OpenBIOS are different codes, Open
Firmware is mostly in Forth while OpenBIOS is a mixture of C and Forth and
it's targetted mostly for QEMU and other emulators. This page:
even says "Do not try to put OpenBIOS in a real boot ROM, it will not work
and may damage your hardware!" I think this is still mostly correct unless
you know what you are doing and check that the init code is correct.
On real hardware you might have better luck with the Open Firmware code
but as you've found that's old and unmaintained and not sure what it was
running on before. (I think mostly Suns and OLPC with x86 but not sure
about the PPC version.)
As for giving
the device tree to OpenBIOS I think it should just know it or
construct it from discovering the hardware as the point of the device tree
is to describe the hardware for the operating system so the firmware should
know the hardware and provide the device tree. It does not get it from
The "firmware" is our handmade init-assemblercode. It has to enable the
machine (beginning from Adam...) to run C-code in its RAM.
If you have that, you could use that as the init code for your platform
and maybe get something working. I'm still not sure what's your target is
though. Is it to boot a Linux kernel eventually? If so there might be
simpler ways to do that than going through a full blown Open Firmware
implementation, but it's true that with the Open Firmware code mostly in
Forth you might get a lot of functions after you manage to get the Forth
interpreter running if you don't mind the strange programming language.
What will this hardware be? A compute farm made from old game consoles? Do
you plan to have some operating system on it or you just need a basic
firmware to operate it?
OpenBIOS does not have that many drivers but maybe the basics are
there, only the platform specific init code might need to be adapted for a
That would be very nice. We give it a try. Maybe with help from you / the
I'm afraid I can't help much. You wrote in the other reply:
In my understanding we do the basic inits in powerpc
that the right flags are set and the RAM is able to work and then we
call OpenBIOS from this assemblercode and give it our devicetree with
the whole information about the hardware. The OpenBIOS then initialises
serial & network and gives us the opportunity to debug some stuff and to
boot in different ways.
The way OpenBIOS works with QEMU is that it's mapped as ROM and starts
executing when the machine is turned on and does init itself so your code
would need to be integrated in this sequence. (See in arch/ppc/qemu.) On
QEMU it also uses FW_CFG which is a virtual device provided by QEMU to get
some machine informations while it has a lot of other stuff including the
device tree hard coded. This is not optimal but that's what the current
However all this is probably useless for you when I tell that OpenBIOS
does not use network cards and does not really support booting from the
network so if that's your goal you're probably better off with the Open
Firmware code which should support all that and more or be prepared to
implement it in OpenBIOS. Unfortunately I don't think a lot of people know
about Open Firmware code here so not sure you can get help with that.
Did you use OpenBIOS in a recent qemu and have you
been able to remote-debug
it there? I was able to load and run the old OpenBIOS code (from svn repo)
Yes, that works with OpenBIOS as described here:
if debugging OpenBIOS, you'd give the obj-ppc/openbios-qemu.elf.nostrip
for gdb to have symbols and source level debugging. You also need a
cross-gdb supporting the architecture you want to debug so you may need to
compile it the same way you compiled your cross compiler (or get it from
the same place).
When you say OpenBIOS code from svn repo are you really referring to Open
Firmware? Debugging that under QEMU should work similarly but as I've said
not much is known about that at least not by me.
Debugging this way uses the built in gdbserver in QEMU, if you later want
to debug on real hardware you might need something like described here:
that is running gdbserver on the hardware somehow. Don't let it confuse
you that in this page the other machine that would be your real hardware
is emulated in qemu, but this is not using the built in gdbserver of QEMU.