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> 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-loadeval-fcodeprobe-fcodecreate-new-pci-devicescan-for-pci-devicesprobe-pci-deviceprobe-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-slotsprobe-pciprobe-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.