Home Original page

[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