[OpenBIOS] Beginners How-To for DTS and OpenFirmware?
balaton at eik.bme.hu
Mon Nov 21 23:35:32 CET 2016
On Mon, 21 Nov 2016, Michael wrote:
> On Mon, Nov 21, 2016 at 07:15:21PM +0100, BALATON Zoltan wrote:
>> talking about Open Firmware: the standard or the implementation with the
>> same name.
> 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.)
>> Actually 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?
>> In fact 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 assemblercode, so
> 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)
> on "qemu-system-ppc".
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.
More information about the OpenBIOS