On Sun, 25 Sep 2022, Mark Cave-Ayland wrote:
On 25/09/2022 14:29, BALATON Zoltan wrote:
On Sun, 25 Sep 2022, Mark Cave-Ayland wrote:
On 18/09/2022 22:14, BALATON Zoltan wrote:
On Sun, 18 Sep 2022, Mark Cave-Ayland wrote:
On 15/09/2022 21:22, BALATON Zoltan wrote:
On Thu, 15 Sep 2022, Mark Cave-Ayland wrote: > On 10/09/2022 12:58, BALATON Zoltan wrote: > >> This word does not appear in OpenFirmware nor OpenBoot but Apple OF >> has a word called parse-1hex which is used by code running on that >> OF implementation. Rename parse-hex accordingly for compatibility. >> >> Signed-off-by: BALATON Zoltan balaton@eik.bme.hu >> --- > > I'd be wary of using Apple's Open Firmware as the baseline standard > since it has a number of bugs and incompatibilities with the OF > specification. Is there any significance to the digit 1 in parse-1hex? > If not, I'd be inclined to add a simple ": parse-1hex parse-hex ;" > somewhere in the PPC-specific part of OpenBIOS and use that instead.
The parse-1hex word is used in a Mac FCode ROM we've tried so to run it we need this word. I've got this info from someone who tested Apple OF:
> parse-1hex is a word in every Apple Open Firmware for parsing one hex > string into a number. > > It looks like this: > > > : parse-ints ( str len count - numbers... ) > { local_0 local_1 local_2 ; ... } > local_2 0 do > local_1 if > local_0 local_1 2c left-parse-string \ 2c = ',' it's a > comma! > 2swap > -> local_1 > -> local_0 > $number > if > 0 > then > else > 0 > then > >r > loop > local_2 > 0 > do > r> > loop > ; > > : parse-nhex ( str len count -- val... ) base @ >r hex parse-ints r> > base ! ; \ save base, set base to hex, parse-ints, restore base > : parse-1hex ( str len -- val ) 1 parse-nhex ; > : parse-2hex ( str len -- val.lo val.hi ) 2 parse-nhex ; > : parse-3hex ( str len -- val.lo val.med van.hi ) 3 parse-nhex ; > : parse-2int ( str len -- val.lo val.hi ) 2 parse-ints ; / > Convert a “hi,lo” string into a pair of values. > > > I don't think OpenBIOS supports the Apple Open Firmware { locals from > stack... ; locals... } syntax so you will have to make changes to > parse-ints using normal forth stack manipulation words. > > parse-2int is in the IEEE 1275 spec, so maybe OpenBIOS has that word. > Same for $number and left-parse-string .
On the other hand parse-hex does not seem to appear in any other OF implementation (Open Firmware, OpenBOOT, SmartFirmware and SLOF, while SLOF has : parse-1hex 1 hex-decode-unit ;) so I assume parse-hex is also non-standard. Therefore we could just call it parse-1hex which at least is compatible with Apple and SLOF and not likely to cause any more problems than having a non-standard parse-hex word that we already have. I'd be OK with adding an alias in ppc/qemu too just don't see a reason for that as we'd then end up with two non-standard words instead of one.
Right, I think going for a simple PPC-specific alias similar to SLOF is the best way to go here.
How did you come to that conclusion from the above? The definition from SLOF does not work as it's based on some hex-decode-unit word which is also non-standard and unique to SLOF. I've actually ported that to OpenBIOS before as part of the fdt parsing code, look it up in the mail archive somwhere, but that's probably too much stuff for just parse-1hex. I still think renaming parse-hex to parse-1hex is the minimal change that's least likely to cause any problems here. Are you aware of anything that could break by it? If you don't like this patch then please do what you like and implement parse-1hex the way you think is better but some FCode ROMs will need this word.
Replacing one non-standard word with another non-standard word is just going to create code churn, with no discernible benefit. So let's go with just adding a PPC-specific alias for now.
I think just one word which at least exists in some implementations is better than two words but it would also work with aliasing it in ppc so I'll try to do that then.
A more complete compatibility or changing parse-hex to use parse-ints instead of a separate implementation my also be possible based on the above info but that could be done after this patch and I don't need more than parse-1hex so I don't intend to do such change just passing on the info here if it's useful for somebody in the future. This patch is enough the run the ROMs we wanted to run.
Is there a need for other parseX-hex words in order to execute the particular FCode ROM you are testing in QEMU?
No, only parse-1hex for now but you'll need the other missing words I've posted almost 3 years ago. I've just sent a v2 that adds config-[wl] variants too as some other ROMs were needing those.
Apart from those we've found (again) "us" wotd is missing: https://mail.coreboot.org/pipermail/openbios/2017-December/010085.html
It should be fairly trivial to implement us by reading the timebase in a similar manner to ciface_milliseconds()/
Looks like despite it's being trivial you could not get to do it in 3 years so we'll keep on waiting. I have no intention to do it as I don't need it.
That comment was about fixing up the existing timers for non-SPARC architectures generally, not implementing the us word. If someone wants to implement the us word for PPC separately similar to ciface_milliseconds() then I'm happy to take a patch for it, however it is not on my immediate TODO list.
Well, apparently nobody wanted to do it for quite some time and I don't expect many people come forward to do it now either.
I'd also like to point out that making snarky comments is not appropriate behaviour for this mailing list: no one on this list is sponsored to maintain the project, so maintainership is done as time and interest allows. The
I'm sorry. Let's not start this again and try to leave it behind. We just spent some hours to find this out again only to realise all this was debugged and found 3 years ago already so we've lost some time (more than a few us ;-) ) on this again.
quickest way to get a patch merged is to work with the list members and maintainers in a cooperative manner: trying to blame people for not doing what you think they should be doing is not helpful.
I wasn't trying to blame you, just trying to say that what you think is trivial might not be for others because they first need to understand what you already know so instead of telling others to do it you could just do it if it's so simple. It might take much less time for you if you already see what to do than for sombody who first has to learn a lot about OpenBIOS and open firmware in general. From past experience you're also quick to dismiss any patches that aren't to your liking which discourages any potential contributor to spend time with it if the hours put in are dismissed then. That leaves you the only one at the end who can fix stuff in OpenBIOS.
With the config-*, r*, map-* fixes, parse-1hex and substituting us with 1 ms for now we could run the FCode ROM of some ATI and NVidia cards.
That's good progress :)
The ATI ROMs ran 3 years ago so no real progress there it's still the same. I did not try NVidia ROMs but we've found most don't run due to a different problem with colom defs within if. I have some info on this that I'll forward here in case it helps but basically old world Apple OF also has the same problem so people in the forum thread I've forwarded now patching these ROMs so that would also avoid the problem on OpenBIOS. Other than that NVidis ROMs only needed the config-[wl] words that was really trivial to add analogously to config-b and the "us" which could be defined as : us drop 1 ms ; (this could be mare complex but no need to as all delays were below 1 ms).
Are there any other people who are interested in working on this? Even if you don't have the time/interest yourself, then I'm happy for discussions about features and patches to be discussed on this mailing list.
So this came up again when somebody wanted to try passing through a real video card to MacOS for which we need to run the card's ROM to init both the card and the device tree for MacOS. With emulated cards this could be patched up sonehow but for a real card using the genuine Mac FCode ROM is the best way and the best way to do this cleanly. This was also the reason this came up 3 years ago from JD Lyons' experiments with some NVidia card and I only got involved because I wanted to test my ati-vga emulation with MacOS and real card ROMs to identify missing parts and fix the emulation that way. Back then I managed to get the ATI ROM run and MacOS boot and find some bugs in ati-vga that way. I've posted the bugs and proposed solutions to this list that I've identified during this but that's all I could do. Now we came together again because somebody still wanted to try this real card pass through and had to gather the pieces and rediscover some stuff. After spending a week with it people ran out of free time so it stalled again but I'm trying to get at least the parts upstreamed we already have so others don't have to go through all this again and again.
I think most people who wanted to use this won't come here, they are just try it and find it's not working and abandon it or maybe post on forums but very few people get to find this list and even less get to send patches here. For now this effort has stalled again, I'll try to forward at least the info we found, most of these are in these patches and there's one more in the forum thread about NVidia ROMs vs old world Apple OF which may also be a problem with OpenBIOS. I'll gather the discussion on that to forward here later just to have it documented somewhere.
Regards, BALATON Zoltan