[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?
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.
Andreas
More information about the OpenBIOS
mailing list