On Dec 29, 2017, at 1:05 AM, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2017-Dec-29 00:40 , Jd Lyons wrote: [...]
b(>resolve) ( 0x0b2 ) (unnamed-fcode) [0xddf]<————This calls the offset? 0xddf
new-token ( 0x0b5 ) 0xddf b(:) ( 0x0b7 ) b(lit) ( 0x010 ) 0x10 (unnamed-fcode) [0xdde] <——This calls the offset? 0xdde
new-token ( 0x0b5 ) 0xdde b(:) ( 0x0b7 ) my-space ( 0x103 ) + ( 0x01e ) dup ( 0x047 ) (unnamed-fcode) [0xa08]<—— this calls 0xa08
new-token ( 0x0b5 ) 0xa08 b(:) ( 0x0b7 ) b(") ( 0x012 ) ( len=9 ) " config-l@" $call-parent ( 0x209 ) b(;) ( 0x0c2 )
Ah! Seeing that structure, the sequence comes down to:
0x10 my-space + dup " config-l@" $call-parent
That looks different than the debug output which seemed to be showing a bunch of extraneous "and"s.
So this is reading the first BAR at PCI config space address 10.
It's calling config-l@ from the parent, because this is a word defined by the PCI node. The code looks entirely reasonable. The questions to pursue:
- What is the value of my-space at that time?
- What is the value of my-self at that time? (because $call-parent will use my-self to find my-parent and thus the pci instance).
I’m using:
“ /pci/@2” open-dev to my-self
Not sure how I can get the value of my-self at the time of the exception?
If either of them has something questionable, that's what is blowing up, and we can track back to figure out what happened.
OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you