Hello,
On Tue, 30 Jul 2019, BALATON Zoltan wrote:
- Try to get some other OF implementation working like OpenFirmware. Based
on previous work by Atar for the 40p this is possible although to do it cleanly may be more work and hindered by the need to do it in Forth completely. But Forth is needed to hack on OpenBIOS as well so once someone gets over that hurdle it does not matter. I've started looking at this posibility to find out how much work would this be that's why I was asking the question. I've compiled Atar's work which is now upstram in Mitch Bradley's tree and it worked well with 40p and even started with pegasos2 but of course it did not init the hardware correctly expecting to run on 40p (haven't tried with mac99 but I expect the same result). So OpenFirmware already works on PPC and has some QEMU specific drivers what we may need is porting drivers for mac specific and pegasos2 devices from OpenBIOS from C to Forth (or get equivalents from somewhere else) and think about how to pass the initial device tree similar to SLOF to avoid having to implement each board in OpenFirmware separately (although doing hardcoded board implementation like Atar's 40p might be a quick and dirty way to get it working with much less work).
I gave it a try playing with it for a few hours (without really knowing what am I doing) just to get to know it better and see what's needed. So I started by stripping down Atar's QEMU PReP port removing PReP specific parts and just leaving a bare minimum to work on PowerPC and I actually managed to build a ROM image that works with my pegasos2 emulation and gets me an OF environment over diag serial port now:
$ qemu-system-ppc -M pegasos2 -bios ofw.rom -serial stdio setup_mem_windows: Should enable region 14 Mapping pci1-io-win 0x0+0x2000000 @ 0xfe000000 setup_mem_windows: Should enable region 20
Type 'i' to interrupt stand-init sequence First stand-init: Calibrate CIF buffers DHCP init memory node Instruction cache on Decrementer Enable machine check exceptions Set Memory Map MMU Root node Data cache on Fast CPU mode PCI host bridge CPU nodes Keyboard overrides Memory node not found. not found. /pci/isa/serial@i2f8 not found. /pci/isa/serial@i2f8 not found. not found. not found. , Serial #0, 128 MiB memory installed Open Firmware Copyright (c) 1995-2000, FirmWorks. Copyright (c) 2014,2017,2019 Artyom Tarasenko.
Type any key to interrupt automatic startup 6 5 4 3 2 1
Boot device: net Arguments:
Can't open boot device
ok show-devs /dropin-fs /null-nvram /cpus /<Unnamed> /mmu /memory@0 /aliases /options /openprom /chosen /packages /cpus/PowerPC,603evARTHUR@0 /packages/ext2-file-system /packages/disk-label /packages/iso9660-file-system /packages/fat-file-system /packages/obp-tftp /packages/deblocker /packages/stringio /packages/terminal-emulator /packages/client-services ok printenv Variable Name Value Default Value
hrp-memmap? false false virt-size 0x0 0xffffffff virt-base 0x0 0xffffffff real-size 0x0 0xffffffff real-base 0x0 0xffffffff real-mode? false false diag-switch? false false fcode-debug? false false ip-address 255.255.255.255 255.255.255.255 ip-router ip-domain ip-netmask 255.255.255.0 255.255.255.0 ip-dns-server local-mac-address? false false oem-logo oem-logo? false false oem-banner oem-banner? false false output-device /pci/isa/serial@i2f8 /pci/isa/serial@i2f8 input-device /pci/isa/serial@i2f8 /pci/isa/serial@i2f8 load-base 4194304 4194304 boot-command boot boot auto-boot? true true watchdog-reboot? false false diag-file diag-device net net boot-file boot-device disk net disk net ansi-terminal? true true screen-#columns 80 80 screen-#rows 34 34 silent-mode? false false use-nvramrc? false false nvramrc security-password security-#badlogins 0 security-mode none diag-switch? false false ok dev / ok .properties #address-cells 00000001 ok dev openprom ok .properties model FirmWorks,3.0 aligned-allocator relative-addressing name openprom ok dev /cpus/PowerPC,603evARTHUR ok .properties clock-frequency 05f5e100 reg 00000000 timebase-frequency 007de290 tlb-sets 00000080 tlb-size 00000100 d-cache-sets 00000080 d-cache-block-size 00000020 d-cache-size 00008000 i-cache-sets 00000080 i-cache-block-size 00000020 i-cache-size 00008000 device_type cpu name PowerPC,603evARTHUR ok
Of course it's only the start and has a lot of missing parts yet: does not detect PCI bus and devices (I need to write a driver for the PCI host similar to what Atar did for 40p), it misdetects the CPU (or it may be hard coded somewhere), does not detect memory size (this is mentioned on Atar's blog) and may have other defficiencies. But for a start it works quite well and it was surprisingly easy to get it up thanks to previous work. Given that the Pegasos2 is quite close to PReP and PC hardware most of the drivers for PC like hardware are already there in OF, so maybe if I can make a working driver for the system controller chip the rest would just work or should be relatively easy to fix. So for the pegasos2 this seems to be a viable alternative that may not be too hard to get working if I limit the scope to just the pegasos2.
For Mac machines more drivers would need to be written as these are not included in the open source OF version that was released for OLPC so only those drivers are included which were needed for that. Therefore it would be more work to write those missing drivers. We have USB driver (I've once tried porting that to OpenBIOS[1]) so keyboard and mouse might work where we have USB but we would still need drivers for uninorth and mac-io at least to get something working but maybe others as well, I'm not sure.
For Sparc machines even CPU support is missing so it may be more difficult to get that working. Or maybe not as this could be added based on some other similar architecture: arm, mips and ppc are already there but these do have a lot of Forth files so it may take a while to understand those. I don't know Sparc hardware to tell what drivers may be needed.
But from Atar's blog on getting OF working for QEMU PReP/40p I got the impression that Mitch Bradley (inventor of OpenFirmware and founder of FirmWorks) did help him by releasing some additional drivers or sources that he needed so maybe asking politely would not hurt and it may get easier, unless there are legal hurdles in releasing additional sources. Otherwise those need to be recreated but that may still be doable if someone does not mind learning enough Forth to do it.
I'm not sure which is more work, getting OpenBIOS to the same level or writing drivers for OpenFirmware but maybe for PPC machines it's not much harder to rewrite the missing drivers. For Sparc I'm not sure, PPC support was already there so I don't know what it takes to add a new cpu support.
Regards, BALATON Zoltan
[1] One can follow the thread starting here: https://mail.coreboot.org/pipermail/openbios/2014-May/008244.html but basically the attempt to port OF driver to OpenBIOS ended with: https://mail.coreboot.org/pipermail/openbios/2014-May/008281.html some of those words are already there now but some are still missing. I've ended up finishing the C driver which was finally added, even though I only wanted to try qemu-system-ppc64 originally and did not plan to port a USB driver. That's what I meant saying I end up having to do fixes whenever I try something in OpenBIOS: like trying an FCode ROM the last time. At least OpenFirmware implements the standard already perfectly so we would only need to care about getting it to work with the machine and not if it has everythung that might be needed by stuff using it (or at least much less so than starting from scratch).
It sounds like we are better off sticking with OpenBIOS for now. OpenBIOS has the advantage of being partly written in C. I'm sure any advantages OpenFirmware has currently can always be ported over to OpenBIOS.
On Tue, Jul 30, 2019 at 9:14 PM BALATON Zoltan balaton@eik.bme.hu wrote:
Hello,
On Tue, 30 Jul 2019, BALATON Zoltan wrote:
- Try to get some other OF implementation working like OpenFirmware.
Based
on previous work by Atar for the 40p this is possible although to do it cleanly may be more work and hindered by the need to do it in Forth completely. But Forth is needed to hack on OpenBIOS as well so once
someone
gets over that hurdle it does not matter. I've started looking at this posibility to find out how much work would this be that's why I was
asking
the question. I've compiled Atar's work which is now upstram in Mitch Bradley's tree and it worked well with 40p and even started with
pegasos2 but
of course it did not init the hardware correctly expecting to run on 40p (haven't tried with mac99 but I expect the same result). So OpenFirmware already works on PPC and has some QEMU specific drivers what we may need
is
porting drivers for mac specific and pegasos2 devices from OpenBIOS from
C to
Forth (or get equivalents from somewhere else) and think about how to
pass
the initial device tree similar to SLOF to avoid having to implement
each
board in OpenFirmware separately (although doing hardcoded board implementation like Atar's 40p might be a quick and dirty way to get it working with much less work).
I gave it a try playing with it for a few hours (without really knowing what am I doing) just to get to know it better and see what's needed. So I started by stripping down Atar's QEMU PReP port removing PReP specific parts and just leaving a bare minimum to work on PowerPC and I actually managed to build a ROM image that works with my pegasos2 emulation and gets me an OF environment over diag serial port now:
$ qemu-system-ppc -M pegasos2 -bios ofw.rom -serial stdio setup_mem_windows: Should enable region 14 Mapping pci1-io-win 0x0+0x2000000 @ 0xfe000000 setup_mem_windows: Should enable region 20
Type 'i' to interrupt stand-init sequence First stand-init: Calibrate CIF buffers DHCP init memory node Instruction cache on Decrementer Enable machine check exceptions Set Memory Map MMU Root node Data cache on Fast CPU mode PCI host bridge CPU nodes Keyboard overrides Memory node not found. not found. /pci/isa/serial@i2f8 not found. /pci/isa/serial@i2f8 not found. not found. not found. , Serial #0, 128 MiB memory installed Open Firmware Copyright (c) 1995-2000, FirmWorks. Copyright (c) 2014,2017,2019 Artyom Tarasenko.
Type any key to interrupt automatic startup 6 5 4 3 2 1
Boot device: net Arguments:
Can't open boot device
ok show-devs /dropin-fs /null-nvram /cpus /<Unnamed> /mmu /memory@0 /aliases /options /openprom /chosen /packages /cpus/PowerPC,603evARTHUR@0 /packages/ext2-file-system /packages/disk-label /packages/iso9660-file-system /packages/fat-file-system /packages/obp-tftp /packages/deblocker /packages/stringio /packages/terminal-emulator /packages/client-services ok printenv Variable Name Value Default Value
hrp-memmap? false false virt-size 0x0 0xffffffff virt-base 0x0 0xffffffff real-size 0x0 0xffffffff real-base 0x0 0xffffffff real-mode? false false diag-switch? false false fcode-debug? false false ip-address 255.255.255.255 255.255.255.255 ip-router ip-domain ip-netmask 255.255.255.0 255.255.255.0 ip-dns-server local-mac-address? false false oem-logo oem-logo? false false oem-banner oem-banner? false false output-device /pci/isa/serial@i2f8 /pci/isa/serial@i2f8 input-device /pci/isa/serial@i2f8 /pci/isa/serial@i2f8 load-base 4194304 4194304 boot-command boot boot auto-boot? true true watchdog-reboot? false false diag-file diag-device net net boot-file boot-device disk net disk net ansi-terminal? true true screen-#columns 80 80 screen-#rows 34 34 silent-mode? false false use-nvramrc? false false nvramrc security-password security-#badlogins 0 security-mode none diag-switch? false false ok dev / ok .properties #address-cells 00000001 ok dev openprom ok .properties model FirmWorks,3.0 aligned-allocator relative-addressing name openprom ok dev /cpus/PowerPC,603evARTHUR ok .properties clock-frequency 05f5e100 reg 00000000 timebase-frequency 007de290 tlb-sets 00000080 tlb-size 00000100 d-cache-sets 00000080 d-cache-block-size 00000020 d-cache-size 00008000 i-cache-sets 00000080 i-cache-block-size 00000020 i-cache-size 00008000 device_type cpu name PowerPC,603evARTHUR ok
Of course it's only the start and has a lot of missing parts yet: does not detect PCI bus and devices (I need to write a driver for the PCI host similar to what Atar did for 40p), it misdetects the CPU (or it may be hard coded somewhere), does not detect memory size (this is mentioned on Atar's blog) and may have other defficiencies. But for a start it works quite well and it was surprisingly easy to get it up thanks to previous work. Given that the Pegasos2 is quite close to PReP and PC hardware most of the drivers for PC like hardware are already there in OF, so maybe if I can make a working driver for the system controller chip the rest would just work or should be relatively easy to fix. So for the pegasos2 this seems to be a viable alternative that may not be too hard to get working if I limit the scope to just the pegasos2.
For Mac machines more drivers would need to be written as these are not included in the open source OF version that was released for OLPC so only those drivers are included which were needed for that. Therefore it would be more work to write those missing drivers. We have USB driver (I've once tried porting that to OpenBIOS[1]) so keyboard and mouse might work where we have USB but we would still need drivers for uninorth and mac-io at least to get something working but maybe others as well, I'm not sure.
For Sparc machines even CPU support is missing so it may be more difficult to get that working. Or maybe not as this could be added based on some other similar architecture: arm, mips and ppc are already there but these do have a lot of Forth files so it may take a while to understand those. I don't know Sparc hardware to tell what drivers may be needed.
But from Atar's blog on getting OF working for QEMU PReP/40p I got the impression that Mitch Bradley (inventor of OpenFirmware and founder of FirmWorks) did help him by releasing some additional drivers or sources that he needed so maybe asking politely would not hurt and it may get easier, unless there are legal hurdles in releasing additional sources. Otherwise those need to be recreated but that may still be doable if someone does not mind learning enough Forth to do it.
I'm not sure which is more work, getting OpenBIOS to the same level or writing drivers for OpenFirmware but maybe for PPC machines it's not much harder to rewrite the missing drivers. For Sparc I'm not sure, PPC support was already there so I don't know what it takes to add a new cpu support.
Regards, BALATON Zoltan
[1] One can follow the thread starting here: https://mail.coreboot.org/pipermail/openbios/2014-May/008244.html but basically the attempt to port OF driver to OpenBIOS ended with: https://mail.coreboot.org/pipermail/openbios/2014-May/008281.html some of those words are already there now but some are still missing. I've ended up finishing the C driver which was finally added, even though I only wanted to try qemu-system-ppc64 originally and did not plan to port a USB driver. That's what I meant saying I end up having to do fixes whenever I try something in OpenBIOS: like trying an FCode ROM the last time. At least OpenFirmware implements the standard already perfectly so we would only need to care about getting it to work with the machine and not if it has everythung that might be needed by stuff using it (or at least much less so than starting from scratch). _______________________________________________ OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
On Wed, 31 Jul 2019, BALATON Zoltan wrote:
For Sparc machines even CPU support is missing so it may be more difficult to get that working. Or maybe not as this could be added based on some other similar architecture: arm, mips and ppc are already there but these do have a lot of Forth files so it may take a while to understand those. I don't know Sparc hardware to tell what drivers may be needed.
It's just occured to me that Sun's OpenBoot (and thus the needed cpu support and drivers) is also open sourced and available at 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 out by trying I guess. Even in case these sources cannot completely be merged to a single code base, what has been learned and done with OFW could be applied to and done with OBP to get a ROM built from the original sources for sparc emulation. (One difficulty in building it may be that for ppc there's a cross-forth that can compile it on x86 so no qemu-ppc or PPC hardware is needed to build PPC ROM image which can be done conveniently on x86 host. For Sparc the same likely does not exist so this may need a real or virtual machine or qemu user emulation like used for mips or doing something similar to ppcforth. I think ppcforth depends on a simple PPC simulator in cpu/ppc/ppcsim so if something similar can be found or written for Sparc it may work the same way or qemu-sparc may also work instead.) People interested in Sparc machine emulation (Marc and Atar I think) may want to look at this to evaluate if it would help getting a more complete firmware for Sparc 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 a lot of init code should not be needed which would simplify it to only need to write (or port) appropriate drivers where missing which probably there aren't too many so may not be that difficult. If that's doable then maybe the most missing pieces are the Mac drivers which means that for Mac machines OpenBIOS may still have the advantage of having the drivers and support for booting OSes but also the disadvantage of being incomplete in implementing the standard. I still think that putting some work in trying to get OFW working at least for some time is worth it because if it works we could have a firmware that should be most compatible with the expectation of guests and if it doesn't work out we can always get back to trying to reimplement all the missing pieces in OpenBIOS.
Regards, BALATON Zoltan
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.
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. 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.
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. 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
On Tue, 6 Aug 2019, BALATON Zoltan wrote:
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. 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.)
I've come across this piece of info:
http://wiki.laptop.org/go/Cross_Compiling_Open_Firmware
which says cross forth for Sparc does exist but I'm not sure where. I could not find it in the openfirmware source. But if so then one should probably ask OFW developers before trying to reimplement cross forth for Sparc to try building OBP and they can likely point to the right direction.
Regards, BALATON Zoltan
Hi Zoltan,
On Tue, Aug 6, 2019 at 1:11 AM BALATON Zoltan balaton@eik.bme.hu 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 -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
Hello,
On Tue, 17 Sep 2019, Artyom Tarasenko wrote:
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.
Are you sure about SLOF being GPL? It looks like it has BSD style licence: https://github.com/aik/SLOF/blob/master/LICENSE
All the code copied from SLOF is in a single file though but if we combine it with QEMU which is GPL the whole may be under GPL anyway. But I think the OFW with fdt parsing from SLOF is still under BSD licence. Maybe an additional IBM copyright line may need to be mentioned to satisfy licence terms.
Regards, BALATON Zoltan
On Tue, Sep 17, 2019 at 4:00 PM BALATON Zoltan balaton@eik.bme.hu wrote:
Hello,
On Tue, 17 Sep 2019, Artyom Tarasenko wrote:
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.
Are you sure about SLOF being GPL? It looks like it has BSD style licence: https://github.com/aik/SLOF/blob/master/LICENSE
Ups, my bad.
All the code copied from SLOF is in a single file though but if we combine it with QEMU which is GPL the whole may be under GPL anyway.
This is exactly my point. OFW is not the part of QEMU, so it should not be re-licensed.
But I think the OFW with fdt parsing from SLOF is still under BSD licence. Maybe an additional IBM copyright line may need to be mentioned to satisfy licence terms.
Regards, BALATON Zoltan
-
Artyom Tarasenko -
BALATON Zoltan -
G 3