On 2017-Dec-17 11:00 , Jd Lyons wrote: [...]
0 > load hd:,\ppc\6600.fcode ok 0 > 4000000 400 dump 4000000 55 aa 40 00 00 00 00 00 00 00 00 00 00 00 00 00 U�@............. 4000010 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ ....... 4000020 50 43 49 52 de 10 41 01 00 00 20 00 00 00 00 03 PCIR�.A... ..... 4000030 84 00 00 00 01 80 00 00 00 00 00 00 00 00 00 00 �....�..........
That looks like stuff from a PCI option ROM. But you can't start at 4000020, that's still in the PCI header overhead.
See
https://code.coreboot.org/p/openboot/source/tree/1/obp/dev/pci/fcode-rom.fth
Follow the code in locate-fcode and fcode-image? to find where the code starts. From my recollection, this looks like the FCode is for a card with vendor ID 10de and device ID 0141. It looks like the FCode should start at 4000040, so that's the address you should feel into byte-load.
0 > 0 0 " 4,0" " /pci@80000000" begin-package ok 0 > dev /pci ls
That "dev" is harmful, it's taking you out of the PCI node, you need to stay inside unnamed node. Don't do that.
0 > setenv focde-debug? true ok 0 > 4000020 1 byte-load ok
If this had worked with fcode-debug? set to true, I think you would normally have gotten the name of the device printed out.
0 > dev /pci ls
This is again taking you out of wherever you had run the FCode.
0 > setenv fcode-debug? true ok 0 > 4000020 1 byte-load byte-load: warning stack overflow, diff -3 ok 0 >
At this point, you're doing a second execution of the PCI header, and I have no idea what "PCIR" does as FCodes. It undoubtedly got confused and did something dumb.