On 21.11.2016 21:07, Michael wrote:
Hello Zoltan, hey list,
On Mon, Nov 21, 2016 at 07:15:21PM +0100, BALATON Zoltan wrote:
This is a bit confusing. There are multiple implementations of the IEEE standard (commonly referred to as Open Firmware) and one of these is also called Open Firmware. These are listed under Implementations on the left of the page at www.openfirmware.info. Another implementation used by QEMU for
Yes and I looked at them. But they are either very old or not usable for ppc (too much work to implement a new arch).
By the way, https://www.openfirmware.info/SLOF seems to be very outdated, too. The links do not work anymore. Could anybody with write-access to the wiki please update the page and point to the git repository? The URL is https://github.com/aik/SLOF/
... 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"... So I have two statements which don't fit well. Please remember that I am new to this and did not live through the history.
AFAIK www.openfirmware.info is generally the website of OpenBIOS - but it also lists the other available implementations. That's indeed a little bit confusing - maybe the other implementations should rather not be listed in a prominent place in the left hand menu, but rather on a separate sub-page?
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 there is no software-interface, then we provide the device-tree maybe in forth or in a blob. Just thinking loudly.
OK, maybe you should consider something else first:
What kind of interface do you want to provide between your firmware and your OS (Linux?)? In the PPC world, there are two interfaces, first the Open Firmware interface, where the OS can call certain "functions" in Open Firmware and even execute arbitrary Forth code. Second, there is the so-called ePAPR interface where the firmware only passes a pointer to the flattened device tree blob to the OS and there is no more interaction between the two.
If you just want to have the ePAPR interface, you might not need an implementation of Open Firmware at all - just write a custom firmware, and finally pass the FDT to the OS.
But if you want the full-blown Open Firmware interface, you either have got to construct the device tree in Forth (AFAIK), or you've got to use some other magic to translate a FDT to an Open Firmware device tree, for example. Not sure about OpenBIOS, but at least SLOF has some code already to transform an FDT into an Open Firmware DT, so you might want to peek there: https://github.com/aik/SLOF/blob/master/board-qemu/slof/fdt.fs
By the way, you mentioned Cell in another mail (may I ask which kind of machines you're using?) ... Did you know that SLOF was once used on the QS20, QS21 and QS22 machines from IBM that also used the Cell chip? Unfortunately, the Cell-specific parts have never been released with the Open Source version of SLOF, the github repo only contains code for the JS20 and JS21 machines, and the pseries QEMU machine.
PS: Yes, sorry, this was a mail from a SLOF guy - if my response is too inappropriate for the openbios mailing list, just tell me to shut up ;-)