[PATCH] Utilize Blackfin L1 SRAM
Daniel Jacobowitz
drow@false.org
Fri Jul 11 17:33:00 GMT 2008
On Sat, Jul 12, 2008 at 12:50:23AM +0800, Jie Zhang wrote:
> Because I think it's much simpler to maintain this option than a
> processor specific linker script, which is almost as same as the generic
> one.
But I don't see how it does what you want. LD will still put the
code in a segment with some other LMA/VMA. The L1 is what LD calls a
region and could be treated as such.
>>> --code-in-l1 and --data-in-l1
>>>
>>> They are Blackfin specific options. ld will set EF_BFIN_CODE_IN_L1 or
>>> EF_BFIN_DATA_IN_L1 flag in the output file's elf header flags
>>> respectively. These flags tells loader to put code or data into L1 SRAMs.
>>
>> Similarly, I'm not sure why file-level ELF flags are right for this.
>> If you put the input data in the right named sections (e.g. with a
>> compiler option, or manually) the linker script would do the work.
>>
> We have GCC attributes to put functions or data in to L1 SRAMs. But some
> users don't like to add such attributes to each functions and data in a
> shared library. They just want to put the whole shared library in L1
> SRAMs. So we provide these two options. Compiler option to put data in
> the right named sections does not help here, since section names of
> precompiled object files or libraries, which are going to be linked in,
> cannot be changed.
I think I missed "loader" in this explanation. I'm still confused
about the model though. Does it get relocated by whatever loader this
is?
--
Daniel Jacobowitz
CodeSourcery
More information about the Binutils
mailing list