Thanks Mark, I’m unsure how to get Openbios to execute the Fcode, I can load it to the correct address on my PCI card, via a little hack to Openbios.
I’d really like to just go ahead and fix the fact that Openbios doesn’t probe for Fcode Rom’s on PCI devices. I know this will likely break a few things, requiring other fixes. If I had some idea of where to start, some sample code I maybe able to hack something together, but it would likely break more than it fixes.
I’m sure you're busy, I’m retired and this is just something to keep my occupied, tho I’m not really qualified to do it.
If it could be added as a priority to Openbios, to probe and execute FCode Rom’s on PCI devices, that would be great. I’m sure someone will take it up when they have a little spare time.
I’m having trouble CC ing the list, I know stupid of me.
Any idea what the unnamed FCode in the detok is?
Does detok just not understand it, or is it words or methods?
On Dec 15, 2017, at 4:08 PM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
On 12/12/17 09:06, Jd Lyons wrote:
On Dec 12, 2017, at 3:24 AM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk mailto:mark.cave-ayland@ilande.co.uk> wrote:
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/tn2000....
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.
We had an online forum were we discussed hacking Fcode Roms, all gone now tho, but a lot of info, and Rom still at: http://themacelite.wikidot.com Most of all the old Fcode Roms in the downloads section, I don’t think anyone added the old 3dfx Roms for Powermac’s, but they can be extracted from the 3dfx control panel. I did some work emulating the Voodoo cards for Openbios/Qemu_PPC, really I’m just wanting to emulate a Voodo2, so I’m playing around with PCI Passthough while waiting to find an affordable Voodoo2, you wouldn’t believe what they sell for these days. The 6600 was only a few bucks, so I got it, but I was hoping to lighten the Emulated cpu load, as screen redraws seem to suck up all the CPU cycles under OS X. So a little QE may help there. Anyway, the Voodoo2 didn’t have a rom, and it wasn’t really a VGA card, those some people have hacked it to display the desktop, it was really a 3D Accelerator with VGA Passthough for the main system display card. So I don’t think I’ll have any trouble with PCI Passthrough with that. Anyway, I think we may want to work on some code for Openbios that detects vfio-pci and reads the rom for the device and tries to execute the Fcode, rather than what we have now, it’s not really a workable solution for PCI Passthrough of VGA. The pseries firmware is aware of a vfio-pci device, but it doesn’t seem to be aware of the Rom on the card either. I did some hacks to Openbios and got the rom mapped in @0x30 for the 6600, but Openbios still does not try and execute the rom. A quick look at the detok Fcode:
Thanks for the dump of the ROM. At first glance I don't see anything too unusual in there - the main culprits to look at will be map-in, my-address and the config-* words for accessing PCI config space...
Once you're able to run the FCode you can also do:
true to fcode-debug?
which should dump out the FCode tokens on the console as they are being debugged.
ATB,
Mark.
On 15/12/17 23:26, Jd Lyons wrote:
Thanks Mark, I’m unsure how to get Openbios to execute the Fcode, I can load it to the correct address on my PCI card, via a little hack to Openbios.
I’d really like to just go ahead and fix the fact that Openbios doesn’t probe for Fcode Rom’s on PCI devices. I know this will likely break a few things, requiring other fixes. If I had some idea of where to start, some sample code I maybe able to hack something together, but it would likely break more than it fixes.
I’m sure you're busy, I’m retired and this is just something to keep my occupied, tho I’m not really qualified to do it.
I really wouldn't worry about being qualified. My involvement with OpenBIOS and QEMU started because I wanted to try and boot some old Solaris HD images in QEMU, and that was 8 years ago and I'm still not quite there - it's been a great learning experience though :)
The part that takes the time is doing the investigation rather than the patches, so just being able to hack up something that works gives us something to work with. Yes, I am fairly busy with other bits of work right now but I'm happy to answer any questions that you might have.
If it could be added as a priority to Openbios, to probe and execute FCode Rom’s on PCI devices, that would be great. I’m sure someone will take it up when they have a little spare time.
I would say that there are 2 different tasks here:
1) Add PCI option ROM support to OpenBIOS
From looking at the code it appears that the pc-bios/vgabios-stdvga.bin option ROM is added to QEMU's default PCI VGA adapter, so you need to add the relevant properties to "reg"/"assigned-addresses" using your previous http://mirror.informatimago.com/next/developer.apple.com/technotes/tn/tn2000... link as a guide.
The above link suggests the key is to look at offset 0x30 in configuration space for that device and use that to determine ROM base address but please experiment and report back what happens.
2) Try executing the FCode and see what fails
Obviously we know about the config-* Forth words, but creating Forth wrappers around those words shouldn't be too hard - I can point you towards commits that do similar things when you get to that point.
I’m having trouble CC ing the list, I know stupid of me.
Any idea what the unnamed FCode in the detok is?
Does detok just not understand it, or is it words or methods?
From memory I believe it's an anonymous Forth word, i.e. one where the dictionary name is empty but it can still be called by its address.
ATB,
Mark.
Hi!
On Sun, Dec 17, 2017 at 10:22:29AM +0000, Mark Cave-Ayland wrote:
On 15/12/17 23:26, Jd Lyons wrote:
I’m having trouble CC ing the list, I know stupid of me.
Any idea what the unnamed FCode in the detok is?
Does detok just not understand it, or is it words or methods?
From memory I believe it's an anonymous Forth word, i.e. one where the dictionary name is empty but it can still be called by its address.
That's right. It's a token created with new-token instead of named-token or external-token (b5, b6, ca respectively). It has no name, so you cannot call it by name, but it is perfectly valid FCode, you can access the created word by token number like everything else.
Segher
I'm a little lost. I don't have an old G5 with a PCI-E slot to dump the propreties of the card. I'm not sure if the PCI Header is not being loaded that the FCode can match to the device(pci10de,0141). I don't know if that's related to this issue or not.
When I do: 0 > 0 0 " 4,0" " /pci@f2000000" begin-package ok 0 > dev /pci ls fff8042c mac-io@c fff83008 usb@d fff83374 QEMU,VGA@e fff87994 NE2000@f fff87d44 pci10de,141@10 fffad3dc <noname> ok 0 >
It creates a <noname> device, but it has no address, so I can't get the .properties or words from it. I'm sure I'm not getting this command right, I don't think OpenBios has a "Slot" property for PCI Cards? That maybe an issue?
On Sunday, December 17, 2017, 12:06:51 PM EST, Segher Boessenkool segher@kernel.crashing.org wrote:
Hi!
On Sun, Dec 17, 2017 at 10:22:29AM +0000, Mark Cave-Ayland wrote:
On 15/12/17 23:26, Jd Lyons wrote:
I’m having trouble CC ing the list, I know stupid of me.
Any idea what the unnamed FCode in the detok is?
Does detok just not understand it, or is it words or methods?
From memory I believe it's an anonymous Forth word, i.e. one where the dictionary name is empty but it can still be called by its address.
That's right. It's a token created with new-token instead of named-token or external-token (b5, b6, ca respectively). It has no name, so you cannot call it by name, but it is perfectly valid FCode, you can access the created word by token number like everything else.
Segher
On 2017-Dec-17 12:34 , Jd Lyons wrote:
When I do:
0 > 0 0 " 4,0" " /pci@f2000000" begin-package ok 0 > dev /pci ls fff8042c mac-io@c fff83008 usb@d fff83374 QEMU,VGA@e fff87994 NE2000@f fff87d44 pci10de,141@10 fffad3dc <noname> ok 0 >
It creates a <noname> device, but it has no address, so I can't get the .properties or words from it. I'm sure I'm not getting this command right, I don't think OpenBios has a "Slot" property for PCI Cards?
That maybe an issue?
The above is expected behaviour; when you create the node, it has no name. The FCode is supposed to create the "reg" and "name" properties which give it the values you see. Although, looking at the above, I'm seeing a "pci10de,141" node, which is probably your card. Maybe you should be running the FCode in that node? Rather than
0 0 " 4,0" " /pci@f2000000" begin-package
try
" /pci/pci10de,141@10" begin-select-dev
Then do the load/byte-load operations.
On Dec 17, 2017, at 8:44 PM, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2017-Dec-17 12:34 , Jd Lyons wrote:
When I do:
0 > 0 0 " 4,0" " /pci@f2000000" begin-package ok 0 > dev /pci ls fff8042c mac-io@c fff83008 usb@d fff83374 QEMU,VGA@e fff87994 NE2000@f fff87d44 pci10de,141@10 fffad3dc <noname> ok 0 >
It creates a <noname> device, but it has no address, so I can't get the .properties or words from it. I'm sure I'm not getting this command right, I don't think OpenBios has a "Slot" property for PCI Cards?
That maybe an issue?
The above is expected behaviour; when you create the node, it has no name. The FCode is supposed to create the "reg" and "name" properties which give it the values you see. Although, looking at the above, I'm seeing a "pci10de,141" node, which is probably your card. Maybe you should be running the FCode in that node? Rather than
0 0 " 4,0" " /pci@f2000000" begin-package
try
" /pci/pci10de,141@10" begin-select-dev
Then do the load/byte-load operations.
I’m think the same thing, just didn’t no how to select the device as the node, unfortunately it seems “begin-select-dev” isn’t a word in Openbios, yet.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On 2017-Dec-17 20:53 , Jd Lyons wrote:
I’m think the same thing, just didn’t no how to select the device as the node, unfortunately it seems “begin-select-dev” isn’t a word in Openbios, yet.
Aw, crud. Then use " dev /pci/pci10d3,141@10" . That's not quite correct, but it should work. If not, try begin-open-dev (per the name changes on page 251 of IEEE 1275).
Alternatively, you could try:
dev /pci/pci10d3,141@10 : open true ; open-dev " /pci/pci10d3,141@10"
then do the load/byte-load operations.
begin-open-dev is also not a word in openbios
On Dec 17, 2017, at 9:03 PM, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2017-Dec-17 20:53 , Jd Lyons wrote:
I’m think the same thing, just didn’t no how to select the device as the node, unfortunately it seems “begin-select-dev” isn’t a word in Openbios, yet.
Aw, crud. Then use " dev /pci/pci10d3,141@10" . That's not quite correct, but it should work. If not, try begin-open-dev (per the name changes on page 251 of IEEE 1275).
Alternatively, you could try:
dev /pci/pci10d3,141@10 : open true ; open-dev " /pci/pci10d3,141@10"
then do the load/byte-load operations.
begin-open-dev is also not a word in openbios.
Not sure about the next command:
dev /pci/pci10de,141@10 works as expected.
But, I’m not sure about the next command, should it be
: open true ; with a space between : and open, that returns "open is not unique". Maybe running up against the generic FCode that Openbios loads for all VGA devices, it already has the open word?
:open true; this returns :open: undefined word.
Thanks for the help, it’s been so many year since I fooled with Openfirmware that I’ve forgotten much of what I knew, whitch wasn’t that much to begin with. I always wanted to figure out how to test FCode Roms on cards before I flashed the EPRom, but I never did figure it out, so I just flashed each Rom to see if/how it would work.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On 2017-Dec-17 21:25 , Jd Lyons wrote:
dev /pci/pci10de,141@10 works as expected.
But, I’m not sure about the next command, should it be
: open true ; with a space between : and open, that returns "open is not unique".
Oh (yes, the space is needed. ": " says the next token is the name of a method to define). That means it already has an open method, that shouldn't happen unless it has already interpreted an FCode.
Maybe running up against the generic FCode that Openbios loads for all VGA devices, it already has the open word?
Could well be.
Since it already has an open method, try:
" /pci/pci10d3,141@10" open-dev
(I had it backwards before. You need the string as an argument to open-dev).
Assuming that works, try "words" in there to see what's defined. If only open is defined, then try doing the load and byte-load operations. If it has a bunch of methods, that suggests that that openbios' internal fcode has already been applied to it, and you'll have to disable that somehow.
On Dec 17, 2017, at 9:51 PM, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2017-Dec-17 21:25 , Jd Lyons wrote:
dev /pci/pci10de,141@10 works as expected.
But, I’m not sure about the next command, should it be
: open true ; with a space between : and open, that returns "open is not unique".
Oh (yes, the space is needed. ": " says the next token is the name of a method to define). That means it already has an open method, that shouldn't happen unless it has already interpreted an FCode.
Maybe running up against the generic FCode that Openbios loads for all VGA devices, it already has the open word?
Could well be.
Since it already has an open method, try:
" /pci/pci10d3,141@10" open-dev
(I had it backwards before. You need the string as an argument to open-dev).
Assuming that works, try "words" in there to see what's defined. If only open is defined, then try doing the load and byte-load operations. If it has a bunch of methods, that suggests that that openbios' internal fcode has already been applied to it, and you'll have to disable that somehow.
It has the open and close words, really two open words now, because we added one.
I’ll rebuild Openbios and edit out the:
feval("['] vga-driver-fcode 2 cells + 1 byte-load”);
That should keep the Fcode for VGA devices from loading…..
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
-
Jd Lyons -
Mark Cave-Ayland -
Segher Boessenkool -
Tarl Neustaedter