[OpenBIOS] Beginners How-To for DTS and OpenFirmware?
thuth at redhat.com
Tue Nov 22 08:58:41 CET 2016
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
>> 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:
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 ;-)
More information about the OpenBIOS