On Tue, Aug 6, 2019 at 1:11 AM BALATON Zoltan firstname.lastname@example.org wrote:
On Thu, 1 Aug 2019, BALATON Zoltan wrote:
https://openbios.org/OpenBOOT so this may make it the same level to get OpenFirmware working for Sparc machines in QEMU as 40p or Pegasos2. At first sight the directory organisation is the same and while the Sun OBP is probably older than OFW so the latter may have changes from later development that prevent just copying the cpu/sparc and drivers from dev over to OFW tree to get it to work for Sparc but it may be that easy or doable with some porting or much more difficult depending on what changes were made between OBP and OFW and how much these have been diverged. This could only be found
After looking at the OFW code some more it looks like it's based on Sun's OBP but it was changed for the OLPC probably omitting what's not needed there and adding what's needed and also reorganising stuff so these are likely not too similar any more. E.g. Most of OpenBoot is just squashed together in a single big file in ofw/core/ofwcore.fth (one can find comments in there where the parts are coming from). So I think just copying cpu/sparc and drivers from OBP might not work without some porting due to differences between OBP and OFW.
The structure is a bit different. OFW is sort of based on OBP, because it was developed by the inventor of OBP. But since Mitch left Sun there were some changes, and to keep their copyright Mitch just copied the complete files from the published OBP tree as is and modified the OFW structure to keep them useable. The above is just my speculations though.
The old OBP structure looks more logical to me, because it really respected the variety of architecures: /arch /cpu /dev In the new one there is still /dev for pci and isa devices, but the contents of /arch is now underneath the /cpu. Meaning that sharing code between say sun and ppc architectures is more tricky.
Concerning the porting devices from OBP, the simple cases would work out of the box, but I vaguelly remember that some cross-package calls have a different API now, and the words which used to use ihandle are using phandle and vice versa.
Therefore it might be easier to first try building OBP natively to see if it produces a working ROM image, but I think this only builds on Solaris so one would need a suitable (virtual) machine for that.
I think you also gonna need a sun compiler for that. And BTW the build process of OFW is really different from OBP. OBP is Makefile based, while for OFW Mitch invented the .bth files.
Then when one is familiar with how it can be built natively, cross building it on x86 Linux could be attempted taking inspiration of the mips port of OFW that uses QEMU user emulation to run a cross built forth executable (also the version of forth working on Linux might be needed from OFW for this if the one in OBP cannot be built on Linux). (Another way OFW uses for cross building PPC and ARM ports is to include its own CPU simulator that can run enough of the CPU machine code that's needed for building forth with inline assembly so if there's a sparc simulator available that's another way to build it but using QEMU like the mips port does might be simpler in this case.)
Then if cross building also works one should have more understanding on what's needed for OBP and if it can be merged with OFW or it's better to keet it as a separate tree. In any case this might give us a more complete firmware for QEMU sparc machines that is mostly identical to the original firmware but we can distribute with QEMU and could make changes if needed. You could consider which is faster to do finding out how to build OBP and what to strip from it to work with QEMU or implement all the missing pieces in OpenBIOS to get to the same level.
FWIW I think the firmware development process for physical and emulated hardware is quite different. For physical hardware the OFW is a clear winner: you just need to have a small core and a serial port and then you have an interactive environment where you can debug all your devices. So, for instance if you want to run AIX on a physical Pegasos board, OFW is the best choice. For the emulated hardware you have a luxus of gdb connected to your system and QEMU monitor to see the devices state, so debugging the C-code might be easier. Ok, you still can not trigger say a DMA transfer from gdb, but writing the C code which would perform it, compiling and executing it is nearly interactive in the virtual environment nowadays.
emulation. I'm not interested in that. I'm trying to get OFW working for Pegasos2 but instead of hardcoding init code as is the usual way of porting OFW to a new platform I'm trying to figure out if it would be possible to do it the SLOF way by passing the initial parameters from QEMU so the same way would work for other machines later so we don't have to implement each board in OFW as well. Since we don't want it to run on real hardware only for QEMU
Meanwhile (after two days fighting with Forth) I've managed to get fdt unflattening from SLOF working with OFW so now I have it working with Pegasos2 emulation with CPU and memory info passed from QEMU via a flattened DTB that's OFW then uses to build the device tree from so I could remove a lot of hard coded values compared to Artyom's PReP/40p port and basically have a mostly generic PPC firmware now that I hope could eventually work with other machines in QEMU as well.
Good job! Beware though that SLOF is GPL- and OFW is MIT-Licensed (except for the OBP parts which are under BSD), so when borrowing the code the minimal exchange entity is a file.
But I'm not there yet and it does not fully work with Pegasos2 either as it cannot handle the PCI bus yet so can't find disks to boot something from. So I'll have to figure out what's needed for that (likely a driver for the Pegasos's system controller/PCI host chip first then hook it up in the firmware somehow). I'll play with it some more and will eventually publish it when I'll need some help with it. For using it on Mac machines in QEMU we would need more drivers that should be written in Forth so it may not be that easy but we'll see when we get there. I'll follow up on the openfirmware mailing list which is proabably more appropriate for this and keep OpenBIOS related discussion here.
For those wanting to get to know OFW better (and this is also useful for OpenBIOS hacking) I've found this documentation from Mitch Bradley: http://wiki.laptop.org/go/Forth_Lessons which starts with Forth basics but in later lessons it also discusses implementation details and working of OpenFirmware in simple terms. This is the concise info on the most needed details what I've asked for before. This is needed to get started with OpenFirmware hacking that probably can't be get from the standard documents and without this info those documents don't make sense or harder to understand so this is recommended reading for everyone wanting to hack on OpenBIOS or OpenFirmware. For learning Forth I've found this book https://www.forth.com/starting-forth/ entertaining enough to get the needed details to survive Forth (the on-line version can be read non-linearly from the table of contents on the right).
Regards, BALATON Zoltan _______________________________________________ OpenBIOS mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org