OpenBIOS

openbios@openbios.org

4284 discussions

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Jd Lyons 07 May '18

07 May '18

> On May 7, 2018, at 7:33 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > > >> On May 6, 2018, at 8:12 PM, Joe van Tunen <joevt(a)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(a)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 >

1 0

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Jd Lyons 07 May '18

07 May '18

> On May 7, 2018, at 5:21 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > Sorry, I wasn’t clear, no trouble executing this in Apple’s Open Firmware implementation. I’ve moved back to Openbios to see if I can get PCI Passthough working with Qumu-system-ppc. > > The host is an AMD B350 board running Debian 9. With a Geforce 6600 PCI-E card from a G5. > > > >> On May 6, 2018, at 10:25 PM, Joe van Tunen <joevt(a)shaw.ca> wrote: >> >> 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(a)openbios.org on behalf of tarl-b2(a)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 >> >> >> >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you >

1 0

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Jd Lyons 07 May '18

07 May '18

> On May 6, 2018, at 1:08 PM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > True, I’m just not sure yet what to fix, I forgot the point we got to before, so I’ll have to do a little back tracking. > > I tried to b?branch before, but the way I did it just made things worse. > > Once I get down to the exact reason for the exception here, should give me a little better idea what I need to fix. > > I do remember getting passed this before, but things didn’t get much further. > > Sometimes it’s better to be lucky than good. > >> On May 6, 2018, at 12:21 PM, Segher Boessenkool <segher(a)kernel.crashing.org> wrote: >> >> On Sun, May 06, 2018 at 12:08:47PM -0400, Jd Lyons wrote: >>> I noticed that openbios builds the open and close methods for the pci device( nVidia ). >>> >>> Is there a way to destroy these words/methods before I call 1 byte-load? >> >> It is probably easier to make openbios do the right thing here, make it >> more standard-compliant -- you can add workaround on top of workaround, >> but at some point it becomes easier to just fix things, no matter how >> much work that is. >> >> >> Segher >

1 0

Re: [OpenBIOS] Back at it again( PCI Passthrough )
by Jd Lyons 07 May '18

07 May '18

> On May 6, 2018, at 12:08 PM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > I noticed that openbios builds the open and close methods for the pci device( nVidia ). > > Is there a way to destroy these words/methods before I call 1 byte-load? > > > >> On May 6, 2018, at 11:11 AM, Jd Lyons via OpenBIOS <openbios(a)openbios.org> 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 >> >> >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you >

1 0

Back at it again( PCI Passthrough )
by Jd Lyons 07 May '18

07 May '18

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

4 5

Re: [OpenBIOS] Apple's Open Firmware.
by Jd Lyons 03 May '18

03 May '18

Ok, I got a PC bios nVidia card working by loading the FCode rom from a file in my Quicksilver. load hd:12,ppc/GMC.rom dev agp/@10 800000 1 byte-load “ agp/@10” open-dev to my-self 800000 1 byte-load bye I likely wouldn’t have to call 1 byte-load twice if I knew how to properly call device-open, I think the first time I call it, it’s setting up the open and close methods for the device, because if I do “ agp/@10” open-dev to my-self before it complains that the device has no open and close methods. OS X didn’t care for it( kernel panic ), but it didn’t properly build the compatible properties. OS 9 was fine with it, as soon as I Mac-boot/bye I get video from the card, and everything works as expected 2D/3D and DVD playback. Now I just have to figure out how to get Openbios to do this with PCI Passthrough;-) Thanks everyone.

2 1

[PATCH] openbios: compile fixes for GCC 7.3
by Mark Cave-Ayland 03 May '18

03 May '18

This fixes additional warnings found when upgrading my compiler toolset from GCC 5.x to 7.x. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- fs/hfs/hfs_fs.c | 2 +- libopenbios/video_common.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/hfs/hfs_fs.c b/fs/hfs/hfs_fs.c index 2d62ec0..2e63dbf 100644 --- a/fs/hfs/hfs_fs.c +++ b/fs/hfs/hfs_fs.c @@ -101,7 +101,7 @@ _search( hfsvol *vol, const char *path, const char *sname, hfsfile **ret_fd ) *p = 0; topdir = 0; - strncat( buf, ent.name, sizeof(buf) ); + strncat( buf, ent.name, sizeof(buf) - 1); if( (status=_search(vol, buf, sname, ret_fd)) != 2 ) continue; topdir = 1; diff --git a/libopenbios/video_common.c b/libopenbios/video_common.c index 9bbc18c..7496446 100644 --- a/libopenbios/video_common.c +++ b/libopenbios/video_common.c @@ -191,7 +191,7 @@ void setup_video() values in the Forth dictionary. Hence everything is always in sync. */ phandle_t options; - char buf[6]; + char buf[10]; feval("['] display-ih cell+"); video.ih = cell2pointer(POP()); -- 2.11.0

1 1

Probing the PCI bus for Option ROMs.
by Jd Lyons 06 Apr '18

06 Apr '18

Joe, if it would be something that interests you, and you have the time, we could work on adding proper PCI Probing to Openbios. As it stands the Qemu_VGA is a pci device, and Qemu loads an Option rom, but it’s the VGA Bios and Opennbios doesn’t probe for option roms. Openbios has the Fcode for the Qemu-Vga device and there is a NDRV that gets loaded from a file. What we really need is to make a proper FCode Rom image with the NDRV for the Qemu_VGA device, we could make a hybrid Bios/Fcode rom and not have to change the code in Qemu at all, I don’t think. Here are some instructions on setting up and building Openbios on OS X Intel. There is an effective tutorial on the openbios site. If you run OSX, you nee to install the fcode utils and use the awos cross compiler linked to: http://www.mediafire.com/download/wy5xg ... pilers.zip <http://www.mediafire.com/download/wy5xgj2hwjp8k4k/AWOS_Cross-Compilers.zip> This is my script to build the OpenBIOS binary: PATH=:/usr/local/ppcelf/ppcelf/bin:/users/hsp/src/fcode-utils-devel/toke:$PATH export PATH cd openbios CROSS_COMPILE=ppc-elf- ./config/scripts/switch-arch ppc #(remove -Werror from CFLAGS in Makefile.target in top directory) make Best, Cat_7 I forget the file that has the Forth for the Qemu_VGA device, Mark? Also SLOF has some code for probing option roms for at least the GeForce 6600 PCI-E card, so that maybe something we can use to add support for option roms to OB. \ ***************************************************************************** \ * Copyright (c) 2004, 2008 IBM Corporation \ * All rights reserved. \ * This program and the accompanying materials \ * are made available under the terms of the BSD License \ * which accompanies this distribution, and is available at \ * http://www.opensource.org/licenses/bsd-license.php \ * \ * Contributors: \ * IBM Corporation - initial implementation \ ****************************************************************************/ my-space pci-class-name type my-space pci-device-generic-setup pci-io-enable pci-mem-enable 30 config-l@ pci-find-fcode execute-rom-fcode : check-display ( nodepath len -- true|false ) \ true if display found and "screen" alias set \ check if display available, set screen alias 2dup find-node \ ( path len phandle|0 ) find node ?dup IF \ node found, get "display-type" property s" display-type" rot get-property ( path len true|propaddr proplen 0 ) 0= IF ( path len propaddr proplen ) \ property found, check if the value is not "NONE" s" NONE" 0 char-cat ( path len propaddr proplen str strlen ) \ null-terminated NONE string str= 0= IF ( path len ) \ "display-type" property is not "NONE" so we can set "screen" alias s" screen" 2swap set-alias true ( true ) \ return true ELSE 2drop false ( false ) \ return false THEN THEN THEN ; get-node node>path s" /NVDA,DISPLAY-A" $cat check-display 0= IF \ no display found on DISPLAY-A ... check DISPLAY-B get-node node>path s" /NVDA,DISPLAY-B" $cat check-display drop \ drop result THEN s" name" get-my-property drop s" ( " type type s" ) " type cr

3 3

Apple's Open Firmware.
by James Lyons 04 Apr '18

04 Apr '18

As an addition to our work trying to get the 6600 PCI-E working with PCI Passthrough, I've got a QuickSilver G4 and a couple of Geforce/ Quadro cards. I've been working on some FCode Roms for them, and I'd like to test them before I flash it to the EEProm, however I don't seem to have the commands correct. " agp/@10" open-dev to my-self load hd:12,\ppc\4600.rom 800000 1 byte-load That all returns ok, but the FCode doesn't seem to execute. Also, I had to strip the PCI Header from the ROM to get the load command to work. Have a look at this ROM and see if the FCode starts at 0x40, looks like it does to me?

6 29

Re: [OpenBIOS] Apple's Open Firmware.
by James Lyons 20 Mar '18

20 Mar '18

Seems I wasn't using a crossover cable, I don't know why anyone would make a yellow cable that wasn't crossover. Anyway, now I have input via telnet, but I can't get the Mac to boot to a OF telnet session? I tried to set it via nvramrc, but that doesn't seem to work: setenv auto-boot? false nvedit " enet:telnet,10.1.2.3" io nvstore setenv use-nvramrc? true reset-all Returns me to the OF prompt but no in telnet. I seem to recall doing this on an Old World Mac many years ago, I need to change the input-device and output-device to enet?

1 0

Jump to page: