[OpenBIOS] Beginners How-To for DTS and OpenFirmware?

[BALATON Zoltan]

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:
https://www.openfirmware.info/OpenBIOS
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
> list.

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 
state is.

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: 
https://en.wikibooks.org/wiki/QEMU/Debugging_with_QEMU 
http://wiki.qemu.org/Documentation/Debugging

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:
https://balau82.wordpress.com/2010/08/17/debugging-arm-programs-inside-qemu/

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.

Regards,
BALATON Zoltan