[OpenBIOS] Q: How to "squeeze" C functions in between two symbols?

[Andreas Färber]

Am 12.10.2010 um 20:50 schrieb Blue Swirl:

> On Mon, Oct 11, 2010 at 7:18 PM, Andreas Färber <andreas.faerber at 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.

Thanks for the pointer, that works quite nicely.

>> 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.

Ah, I found OUTPUT_FORMAT(binary). Didn't know we could emit non-ELF  
formats with --target=*-elf.

>> 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).

I was successful using a section ".rtasentry", but since I get r4 as a  
pointer to the start of memory, I'll rather use a known offset.

I got OpenBIOS to load my RTAS blob and AIX to enter my RTAS C  
function and emit something to escc uart from there. It looks like AIX  
is trying to emit "\nAIX " via display-character RTAS calls.
My code's not very stable though, the same code snippet didn't work  
inside a [{static,inline}] serial_putchar() function but did directly  
in my main function called from assembly. Still poking at ldscript and  
assembler to find the cause or a workaround. Right now it does print  
okay but hangs on returning from the RTAS call. Will post an RFC once  
I've cleaned it up a little, maybe it's something obvious...

Andreas