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.
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()/
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 :)
ATB,
Mark.