Hello Zoltan, hey list,
On Mon, Nov 21, 2016 at 07:15:21PM +0100, BALATON Zoltan wrote:
... For forth commands I've found this page useful (not sure if this is linked from somewhere): http://www.firmworks.com/QuickRef.html
Thank you, I found this (and more) last week. The OLPC sites are the best for me:
1: http://wiki.laptop.org/go/Open_Firmware 2: http://wiki.laptop.org/go/Forth_Lessons 3: http://wiki.laptop.org/go/Cross_Compiling_Open_Firmware
... 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).
... 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.
... 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.
fixing. This is true for any implementation that does not support the hardware you want to run it on, then you likely need to port it.
That there will be the need for porting was clear.
... it's enough to have the basics in there. Not sure how much up to date is this but this is discussed in the kernel documentation here: https://www.kernel.org/doc/Documentation/devicetree/booting-without-of.txt
Thank you, I missed this source.
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.
... 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.
new board. For ppc these would be in arch/ppc. Running on QEMU is quite a bit simpler as we can skip a lot of init code (such as memory controller or other hardware) so maybe these are not well implemented or buggy as they were not tested with real hardware for a while. ...
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".
Thank you for your time and suggestions, greetings, Michael
On 2016-Nov-21 15:07 , Michael wrote:
Thank you, I found this (and more) last week. The OLPC sites are the best for me:
1: http://wiki.laptop.org/go/Open_Firmware 2: http://wiki.laptop.org/go/Forth_Lessons 3: http://wiki.laptop.org/go/Cross_Compiling_Open_Firmware
[...]
Some history behind that...
Back in the dim, dark past (1980's), Mitch Bradley worked for Sun Microsystems on system startup. At some point, he left to create a startup (firmworks.com), and produced a forth kernel used for booting SPARCs, which sun adopted for the sun4c models and later. They worked together at producing an IEEE standard, IEEE 1275-1994.
For a long time, Sun and Firmworks exchanged source code (I think actually mostly Firmworks to Sun, but formally listed as exchange). During that period, several other companies produced systems based on an OpenFirmware initialization (Motorola, Apple & IBM's PPC implementations are the ones which come to mind). As I understand it, these were entirely separate implementations based on the IEEE 1275 document. Fujitsu based their systems on a SPARC core, and I believe based their code on Sun's implementation.
Decades went by, and industry interest in OpenFirmware waned (mostly because EFI came on the scene, and for all its faults, it did adopt most of OpenFirmware's important concepts and the massive support from the PC market meant it was going to prevail), so eventually Mitch shut down Firmworks.
Mitch got a contract to help the One-Laptop project with their BIOS work and eventually persuaded them to ditch the traditional PC bios and instead use a forth-based initialization, based on Firmwork's OpenFirmware implementation. There were a number of factors involved, primarily being that they were tremendously prom-limited, and a forth implementation can pack in more functionality per byte than ordinary executable code can.
Since Mitch is the leading prophet of the OpenFirmware cult, he's made a point of carefully documenting everything involving OpenFirmware on One-Laptop. So anything you find under laptop.org is going to be the most recent edition by the person who knows the most about the standard and implementations.
Hello Tarl, thank you for this background infos! I like to learn from history.
Am Montag, den 21.11.2016, 16:34 -0500 schrieb Tarl Neustaedter: ...
Since Mitch is the leading prophet of the OpenFirmware cult, he's made a point of carefully documenting everything involving OpenFirmware on One-Laptop. So anything you find under laptop.org is going to be the most recent edition by the person who knows the most about the standard and implementations.
...
So thank you Mitch, also. He did a nice and sustainable job! In my opinion, more Computers should use OpenFirmware instead of old BIOS or EFI.
Compliments.
On Mon, Nov 21, 2016 at 10:34 PM, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2016-Nov-21 15:07 , Michael wrote:
Thank you, I found this (and more) last week. The OLPC sites are the best for me:
1: http://wiki.laptop.org/go/Open_Firmware 2: http://wiki.laptop.org/go/Forth_Lessons 3: http://wiki.laptop.org/go/Cross_Compiling_Open_Firmware
[...]
Some history behind that...
Back in the dim, dark past (1980's), Mitch Bradley worked for Sun Microsystems on system startup. At some point, he left to create a startup (firmworks.com), and produced a forth kernel used for booting SPARCs, which sun adopted for the sun4c models and later. They worked together at producing an IEEE standard, IEEE 1275-1994.
For a long time, Sun and Firmworks exchanged source code (I think actually mostly Firmworks to Sun, but formally listed as exchange). During that period, several other companies produced systems based on an OpenFirmware initialization (Motorola, Apple & IBM's PPC implementations are the ones which come to mind). As I understand it, these were entirely separate implementations based on the IEEE 1275 document. Fujitsu based their systems on a SPARC core, and I believe based their code on Sun's implementation.
Decades went by, and industry interest in OpenFirmware waned (mostly because EFI came on the scene, and for all its faults, it did adopt most of OpenFirmware's important concepts [...]
That's a very interesting point. Does EFI actually have any advantages over IEEE 1275? For instance, Apple moved to EFI, but was their real motivation? Did they just wanted to ditch Forth?
Mitch got a contract to help the One-Laptop project with their BIOS work and eventually persuaded them to ditch the traditional PC bios and instead use a forth-based initialization, based on Firmwork's OpenFirmware implementation. There were a number of factors involved, primarily being that they were tremendously prom-limited, and a forth implementation can pack in more functionality per byte than ordinary executable code can.
Also the first versions of OLPC were not based on x86 CPUs, so there was no requirements on the PC BIOS compatibility initially.
Since Mitch is the leading prophet of the OpenFirmware cult, he's made a point of carefully documenting everything involving OpenFirmware on One-Laptop. So anything you find under laptop.org is going to be the most recent edition by the person who knows the most about the standard and implementations.
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
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.
Thomas
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 ;-)
On 22/11/16 07:58, Thomas Huth wrote:
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
Funnily enough one of the conversations I had with Ben a while back was as to whether it was worth switching OpenBIOS to libfdt.
While it works well for the tree properties, I'm not exactly clear how it would work in the case of binding Forth words into the device tree nodes (e.g. as in https://github.com/openbios/openbios/blob/ef8a14e8afb47635c9c5f7524a52c32518...) and other arbitrary C functions without getting messy.
How does SLOF cope with this?
ATB,
Mark.
On 23.11.2016 22:43, Mark Cave-Ayland wrote:
On 22/11/16 07:58, Thomas Huth wrote:
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
Funnily enough one of the conversations I had with Ben a while back was as to whether it was worth switching OpenBIOS to libfdt.
While it works well for the tree properties, I'm not exactly clear how it would work in the case of binding Forth words into the device tree nodes (e.g. as in https://github.com/openbios/openbios/blob/ef8a14e8afb47635c9c5f7524a52c32518...) and other arbitrary C functions without getting messy.
How does SLOF cope with this?
SLOF transforms the FDT from QEMU to its internal, Forth-based representation once, then adds some necessary Forth words manually where required. E.g. have a look at the end of this file here:
https://github.com/aik/SLOF/blob/master/board-qemu/slof/tree.fs
It's doing things like this to add missing words:
s" /aliases" find-device : open true ; : close ; device-end
Once the device tree is in place, the FDT is discarded and never used again.
IMHO, libfdt is nice if you need to create a FDT only once (e.g. to pass it to the OS), or if you only need to read from a FDT, but it is not very well suited for dynamic manipulations - and since there is also no concept of device tree node functions (Forth words) in here, it does not make too much sense to completely base an Open Firmware implementation on this library. For your firmware-internal representation, you better use something else, and not a FDT.
Thomas
On 22/11/16 07:58, Thomas Huth wrote:
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/
Hi Thomas,
I've now updated the relevant page on the OpenBIOS wiki to point to the new SLOF repository URL - let me know if there are any other changes required.
ATB,
Mark.
On 13.02.2017 09:55, Mark Cave-Ayland wrote:
On 22/11/16 07:58, Thomas Huth wrote:
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/
Hi Thomas,
I've now updated the relevant page on the OpenBIOS wiki to point to the new SLOF repository URL - let me know if there are any other changes required.
Hi Mark!
Thanks a lot for the update! If you've got some spare minutes, it would also be great if you could change the wording of the last two items a little bit, since this has apparently been written in the very early days of SLOF and is not up-to-date anymore:
- Instead of "Pseudo Open Firmware", please write "An Open Firmware implementation" (since most of IEEE1275 has been realized nowadays)
- Instead of " Low Level Firmware for IBM's JS20 (closed source)" please write: "Low Level Firmware for IBM's JS20, JS21 and the YDL PowerStation (partially closed source)"
- And maybe add an additional entry like this: "Firmware for the emulated 'pseries' machine of QEMU"
Thomas
On 13/02/17 10:22, Thomas Huth wrote:
Thanks a lot for the update! If you've got some spare minutes, it would also be great if you could change the wording of the last two items a little bit, since this has apparently been written in the very early days of SLOF and is not up-to-date anymore:
- Instead of "Pseudo Open Firmware", please write "An Open Firmware
implementation" (since most of IEEE1275 has been realized nowadays)
- Instead of " Low Level Firmware for IBM's JS20 (closed source)" please
write: "Low Level Firmware for IBM's JS20, JS21 and the YDL PowerStation (partially closed source)"
- And maybe add an additional entry like this: "Firmware for the emulated 'pseries' machine of QEMU"
Thomas
All done :)
ATB,
Mark.
-
Artyom Tarasenko -
BALATON Zoltan -
Mark Cave-Ayland -
Michael -
Michael Wimmer -
Tarl Neustaedter -
Thomas Huth