[ECOS] initialized variables/code in sram

[ECOS] initialized variables/code in sram

[Ilko Iliev]

Hello!

I have custom board with ARM7 (AT9155800) with external RAM and ROM:
MEMORY
{
     sram : ORIGIN = 0, LENGTH = 0x2000        <--- on chip 8KB ram
     rom : ORIGIN = 0x1000000, LENGTH = 0x200000
     ram : ORIGIN = 0x2000000, LENGTH = 0x80000
}

I can put uninitialized variables in SRAM:
int abc __attribute__ ( section (".sram"));

But how can I put initialized variables or code to SRAM?
void func1(void) __attribute__ ( section (".sram"));
void func1(void)
{
}

When I start in RAM is no problem - the debugger load the .sram section.

To work in ROM  I must correct vectors.S to initialize this .sram section, 
but I need start and end address of this section in ROM (like 
.__rom_data_start).

Other words I need second data and bss sections in SRAM, not in RAM


best regards
Ilko


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] initialized variables/code in sram

[Sergei Organov]

For my embedded application (that doesn't use eCos) I've adopted general
solution inspired by .ctors/.dtors handling. The idea is to use linker to
prepare tables containing (from_addr, to_addr, size) entries for data that
should be copied from ROM to RAM at startup. Then you need general code at
startup that uses linker-defined symbols that point to the beginning and
one-past-the-end of this table to actually copy data. I also have similar
table for sections that must be cleared at startup but in this case the table
has (addr, size) entries as well as corresponding code that fills regions
pointed to by this table with zeros.

I believe you can use similar technique with eCos. However it seems that
current eCos linker script generation tools aren't sophisticated enough, so
you will need to maintain your own "target.ld" file. You also will need to
change startup code, but you need to do it only once.

And here is the question to the eCos community: Do you think it's worth to add
more general support for clearing memory regions / copy of data at startup to
the eCos configuration/build system (including startup code) on architectures
where it could be easily supported (such as those using ELF for
object/executable files)?

BR,
Sergei Organov.

Ilko Iliev <iliev@caretec.at> writes:
> Hello!
> 
> I have custom board with ARM7 (AT9155800) with external RAM and ROM:
> MEMORY
> {
>      sram : ORIGIN = 0, LENGTH = 0x2000        <--- on chip 8KB ram
>      rom : ORIGIN = 0x1000000, LENGTH = 0x200000
>      ram : ORIGIN = 0x2000000, LENGTH = 0x80000
> }
> 
> I can put uninitialized variables in SRAM:
> int abc __attribute__ ( section (".sram"));
> 
> But how can I put initialized variables or code to SRAM?
> void func1(void) __attribute__ ( section (".sram"));
> void func1(void)
> {
> }
> 
> When I start in RAM is no problem - the debugger load the .sram section.
> 
> To work in ROM I must correct vectors.S to initialize this .sram section, but
> I need start and end address of this section in ROM (like .__rom_data_start).
> 
> 
> Other words I need second data and bss sections in SRAM, not in RAM
> 
> 
> best regards
> Ilko
> 
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] initialized variables/code in sram

[Jonathan Larmour]

Sergei Organov wrote:
> 
> For my embedded application (that doesn't use eCos) I've adopted general
> solution inspired by .ctors/.dtors handling. The idea is to use linker to
> prepare tables containing (from_addr, to_addr, size) entries for data that
> should be copied from ROM to RAM at startup. Then you need general code at
> startup that uses linker-defined symbols that point to the beginning and
> one-past-the-end of this table to actually copy data. I also have similar
> table for sections that must be cleared at startup but in this case the table
> has (addr, size) entries as well as corresponding code that fills regions
> pointed to by this table with zeros.

I think that would indeed be a good system.
 
> I believe you can use similar technique with eCos. However it seems that
> current eCos linker script generation tools aren't sophisticated enough, so
> you will need to maintain your own "target.ld" file. You also will need to
> change startup code, but you need to do it only once.
> 
> And here is the question to the eCos community: Do you think it's worth to add
> more general support for clearing memory regions / copy of data at startup to
> the eCos configuration/build system (including startup code) on architectures
> where it could be easily supported (such as those using ELF for
> object/executable files)?

We already assume ELF support. I think that changing the linker script
generation tools on the host side to support this type of functionality
would be ideal. The host tool code is all available in anoncvs. On the
other hand it would be non-trivial effort.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss