OpenBIOS May 2018

openbios@openbios.org

8 participants
16 discussions

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