Re: [PATCH] Utilize Blackfin L1 SRAM

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

Jonathan S. Shapiro wrote:
> On Sat, 2008-07-12 at 02:47 +0800, Jie Zhang wrote:
> > Yes. The loader will do relocation when load application or shared 
> > library into L1 SRAMs. We use FD-PIC ABI here since Blackfin has no MMU. 
> > In FD-PIC ABI, each segment can be relocated independently. In fine 
> > grained control, code segment for normal code will be loaded into SDRAM, 
> > while code segment for L1 SRAM will be loaded into L1 instruction SRAM. 
> > In coarse grained control, all code segment will be loaded into L1 
> > instruction SRAM if EF_BFIN_CODE_IN_L1 is set in ELF header. The 
> > situation for data is similar.
>
> Since the linker already provides the relocation capability you need,
> it's not clear why you felt compelled to complicate your tool chain, but
> I'm sure you had what seemed like good reasons. That being said, note
> that using "ld -r" initially followed by a final "ld" run to specify
> final target addresses will handle all of this.
It might be right. But it's much easier to add some options in LDFLAGS 
in makefiles than modifying rules.

> In any case, based on what you have said so far I agree with the
> original view that this patch does not seem well motivated, and is very
> unlikely to be generally useful.
I don't know what you referred to by "generally useful". --sep-code 
currently is only useful for Blackfin, since there are very few general 
purpose processors has linux running on it and have such a fast, not 
readable, not writable, instruction SRAM. Or maybe there are some, but 
their user space applications cannot use that SRAM now. So you are 
right, it's not generally useful now, but it's very useful for Blackfin.

> Is there some requirement I am failing to understand that precludes
> using the existing tools to accomplish what you want?
>
>   1. Use objcopy to rename the sections after each .o is produced.
>   2. Modify the linker script template to gather and group
>      the new section names (if the necessary parts aren't there
>      already).
>
> What requirement do you have that cannot be solved using this approach?
I don't like to use a modified linker script. Maintaining it will be a pain.


Jie