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
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@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
For what it's worth:
On 2018-May-6 20:12 , Joe van Tunen wrote:
b(lit) 0xff and my-space + (unnamed-fcode) [0xa08] b(lit) 0x6 and b(lit) 0x4 =
That sequence is probably testing a BAR for 64-bit capability. Bits 1-2 are the type of memory referenced by a BAR (0=IO, 1=32-bit mem, 2=64-bit mem).
https://en.wikipedia.org/wiki/PCI_configuration_space#Bus_enumeration
Does QEMU do something funny with 64-bit BARs? An NVIDIA card is almost certain to have 64-bit addressing in at least one BAR, and if QEMU doesn't support it, bad things may be happening.
I'm not sure about QEMU. Jd Lyons is getting the exception using Apple's Open Firmware implementation on a Quicksilver PowerMac G4.
On 5/6/18, 5:21 PM, "OpenBIOS on behalf of Tarl Neustaedter" <openbios-bounces@openbios.org on behalf of tarl-b2@tarl.net> wrote:
For what it's worth:
On 2018-May-6 20:12 , Joe van Tunen wrote: > b(lit) 0xff > and > my-space > + > (unnamed-fcode) [0xa08] > b(lit) 0x6 > and > b(lit) 0x4 > =
That sequence is probably testing a BAR for 64-bit capability. Bits 1-2 are the type of memory referenced by a BAR (0=IO, 1=32-bit mem, 2=64-bit mem).
https://en.wikipedia.org/wiki/PCI_configuration_space#Bus_enumeration
Does QEMU do something funny with 64-bit BARs? An NVIDIA card is almost certain to have 64-bit addressing in at least one BAR, and if QEMU doesn't support it, bad things may be happening.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On 07/05/18 01:21, Tarl Neustaedter wrote:
For what it's worth:
On 2018-May-6 20:12 , Joe van Tunen wrote:
b(lit) 0xff and my-space + (unnamed-fcode) [0xa08] b(lit) 0x6 and b(lit) 0x4 =That sequence is probably testing a BAR for 64-bit capability. Bits 1-2 are the type of memory referenced by a BAR (0=IO, 1=32-bit mem, 2=64-bit mem).
https://en.wikipedia.org/wiki/PCI_configuration_space#Bus_enumeration
Does QEMU do something funny with 64-bit BARs? An NVIDIA card is almost certain to have 64-bit addressing in at least one BAR, and if QEMU doesn't support it, bad things may be happening.
I had to fix this for my virtio patches: OpenBIOS does support 64-bit BARs but only maps devices into 32-bit addresses (i.e. the top 32-bits are always 0).
ATB,
Mark.
On 07/05/18 01:12, Joe van Tunen 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.
Right. The Solaris 64-bit FCode bootloader is hugely complex, and getting this to execute in OpenBIOS fixed several bugs in the b?branch/b(>resolve) area so I'd be surprised (although its not impossible) if this were a bug there.
It would say it's much more likely the OpenBIOS is missing a word present in real OF somewhere in the FCode but it's difficult to see.
Have you tried using the OpenBIOS detok utility to dump out the FCode? (see https://github.com/openbios/fcode-utils).
ATB,
Mark.
-
Jd Lyons -
Joe van Tunen -
Mark Cave-Ayland -
Tarl Neustaedter