On Sat, Jul 13, 2019 at 10:34:45PM +0200, BALATON Zoltan wrote:
On Sat, 13 Jul 2019, Segher Boessenkool wrote:
: _926 my-address 01000014 + my-space + _867 " map-in" _91f TO _86c 4 my-space + dup " config-b@" _91f 1 or swap " config-b!" _91f ;
Thanks for rewriting it into more idiomatic Forth but I'm afraid I can't read that any better than the above. All I can grasp from it is that it tries to map something (maybe card's PCI config space) somewhere and set a bit in it or something along that line.
01000014 means the PCI I/O space mapped by BAR 1 (the one at config space address 14). What *exactly* it means I cannot tell either, there is a lot of missing context.
https://www.openfirmware.info/data/docs/bus.pci.pdf
What's my-space? That's relevant to my other question (unrelated to this but more interesting to me):
my-space returns the high 32 bits of an address (PCI addresses are 3 such 32-bit numbers, in open firmware).
https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/WVQ6R...
I could read that if the https was set up correctly, perhaps.
Yes. new-token makes a word header without a name.
OK I don't know how Forth works internally so the debug output did not make much sense.
https://www.openfirmware.info/data/docs/of1275.pdf
Pay special attention to A.2, the glossary. The entry for : says, for example:
Tokenizer equivalent: new-token|named-token|external-token b(:)
SLOF runs in real mode, so its memory mapping functions are trivial.
I think we can conclude that it gets exception because all the words it tries to use: map-in, config-b@, config-b! are missing in OpenBIOS so it can't really work and likely trips on map-in already.
It should normally fail with an intelligible error message, not try to jump to address zero or similar. But there can be bugs of course, and there is not much you can do about bugs in the FCode program (the card's ROM), etc.
Segher