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