[OpenBIOS] Back at it again( PCI Passthrough )

Thu May 10 12:33:27 CEST 2018

> On May 9, 2018, at 4:16 PM, Joe van Tunen <joevt at shaw.ca> wrote:
> 
> On 5/9/18, 7:07 AM, "Segher Boessenkool" <segher at kernel.crashing.org> wrote:
> 
>    On Wed, May 09, 2018 at 08:27:14AM -0400, Jd Lyons wrote:
>> Bear with me, while I try to understand this, but it looks like b?branch sets up some type of temporary buffer, and b(>resolve) try to “flush” that buffer.
> 
>    Yes; and that is incorrect.  b?branch in interpret mode is only allowed
>    for forward branches (which you have here), and it should simply skip that
>    much forward (in the fcode stream) if the top of stack was 0.  Not compile
>    anything.
> 
> 
> The code in OpenBIOS is currently doing it differently. Someone put some effort in making it this way (though README.device says fcode.fs is partly untested). Before changing it, it should be proven that it can't work that way. This current method means all the bytes in the fcode stream are processed in some way. 
> 
> 
> On May 9, 2018, at 4:55 AM, Jd Lyons via OpenBIOS <mailto:openbios at openbios.org> wrote:
> 
>    I don’t know if this is helpful, but I did a debug of b?branch and b(>resolve):
> 
> The output is missing the changes you made to (debug-feval). What did you do to get that debug output? Did you just follow the instructions from README.debugger with b?branch and b(>resolve)?

Just ran debug (word) from the OB command line. I’ll look into the debugger readme and see if I can get some more useful info.

> The debug output doesn't show what the second execute-tmp-comp is executing (the first execute-tmp-comp does nothing since depth hasn't returned to tmp-comp-depth yet). I don't see anything wrong with the debug output that you have so far. I think you need to look at debugging all the fcodes after the first b?branch. Can you do a debug trace of execute-tmp-comp?
> 
>    Just deleting the b(>resolve) I’m hanging on and replacing it with ff gets a little further,
>    and what I’m thinking is these two b(>resolves) and the two b?branch that come before them
>    have something to do with the children, NVDA,Display-A and NVDA,Display-B. Maybe something
>    to do with display detection, or the set-mode command.
> 
> If there's a problem with b?branch, then you shouldn't be using the nvidia rom to test it - use a simplified fcode image instead.
> 
> ff is the fcode for end1, but that does nothing while in compile mode. OpenBIOS won't leave compile mode started by b?branch without a corresponding b(>resolve), and it eventually exceeds the temporary compile buffer size, trashing the dictionary, and then causing a hang. Maybe OpenBIOS needs a guard against that? "here!" should probably take two values, the new "here" value and a "limit". Then anything that adds to the dictionary should use that new limit instead of the usual limit.
> 
>    Get-mode, show-mode, and set-mode are called twice, I assume once for each display node, so
>    something is going wrong with NVDA,Dispaly-A/B, I just don’t know what it is.
> 
> They are not executed, because OpenBIOS hasn't left compile mode, because you removed (b>resolve).
> 
> 
> 
> On 5/9/18, 11:34 AM, "Mark Cave-Ayland" <mark.cave-ayland at ilande.co.uk> wrote:
> 
>    I'm confused here: b?branch is FCode-only and executed as part of the 
>    FCode evaluation. The tmp-comp-buf is used to hold the xts derived from 
>    the FCode token stream until the point where the branch is resolved.
> 
>    However I still think for the moment we're digging way to deep here...
> 
> I agree. We haven't proved there's anything wrong with b?branch (except that the size of the temporary compile buffer could be exceeded but that's not the problem with the nvidia rom). Running that test fcode image that I mentioned would probably have shown that it works.
> 
> 
> 
> On 5/9/18, 11:45 AM, "OpenBIOS on behalf of Mark Cave-Ayland" <openbios-bounces at openbios.org on behalf of mark.cave-ayland at ilande.co.uk> wrote:
> 
>    I suspect that it's something within that branch failing which is only 
>    visible at the final b(>resolve) once the condition is evaluated, so 
>    with indentation:
> 
>    ...
> 
>    Most of that looks fairly normal, so I'd start by looking at the 0x9bd 
>    and 0xa08 FCodes which will have been generated further up in your 
>    output file.
> 

new-token 0xa08
b(:) 
    b(") ( len=9 )
    " config-l@"
    $call-parent 
b(;) 
-------------------------
new-token 0x9bd
b(constant) 
b(lit) 0x42000014
--------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6600.fcode
Type: application/octet-stream
Size: 618341 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/openbios/attachments/20180510/477d98a0/attachment-0001.obj>
-------------- next part --------------

b?branch 0x0026 ( =dec 38)
    (unnamed-fcode) [0x9bd] 
    b(lit) 0xff
    and 
    my-space 
    + 
    (unnamed-fcode) [0xa08] 
    b(lit) 0x6
    and 
    b(lit) 0x4
    = 
    b?branch 0x0009 ()
        b(') (unnamed-fcode) [0x9c1] 
        b(to) (unnamed-fcode) [0x9c0] 
    b(>resolve) 
b(>resolve) 
(unnamed-fcode) [0xddf] 
(unnamed-fcode) [0xe04] 
(unnamed-fcode) [0xe38] 
(unnamed-fcode) [0xe06] 
(unnamed-fcode) [0xce5] 
(unnamed-fcode) [0xdb0] 
(unnamed-fcode) [0xe07] 
(unnamed-fcode) [0xe1a] 
(unnamed-fcode) [0xc5b] 
(unnamed-fcode) [0xe28] 
(unnamed-fcode) [0xe20] 
(unnamed-fcode) [0xdfa] 
(unnamed-fcode) [0xe37] 
(unnamed-fcode) [0xe2c] 
(unnamed-fcode) [0xe2d] 
b(") ( len=0xb [11 bytes] )

>    I suspect you'll end up converting chunks of FCode back into Forth to 
>    figure out which part is failing.
> 
> I think a debug trace of execute-tmp-comp might work to get to what part of 0x9bd or 0xa08 is causing the exception?
> 
> 
> 

4010035 fff81e54 : b?branch [ 0x14 ]
       (offset) 26 
4010039 fff57240 : (compile)  [ 0x9bd ]
401003a fff57244 : (compile) b(lit) [ 0x10 ]
401003f fff5724c : (compile) and [ 0x23 ]
4010041 fff57250 : (compile) my-space [ 0x103 ]
4010042 fff57254 : (compile) + [ 0x1e ]
4010044 fff57258 : (compile)  [ 0xa08 ]
4010045 fff5725c : (compile) b(lit) [ 0x10 ]
401004a fff57264 : (compile) and [ 0x23 ]
401004b fff57268 : (compile) b(lit) [ 0x10 ]
4010050 fff57270 : (compile) = [ 0x3c ]
4010051 fff57274 : (compile) b?branch [ 0x14 ]
       (offset) 9 
4010054 fff5727c : (compile) b(') [ 0x11 ]
4010057 fff57284 : (compile) b(to) [ 0xc3 ]
401005a fff57290 : (compile) b(>resolve) [ 0xb2 ]

: execute-tmp-comp  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff5723c 0 ) 
fff3de1c: depth  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff5723c 0 11 ) 
fff3de20: tmp-comp-depth  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff5723c 0 11 fff3dd80 ) 
fff3de24: @  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff5723c 0 11 f ) 
fff3de28: =  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff5723c 0 0 ) 
fff3de2c: do?branch  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff5723c 0 ) 
fff3de78: (semis) 
[ Finished execute-tmp-comp ] 401005b fff57290 : (compile) b(>resolve) [ 0xb2 ]

: execute-tmp-comp  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) 
fff3de1c: depth  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff f ) 
fff3de20: tmp-comp-depth  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff f fff3dd80 ) 
fff3de24: @  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff f f ) 
fff3de28: =  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ffffffff ) 
fff3de2c: do?branch  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) 
fff3de34: -1  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ffffffff ) 
fff3de38: tmp-comp-depth  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ffffffff fff3dd80 ) 
fff3de3c: !  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) 
fff3de40: (lit)  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff3d0c4 ) 
fff3de48: ,  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) 
fff3de4c: tmp-comp-buf  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff3dd9c ) 
fff3de50: @  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 ) 
fff3de54: dup  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 fff57230 ) 
fff3de58: @  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 fff81e54 ) 
fff3de5c: here!  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 ) 
fff3de60: 0  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 0 ) 
fff3de64: state  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 0 fff3d648 ) 
fff3de68: !  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 ) 
fff3de6c: /n  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 4 ) 
fff3de70: +  ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57234 ) 
fff3de74: execute 
byte-load: exception caught!
 ok
0> here u. fff81e54 

> 
> -- 
> OpenBIOS                 http://openbios.org/
> Mailinglist:  http://lists.openbios.org/mailman/listinfo
> Free your System - May the Forth be with you