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

Andreas Färber andreas.faerber at web.de
Fri Oct 8 20:48:19 CEST 2010

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:
>>> 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?

Erm, OpenBIOS is lacking in that aspect. I don't see where it would  
respect the little-endian? option on ppc, just like the real-mode?  
option. And depending on what spec you read, there's both rtas- 
instantiate and rtas-instantiate-64, or the MSR(?) setting at RTAS  
initialization time decides in what mode it's supposed to run. So it  
can in fact be different from the compile-time setting of 32-bit big  
endian! :(

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

Calls for code sharing with OpenBIOS imo.


More information about the OpenBIOS mailing list