On Sat, 13 Jul 2019, Segher Boessenkool wrote:
8552: new-token 0x926
Here is the rest of it:
8555: b(:) 8556: my-address 8558: b(lit) 0x1000014 8563: my-space 8565: + 8566: (unnamed-fcode) [0x867] 8568: b(") ( len=6 ) " map-in" 8576: (unnamed-fcode) [0x91f] 8578: b(to) (unnamed-fcode) [0x86c] 8581: b(lit) 0x4 8586: my-space 8588: + 8589: dup 8590: b(") ( len=9 ) " config-b@" 8601: (unnamed-fcode) [0x91f] 8603: 1 8604: or 8605: swap 8606: b(") ( len=9 ) " config-b!" 8617: (unnamed-fcode) [0x91f] 8619: b(;)
: _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. If it worked I should have seen access to pci config space of the card but it just failed with an exception. According to Jd it may work with SLOF, I'll retry that later.
What's my-space? That's relevant to my other question (unrelated to this but more interesting to me):
https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/WVQ6R...
Do you have some insight on that maybe? Although I probably need some help from someone with OpenBIOS knowledge if there are anyone here with that.
Here's the detok output around there:
8033: new-token 0x91d 8036: b(:) 8037: const_0xb0 8039: (unnamed-fcode) [0x90a] 8041: b(;)
: _91d 00b0 _090a ;
8042: 0 8043: new-token 0x91e 8046: b(value)
0 VALUE _91e
8047: new-token 0x91f 8050: b(:) 8051: my-self 8053: 0<> 8054: b?branch 0x000b ( =dec 11 dest = 8066 ) 8057: my-self 8059: b(to) (unnamed-fcode) [0x869] 8062: bbranch 0x0009 ( dest = 8072 ) 8065: b(>resolve) 8066: (unnamed-fcode) [0x869] 8068: b(to) my-self 8071: b(>resolve) 8072: $call-parent 8074: b(;)
: _091f my-self 0<> IF my-self TO _869 ELSE _869 TO my-self THEN $call-parent ;
I.e.: if my-self is non-zero, just call $call-parent ; and if it is zero, set the previously used instance as current instance.
This is pretty curious.
8075: new-token 0x920
So if 0x91f should be the one that does $call-parent then new-token comes before the : not after the ; in these listings.
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.
(But then what is 0x91e and if it's the value 0 then what about the :; block without new-token before that?)
I'm not sure which block you mean?
I was confused by that the new-token comes usually before the defined word but for the 0 value _91e it was between the number and b(value) so not what I expected:
new-token 91e 0 b(value)
as with :; blocks. But the above explains which lines belong to which new-token definition.
So is map-in map-out expected to work in OpenBIOS or is it known to be missing? Since these are also used by some OpenBIOS drivers and pci.c does have some code for these maybe it could work. SLOF has these words but some implementation just print a message and do drop2 so does not seem to be really implemented there but maybe it works I just can't read Forth.
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.
Thank you, BALATON Zoltan