On Mon, Oct 11, 2010 at 7:18 PM, Andreas Färber andreas.faerber@web.de wrote:
Am 08.10.2010 um 19:22 schrieb Alexander Graf:
On 08.10.2010, at 19:11, Andreas Färber wrote:
Am 08.10.2010 um 15:30 schrieb Alexander Graf:
Why don't you just create a separate binary for RTAS which can then use relative branching inside of itself? You could then copy the whole blob somewhere and be sure that everything's there.
How? :) Assuming I managed to fork arch/ppc/qemu/{start.S,ldscript} for a separate ELF binary, what would we do with it? Would QEMU need to load it separately as a ROM with known location, like openbios-ppc? Or would you embed such a binary into OpenBIOS somehow?
You'd embed in into OpenBIOS. Just create a .c file keeping the blob as variable from the .elf binary.
Sorry to bug... I have a very simple rtas.S now, linked into an rtas-qemu.elf. What now?
i) Is there an existing way to get my binary file into a .c file variable, or do I need to write my own generator in C? (or worse, Forth)
The dictionary blobs are transformed to C with hexdump.
ii) To do anything with the blob I need to load it properly as an ELF image, and libopenbios/elf_load.c:elf_load() requires an ihandle. How would I get an ihandle from a variable in a .c file? It doesn't let me specify the (client-supplied) memory address either.
I'd not use ELF here but binary blobs, real ROMs don't have any ELF headers.
iii) Once I've loaded the ELF image, how do I get the function's entry point? OpenBIOS itself just uses the CPU's reset vector and branches to _entry from there - anything I need to add/change in the ldscript?
You could assume that the first location is the starting point. This can be arranged by the linker script (special section for the starting point).