[OpenBIOS] Back at it again( PCI Passthrough )

Jd Lyons lyons_dj at yahoo.com
Mon May 7 18:08:34 CEST 2018



> On May 7, 2018, at 7:33 AM, Jd Lyons <lyons_dj at yahoo.com> wrote:
> 
> 
> 
>> On May 6, 2018, at 8:12 PM, Joe van Tunen <joevt at shaw.ca> wrote:
>> 
>> It is unclear to me if the exception is caused by compiling the fcode or interpreting (executing) it. Your verbose output (which I'm unfamiliar with) shows only "(compile)". Without trying it myself or looking at Apple's byte-load code, I'm guessing that's some kind of context, and perhaps there's an interpret (execute) context? Can you send the full output directly to me or post a link? 
>> 
>> Can you check the value of "here" before byte-load and after the exception to see how much dictionary space was used? I wonder if an exception would cause a rewind of some kind, or just leave everything as is.
>> 
>> The fcode in question is at the top level and looks like this:
>> 
>> 
>> new-token 0xe38
>> b(:)
>>   ...
>> b(;) 
>> b(') (unnamed-fcode) [0xc84] 
>> b(to) (unnamed-fcode) [0x9a9] 
>> (unnamed-fcode) [0xe34] 
>> (unnamed-fcode) [0xdff] 
>> (unnamed-fcode) [0x93d] 
>> b(lit) 0xf
>> <> 
>> 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]
>> ...
>> 
>> 
>> Since it's at the top level, it probably must be getting executed. The problem might be in executing 0xddf (defined earlier in the fcode).
>> 
>> Once I get my fcode token to forth converter updated (so it can be used with Unix/macOS instead of MPW) then you can make your own nvidia open firmware driver with added debugging code.
>> 
>> You should look at the 1275.pdf document "IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices" to get a description of the tokens. "b?branch ... b(>resolve)" are the tokens for the forth "if ... then" statements (when the b?branch fcode offset is positive). The document also describes how a token behaves while the fcode evaluator is in interpretation state and compilation state.
>> 
>> 
>> On 5/6/18, 8:11 AM, "Jd Lyons" <lyons_dj at yahoo.com> wrote:
>> 
>>   Ok, now that I know we can load a Fcode Rom for an nVidia card in Apple’s Open Firmware implementation, I figured I try this again.
>> 
>>   I have to catch up a little one what we did before, so I maybe tripping over something I got passed before.
>> 
>>> true to ?fcode-verbose
>>> “ /pci/@10” open-dev to my-self
>>> load hd:,\ppc\6600.rom
>>> 4000040 1 byte-load
>> 
>>   …….
>> 
>> 
>>         (offset) 26 
>>   400fff9 : (compile)  [ 0x9bd ]
>>   400fffa : (compile) b(lit) [ 0x10 ]
>>   400ffff : (compile) and [ 0x23 ]
>>   4010001 : (compile) my-space [ 0x103 ]
>>   4010002 : (compile) + [ 0x1e ]
>>   4010004 : (compile)  [ 0xa08 ]
>>   4010005 : (compile) b(lit) [ 0x10 ]
>>   401000a : (compile) and [ 0x23 ]
>>   401000b : (compile) b(lit) [ 0x10 ]
>>   4010010 : (compile) = [ 0x3c ]
>>   4010011 : (compile) b?branch [ 0x14 ]
>>          (offset) 9 
>>   4010014 : (compile) b(') [ 0x11 ]
>>   4010017 : (compile) b(to) [ 0xc3 ]
>>   401001a : (compile) b(>resolve) [ 0xb2 ]
>>   401001b : (compile) b(>resolve) [ 0xb2 ]
>> 
>>   byte-load: exception caught!
>>    ok
>>   0 > 4010014 200 dump 
>>   4010014  11 09 c1 c3 09 c0 b2 b2  0d df 0e 04 0e 38 0e 06    ..��.���.�...8..
>>   4010024  0c e5 0d b0 0e 07 0e 1a  0c 5b 0e 28 0e 20 0d fa    .�.�.....[.(. .�
>>   4010034  0e 37 0e 2c 0e 2d 12 0b  4e 56 44 41 2c 50 61 72    .7.,.-..NVDA,Par
>>   4010044  65 6e 74 02 01 a6 01 11  12 0e 23 61 64 64 72 65    ent..�....#addre
>>   4010054  73 73 2d 63 65 6c 6c 73  01 10 a5 01 11 12 0b 23    ss-cells..�....#
>>   4010064  73 69 7a 65 2d 63 65 6c  6c 73 01 10 09 c7 09 3d    size-cells...�.=
>>   4010074  10 00 00 00 35 42 14 00  0d a6 09 33 27 09 35 24    ....5B...�.3'.5$
>>   4010084  c3 09 35 b2 09 41 10 00  00 00 10 27 09 35 24 01    �.5�.A.....'.5$.
>>   4010094  11 12 0d 4e 56 44 41 2c  46 65 61 74 75 72 65 73    ...NVDA,Features
>>   40100a4  01 10 a6 01 11 12 0a 4e  56 44 41 2c 4c 65 76 65    ..�....NVDA,Leve
>>   40100b4  6c 01 10 a5 a5 0e 2e 09  bc 09 c3 0e 2e 01 12 09    l..��...�.�.....
>>   40100c4  c0 09 c6 0e 2e 01 12 09  be 09 c4 0e 2e 01 12 09    �.�.....�.�.....
>>   40100d4  bf 09 c5 0e 2e 01 12 12  03 72 65 67 01 10 a6 01    �.�......reg..�.
>>   40100e4  11 12 0e 23 61 64 64 72  65 73 73 2d 63 65 6c 6c    ...#address-cell
>>   40100f4  73 01 10 a5 01 11 12 0b  23 73 69 7a 65 2d 63 65    s..�....#size-ce
>>   4010104  6c 6c 73 01 10 12 1a 3a  20 64 65 63 6f 64 65 2d    lls....: decode-
>>   4010114  75 6e 69 74 20 70 61 72  73 65 2d 31 68 65 78 20    unit parse-1hex 
>>   4010124  3b cd 0c 7c 47 01 11 4a  01 11 01 12 12 0c 56 52    ;�.|G..J......VR
>>   4010134  41 4d 2c 6d 65 6d 73 69  7a 65 01 10 a5 c3 09 52    AM,memsize..��.R
>>   4010144  09 51 a5 18 00 16 19 0a  41 0a 4a 08 ea 3d 14 00    .Q�.....A.J.�=..
>>   4010154  08 19 c3 09 52 1b b2 15  ff ee 09 46 38 14 01 b0    ..�.R.�.��.F8..�
>>   4010164  09 52 0a 41 01 1f 0e 32  b5 0e 39 b7 09 52 0a 41    .R.A...2�.9�.R.A
>>   4010174  0d f1 c3 01 62 c2 b5 0e  3a b7 09 52 0a 41 0d f2    .��.bµ.:�.R.A.�
>>   4010184  c2 b6 08 67 65 74 2d 6d  6f 64 65 0e 3b b7 0d cb    ¶.get-mode.;�.�
>>   4010194  c2 b6 0a 73 68 6f 77 2d  6d 6f 64 65 73 0e 3c b7    ¶.show-modes.<�
>>   40101a4  0d cc c2 ca 08 73 65 74  2d 6d 6f 64 65 0e 3d b7    .���.set-mode.=�
>>   40101b4  09 52 0a 41 0d ca c2 ca  0e 64 72 61 77 2d 72 65    .R.A.���.draw-re
>>   40101c4  63 74 61 6e 67 6c 65 0e  3e b7 09 52 0a 41 0d d5    ctangle.>�.R.A.�
>>   40101d4  c2 ca 0e 66 69 6c 6c 2d  72 65 63 74 61 6e 67 6c    ��.fill-rectangl
>>   40101e4  65 0e 3f b7 09 52 0a 41  0d d7 c2 ca 0e 72 65 61    e.?�.R.A.���.rea
>>   40101f4  64 2d 72 65 63 74 61 6e  67 6c 65 0e 40 b7 09 52    d-rectangle.@�.R
>>   4010204  0a 41 0d d6 c2 ca 06 63  6f 6c 6f 72 21 0e 41 b7    .A.���.color!.A�
>>    ok
>>   0 > my-self . fc5ac34  ok
>> 
>>   I think this is the point I got to before. I’m not real sure what is going wrong here?
>> 
>>   Seems to be tripping over the second b(>resolve), tho I’m not sure what this fcode is trying to do?
>> 
>>   Joe, see if you can have a look at it, when you have time, and see if you have any ideas what is causing the exception.
>> 
>>    b?branch 0x0009 ()
>>           b(') (unnamed-fcode) [0x9c1] 
>>           b(to) (unnamed-fcode) [0x9c0] 
>>       b(>resolve) 
>>   b(>resolve) <—Here?
>>   (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] )
>>   " NVDA,Parent"
>>   device-name 
>>   1 
>>   encode-int 
>>   b(") ( len=0xe [14 bytes] )
>>   " #address-cells"
>>   property 
>>   0 
>> 
>> 
> 
> Ok, I think the reason for the exception with [dff] is I don’t have an active device tree node. So, “ /pci/@x” open-dev to my-self works on Apple’s implementation of OF, but Openbios and SLOF deal with things a little different.
> 
> s” /pci/@x” select-dev
> 
> That works in SLOF, otherwise SLOF throws an exception with [dff] and tells us there is no active device tree node.
> 
> Using that code in Openbios still raises the same exception at 401005b, but I really think it’s the next thing [dff], it can’t resolve the device?
> 
> Doesn’t anyone know how I can view the active device tree node?
> 
> 
> 
> 
>> 
>> 
>> 
>> 
>> -- 
>> OpenBIOS                 http://openbios.org/
>> Mailinglist:  http://lists.openbios.org/mailman/listinfo
>> Free your System - May the Forth be with you
> 




More information about the OpenBIOS mailing list