OpenBIOS December 2017

openbios@openbios.org

6 participants
18 discussions

Suggestion - add minor version number to banner
by Programmingkid 17 Dec '17

17 Dec '17

I was wondering if we could add a minor version number to the banner. It would mean instead of see "OpenBIOS v1.1", what would be printed is "OpenBIOS v1.1.x". I think this would help distinguish added features to a particular binary easier than how we do things now.

1 0

Re: [OpenBIOS] Loading a PCI Option rom.
by Programmingkid 17 Dec '17

17 Dec '17

> On Dec 17, 2017, at 1:28 PM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > From what I remember, there are a bunch of properties, the most important is the NVDA,BMP that’s where the GPU and Memory Registers get written. There is a Strap, the NVStrap near the beginning of the Rom, and one part of the NVStrap sets up how the NVDA,BMP is read and written. The BMP is common between PC and FCode Option Roms, as is the strap. In the BMP there are a series of tables 0-7 and one offset of the strap determines what table gets loaded. It was a throwback to a program nVidia gave to it board partners. The NVStap Editor, I think it was called, it allowed them to use a reference Bios and plug in some values depending on how they deviated from the reference PCB. The NVStrap has and And/Or mask, So you can append the resistors on the PCB, or just read them as they are, and you can change the last byte of the Device ID. > > So if one of there board partners used some cheap memory they could get a ready supply of, they could just plug the memory specs into the BMP Editor and set the Soft Strap(NVStrap) without the need to make a new Bios in assembly. > > We got lucky, and they used the BMP in the Fcode Rom too, and that allowed us to figure out how to edit it to flash PC cards for use in PPC systems. > > There is a GPU check in the Fcode rom too, so you have to bypass that check, if you want to use a GPU the Rom wasn’t made for. This is how we made the Geforce 6200 Rom from the Apple OEM Geforce 6600 Rom. Thank you for the info. You know a lot of Nvidia cards. Still there is the exception that we see when executing the card's Fcode. Finding out what is causing the exception would be very helpful. Were there any values in the stack that might mean anything when the exception happened? Did you see any other messages? The serial console may have something printed there. I found the definition to byte-load in the forth/device/feval.fs file. This is part of it: : byte-load ( addr xt -- ) ?fcode-verbose if cr ." byte-load: evaluating fcode at 0x" over . cr then \ save state >r >r fcode-push-state r> r> \ set fcode-c@ defer dup 1 = if drop ['] c@ then \ FIXME: uses c@ rather than rb@ for now... to fcode-c@ dup to fcode-stream-start to fcode-stream 1 to fcode-spread false to ?fcode-offset16 alloc-fcode-table false fcode-end ! \ protect against stack overflow/underflow 0 0 0 0 0 0 depth >r ['] (feval) catch if cr ." byte-load: exception caught!" cr then You see the message "exception caught!" takes place because the (feval) word has a problem with something. Looking at the (feval) word I see it has a (debug-feval) word that might be helpful. This word is also located in the feval.fs file. As an experiment could you set the ?fcode-verbose to true when running QEMU? I think this QEMU option would help: -prom-env ?fcode-verbose=true If this doesn't work, then maybe we should redefine the " word to print out what it finds to the serial console. That might tell us what is wrong.

1 0

Re: [OpenBIOS] Loading a PCI Option rom.
by Programmingkid 17 Dec '17

17 Dec '17

https://nouveau.freedesktop.org/wiki/DumpingVideoBios/ I found this really helpful page on obtaining information on properties. If you have Linux installed on a PowerPC Macintosh, then finding the properties is as simple as typing this command in the terminal: cd "/proc/device-tree/pci@f0000000/NVDA,Parent@10" Just checked my PowerPC iMac. It has an ATI Radeon video card, so it won't be much help. I think the reason why OpenBIOS fails to make the property is because there is something interesting about the name. Maybe an unhandled character type like unicode is used. Having a list of all the properties that this card has would be very helpful.

1 0

Re: [OpenBIOS] Loading a PCI Option rom.
by Jd Lyons 17 Dec '17

17 Dec '17

Ok, here's what I'm getting now: C>> annot manage 'VGA controller' PCI device type 'display': >> 10de 141 (3 0 0) >> ============================================================= >> OpenBIOS 1.1 [Dec 17 2017 13:36] >> Configuration device id QEMU version 1 machine id 2 >> CPUs: 1 >> Memory: 128M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,750 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Dec 17 2017 13:36 0 > load hd:,\ppc\6600.fcode ok 0 > 4000000 400 dump 4000000 55 aa 40 00 00 00 00 00 00 00 00 00 00 00 00 00 U�@............. 4000010 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ ....... 4000020 50 43 49 52 de 10 41 01 00 00 20 00 00 00 00 03 PCIR�.A... ..... 4000030 84 00 00 00 01 80 00 00 00 00 00 00 00 00 00 00 �....�.......... 4000040 f1 08 17 0f 00 01 06 55 12 2a 00 00 00 00 00 00 �......U.*...... 4000050 00 00 00 00 de 10 50 00 3e 00 21 00 81 90 40 a3 ....�.P.>.!.��@� 4000060 00 00 00 00 90 04 00 80 00 00 a5 f4 00 00 00 00 ....�..�..��.... 4000070 00 00 00 00 52 a5 b5 08 00 ba a5 10 00 00 00 08 ....R��..��..... 4000080 b5 08 01 be a7 b5 08 02 be a7 b5 08 03 be 10 00 �..��..��..�.. 4000090 00 00 04 b5 08 04 be a7 b5 08 05 be a6 b5 08 06 ...�..��..��.. 40000a0 be a6 b5 08 07 be a6 b5 08 08 be a6 b5 08 09 be ��..��..��..� 40000b0 a6 b5 08 0a be a6 b5 08 0b be a6 b5 08 0c be 10 ��..��..��..�. 40000c0 00 00 00 0a b5 08 0d be a5 b5 08 0e be a6 b5 08 ....�..��..��. 40000d0 0f be a6 b5 08 10 be a6 b5 08 11 be 10 00 00 00 .��..��..�.... 40000e0 10 b5 08 12 be 10 00 00 00 48 b5 08 13 be a6 b5 .�..�....H�..�� 40000f0 08 14 be a6 b5 08 15 be b5 08 16 ba a5 a7 b5 08 ..��..��..��. 4000100 17 be a6 b5 08 18 be a6 b5 08 19 be a6 b5 08 1a .��..��..��.. 4000110 be a6 b5 08 1b be a6 b5 08 1c be a6 b5 08 1d be ��..��..��..� 4000120 a6 b5 08 1e be a6 b5 08 1f be a6 b5 08 20 be a6 ��..��..��. �� 4000130 b5 08 21 be a6 b5 08 22 be a6 b5 08 23 be a6 b5 �.!��."��.#�� 4000140 08 24 be a6 b5 08 25 be a6 b5 08 26 be a6 b5 08 .$��.%��.&��. 4000150 27 be b5 08 28 ba a5 a6 b5 08 29 be a6 b5 08 2a '��.(��.)��.* 4000160 be a5 b5 08 2b be a6 b5 08 2c be 10 00 00 00 04 ��.+��.,�..... 4000170 b5 08 2d be a6 b5 08 2e be a6 b5 08 2f be a6 b5 �.-��..��./�� 4000180 08 30 be a7 b5 08 31 be a7 b5 08 32 be 10 00 00 .0��.1��.2�... 4000190 00 06 b5 08 33 be 10 00 00 00 23 b5 08 34 be 10 ..�.3�....#�.4�. 40001a0 00 00 00 11 b5 08 35 be 10 00 00 00 09 b5 08 36 ....�.5�.....�.6 40001b0 be 10 00 00 00 2e b5 08 37 be a6 b5 08 38 be b5 �.....�.7��.8�� 40001c0 08 39 ba a5 a6 b5 08 3a be a6 b5 08 3b be a6 b5 .9��.:��.;�� 40001d0 08 3c be a6 b5 08 3d be a7 b5 08 3e be a7 b5 08 .<��.=��.>��. 40001e0 3f be a7 b5 08 40 be a7 b5 08 41 be a7 b5 08 42 ?��.@��.A��.B 40001f0 be a7 b5 08 43 be a7 b5 08 44 be a7 b5 08 45 be ��.C��.D��.E� 4000200 a7 b5 08 46 be a7 b5 08 47 be a7 b5 08 48 be a7 ��.F��.G��.H�� 4000210 b5 08 49 be 10 00 00 00 04 b5 08 4a be a6 b5 08 �.I�.....�.J��. 4000220 4b be a6 b5 08 4c be a6 b5 08 4d be a6 b5 08 4e K��.L��.M��.N 4000230 be a6 b5 08 4f be a6 b5 08 50 be a6 b5 08 51 be ��.O��.P��.Q� 4000240 a6 b5 08 52 be 10 00 00 00 04 b5 08 53 be 10 00 ��.R�.....�.S�.. 4000250 00 00 18 b5 08 54 be a6 b5 08 55 be a6 b5 08 56 ...�.T��.U��.V 4000260 be a6 b5 08 57 be a6 b5 08 58 be a6 b5 08 59 be ��.W��.X��.Y� 4000270 a6 b5 08 5a be a6 b5 08 5b be a6 b5 08 5c be 10 ��.Z��.[��.\�. 4000280 00 00 00 04 b5 08 5d be a6 b5 08 5e be a6 b5 08 ....�.]��.^��. 4000290 5f be a6 b5 08 60 be a6 b5 08 61 be a6 b5 08 62 _��.`��.a��.b 40002a0 be a6 b5 08 63 be a6 b5 08 64 be a6 b5 08 65 be ��.c��.d��.e� 40002b0 a7 b5 08 66 be a7 b5 08 67 be b5 08 68 ba a5 a6 ��.f��.g��.h�� 40002c0 b5 08 69 be a6 b5 08 6a be a6 b5 08 6b be a6 b5 �.i��.j��.k�� 40002d0 08 6c be a7 b5 08 6d be a7 b5 08 6e be a7 b5 08 .l��.m��.n��. 40002e0 6f be a7 b5 08 70 be a7 b5 08 71 be a6 b5 08 72 o��.p��.q��.r 40002f0 be a6 b5 08 73 be a6 b5 08 74 be a6 b5 08 75 be ��.s��.t��.u� 4000300 a6 b5 08 76 be b5 08 77 ba a5 a6 b5 08 78 be a6 ��.v��.w��.x�� 4000310 b5 08 79 be a6 b5 08 7a be a6 b5 08 7b be 10 00 �.y��.z��.{�.. 4000320 00 00 04 b5 08 7c be 10 00 00 00 04 b5 08 7d be ...�.|�.....�.}� 4000330 10 00 00 00 04 b5 08 7e be 10 00 00 00 04 b5 08 .....�.~�.....�. 4000340 7f be 10 00 00 00 04 b5 08 80 be 10 00 00 00 04 �.....�.��..... 4000350 b5 08 81 be b5 08 82 ba a5 10 00 00 00 04 b5 08 �.��.��.....�. 4000360 83 be 10 00 00 00 04 b5 08 84 be 10 00 00 00 04 ��.....�.��..... 4000370 b5 08 85 be 10 00 00 00 04 b5 08 86 be 10 00 00 �.��.....�.��... 4000380 00 04 b5 08 87 be 10 00 00 00 04 b5 08 88 be 10 ..�.��.....�.��. 4000390 00 00 00 04 b5 08 89 be 10 00 00 00 04 b5 08 8a ....�.��.....�.� 40003a0 be 10 00 00 00 04 b5 08 8b be 10 00 00 00 04 b5 �.....�.��.....� 40003b0 08 8c be 10 00 00 00 04 b5 08 8d be 10 00 00 00 .��.....�.��.... 40003c0 04 b5 08 8e be b5 08 8f ba a5 a6 b5 08 90 be a6 .�.��.��.�� 40003d0 b5 08 91 be a6 b5 08 92 be a6 b5 08 93 be b5 08 �.��.��.��. 40003e0 94 ba a5 a6 b5 08 95 be a6 b5 08 96 be a7 b5 08 ��.��.��. 40003f0 97 be 10 00 00 00 04 b5 08 98 be 10 00 00 00 04 ��.....�.��..... ok 0 > 0 0 " 4,0" " /pci@80000000" begin-package ok 0 > dev /pci ls fff8043c QEMU,VGA@1 fff84a84 NE2000@2 fff84e5c mac-io@3 fff878ac pci10de,141@4 fff884f4 <noname> ok 0 > setenv focde-debug? true ok 0 > 4000020 1 byte-load ok 0 > dev /pci ls fff8043c QEMU,VGA@1 fff84a84 NE2000@2 fff84e5c mac-io@3 fff878ac pci10de,141@4 fff884f4 <noname> ok 0 > printenv name "options" boot-args "" boot-device "hd:,\\:tbxi hd:,\ppc\bootinfo.txt hd:,%BOOT" use-generic? "false" boot-script "" boot-screen "" vga-ndrv? "true" virt-size "-1" virt-base "-1" load-base "4000000" real-size "-1" real-base "-1" real-mode? "false" little-endian? "false" scroll-lock "true" skip-netboot? "false" default-mac-address "false" pci-probe-mask "-1" selftest-#megs "0" screen-#rows "75" screen-#columns "100" output-device "/pci@80000000/mac-io@3/escc/ch-a" input-device "/pci@80000000/mac-io@3/escc/ch-a" use-nvramrc? "false" oem-logo? "false" oem-banner "" oem-banner? "false" nvramrc "" fcode-debug? "false" diag-switch? "false" boot-file "" boot-command "boot" auto-boot? "false" focde-debug? "true" ok 0 > setenv fcode-debug? true ok 0 > 4000020 1 byte-load byte-load: warning stack overflow, diff -3 ok 0 > I'm not sure, I'm assuming something in the Rom is casing a stack overflow? Does openbios support fcode-verbose? gdb '/home/jam/os9.2/obj-ppc/openbios-qemu.elf.nostrip' GNU gdb (Debian 7.12-6) 7.12.0.20161007-git Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/jam/os9.2/obj-ppc/openbios-qemu.elf.nostrip...done. (gdb) target remote :1234 Remote debugging using :1234 warning: while parsing target description (at line 1): Target description specified unknown architecture "powerpc:common" warning: Could not load XML target description; ignoring 0x00000000 in ?? () (gdb) b load Breakpoint 1 at 0xfff16f7c: file /Users/jam/OpenBios/master/libopenbios/load.c, line 55. (gdb) c Continuing. gdb isn't breaking at the load command, but I'm not sure that matters anymore, as it's working, anyway. On Sunday, December 17, 2017, 9:44:34 AM EST, Jd Lyons <lyons_dj(a)yahoo.com> wrote: Sorry, I forgot I remained the Rom file and was trying to load a file that didn’t exist, lead us down a false path. Loading the correct file and dumping the load base address does yell the Rom. > On Dec 17, 2017, at 9:02 AM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote: > > On 17/12/17 13:53, Jd Lyons wrote: > >>> On Dec 17, 2017, at 7:56 AM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote: >>> >>> On 17/12/17 12:41, Jd Lyons wrote: >>> >>>>>>> Also what FS is your HD image? HFS/HFS+ should work best on qemu-system-ppc, ISO9660 works but is case-sensitive from memory. >>>>>> FS is HFS+, when I execute: >>>>>>> dir hd:,\ >>>>>> I get the list of files, so I know I’m trying to load the Rom from the correct place, and OB can read the drive. I can: >>>>>>> 4000 load hd:,\System\Library\CoreServices\BootX >>>>>> And the system boots. >>>>> >>>>> Which version of QEMU/OpenBIOS are you using? load should only copy the code and run init-program, rather than set up a CPU context and execute go. >>>>> >>>>> Presumably you are building OpenBIOS from git master to get extra debugging information? >>>> git clone https://github.com/openbios/openbios.git. ????? >>> >>> Yes, that looks correct. >>> >>>> Not sure I’m pulling from the master or not. >>>> Is there anything I need to do to enable extra debugging when I build? >>>> PATH=:/usr/local/ppcelf/ppcelf/bin:/users/hsp/src/fcode-utils-devel/toke:$PATH >>>> export PATH >>>> Make -j8 >>> >>> My normal build process for debugging OpenBIOS looks like this: >>> >>> vi Makefile.target >>> >>> (alter line 28 to build a debug ELF executable by changing the -Os option in CFLAGS to -O0) >>> >>> rm -rf obj-*; >>> ./config/scripts/switch-arch ppc >>> >>> Then start QEMU from a separate terminal like this: >>> >>> ./qemu-system-ppc -bios /patch/to/openbios/obj-pp/openbios-qemu.elf.nostrip -s -S >> Seems to fail here, never boots with -S? > > Yes indeed. -s -S tell QEMU to wait until the remote gdb connects to QEMU before starting the VM. > >>> >>> Swtich back to your OpenBIOS terminal and then do: >>> >>> powerpc-linux-gdb obj-ppc/openbios-qemu.elf.nostrip >>> target remote :1234 (connect to QEMU gdbstub) >>> b load (set breakpoint in libopenbios/load.c's load() function) >>> c >>> >>> You should then find that when you type load into OpenBIOS gdb hits the breakpoint and you can step through the C parts of the code to see what happens. Sadly gdb doesn't have support for debugging Forth, but if you can get this working it will help a lot since all of the ELF/load/init-program and PCI routines are all in C. >>> >>>> I didn’t thing the 4000 load hd:,\bootx should boot the system, yet it does. Assuming I put BootX at the root of my drive, I was thinking it should just load it into system memory at the address 4000. Adding -h doesn’t help, nor does adding -h to the boot command, I’m assuming -h is unemiplmented in Openbios. >>> >>> You actually don't need the 4000 since according to the specification "load" places the resulting image at the location specified by load-base: >>> >>> 0 > cd /options ok >>> 0 > .properties >>> name "options" >>> boot-args "" >>> boot-device "hd:,\\:tbxi hd:,\ppc\bootinfo.txt hd:,%BOOT" >>> use-generic? "false" >>> boot-script "" >>> boot-screen "" >>> vga-ndrv? "true" >>> virt-size "-1" >>> virt-base "-1" >>> load-base "4000000" >>> real-size "-1" >>> real-base "-1" >>> real-mode? "false" >>> little-endian? "false" >>> scroll-lock "true" >>> skip-netboot? "false" >>> default-mac-address "false" >>> pci-probe-mask "-1" >>> selftest-#megs "0" >>> screen-#rows "75" >>> screen-#columns "100" >>> output-device "/pci@80000000/mac-io@3/escc/ch-a" >>> input-device "/pci@80000000/mac-io@3/escc/ch-a" >>> use-nvramrc? "false" >>> oem-logo? "false" >>> oem-banner "" >>> oem-banner? "false" >>> nvramrc "" >>> fcode-debug? "false" >>> diag-switch? "false" >>> boot-file "" >>> boot-command "boot" >>> auto-boot? "true" >>> ok >>> 0 > >>> >>> Ahhh so wait a second - load-base is set to 0x4000000 rather than 0x4000 which is the default in SPARC. So how about something like: >>> >>> load hd:,\6600.fcode >>> 4000000 40 dump > > Any luck with this bit on your existing setup? > > > ATB, > > Mark.

5 10

Re: [OpenBIOS] Loading a PCI Option rom.
by Jd Lyons 17 Dec '17

17 Dec '17

> On Dec 15, 2017, at 4:02 PM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote: > > On 14/12/17 13:36, Jd Lyons wrote: > >> I’m trying to see if I can get Openbios to execute the Option rom of my Geforce 6600. Using the method described here: >> https://docs.oracle.com/cd/E19253-01/806-1379-10/fctest.html#35443 >> I’m not understanding some of it, and I’m varying the commands, somewhat. >> ok4000 dload /stand/mydev.fcode >> ok0 0 " 4,0" " /pci@1f,2000" begin-package >> ok4020 1 byte-load >> okend-package > > Yeah OpenBIOS doesn't implement dload because it doesn't have a TCP/IP stack :( > >> Rather than the above I’m using: >> ok4000 load hd:,6600.rom >> ok0 0 " 4,0" " /pci@f2000000" begin-package >> ok4020 1 byte-load >> okend-package >> I’m not sure the deference between “dload” and “load”? >> dload is not a word in Openbios, yet, and should load a file over ethernet, if I’m reading the documentation right? > > Yes, that's correct - dload probably pulls a file via TFTP or similar. > >> I’m not sure I can just load the raw rom image like this, or I need just the FCode? >> Also, should I be using the address of the pci controller( @f2000000 ) or am I misunderstanding this part, should I be using the address of my pci card? > > From memory I think the FCode executes within the context of the parent, i.e. it is responsible for calling begin-package and end-package. And also I believe that for PCI the address of the package to be created should match the PCI slot I think you are fairly close with: > > 0 0 " 4,0" " /pci@f2000000" begin-package > 4020 1 byte-load > end-package > > What happens when you try and execute that? Do you get any messages? You should also be able to display the option ROM (assuming it has loaded successfully at 0x4000) with: > > 4000 1000 dump > > And with FCode it's always useful to test in -nographic mode until you know what commands you need as it's easier to cut/paste. Don’t seem to load the Rom at all, I get ok, but then: 1 > And dumping the first 100 bytes doesn’t yield anything but zeroes. I tested to see if load of a non existent file did the same thing, and it does. So I’m not getting the command right. > ATB, > > Mark.

2 1

Re: [OpenBIOS] PIC Passthough( VGA )
by Programmingkid 17 Dec '17

17 Dec '17

If someone wanted to enhance OpenBIOS to load a FCode ROM from a video card, what would need to be changed? My theory is this line in the pci.c file's vga_config_cb() function would need this line changed: feval("['] vga-driver-fcode 2 cells + 1 byte-load"); I think the vga-driver-fcode word is what points to the generic driver. Would this be a correct assumption?

2 1

Re: [OpenBIOS] PIC Passthough( VGA )
by Mark Cave-Ayland 12 Dec '17

12 Dec '17

On 12/12/17 03:24, Jd Lyons wrote: >>> I’m assuming that Openbios is not reading the Option Rom of the card, but I’m not sure why. >> >> Well... at the moment we actually cheat ;) Instead of reading the VGA FCode ROM from the virtual display adapter, OpenBIOS embeds its own copy of the FCode ROM and executes it unconditionally when it detects a VGA display device. I must admit I hadn't considered that someone would be interested in legacy device passthough to enable a device that isn't the standard QEMU display adapter. > > Are we talking about the ‘NDRV’ patch? > > I noticed that the ‘NDRV’ for the QEMU,VGA loads to any VGA card in the system. Yet the vga-pci.c loads a PC Video bios for the qemu,vga device, tho I’m pretty sure Openbios doesn’t use it. I’m having trouble locating how the QEMU,VGA device is able to be used by Openbios, how does it “init” the device? The NDRV driver is loaded into the "driver,AAPL..." property after the device node has been created by the FCode device so that occurs later in the process. OpenBIOS creates a basic PCI device node for every device it finds during a PCI bus scan and then executes a callback depending upon the resulting vendorid/deviceid. The code in OpenBIOS is in vga_config_cb() and as you can see, it currently executes the in-built FCode directly rather than trying to map the ROM using the process documented at http://mirror.informatimago.com/next/developer.apple.com/technotes/tn/tn200…. >> As a starting point I'd suggest that if you still have the old hardware lying around, you can use the article above to extract the ROM from a real Mac and then run the resulting code through fcode-utils detok which effectively "decompiles" the ROM and therefore give us an idea as to how many Forth words need to be implemented. >> > > Ok, I’ve done some detok of nVidia Fcode Rom’s before, and I know about words that Openfirmware doesn’t understand, years ago I wanted two get an nVidia card to work in my Old World PM8600, and I figured it was the “map-in” bug, but as it turns out, it was some words in nVidia's FCode Rom that my version of OF didn’t have. > > Atriu Itra was able to get an nVidia card to work in OpenFimware on an Old World machine, but it wouldn’t boot the OS, however if he had stayed at it, I’m sure he’d have figured it out. He did basically what you are preposing. Guy was an Fcode master, we could really use him on this project. Sounds like someone has already done some of the work here - do you have a copy of the detok FCode or any emails related to the subject at all? Otherwise I would say the first step would be to hack OpenBIOS to expose the passthrough ROM and then dump it out from within QEMU. ATB, Mark.

1 0

PIC Passthough( VGA )
by Jd Lyons 11 Dec '17

11 Dec '17

I was hoping I could use PCI Passthrough with an old Apple OEM Geforce 6600 PCI-E card, as the display device, but I’m not having any luck. Openbios seems to have an error” Can not manage “VGA controller’ PCI device type ‘display’ 10de 141 ( 3 0 0 ) I’m assuming that Openbios is not reading the Option Rom of the card, but I’m not sure why. I’m having trouble checking to see if Openbios can read the Rom of the card, I’m, sure I’m not doing it right, could someone offer a little guidance? http://mirror.informatimago.com/next/developer.apple.com/technotes/tn/tn200… >dev / ls >dev pci >dev @10 >.properties >” ..” find-device open >. This is where, I think it should return ffffffff, however it returns -1. I was thinking “-1” was 0xffffffff? Here is where I’m getting stuck: >1180e config-b@ config-b@ undefined word. Can anyone offer what I’m doing wrong, should I have another value for “1180e”? The address 1180e is the Configuration Space address we want to read. The word config-b@ reads a byte from this address. The . word displays the top item on the stack, which is the Header Type register. Since this is a Header Type Zero, we know the expansion ROM BAR is at offset 0x30. Thanks

2 1