Re: [OpenBIOS] Apple's Open Firmware.

[Jd Lyons]

> On Mar 31, 2018, at 10:37 PM, Joe van Tunen  wrote:
>
> On 3/31/18, 2:27 AM, "Jd Lyons" <[e-mail] > wrote:
> > On Mar 30, 2018, at 7:02 PM, Segher Boessenkool  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
>
> 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:
> Fourth (ASCII text) (starts with a comment and space characters "\ "). Sets go to use go-forth.
> FCode (tokens) (starts with a start1 token (0xf1) followed by a header that begins with a 0x08 byte). Sets go to use go-fcode.
> a CHRP-BOOT file (starts with signature "<CHRP-BOOT>")
> XCOFF file (starts with bytes 01DF)
> MACHO file (start with bytes FEEDFACE)
> PE/COFF file (starts with bytes F001)
> 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.
>