[OpenBIOS] b?branch
Tarl Neustaedter
tarl-b2 at tarl.net
Fri Dec 29 07:05:45 CET 2017
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).
If either of them has something questionable, that's what is blowing up,
and we can track back to figure out what happened.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/openbios/attachments/20171229/c863ee2e/attachment.html>
More information about the OpenBIOS
mailing list