On Tue, Aug 6, 2019 at 1:11 AM BALATON Zoltan <balaton(a)eik.bme.hu> wrote:
On Thu, 1 Aug 2019, BALATON Zoltan wrote:
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:
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
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.
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:
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
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
OpenBIOS mailing list -- openbios(a)openbios.org
To unsubscribe send an email to openbios-leave(a)openbios.org
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu