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

[Alexander Graf]

On 08.10.2010, at 19:11, Andreas Färber wrote:

> Am 08.10.2010 um 15:30 schrieb Alexander Graf:
> 
>> On 08.10.2010, at 15:23, Andreas Färber wrote:
>> 
>>> Am 08.10.2010 um 14:54 schrieb Alexander Graf:
>>> 
>>>> On 08.10.2010, at 14:44, Andreas Färber wrote:
>>>> 
>>>>> The RTAS code in arch/ppc/qemu/start.S currently looks like this:
>>>>> 
>>>>> GLOBL(of_rtas_start):
>>>>> 	blr
>>>>> GLOBL(of_rtas_end):
>>>>> 
>>>>> ...and I would like to branch to C code from there.
>>>>> 
>>>>> Is there a way to have code from, say, rtas.c go between the blr and of_rtas_end symbol?
>>>>> Or do I need to move the symbols to the ldscript and place the code in a special section? If yes, how?
>>>> 
>>>> Why do you want to have the code in between? You can just branch to the C code:
>>>> 
>>>> b c_rtas_function
>>>> 
>>>> The only thing you need to make sure is that you follow the ABI :). Input parameters go in r3-rsomething, output is in r3, stack pointer (r1) has to be valid.
>>>> 
>>>> Also by only doing the b instead of blr you jump to the C function directly, so a return from there actually returns from the rtas function.
>>> 
>>>> If the rtas function follows a different ABI, better set up a stack frame and blr into the C function.
>>> 
>>> I assumed the latter is what I should do, following the CIF example.
>>> 
>>>>> Those symbols are being used for code size calculation and relocation in arch/ppc/qemu/methods.c.
>>>> 
>>>> Maybe I don't really understand the question though.
>>> 
>>> Thanks for promptly trying!
>>> 
>>> The code in methods.c basically does a memcpy() of of_rtas_start..of_rtas_end to memory that AIX allocates for us. The code is never called at its original location so needs to be PIC. Thus, if the C functions are not copied along, any relative addressing wouldn't work and absolute addressing would break as soon as the functions get unmapped. You might think of it as a "separate" executable that OpenBIOS loads and sets up.
>>> Therefore I need a way to get one piece of memory containing the entry point, data storage and all helper functions called.
>> 
>> Oh. That's not exactly easy. So the rtas space stays intact while all the openbios functions it wants to call don't? Hrm.
> 
> At least that's what [1] and [2] suggested. CHRP System Architecture spec 1.0 chapter 7.1 (hrpa_103.ps) specifically says:
> 
> "The role of RTAS versus Open Firmware is very important to understand.
> Open Firmware and RTAS are both vendor-provided software, and both are tailored
> by the hardware vendor to manipulate the specific platform hardware.
> However, RTAS is intended to be present during the execution of the OS, and
> to be called by the OS to access platform hardware features on behalf of the
> OS, whereas Open Firmware need not be present when an OS is running. This
> frees Open Firmware’s memory to be used by applications. RTAS is small
> enough to painlessly coexist with OSs and applications."
> 
> I'd be happy to continue in some way that plays nicely with the relocation only for now though.
> 
> [1] http://www.scribd.com/doc/23367157/Concept-Design-and-Implementation-of-a-Slimline-Boot-Firmware-for-Linux-on-Power-Architecture pp. 8 f.
> [2] http://www.slideshare.net/schihei/agnostic-device-drivers slides 16 f.
> 
>> I guess you'll have to copy them down too, which can become very hairy very quick.
> 
>> 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.

> In theory we need support for both bitnesses and both endiannesses, i.e. up to four executables...

I don't see why. Just compile natively for the target arch. The RTOS blob has the same characteristics as openBIOS, no?

> And how would the interaction between OpenBIOS and RTAS work then? Would we have to duplicate all info into the RTAS private memory using an init function called during initialize-rtas?

Some shared struct that gets initialized in openbios and then copied into rtas space maybe?

> PCI for instance is supposed to be handled by RTAS (e.g., read-pci-config and write-pci-config), and the OS is supposed to call restart-rtas after reconfiguring PCI, which sort of implies probing capabilities inside RTAS...

Sounds like work :)


Alex