Apple's Open Firmware.

[James Lyons]

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?

[Tarl Neustaedter]

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.

[James Lyons]

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

[Tarl Neustaedter]

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.

[Segher Boessenkool]

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

[Tarl Neustaedter]

On 2018-Mar-19 19:57 , Segher Boessenkool wrote:
  That all
returns ok, but the FCode doesn't seem to execute.
 You probably need to call
its "open" method before it does much.
It should be creating properties (like name and reg) without doing the open.

Did it?

[James Lyons]

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

[Segher Boessenkool]

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

[Jd Lyons]

  On Mar 19, 2018, at 8:58 PM, Segher Boessenkool
<segher(a)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.

[Segher Boessenkool]

On Thu, Mar 29, 2018 at 06:44:15AM -0400, Jd Lyons wrote:
  On Mar 19,
2018, at 8:58 PM, Segher Boessenkool <segher(a)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

[Jd Lyons]

  On Mar 29, 2018, at 3:57 PM, Segher Boessenkool
<segher(a)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(a)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

[Segher Boessenkool]

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

[Joe van Tunen]

On 3/30/18, 4:02 PM, "OpenBIOS on behalf of Segher Boessenkool"
<openbios-bounces(a)openbios.org on behalf of segher(a)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.

[Mark Cave-Ayland]

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(a)openbios.org on behalf of
segher(a)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.

[Joe van Tunen]

On 4/2/18, 5:51 AM, "Mark Cave-Ayland" <mark.cave-ayland(a)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(a)openbios.org on behalf of
segher(a)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<\">" );
	}

[Segher Boessenkool]

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

[Joe van Tunen]

On 4/2/18, 5:30 PM, "Segher Boessenkool" <segher(a)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????

[Jd Lyons]

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(a)shaw.ca> wrote:
 
 On 4/2/18, 5:30 PM, "Segher Boessenkool" <segher(a)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????

[Joe van Tunen]

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(a)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(a)shaw.ca> wrote:
 
 On 4/2/18, 5:30 PM, "Segher Boessenkool" <segher(a)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????

[Segher Boessenkool]

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

[Jd Lyons]

  On Mar 30, 2018, at 7:02 PM, Segher Boessenkool
<segher(a)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

[Joe van Tunen]

On 3/31/18, 2:27 AM, "Jd Lyons" <lyons_dj(a)yahoo.com> wrote:

    
    
  On Mar 30, 2018, at 7:02 PM, Segher Boessenkool
<segher(a)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.

[Jd Lyons]

  On Mar 31, 2018, at 10:37 PM, Joe van Tunen
<joevt(a)shaw.ca> wrote:
 
 On 3/31/18, 2:27 AM, "Jd Lyons" <lyons_dj(a)yahoo.com
<mailto:[e-mail]>> wrote:
 
 
 
  On Mar 30, 2018, at 7:02 PM, Segher Boessenkool
&lt;segher(a)kernel.crashing.org&gt; 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

[Segher Boessenkool]

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

[Jd Lyons]

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(a)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

[Jd Lyons]

  On Apr 2, 2018, at 6:43 AM, Jd Lyons via OpenBIOS
<openbios(a)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?

[Joe van Tunen]

From: Jd Lyons <lyons_dj(a)yahoo.com>
Date: Monday, April 2, 2018 at 3:52 AM

	On Apr 2, 2018, at 6:43 AM, Jd Lyons via OpenBIOS <mailto:[e-mail]>
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.

[Mark Cave-Ayland]

On 02/04/18 13:19, Joe van Tunen wrote:

  From: Jd Lyons <lyons_dj(a)yahoo.com>
 Date: Monday, April 2, 2018 at 3:52 AM
 
 	On Apr 2, 2018, at 6:43 AM, Jd Lyons via OpenBIOS <mailto:[e-mail]>
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.

[Joe van Tunen]

On 4/2/18, 6:04 AM, "Mark Cave-Ayland" <mark.cave-ayland(a)ilande.co.uk>
wrote:

    On 02/04/18 13:19, Joe van Tunen wrote:
    
  From: Jd Lyons <lyons_dj(a)yahoo.com>
 Date: Monday, April 2, 2018 at 3:52 AM
 
 	On Apr 2, 2018, at 6:43 AM, Jd Lyons via OpenBIOS <mailto:[e-mail]>
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).

[Jd Lyons]

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(a)shaw.ca> wrote:
 
 On 4/2/18, 6:04 AM, "Mark Cave-Ayland" <mark.cave-ayland(a)ilande.co.uk>
wrote:
 
    On 02/04/18 13:19, Joe van Tunen wrote:
 
  From: Jd Lyons <lyons_dj(a)yahoo.com>
 Date: Monday, April 2, 2018 at 3:52 AM
 
 	On Apr 2, 2018, at 6:43 AM, Jd Lyons via OpenBIOS <mailto:[e-mail]>
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).