On Tue, 30 Jul 2019, Mark Cave-Ayland wrote:
On 29/07/2019 15:34, BALATON Zoltan wrote:
OpenBIOS is not OpenHackWare but seems to be equally incomplete, patchy and rely on random hacks. Trying to clean it up and implement missing stuff seems to be as complex as rewriting OpenFirmware. Given all OpenBIOS's missing features and non-existing developer comunity with only limited resources to improve it I wonder if we should try to move on to OpenFirmware instead eventually to at least have a complete OF implementation so we only need to care about porting that to QEMU and adding Apple specific stuff and not to implement OF itself. Apparently this was already done for QEMU prep a few years ago:
I find this attitude unhelpful and disrespectful to the people who have worked on OpenBIOS over the years, some of whom are still on this mailing list.
Don't take it personal. I did not mean to say that you're not doing all you can to improve and advance OpenBIOS and thanks for keeping the project alive. But what I'm saying is that alone may not be enough to reach project goals. If you look at this page:
https://github.com/openbios/openbios/graphs/contributors
you can see that for the last few years after 2012 you seem to be the only one who still cares about OpenBIOS and if your free time does not allow to continue in the future it will be pretty much dead. So looking for alternatives may be needed unless more people show up and do something to help you. Pointing this out to people still on the list who could do something to better OpenBIOS is more helpful than unhelpful even if they may feel offended by that.
It may be that I'm a bit frustrated by not being able to get a simple fix for MorphOS in since 2016 for no clear reason (other than forcing me to make bigger changes and more cleanup instead) and to find missing parts to implement and things to clean up whenever I try to do something with OpenBIOS and I don't see based on this past experience how will I be able to make changes I need for Pegasos2 emulation so my attitude may have changed a bit, but I'm not accusing you or anyone for this. I still think that if you would not do what you do now the project was already dead. But I accept the facts and point out that only one free time developer may not be enough to make progress fast enough to get OpenBIOS to the level of OpenFirmware in the same time than getting OpenFirmware working in place of it so considering that alternative is valid in my opinion. This does not negate all the work you've put in OpenBIOS so far and it has served QEMU well so far so it wasn't useless even if we take a different turn in the future. But if your and my limited free time is all what we have then getting OpenBIOS working with Pegasos2 to emulate SmartFirmware or even reaching the capabilities of OpenFirmware may not be possible any time soon.
I think when OpenBIOS was started there were no other free OF implementations available yet and making a free implementation of the standard was useful to do. By now all other major implementations (OpenFirmware and SmartFirmware) are free and some machines in QEMU use SLOF instead so it is a valid question if it's worth duplicating all the efforts again in OpenBIOS when there may be other alternatives that are the same amount of work to make usable. Do not only judge this based on how much work you've put already put in OpenBIOS but also what helps to reach the goals fastest. Althugh out goals may be different there are common points I believe.
Certainly OpenBIOS can be improved in certain areas, but please keep the discussion on a technical level rather than making sweeping accusations about the state of the project.
On techincal terms I have three ways to choose from to get a working firmware for pegasos2 replacing the original which has closed source parts so cannot be distributed or included in QEMU:
1. Reimplement it from its parts which are all open source: SmartFirmware, x86emu (used to init video cards but may not be needed on QEMU where we can have our own video bios) and maybe pmon where the loader seems to come from. The closed parts are mostly board init which we probably don't need on QEMU anyway such as setting up memory controller or clocking. This is some amount of work but would only be useful for pegasos2 and not for other machines in QEMU and would add yet another OF implementation to QEMU so not my first option.
2. Get OpenBIOS to be able to emulate SmartFirmware trying to clean up and implement as many parts as needed which would also help other machines using OpenBIOS. For this I think at least the FDT unflattening should be ported from SLOF to be able to define different device trees for different machines in QEMU instead of having to add knowledge about every board in OpenBIOS which already has too many if old_world/new_world, and hardcoded assumptions about memory locations which should be removed by this. This also coincides your work on cleaning up PCI tree creation so I though it would be useful for multiple use cases and what I'm first trying before other options.
3. 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).
Hope the above explains my question and makes people on the list think so we can find the best way to use our limited resources and you don't see this as an attack against you or OpenBIOS which I did not mean to do so sorry if you took it like that.
Regards, BALATON Zoltan