Re: [PATCH] Utilize Blackfin L1 SRAM

[Jie Zhang <jie dot zhang at analog dot com>]

Daniel Jacobowitz wrote:
> On Fri, Jul 11, 2008 at 04:26:12PM +0800, Jie Zhang wrote:
> > Hi,
> >
> > Blackfin processor has two high speed memories: L1 instruction SRAM and
> > L1 data SRAM, which work at core clock speed. To improve the
> > application performance, people may want to put their application in
> > these two SRAMs. This patch adds three options for this purpose.
> >
> > --sep-code
> >
> > It's a target independent option. Usually executable sections are put
> > into the same segment with other read only sections, like .rodata
> > section. However, the other read only sections cannot be put into L1
> > instruction SRAM, since this SRAM cannot be read with load instruction.
> > With this option, executable sections will be put into seperate
> > segments, which contains only code. Thus it can go into L1 instruction SRAM.
>
> Why not just use a linker script for this?
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.

> > --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.


Jie