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?
On 2018-Mar-19 18:09 , James Lyons via OpenBIOS wrote:
[...] " 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.
Did the load bring the FCode in? You don't want to strip out the PCI header, you want to chase the pointer in the PCI header to where the FCode starts, and make the byte-load command take that address (e.g., in the above, given the file you sent, you'd start at 800040). The file you sent does seem to have FCode at offset 40; the "start1" is an f1, so it's starting the way it should.
On Mar 19, 2018, at 6:38 PM, Tarl Neustaedter wrote:
On 2018-Mar-19 18:09 , James Lyons via OpenBIOS wrote:
[...] " 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.
Did the load bring the FCode in?
Thanks Tarl, 800000 100 dump returns the FCode, so that seems to be OK
You don't want to strip out the PCI header, you want to chase the pointer in the PCI header to where the FCode starts, and make the byte-load command take that address (e.g., in the above, given the file you sent, you'd start at 800040).
If I don't strip the header OF returns this to the load command: unrecognized Client Program format Same thing with: boot hd:12,/ppc/4600.rom -h unrecognized Client Program format the -h tag should tell not to try and execute, just load, but that doesn't seem to work. Maybe Apple systems don't support it? I stripped everything to 0x40 in the ROM to get it to load with the load command, I'm not sure how I can get it to load without doing that?
The file you sent does seem to have FCode at offset 40; the "start1" is an f1, so it's starting the way it should.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On 2018-Mar-19 20:03 , James Lyons via OpenBIOS wrote:
If I don't strip the header OF returns this to the load command:
unrecognized Client Program format
Aiee. It's trying to execute it, who knows what it did to you. You need to find a way of getting the FCode brought in which doesn't cause it to execute, so you can control where it does execute.
On Mon, Mar 19, 2018 at 06:09:58PM -0400, James Lyons via OpenBIOS wrote:
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.
You probably need to call its "open" method before it does much. Segher
On Mar 19, 2018, at 7:57 PM, Segher Boessenkool wrote:
On Mon, Mar 19, 2018 at 06:09:58PM -0400, James Lyons via OpenBIOS wrote:
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.
You probably need to call its "open" method before it does much.
Thanks Segher, I tried: dev agp/@10 : open true ; open-dev " agp/@10" ALLOC-MEM request too big! Did I do it correct?
Segher
On Mon, Mar 19, 2018 at 08:11:25PM -0400, James Lyons wrote:
On Mar 19, 2018, at 7:57 PM, Segher Boessenkool wrote:
On Mon, Mar 19, 2018 at 06:09:58PM -0400, James Lyons via OpenBIOS wrote:
" 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.
You probably need to call its "open" method before it does much.
Thanks Segher,
I tried:
dev agp/@10 : open true ; open-dev " agp/@10"
ALLOC-MEM request too big!
Did I do it correct?
You destroyed (well, made inaccessible) any "open" method there was. That is certainly not going to help. Segher
On Mar 19, 2018, at 8:58 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
On Mon, Mar 19, 2018 at 08:11:25PM -0400, James Lyons wrote:
On Mar 19, 2018, at 7:57 PM, Segher Boessenkool wrote:
On Mon, Mar 19, 2018 at 06:09:58PM -0400, James Lyons via OpenBIOS wrote:
" 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.
You probably need to call its "open" method before it does much.
Thanks Segher,
I tried:
dev agp/@10 : open true ; open-dev " agp/@10"
ALLOC-MEM request too big!
Did I do it correct?
You destroyed (well, made inaccessible) any "open" method there was. That is certainly not going to help.
Segher
Segher, how would I properly call open? I seem to have a card with a dead EEPOM on it, so I can’t flash my Fcode ROM to it. Also, does anyone know if Apple’s OF supports fcode-verbose? What I am trying to do, load the Fcode Rom from a file may not be supported in Apple’s Open Firmware. Arti Irta never mentioned it could be done, so it’s maybe there was a reason for that.
On Thu, Mar 29, 2018 at 06:44:15AM -0400, Jd Lyons wrote:
On Mar 19, 2018, at 8:58 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote: On Mon, Mar 19, 2018 at 08:11:25PM -0400, James Lyons wrote:
I tried:
dev agp/@10 : open true ; open-dev " agp/@10"
ALLOC-MEM request too big!
Did I do it correct?
You destroyed (well, made inaccessible) any "open" method there was. That is certainly not going to help.
Segher, how would I properly call open?
You shouldn't do that : open ... If the node did not have an "open" method already, something else is wrong (which you cannot fix _this_ way).
Also, does anyone know if Apple’s OF supports fcode-verbose?
It does afair.
What I am trying to do, load the Fcode Rom from a file may not be supported in Apple’s Open Firmware. Arti Irta never mentioned it could be done, so it’s maybe there was a reason for that.
It can be done. Segher
On Mar 29, 2018, at 3:57 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
On Thu, Mar 29, 2018 at 06:44:15AM -0400, Jd Lyons wrote:
On Mar 19, 2018, at 8:58 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote: On Mon, Mar 19, 2018 at 08:11:25PM -0400, James Lyons wrote:
I tried:
dev agp/@10 : open true ; open-dev " agp/@10"
ALLOC-MEM request too big!
Did I do it correct?
You destroyed (well, made inaccessible) any "open" method there was. That is certainly not going to help.
Segher, how would I properly call open?
You shouldn't do that : open ... If the node did not have an "open" method already, something else is wrong (which you cannot fix _this_ way).
Also, does anyone know if Apple’s OF supports fcode-verbose?
It does afair.
What I am trying to do, load the Fcode Rom from a file may not be supported in Apple’s Open Firmware. Arti Irta never mentioned it could be done, so it’s maybe there was a reason for that.
It can be done.
Segher
Joe Van Tunen gave me a look at how Apple’s OF implements the load command: The only information I could give is what you can get by disassembling the compiled fcode. The best result would probably come from a PowerMac G5 Quad Core (one of the last Macs to use Open Firmware and therefore has the latest Apple implementation of Open Firmware). Part of the disassembly looks like this: FF8905B5: b(:) \ [0x0b7] 0x1cf0 boot|load FF8905C8: 967E FFFC stwu r19,-4(r30) FF8905CC: 7E68 02A6 mflr r19 FF8905D0: 4BFF F789 FF88FD58 bl _reboot-command FF8905D4: 4BFB A4E5 FF84AAB8 bl pack FF8905D8: 4BFB 8701 FF848CD8 bl drop FF8905DC: 4BFD 29E5 FF862FC0 bl security-mode? FF8905E0: 4BFB 6A49 FF847028 bl (b?branch) FF8905E4: 4800 0020 FF890604 b $+32 FF8905E8: 4BFC 6251 FF856838 bl carret FF8905EC: 4BFC C195 FF85C780 bl word FF8905F0: 4BFB 86E9 FF848CD8 bl drop FF8905F4: 4BFB 8B6D FF849160 bl 0 FF8905F8: 4BFB 8B69 FF849160 bl 0 FF8905FC: 4BFF F68D FF88FC88 bl (load) FF890600: 4800 0014 FF890614 b $+20 FF890604: 4BFC 6235 FF856838 bl carret FF890608: 4BFC C179 FF85C780 bl word FF89060C: 4BFB 9BBD FF84A1C8 bl count FF890610: 4BFF F679 FF88FC88 bl (load) FF890614: 4BFB 8B6D FF849180 bl 1 FF890618: 4BFC A659 FF85AC70 bl oft FF89061C: 4BFC 5FC5 FF8565E0 bl not FF890620: 4BFB 6A09 FF847028 bl (b?branch) FF890624: 4800 0020 FF890644 b $+32 FF890628: 4BFB 6969 FF846F90 bl b<"> FF89062C: 0A ... dc.b " load-size=" FF890638: 4BFC 2381 FF8529B8 bl type FF89063C: 4BFF EAB5 FF88F0F0 bl load-size FF890640: 4BFC 6C91 FF8572D0 bl u. FF890644: 4BFB 8B3D FF849180 bl 1 FF890648: 4BFC A629 FF85AC70 bl oft FF89064C: 4BFC 5F95 FF8565E0 bl not FF890650: 4BFB 69D9 FF847028 bl (b?branch) FF890654: 4800 002C FF890680 b $+44 FF890658: 4BFB 6939 FF846F90 bl b<"> FF89065C: 08 ... dc.b " adler32=" FF890668: 4BFC 2351 FF8529B8 bl type FF89066C: 4BFB 8B15 FF849180 bl 1 FF890670: 4BFB 77A1 FF847E10 bl load_base FF890674: 4BFF EA7D FF88F0F0 bl load-size FF890678: 4BFC 60B1 FF856728 bl adler32 FF89067C: 4BFC 6C55 FF8572D0 bl u. FF890680: 4BFB 8B01 FF849180 bl 1 FF890684: 4BFC A5ED FF85AC70 bl oft FF890688: 4BFC 5F59 FF8565E0 bl not FF89068C: 4BFB 699D FF847028 bl (b?branch) FF890690: 4800 0008 FF890698 b $+8 FF890694: 4BFC 2305 FF852998 bl cr FF890698: 4BFB 5E08 FF8464A0 b exit FF8906CD: b(:) \ [0x0b7] 0x1cf2 load FF8906D8: 967E FFFC stwu r19,-4(r30) FF8906DC: 7E68 02A6 mflr r19 FF8906E0: 4BFB 68B1 FF846F90 bl b<"> FF8906E4: 05 ... dc.b " load " FF8906EC: 4BFF FEDD FF8905C8 bl boot|load FF8906F0: 4BFF FA19 FF890108 bl (init-program) FF8906F4: 4BFB 5DAC FF8464A0 b exit FF890865: b(:) \ [0x0b7] 0x1cf8 boot FF890870: 967E FFFC stwu r19,-4(r30) FF890874: 7E68 02A6 mflr r19 FF890878: 4BFB 6719 FF846F90 bl b<"> FF89087C: 05 ... dc.b " boot " FF890884: 4BFF FD45 FF8905C8 bl boot|load FF890888: 4BFF F881 FF890108 bl (init-program) FF89088C: 4BFF FEA5 FF890730 bl go FF890890: 4BFB 5C10 FF8464A0 b exit It should be possible to decompile the compiled fcode in the same way that the Open Firmware "see" command does. Earlier Mac's (Old World Macs) may have tokenized fcode in their ROM that you can more easily detokenize but some of the words may be unnamed (headerless). I guess the G5 (and other New World Macs) has tokenized fcode somewhere but I don't know where it is - maybe it's compressed? The following is detokenized output from a Beige G3's tokenized fcode: : colon_definition_function_8b7 \ (8b7) [0b5 0b7] buffer_8b4_8 \ (8b4 8) [8b4] pack \ [083] drop \ [046] ['] colon_definition_function_8b6 \ (8b6) [011 8b6] to init-program \ [0c3 8b3] carret \ [625] word \ [589] count \ [084] colon_definition_function_8b2 \ (8b2) [8b2] ; \ [0c2] : boot \ (8bc) [0ca 0b7] " boot " \ [012] colon_definition_function_8b7 \ (8b7) [8b7] init-program \ [8b3] go \ [8b8] ; \ [0c2] : load \ (8b9) [0ca 0b7] " load " \ [012] colon_definition_function_8b7 \ (8b7) [8b7] init-program \ [8b3] ; \ [0c2] You'll need the full listing to be able to find the information you need. As you can see the G5 has many more named words than the Beige G3 (as well as more code). The B&W G3 (another New World Mac) is somewhere in between. I don't see "fcode-verbose?" anywhere in the outputs of any Macs. The G5 seems to have some logger stuff but I don't know what that's all about. "oft" (seen above) is a flag in "logger-flags". Setting the flag adds some logging somehow. There are different flags to log different things. Besides logging there are "debug", "resume", "tracing", "stepping" commands. I still have some PowerMacs (8600, 9600, B&W G3, G5) but I haven't turned them on in a long while. What jumps out at me, is both ‘load' and ‘boot’ one the G5 call ‘boatload’, would this be the reason that it is trying to execute the Option ROM when I try and ‘load’ it? Do I need to try and fix that so I can load the entire file, without clipping the PCI Header? Or is getting the current instance by calling " agp/@10" open-dev to my-self, enough that I don’t need the header? I’m not real sure how to proceed, just not exactly sure what is going wrong, how this differers from SLOF and Openbios. What seems to differ is: 1. The load command tries to execute the file, rather than just loading it to the base address like OB/SLOF. 2. 1 byte-load returns ok, but doesn’t seem to do anything, tho it’s hard for me to tell without fcode-verbose.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On Fri, Mar 30, 2018 at 04:14:48AM -0400, Jd Lyons wrote:
FF8906CD: b(:) \ [0x0b7] 0x1cf2 load FF8906D8: 967E FFFC stwu r19,-4(r30) FF8906DC: 7E68 02A6 mflr r19 FF8906E0: 4BFB 68B1 FF846F90 bl b<"> FF8906E4: 05 ... dc.b " load " FF8906EC: 4BFF FEDD FF8905C8 bl boot|load FF8906F0: 4BFF FA19 FF890108 bl (init-program) FF8906F4: 4BFB 5DAC FF8464A0 b exit
FF890865: b(:) \ [0x0b7] 0x1cf8 boot FF890870: 967E FFFC stwu r19,-4(r30) FF890874: 7E68 02A6 mflr r19 FF890878: 4BFB 6719 FF846F90 bl b<"> FF89087C: 05 ... dc.b " boot " FF890884: 4BFF FD45 FF8905C8 bl boot|load FF890888: 4BFF F881 FF890108 bl (init-program) FF89088C: 4BFF FEA5 FF890730 bl go FF890890: 4BFB 5C10 FF8464A0 b exit
It should be possible to decompile the compiled fcode in the same way that the Open Firmware "see" command does.
It is possible (I have done it).
Earlier Mac's (Old World Macs) may have tokenized fcode in their ROM that you can more easily detokenize but some of the words may be unnamed (headerless). I guess the G5 (and other New World Macs) has tokenized fcode somewhere but I don't know where it is - maybe it's compressed?
Yes, many sections are compressed (with LZ77 iirc). Not *all* code is tokenised, but most is. And Apple uses some non-standard FCodes, too (for local variables, most prominently). And their drivers can use anything defined in the "main" OF (so you cannot transplant them to a different machine or a different FW version even).
What jumps out at me, is both ‘load' and ‘boot’ one the G5 call ‘boatload’, would this be the reason that it is trying to execute the Option ROM when I try and ‘load’ it?
"load" does not do "go" (or at least it should not!) Segher
On 3/30/18, 4:02 PM, "OpenBIOS on behalf of Segher Boessenkool" <openbios-bounces@openbios.org on behalf of segher@kernel.crashing.org> wrote: And Apple uses some non-standard FCodes, too (for local variables, most prominently). And their drivers can use anything defined in the "main" OF (so you cannot transplant them to a different machine or a different FW version even). Right. Local variables are used by Apple's device drivers (for example, "mesh" (SATA) and "control" (PowerMac 8600 graphics) devices). Different PowerMacs use different tokens for defining and using local variables. Apple used different tokenizers for the different PowerMacs so the local variables in the tokenized output will work only for PowerMacs using the same Open Firmware. Local variables are not used by third party drivers (ATI/AMD, Nvidia) so third party drivers should work in different Open Firmware implementations, as long as the driver doesn't depend on other non-standard stuff. OpenBIOS does have support for local variables: : hello { a b ; c } a b + -> c c ; 3 4 hello . 7 The runtime support functions for local variables have names on the PowerMac G5 that are different than what OpenBIOS uses. The functions on Old World Macs are unnamed.
On 31/03/18 02:37, Joe van Tunen wrote:
On 3/30/18, 4:02 PM, "OpenBIOS on behalf of Segher Boessenkool" <openbios-bounces@openbios.org on behalf of segher@kernel.crashing.org> wrote:
And Apple uses some non-standard FCodes, too (for local variables, most prominently). And their drivers can use anything defined in the "main" OF (so you cannot transplant them to a different machine or a different FW version even).
Right. Local variables are used by Apple's device drivers (for example, "mesh" (SATA) and "control" (PowerMac 8600 graphics) devices). Different PowerMacs use different tokens for defining and using local variables. Apple used different tokenizers for the different PowerMacs so the local variables in the tokenized output will work only for PowerMacs using the same Open Firmware.
Local variables are not used by third party drivers (ATI/AMD, Nvidia) so third party drivers should work in different Open Firmware implementations, as long as the driver doesn't depend on other non-standard stuff.
OpenBIOS does have support for local variables:
: hello { a b ; c } a b + -> c c ; 3 4 hello . 7
The runtime support functions for local variables have names on the PowerMac G5 that are different than what OpenBIOS uses. The functions on Old World Macs are unnamed.
Right. As the author of the OpenBIOS local variable support, I can confirm that it's limited to Forth without any associated FCode support. It was added simply to be able to run the Apple bootloaders. ATB, Mark.
On 4/2/18, 5:51 AM, "Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk> wrote: On 31/03/18 02:37, Joe van Tunen wrote: > On 3/30/18, 4:02 PM, "OpenBIOS on behalf of Segher Boessenkool" <openbios-bounces@openbios.org on behalf of segher@kernel.crashing.org> wrote: > > And Apple uses some non-standard FCodes, too > (for local variables, most prominently). And their drivers can use > anything defined in the "main" OF (so you cannot transplant them to > a different machine or a different FW version even). > > > Right. Local variables are used by Apple's device drivers (for example, "mesh" (SATA) and "control" (PowerMac 8600 graphics) devices). Different PowerMacs use different tokens for defining and using local variables. Apple used > different tokenizers for the different PowerMacs so the local variables in the tokenized output will work only for PowerMacs using the same Open Firmware. > > Local variables are not used by third party drivers (ATI/AMD, Nvidia) so third party drivers should work in different Open Firmware implementations, as long as the driver doesn't depend on other non-standard stuff. > > OpenBIOS does have support for local variables: > > : hello { a b ; c } a b + -> c c ; > 3 4 hello . > 7 > > The runtime support functions for local variables have names on the PowerMac G5 that are different than what OpenBIOS uses. The functions on Old World Macs are unnamed. Right. As the author of the OpenBIOS local variable support, I can confirm that it's limited to Forth without any associated FCode support. It was added simply to be able to run the Apple bootloaders. ATB, Mark. Fcode support for OpenBIOS is not necessary because the Apple bootloader is in forth, and any standard driver would not use local variable support, or the driver could be included as forth instead of fcode. You couldn't add Apple fcode support because the Apple fcode drivers use different tokens in different firmwares. Below is the results from the firmwares I've checked. In any case, Apple's fcode drivers can be converted from fcode to forth, which your local variable support could then probably handle. But Apple's fcode drivers are for Apple hardware, so there's little reason to do that unless you want to replace Apple's Open Firwmare on Apple hardware. /* fcodes from New World Macs are not included since I only have compiled fcode from them to look at as I have not made an effort to search for actual fcode which is probably compressed in the rom. */ /* The PowerMac G5 info is not included because it keeps all the names even when fcode-debug? is false. The names below of the compiled fcode tokens are the names from the corresponding G5 version of the compiled fcode token. */ /* The B&W G3 has names for the compiled fcodes also, so I don't remember why I included them here. */ /* Only the compiled fcode tokens that are included in Apple fcode drivers are included here. */ if (mac_rom & 1) { /* PowerMac 8600 ROM tokens */ add_token( 0x401, "{ ... ; .... }" ); /* local variables { local_0 ... local_n-1 ; ... }; n is stored in the next byte */ /* compiled fcode tokens */ add_token( 0x432, "(val)" ); add_token( 0x433, "(i-val)" ); add_token( 0x434, "b<to>" ); add_token( 0x435, "b<to>1" ); add_token( 0x436, "(i-to)" ); add_token( 0x437, "(var)" ); add_token( 0x438, "(i-var)" ); add_token( 0x43C, "(defer)" ); add_token( 0x43D, "(i-defer)" ); add_token( 0x43E, "(field)" ); add_token( 0x43F, "b<lit>" ); add_token( 0x440, "b<'>" ); add_token( 0x441, "{'}" ); add_token( 0x454, "b<\">" ); } if (mac_rom & 2) { /* PowerMac G3 ROM tokens */ add_token( 0x407, "{ ; ... }" ); add_token( 0x408, "{ local_0 ; ... }" ); add_token( 0x409, "{ local_0 local_1 ; ... }" ); add_token( 0x40A, "{ local_0 local_1 local_2 ; ... }" ); add_token( 0x40B, "{ local_0 local_1 local_2 local_3 ; ... }" ); add_token( 0x40C, "{ local_0 local_1 local_2 local_3 local_4 ; ... }" ); add_token( 0x40D, "{ local_0 local_1 local_2 local_3 local_4 local_5 ; ... }" ); add_token( 0x40E, "{ local_0 local_1 local_2 local_3 local_4 local_5 local_6 ; ... }" ); add_token( 0x40F, "{ local_0 local_1 local_2 local_3 local_4 local_5 local_6 local_7 ; ... }" ); /* compiled fcode tokens */ add_token( 0x43F, "(val)" ); add_token( 0x440, "(i-val)" ); add_token( 0x441, "b<to>" ); add_token( 0x442, "b<to>1" ); add_token( 0x443, "(i-to)" ); add_token( 0x444, "(var)" ); add_token( 0x445, "(i-var)" ); add_token( 0x449, "(defer)" ); add_token( 0x44A, "(i-defer)" ); add_token( 0x44B, "(field)" ); add_token( 0x44C, "b<lit>" ); add_token( 0x44D, "b<'>" ); add_token( 0x44E, "{'}" ); add_token( 0x462, "b<\">" ); } if (mac_rom & 3) { /* PowerMac 8600 and G3 ROM tokens */ add_token( 0x410, "local_0" ); add_token( 0x411, "local_1" ); add_token( 0x412, "local_2" ); add_token( 0x413, "local_3" ); add_token( 0x414, "local_4" ); add_token( 0x415, "local_5" ); add_token( 0x416, "local_6" ); add_token( 0x417, "local_7" ); add_token( 0x418, "-> local_0" ); add_token( 0x419, "-> local_1" ); add_token( 0x41A, "-> local_2" ); add_token( 0x41B, "-> local_3" ); add_token( 0x41C, "-> local_4" ); add_token( 0x41D, "-> local_5" ); add_token( 0x41E, "-> local_6" ); add_token( 0x41F, "-> local_7" ); } if (mac_rom & 8) { /* B&W G3 ROM tokens */ /* compiled fcode tokens */ add_token( 0x439, "(val)" ); add_token( 0x43A, "(i-val)" ); add_token( 0x43B, "b<to>" ); /* B&W stores at +8 like G5 does */ add_token( 0x43C, "b<to>1" ); add_token( 0x43D, "(i-to)" ); add_token( 0x43E, "(var)" ); add_token( 0x43F, "(i-var)" ); add_token( 0x443, "(defer)" ); add_token( 0x444, "(i-defer)" ); add_token( 0x445, "(field)" ); add_token( 0x446, "b<lit>" ); add_token( 0x447, "b<'>" ); add_token( 0x448, "{'}" ); add_token( 0x458, "b<\">" ); }
On Mon, Apr 02, 2018 at 11:28:43AM -0700, Joe van Tunen wrote:
You couldn't add Apple fcode support because the Apple fcode drivers use different tokens in different firmwares.
They use FCode numbers < 800, and they are the same everywhere. For some reason the didn't use the vendor space (600..7ff) though, but instead reserved FCode #s. (You're right things changed around a bit before NewWorld. Does anyone care? Historians, perhaps.) Oh that reminds me... They do this 16-bit FCode # thing as well, if memory serves lead by an 0f4 token (followed by two bytes). Segher
On 4/2/18, 5:30 PM, "Segher Boessenkool" <segher@kernel.crashing.org> wrote: On Mon, Apr 02, 2018 at 11:28:43AM -0700, Joe van Tunen wrote: > You couldn't add Apple fcode support because the Apple fcode drivers use different tokens in different firmwares. They use FCode numbers < 800, and they are the same everywhere. For some reason the didn't use the vendor space (600..7ff) though, but instead reserved FCode #s. (You're right things changed around a bit before NewWorld. Does anyone care? Historians, perhaps.) Oh that reminds me... They do this 16-bit FCode # thing as well, if memory serves lead by an 0f4 token (followed by two bytes). Segher I've seen that the compiled fcode has token numbers greater than 0xFFF in the New World Macs. I didn't find the fcode that they are compiled from (need to decompress some parts of rom), and therefore hadn't come to realize that they would need to be tokenized in a special way (if they were sourced from fcode). I found the code that checks for 0xF4 in the `get-fc function in the PowerMac G5 compiled fcode. So tokens have three ways to be encoded: 0x00, 0x10-0xFF = one byte 0x?? 0x100-0xFFF = two bytes 0x0??? 0x???? = three bytes 0xF4????
Now you guys are just talking shop;-) Just for a lark, I ran detok on a G4 Firmware update. I’ll have to try and find why it’s finishing prematurely around 27853 bytes.
On Apr 3, 2018, at 6:09 AM, Joe van Tunen <joevt@shaw.ca> wrote:
On 4/2/18, 5:30 PM, "Segher Boessenkool" <segher@kernel.crashing.org> wrote:
On Mon, Apr 02, 2018 at 11:28:43AM -0700, Joe van Tunen wrote:
You couldn't add Apple fcode support because the Apple fcode drivers use different tokens in different firmwares.
They use FCode numbers < 800, and they are the same everywhere. For some reason the didn't use the vendor space (600..7ff) though, but instead reserved FCode #s.
(You're right things changed around a bit before NewWorld. Does anyone care? Historians, perhaps.)
Oh that reminds me... They do this 16-bit FCode # thing as well, if memory serves lead by an 0f4 token (followed by two bytes).
Segher
I've seen that the compiled fcode has token numbers greater than 0xFFF in the New World Macs. I didn't find the fcode that they are compiled from (need to decompress some parts of rom), and therefore hadn't come to realize that they would need to be tokenized in a special way (if they were sourced from fcode).
I found the code that checks for 0xF4 in the `get-fc function in the PowerMac G5 compiled fcode. So tokens have three ways to be encoded:
0x00, 0x10-0xFF = one byte 0x?? 0x100-0xFFF = two bytes 0x0??? 0x???? = three bytes 0xF4????
It's all gibberish. It stops when it sees an end0 token which is just a 0x00 byte. You're detokenizing stuff that isn't fcode. fcode should start with 0xF1,0x08 (start1 format:08 checksum:???? Len:????????). You need to use a version of detok that can skip non-fcode and doesn't stop at a 0x00 byte (like the one I gave you). You also have to find the fcode which is probably in some compressed part of the rom (probably using lz77 or lzss). That seemed too complicated for me, so I created a detok that can just disassemble the compiled fcode from the dictionary (all the bytes between slightly before the first word (which is the last word from the words command) and the value of here). Anyway, regarding your problem with loading a PCI rom: I'm updating my toke, detok, and DumpPCIRom commands and scripts (previously Mac OS 9 MPW commands and scripts) to macOS commands and scripts, so you can convert the fcode of your PCI rom to forth, make changes (add debugging or fixes), and recreate the rom. One of the questions is why the ,A and ,B devices are not created on some systems - the problem might be related to how it uses the same fcode to define both devices (if that's what it does)... It sounds like you are having trouble with connecting to your G4 using telnet. You should boot your G4 into macOS, check the IP address (for example, 192.168.0.120) in the network settings which should come from DHCP from your router, then use that IP address when you boot into Open Firmware (hold Option O F at startup) and type the command: " enet:telnet,192.168.0.120" io The capitalization matters. There must be a space after the first quote and nowhere else. I don't know if telnet works from nvramrc or as an input-device. Set those to defaults to start with. Then in Terminal.app on another Mac type telnet 192.168.0.120 Or use any other telnet client. Current versions of Mac OS X don't come with telnet but it can be easily installed using homebrew or other macOS compatible package installer. On my PowerMac G5, sometimes the telnet connection in Open Firmware stops working and I have to restart the G5. I don't know if it's a bug or a problem with my CPU (it's a quadcore but I have to boot it with cpus=3). If telnet doesn't work, then consider using a serial port. It should definitely work as input-device and output-device. Newer PowerMacs don't have a built in serial port but they do have a built in serial controller chip which is used by a modem. There are products that let you add a serial port using a connection to that serial controller chip. The Griffin G4Port is one such example. There's also the GeeThree Stealth Port (different version for iMac, G3, G4, (PCI, AGP graphics), and G5), and Jamport G4. I have one of them in my B&W G3. You can't use a USB serial port adapter from Open Firmware but your other computer can use a USB serial port adapter to connect to the Open Firmware computer. You can use ttya:57600 (your serial port device might have a different name, maybe you have an scca alias?) as the input and output device to use 57600 bps. I think the default is 38400 bps. You can hack the ttya or scca init routine in Open Firmware so it uses 115200 or 230400 bps (change the init routine so that it will select the RTxC pin (3.8MHz) for the receive and transmit clocks instead of using the baud-rate generator then choose a x16 or x32 divider). On 4/3/18, 3:42 AM, "Jd Lyons" <lyons_dj@yahoo.com> wrote: Now you guys are just talking shop;-) Just for a lark, I ran detok on a G4 Firmware update. I’ll have to try and find why it’s finishing prematurely around 27853 bytes. > On Apr 3, 2018, at 6:09 AM, Joe van Tunen <joevt@shaw.ca> wrote: > > On 4/2/18, 5:30 PM, "Segher Boessenkool" <segher@kernel.crashing.org> wrote: > > On Mon, Apr 02, 2018 at 11:28:43AM -0700, Joe van Tunen wrote: >> You couldn't add Apple fcode support because the Apple fcode drivers use different tokens in different firmwares. > > They use FCode numbers < 800, and they are the same everywhere. For some > reason the didn't use the vendor space (600..7ff) though, but instead > reserved FCode #s. > > (You're right things changed around a bit before NewWorld. Does > anyone care? Historians, perhaps.) > > Oh that reminds me... They do this 16-bit FCode # thing as well, if > memory serves lead by an 0f4 token (followed by two bytes). > > > Segher > > I've seen that the compiled fcode has token numbers greater than 0xFFF in the New World Macs. I didn't find the fcode that they are compiled from (need to decompress some parts of rom), and therefore hadn't come to realize that they would need to be tokenized in a special way (if they were sourced from fcode). > > I found the code that checks for 0xF4 in the `get-fc function in the PowerMac G5 compiled fcode. So tokens have three ways to be encoded: > > 0x00, 0x10-0xFF = one byte 0x?? > 0x100-0xFFF = two bytes 0x0??? > 0x???? = three bytes 0xF4???? > > >
On Tue, Apr 03, 2018 at 03:09:28AM -0700, Joe van Tunen wrote:
I found the code that checks for 0xF4 in the `get-fc function in the PowerMac G5 compiled fcode. So tokens have three ways to be encoded:
0x00, 0x10-0xFF = one byte 0x?? 0x100-0xFFF = two bytes 0x0??? 0x???? = three bytes 0xF4????
00, 10..f3, f5..ff are that number 01..0f xx are 100..fff f4 xx xx are 0000..ffff (so with f4 you can encode either of the other two "types", too). Segher
On Mar 30, 2018, at 7:02 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
On Fri, Mar 30, 2018 at 04:14:48AM -0400, Jd Lyons wrote:
FF8906CD: b(:) \ [0x0b7] 0x1cf2 load FF8906D8: 967E FFFC stwu r19,-4(r30) FF8906DC: 7E68 02A6 mflr r19 FF8906E0: 4BFB 68B1 FF846F90 bl b<"> FF8906E4: 05 ... dc.b " load " FF8906EC: 4BFF FEDD FF8905C8 bl boot|load FF8906F0: 4BFF FA19 FF890108 bl (init-program) FF8906F4: 4BFB 5DAC FF8464A0 b exit
FF890865: b(:) \ [0x0b7] 0x1cf8 boot FF890870: 967E FFFC stwu r19,-4(r30) FF890874: 7E68 02A6 mflr r19 FF890878: 4BFB 6719 FF846F90 bl b<"> FF89087C: 05 ... dc.b " boot " FF890884: 4BFF FD45 FF8905C8 bl boot|load FF890888: 4BFF F881 FF890108 bl (init-program) FF89088C: 4BFF FEA5 FF890730 bl go FF890890: 4BFB 5C10 FF8464A0 b exit
It should be possible to decompile the compiled fcode in the same way that the Open Firmware "see" command does.
It is possible (I have done it).
Earlier Mac's (Old World Macs) may have tokenized fcode in their ROM that you can more easily detokenize but some of the words may be unnamed (headerless). I guess the G5 (and other New World Macs) has tokenized fcode somewhere but I don't know where it is - maybe it's compressed?
Yes, many sections are compressed (with LZ77 iirc). Not *all* code is tokenised, but most is. And Apple uses some non-standard FCodes, too (for local variables, most prominently). And their drivers can use anything defined in the "main" OF (so you cannot transplant them to a different machine or a different FW version even).
What jumps out at me, is both ‘load' and ‘boot’ one the G5 call ‘boatload’, would this be the reason that it is trying to execute the Option ROM when I try and ‘load’ it?
"load" does not do "go" (or at least it should not!)
Load seems to do go in some cases, in both OF and OB, like loading bootx, both will just boot OS X. However I have a custom Fcode script that sets some properties for a graphics card, and load behaves as we would expect, doesn’t do go. But load seems to be trying to do go in Apple’s OF when I load an option rom from disk.
Segher
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On 3/31/18, 2:27 AM, "Jd Lyons" <lyons_dj@yahoo.com> wrote: > On Mar 30, 2018, at 7:02 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote: > > On Fri, Mar 30, 2018 at 04:14:48AM -0400, Jd Lyons wrote: >> FF8906CD: b(:) \ [0x0b7] 0x1cf2 load >> FF8906D8: 967E FFFC stwu r19,-4(r30) >> FF8906DC: 7E68 02A6 mflr r19 >> FF8906E0: 4BFB 68B1 FF846F90 bl b<"> >> FF8906E4: 05 ... dc.b " load " >> FF8906EC: 4BFF FEDD FF8905C8 bl boot|load >> FF8906F0: 4BFF FA19 FF890108 bl (init-program) >> FF8906F4: 4BFB 5DAC FF8464A0 b exit >> >> >> FF890865: b(:) \ [0x0b7] 0x1cf8 boot >> FF890870: 967E FFFC stwu r19,-4(r30) >> FF890874: 7E68 02A6 mflr r19 >> FF890878: 4BFB 6719 FF846F90 bl b<"> >> FF89087C: 05 ... dc.b " boot " >> FF890884: 4BFF FD45 FF8905C8 bl boot|load >> FF890888: 4BFF F881 FF890108 bl (init-program) >> FF89088C: 4BFF FEA5 FF890730 bl go >> FF890890: 4BFB 5C10 FF8464A0 b exit >> >> It should be possible to decompile the compiled fcode in the same way that the Open Firmware "see" command does. > > It is possible (I have done it). > >> Earlier Mac's (Old World Macs) may have tokenized fcode in their ROM that you can more easily detokenize but some of the words may be unnamed (headerless). I guess the G5 (and other New World Macs) has tokenized fcode somewhere but I don't know where it is - maybe it's compressed? > > Yes, many sections are compressed (with LZ77 iirc). Not *all* code is > tokenised, but most is. And Apple uses some non-standard FCodes, too > (for local variables, most prominently). And their drivers can use > anything defined in the "main" OF (so you cannot transplant them to > a different machine or a different FW version even). > >> What jumps out at me, is both ‘load' and ‘boot’ one the G5 call ‘boatload’, would this be the reason that it is trying to execute the Option ROM when I try and ‘load’ it? > > "load" does not do "go" (or at least it should not!) > Load seems to do go in some cases, in both OF and OB, like loading bootx, both will just boot OS X. However I have a custom Fcode script that sets some properties for a graphics card, and load behaves as we would expect, doesn’t do go. But load seems to be trying to do go in Apple’s OF when I load an option rom from disk. > > Segher > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you The only part of the firmware that knows how to load fcode from a PCI rom is part of the probe-all process. probe-fcode is the only routine that checks for the PCIR signature in the PCI rom (it's loaded as little endian and compared with RICP in the code). The call chain is like this: byte-load eval-fcode probe-fcode create-new-pci-device scan-for-pci-devices probe-pci-device probe-pci-slot ?probe-slot x 10 (device nodes have their own ?probe-slot) probe-slots x 10 (device nodes have their own probe-slots) try-probe-slots probe-pci probe-all _cold-init (cold-init) Both the load and open routine will load a program. They call (init-program) to check the format. Only boot calls go. There are a few valid formats: 1) Fourth (ASCII text) (starts with a comment and space characters "\ "). Sets go to use go-forth. 2) FCode (tokens) (starts with a start1 token (0xf1) followed by a header that begins with a 0x08 byte). Sets go to use go-fcode. 3) a CHRP-BOOT file (starts with signature "<CHRP-BOOT>") 4) XCOFF file (starts with bytes 01DF) 5) MACHO file (start with bytes FEEDFACE) 6) PE/COFF file (starts with bytes F001) 7) ELF file (starts with bytes 7F454C46 = 0x7F + 'ELF') So when you load the PCI rom which is none of the above formats then (init-program) outputs "unrecognized Client Program format". I think you can ignore that, use load-base to get the start, add the offset of the start1 token, and call byte-load to execute the tokens. Do it like go-fcode does, using catch to catch any problems.
On Mar 31, 2018, at 10:37 PM, Joe van Tunen <joevt@shaw.ca> wrote:
On 3/31/18, 2:27 AM, "Jd Lyons" <lyons_dj@yahoo.com <mailto:lyons_dj@yahoo.com>> wrote:
On Mar 30, 2018, at 7:02 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
On Fri, Mar 30, 2018 at 04:14:48AM -0400, Jd Lyons wrote:
FF8906CD: b(:) \ [0x0b7] 0x1cf2 load FF8906D8: 967E FFFC stwu r19,-4(r30) FF8906DC: 7E68 02A6 mflr r19 FF8906E0: 4BFB 68B1 FF846F90 bl b<"> FF8906E4: 05 ... dc.b " load " FF8906EC: 4BFF FEDD FF8905C8 bl boot|load FF8906F0: 4BFF FA19 FF890108 bl (init-program) FF8906F4: 4BFB 5DAC FF8464A0 b exit
FF890865: b(:) \ [0x0b7] 0x1cf8 boot FF890870: 967E FFFC stwu r19,-4(r30) FF890874: 7E68 02A6 mflr r19 FF890878: 4BFB 6719 FF846F90 bl b<"> FF89087C: 05 ... dc.b " boot " FF890884: 4BFF FD45 FF8905C8 bl boot|load FF890888: 4BFF F881 FF890108 bl (init-program) FF89088C: 4BFF FEA5 FF890730 bl go FF890890: 4BFB 5C10 FF8464A0 b exit
It should be possible to decompile the compiled fcode in the same way that the Open Firmware "see" command does.
It is possible (I have done it).
Earlier Mac's (Old World Macs) may have tokenized fcode in their ROM that you can more easily detokenize but some of the words may be unnamed (headerless). I guess the G5 (and other New World Macs) has tokenized fcode somewhere but I don't know where it is - maybe it's compressed?
Yes, many sections are compressed (with LZ77 iirc). Not *all* code is tokenised, but most is. And Apple uses some non-standard FCodes, too (for local variables, most prominently). And their drivers can use anything defined in the "main" OF (so you cannot transplant them to a different machine or a different FW version even).
What jumps out at me, is both ‘load' and ‘boot’ one the G5 call ‘boatload’, would this be the reason that it is trying to execute the Option ROM when I try and ‘load’ it?
"load" does not do "go" (or at least it should not!)
Load seems to do go in some cases, in both OF and OB, like loading bootx, both will just boot OS X. However I have a custom Fcode script that sets some properties for a graphics card, and load behaves as we would expect, doesn’t do go.
But load seems to be trying to do go in Apple’s OF when I load an option rom from disk.
Segher
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
The only part of the firmware that knows how to load fcode from a PCI rom is part of the probe-all process. probe-fcode is the only routine that checks for the PCIR signature in the PCI rom (it's loaded as little endian and compared with RICP in the code). The call chain is like this:
byte-load eval-fcode probe-fcode create-new-pci-device scan-for-pci-devices probe-pci-device probe-pci-slot ?probe-slot x 10 (device nodes have their own ?probe-slot) probe-slots x 10 (device nodes have their own probe-slots) try-probe-slots probe-pci probe-all _cold-init (cold-init)
Both the load and open routine will load a program. They call (init-program) to check the format. Only boot calls go. There are a few valid formats: 1) Fourth (ASCII text) (starts with a comment and space characters "\ "). Sets go to use go-forth. 2) FCode (tokens) (starts with a start1 token (0xf1) followed by a header that begins with a 0x08 byte). Sets go to use go-fcode. 3) a CHRP-BOOT file (starts with signature "<CHRP-BOOT>") 4) XCOFF file (starts with bytes 01DF) 5) MACHO file (start with bytes FEEDFACE) 6) PE/COFF file (starts with bytes F001) 7) ELF file (starts with bytes 7F454C46 = 0x7F + 'ELF')
So when you load the PCI rom which is none of the above formats then (init-program) outputs "unrecognized Client Program format". I think you can ignore that, use load-base to get the start, add the offset of the start1 token, and call byte-load to execute the tokens. Do it like go-fcode does, using catch to catch any problems.
It doesn’t seem to load the rom to the load base address. “ agp/@10” open-dev to my-self load hd:12,\ppc\Quadro900Mac.rom 80000000 100 dump Dump doesn’t display the first 100 bytes of the option rom.
-- OpenBIOS http://openbios.org/ <http://openbios.org/> Mailinglist: http://lists.openbios.org/mailman/listinfo <http://lists.openbios.org/mailman/listinfo> Free your System - May the Forth be with you
On Mon, Apr 02, 2018 at 05:20:04AM -0400, Jd Lyons via OpenBIOS wrote:
It doesn’t seem to load the rom to the load base address.
“ agp/@10” open-dev to my-self load hd:12,\ppc\Quadro900Mac.rom 80000000 100 dump
Dump doesn’t display the first 100 bytes of the option rom.
No surprise, because that is not your load-base! There isn't even RAM there (it is the beginning of I/O space). load-base 100 dump Segher
Thanks Segher, load hd:12,\ppc\Quadro900Mac.rom load-base 100 dump Result: 00800000 DEFAULT CATCH!, code=300 at %SRR0: ff847470 %SRR1:0000b030 Striping the PCI Header and doing: load hd:12/ppc/4600.rom “ agp/@10” open-dev to my-self 800000 1 byte-load That seem to execute the fcode, but I can’t get in over a telnet session to see the result. I have two cards, a 4600 Ti and a Quadro 900. The EEROM on the 900 is dead, and the card it’s self maybe fubar. I flashed the 4600 with the Mac FCode ROM and it works fine, doing the above makes the screen go blank, then typing Mac-boot boots the OS and brings the screen back up, seems to add 4:00 to the end of the card name. GeForce4 Ti 4600 4:00. I’m just wanting to figure this out to test Fcode Roms before I flash them to the cards, but it is seeming to be more trouble than it maybe worth. I was just hoping it my tell me something of changes needed to Open Bios to get VGA Passthrough working. I don’t think we learned anything useful.
On Apr 2, 2018, at 5:51 AM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
On Mon, Apr 02, 2018 at 05:20:04AM -0400, Jd Lyons via OpenBIOS wrote:
It doesn’t seem to load the rom to the load base address.
“ agp/@10” open-dev to my-self load hd:12,\ppc\Quadro900Mac.rom 80000000 100 dump
Dump doesn’t display the first 100 bytes of the option rom.
No surprise, because that is not your load-base! There isn't even RAM there (it is the beginning of I/O space).
load-base 100 dump
Segher
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On Apr 2, 2018, at 6:43 AM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote: load hd:12,\ppc\Quadro900Mac.rom load-size=c400 adler32=5ff1641b load-base 100 dump
Result:
00800000 DEFAULT CATCH!, code=300 at %SRR0: ff847470 %SRR1:0000b030
Not sure on that load-size, and I have no clue what the adler32 is?
From: Jd Lyons <lyons_dj@yahoo.com> Date: Monday, April 2, 2018 at 3:52 AM On Apr 2, 2018, at 6:43 AM, Jd Lyons via OpenBIOS <mailto:openbios@openbios.org> wrote: load hd:12,\ppc\Quadro900Mac.rom load-size=c400 adler32=5ff1641b load-base 100 dump Result: 00800000 DEFAULT CATCH!, code=300 at %SRR0: ff847470 %SRR1:0000b030 Not sure on that load-size, and I have no clue what the adler32 is? What is the size of the Quadro900Mac.rom file? adler32 is a checksum algorithm (look it up on Wikipedia). It is called by boot|load. Try calling it yourself with load_base load-size adler32 Looking at (init-program) more carefully (which is called after boot|load), it appears that the “unrecognized Client Program format” error causes the loaded data to be released, so you can’t dump it or byte-load it or adler32 it. Therefore, you must load only the fcode part of the rom or make your own load command.
On 02/04/18 13:19, Joe van Tunen wrote:
From: Jd Lyons <lyons_dj@yahoo.com> Date: Monday, April 2, 2018 at 3:52 AM
On Apr 2, 2018, at 6:43 AM, Jd Lyons via OpenBIOS <mailto:openbios@openbios.org> wrote:
load hd:12,\ppc\Quadro900Mac.rom load-size=c400 adler32=5ff1641b load-base 100 dump
Result:
00800000 DEFAULT CATCH!, code=300 at %SRR0: ff847470 %SRR1:0000b030
Not sure on that load-size, and I have no clue what the adler32 is?
What is the size of the Quadro900Mac.rom file? adler32 is a checksum algorithm (look it up on Wikipedia). It is called by boot|load. Try calling it yourself with
load_base load-size adler32
Looking at (init-program) more carefully (which is called after boot|load), it appears that the “unrecognized Client Program format” error causes the loaded data to be released, so you can’t dump it or byte-load it or adler32 it. Therefore, you must load only the fcode part of the rom or make your own load command.
From memory the IEEE-1275 specification states that a minimum of 8MB memory should be available at load-base for the bootloader, so OpenBIOS simply maps this region on startup. Hence with OpenBIOS you can quite happily do a "load hd:,\path\to\file" and then dump it with "load-base 100 dump" as above even if the file format is unrecognised. I suspect the problem is that your Quadro900Mac.rom is in a format which is recognised by init-program as executable which proceeds to try and run it. But as rightly pointed out earlier in the thread, load should only move the file into memory at load-base and run init-program - it should be up to the user to manually switch to the saved program state with "go". ATB, Mark.
On 4/2/18, 6:04 AM, "Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk> wrote: On 02/04/18 13:19, Joe van Tunen wrote: > From: Jd Lyons <lyons_dj@yahoo.com> > Date: Monday, April 2, 2018 at 3:52 AM > > On Apr 2, 2018, at 6:43 AM, Jd Lyons via OpenBIOS <mailto:openbios@openbios.org> wrote: > > load hd:12,\ppc\Quadro900Mac.rom load-size=c400 adler32=5ff1641b > load-base 100 dump > > Result: > > 00800000 > DEFAULT CATCH!, code=300 at %SRR0: ff847470 %SRR1:0000b030 > > Not sure on that load-size, and I have no clue what the adler32 is? > > > What is the size of the Quadro900Mac.rom file? adler32 is a checksum algorithm (look it up on Wikipedia). It is called by boot|load. Try calling it yourself with > > load_base load-size adler32 > > Looking at (init-program) more carefully (which is called after boot|load), it appears that the “unrecognized Client Program format” error causes the loaded data to be released, so you can’t dump it or byte-load it or adler32 it. > Therefore, you must load only the fcode part of the rom or make your own load command. From memory the IEEE-1275 specification states that a minimum of 8MB memory should be available at load-base for the bootloader, so OpenBIOS simply maps this region on startup. Hence with OpenBIOS you can quite happily do a "load hd:,\path\to\file" and then dump it with "load-base 100 dump" as above even if the file format is unrecognised. I suspect the problem is that your Quadro900Mac.rom is in a format which is recognised by init-program as executable which proceeds to try and run it. But as rightly pointed out earlier in the thread, load should only move the file into memory at load-base and run init-program - it should be up to the user to manually switch to the saved program state with "go". ATB, Mark. So far, without trying the load ourselves, we only have evidence that the load is not accepting the format (which is a PCI option rom with fcode image - if it's just the fcode image than the file should be renamed to make it clear). We don't have evidence that load is running the fcode. You need to check "here" before and after load to see if anything is added to the dictionary (if the fcode makes at least one definition).
Just to be clear, in this thread, we are talking about how to load a PCI Option ROM from for file on actual Apple Hardware. It relates to Openbios because at this time Openbios has no support for probing the PCI Bus for Option ROM’s. I just thought if we could learn how this works on real hardware it may tell us something useful on what changes maybe needed to Openbios to support VGA Passthrough. Other than that, I’m not sure how useful it will be, maybe some network cards had an FCode Option ROM, and there where some PCI/PCI-E drive controllers that did. So, maybe some day someone will want to use one with PCI Passthrough. To sum up: 1. Apple’s Open firmware handles “load” a little different than Openbios. I imagine Openbios handles it correctly and conforms to the IEEE 1275 standard. As it can load a full option rom to the load-base address without error vs, Apple’s implementation where I have to remove everything up to the start of the FCode in the rom image. 2. Even removing the the data up to the start of the FCode does not result in a working PCI Device when I call byte-load from the load-base address. I’m not sure what is going wrong, likely I’m just doing it wrong, as I would assume PCI Device Developers would have used loading an Option ROM from file on Apple systems to test their changes before they flashed it to an EEPROM, but that’s only an assumption. Really just my way of learning how VGA FCode Roms should work if loaded from file, to see why it’s not working with Openbios.
On Apr 2, 2018, at 1:27 PM, Joe van Tunen <joevt@shaw.ca> wrote:
On 4/2/18, 6:04 AM, "Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk> wrote:
On 02/04/18 13:19, Joe van Tunen wrote:
From: Jd Lyons <lyons_dj@yahoo.com> Date: Monday, April 2, 2018 at 3:52 AM
On Apr 2, 2018, at 6:43 AM, Jd Lyons via OpenBIOS <mailto:openbios@openbios.org> wrote:
load hd:12,\ppc\Quadro900Mac.rom load-size=c400 adler32=5ff1641b load-base 100 dump
Result:
00800000 DEFAULT CATCH!, code=300 at %SRR0: ff847470 %SRR1:0000b030
Not sure on that load-size, and I have no clue what the adler32 is?
What is the size of the Quadro900Mac.rom file? adler32 is a checksum algorithm (look it up on Wikipedia). It is called by boot|load. Try calling it yourself with
load_base load-size adler32
Looking at (init-program) more carefully (which is called after boot|load), it appears that the “unrecognized Client Program format” error causes the loaded data to be released, so you can’t dump it or byte-load it or adler32 it. Therefore, you must load only the fcode part of the rom or make your own load command.
From memory the IEEE-1275 specification states that a minimum of 8MB memory should be available at load-base for the bootloader, so OpenBIOS simply maps this region on startup.
Hence with OpenBIOS you can quite happily do a "load hd:,\path\to\file" and then dump it with "load-base 100 dump" as above even if the file format is unrecognised.
I suspect the problem is that your Quadro900Mac.rom is in a format which is recognised by init-program as executable which proceeds to try and run it. But as rightly pointed out earlier in the thread, load should only move the file into memory at load-base and run init-program - it should be up to the user to manually switch to the saved program state with "go".
ATB,
Mark.
So far, without trying the load ourselves, we only have evidence that the load is not accepting the format (which is a PCI option rom with fcode image - if it's just the fcode image than the file should be renamed to make it clear). We don't have evidence that load is running the fcode. You need to check "here" before and after load to see if anything is added to the dictionary (if the fcode makes at least one definition).
participants (6)
-
James Lyons -
Jd Lyons
-
Joe van Tunen -
Mark Cave-Ayland -
Segher Boessenkool -
Tarl Neustaedter