[ECOS] Different section placement for kernel and application

[ECOS] Different section placement for kernel and application

[Martin Rösch]

Hi,

I'm trying to figure out how to run the eCos kernel from ROM and run the application (the main() function) from RAM on the STM32 Eval Board.
Is it possible to place the text, data and rodata sections from the target library to a different memory address (i.e. flash)
than the sections of the application in the image?

Thank you for your help,

Martin


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

RE: [ECOS] Different section placement for kernel and application

[Christophe Coutand]

If you only have a couple of functions to place in RAM, you can use the section attribute:

void my_function( void ) __attribute__ ((section (".2ram.my_function")));

Christophe

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Martin Rösch
Sent: 27. januar 2011 18:24
To: discuss, eCos
Subject: [ECOS] Different section placement for kernel and application

Hi,

I'm trying to figure out how to run the eCos kernel from ROM and run the application (the main() function) from RAM on the STM32 Eval Board.
Is it possible to place the text, data and rodata sections from the target library to a different memory address (i.e. flash)
than the sections of the application in the image?

Thank you for your help,

Martin


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

[ECOS] Re: Different section placement for kernel and application

[Grant Edwards]

On 2011-01-27, Martin R??sch <martin.roesch@neratec.com> wrote:

> I'm trying to figure out how to run the eCos kernel from ROM and run
> the application (the main() function) from RAM on the STM32 Eval
> Board. Is it possible to place the text, data and rodata sections
> from the target library to a different memory address (i.e. flash)
> than the sections of the application in the image?

No, that's not possible in any general/useful sense without major
changes to the way eCos is designed and built.  

The way eCos is built there is no logical separation between the
kernel and the application.  They're both just C/C++ functions that
are linked together to form a single executable ELF file.

In theory, you could apply section attributes to all of the kernel
functions (or all of the application functions) so that you could
separate them at link time into different output sections.  But, that
wouldn't really be useful, since the linkage between the two output
would require that they always be updated together in the target
board.

I _suspect_ what you're really asking about is some sort of
position-independent API between kernel, libraries, and application so
that you can update one without updating the others -- something akin
to the Unix syscall API or the Unix shared library mechanism that
allows kernel, application, and libraries to be changed independently.

-- 
Grant Edwards               grant.b.edwards        Yow! Is this going to
                                  at               involve RAW human ecstasy?
                              gmail.com            


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

Re: [ECOS] Re: Different section placement for kernel and application

[Martin Rösch]

Hi,

Thanks for your answers.

> In theory, you could apply section attributes to all of the kernel
> functions (or all of the application functions) so that you could
> separate them at link time into different output sections.

That's what I was thinking of. I think this can be achieved with a modified
version of the cortexm.ld linker script, which is used to generate the target.ld
linker script.
I studied the documentation of the GNU Linker Scripts and found some hints to
place the sections based from the input object file.
I made a try in the RAM Layout .ldi file:

// eCos memory layout

#include <pkgconf/hal.h>
#include <cyg/infra/cyg_type.inc>

MEMORY
{
    sram  : ORIGIN = 0x20000000, LENGTH = 0x00010000
    flash : ORIGIN = 0x08000000, LENGTH = 0x00080000
    rom   : ORIGIN = 0x60000000, LENGTH = 0x00800000
    ram1  : ORIGIN = 0x64000000, LENGTH = 0x00800000-CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE
    ram2  : ORIGIN = 0x68000000, LENGTH = 0x00800000
}

SECTIONS
{
    SECTIONS_BEGIN
    SECTION_rom_vectors (flash, 0x08010000, LMA_EQ_VMA)
    SECTION_RELOCS (flash, ALIGN (0x8), LMA_EQ_VMA)
    .ecos.text ALIGN (0x8) : LMA_EQ_VMA
    {
    vectors.o(.text*) vectors.o(.gnu.warning) vectors.o(.gnu.linkonce.t.*) vectors.o(.init) vectors.o(.glue_7) vectors.o(.glue_7t)
    extras.o(.text*) extras.o(.gnu.warning) extras.o(.gnu.linkonce.t.*) extras.o(.init) extras.o(.glue_7) extras.o(.glue_7t)
    libtarget.a(.text*) libtarget.a(.gnu.warning) libtarget.a(.gnu.linkonce.t.*) libtarget.a(.init) libtarget.a(.glue_7) libtarget.a(.glue_7t)
    } > flash
    .ecos.rodata ALIGN (0x8) : LMA_EQ_VMA
    {
    FORCE_OUTPUT;
    vectors.o(.rodata*) vectors.o(.gnu.linkonce.r.*)
    extras.o(.rodata*) extras.o(.gnu.linkonce.r.*)
    libtarget.a(.rodata*) libtarget.a(.gnu.linkonce.r.*)  
    } > flash
    SECTION_sram (sram, 0x20000400, LMA_EQ_VMA)
    SECTION_text (ram1, 0x64008000, LMA_EQ_VMA)
    SECTION_fini (ram1, ALIGN (0x8), LMA_EQ_VMA)
    SECTION_rodata (ram1, ALIGN(0x8), LMA_EQ_VMA)
    SECTION_rodata1 (ram1, ALIGN (0x8), LMA_EQ_VMA)
    SECTION_fixup (ram1, ALIGN (0x8), LMA_EQ_VMA)
    SECTION_gcc_except_table (ram1, ALIGN (0x8), LMA_EQ_VMA)
    SECTION_eh_frame (ram1, ALIGN (0x8), LMA_EQ_VMA)
    SECTION_got (ram1, ALIGN (0x8), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
    SECTION_data (ram2, 0x68000000, LMA_EQ_VMA)
    SECTION_bss (ram2, ALIGN (0x8), LMA_EQ_VMA)
    SECTIONS_END
}

hal_vsr_table = 0x20000000;
hal_virtual_vector_table = hal_vsr_table + 128*4;
hal_startup_stack = 0x64800000;

With this modification the sections of the eCos components (from vectors.o, extras.o and libtarget.a)
are placed in the flash region when loaded with the RedBoot ROM monitor and GDB,
but a Bus error occurs in the reset_vector function:

Loading section .rom_vectors, size 0x8 lma 0x8010000
Loading section .ecos.text, size 0x10bcc lma 0x8010008
Loading section .ecos.rodata, size 0x49dc lma 0x8020bd8
Loading section .ARM.exidx, size 0x10 lma 0x64008000
Loading section .text, size 0x924 lma 0x64008010
Loading section .rodata, size 0x108 lma 0x64008938
Loading section .data, size 0xdcc lma 0x68000000
Start address 0x8010009, load size 93624
Transfer rate: 9 KB/sec, 300 bytes/write.

Program received signal SIGBUS, Bus error.
reset_vector () at [snip]/repo/ecos/packages/hal/cortexm/arch/current/src/vectors.S:100
100                ldr     sp,=hal_startup_stack

Is there a chance to get this working?

Greetings,

Martin

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

[ECOS] Re: Different section placement for kernel and application

[Grant Edwards]

On 2011-01-28, Martin R??sch <martin.roesch@neratec.com> wrote:
> Hi,
>
> Thanks for your answers.
>
>> In theory, you could apply section attributes to all of the kernel
>> functions (or all of the application functions) so that you could
>> separate them at link time into different output sections.
>
> That's what I was thinking of. I think this can be achieved with a
> modified version of the cortexm.ld linker script, which is used to
> generate the target.ld linker script.

I'm curious why you want to do this.  What benefit does it provide?

> I studied the documentation of the GNU Linker Scripts and found some
> hints to place the sections based from the input object file. I made
> a try in the RAM Layout .ldi file:
>
> // eCos memory layout
>
> #include <pkgconf/hal.h>
> #include <cyg/infra/cyg_type.inc>
>
> MEMORY
> {
>     sram  : ORIGIN = 0x20000000, LENGTH = 0x00010000
>     flash : ORIGIN = 0x08000000, LENGTH = 0x00080000
>     rom   : ORIGIN = 0x60000000, LENGTH = 0x00800000
>     ram1  : ORIGIN = 0x64000000, LENGTH = 0x00800000-CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE
>     ram2  : ORIGIN = 0x68000000, LENGTH = 0x00800000
> }
>
> SECTIONS
> {
>     SECTIONS_BEGIN
>     SECTION_rom_vectors (flash, 0x08010000, LMA_EQ_VMA)
>     SECTION_RELOCS (flash, ALIGN (0x8), LMA_EQ_VMA)
>     .ecos.text ALIGN (0x8) : LMA_EQ_VMA
>     {
>     vectors.o(.text*) vectors.o(.gnu.warning) vectors.o(.gnu.linkonce.t.*) vectors.o(.init) vectors.o(.glue_7) vectors.o(.glue_7t)
>     extras.o(.text*) extras.o(.gnu.warning) extras.o(.gnu.linkonce.t.*) extras.o(.init) extras.o(.glue_7) extras.o(.glue_7t)
>     libtarget.a(.text*) libtarget.a(.gnu.warning) libtarget.a(.gnu.linkonce.t.*) libtarget.a(.init) libtarget.a(.glue_7) libtarget.a(.glue_7t)
>     } > flash
>     .ecos.rodata ALIGN (0x8) : LMA_EQ_VMA
>     {
>     FORCE_OUTPUT;
>     vectors.o(.rodata*) vectors.o(.gnu.linkonce.r.*)
>     extras.o(.rodata*) extras.o(.gnu.linkonce.r.*)
>     libtarget.a(.rodata*) libtarget.a(.gnu.linkonce.r.*)  
>     } > flash
>     SECTION_sram (sram, 0x20000400, LMA_EQ_VMA)
>     SECTION_text (ram1, 0x64008000, LMA_EQ_VMA)
>     SECTION_fini (ram1, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_rodata (ram1, ALIGN(0x8), LMA_EQ_VMA)
>     SECTION_rodata1 (ram1, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_fixup (ram1, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_gcc_except_table (ram1, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_eh_frame (ram1, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_got (ram1, ALIGN (0x8), LMA_EQ_VMA)
>     CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
>     SECTION_data (ram2, 0x68000000, LMA_EQ_VMA)
>     SECTION_bss (ram2, ALIGN (0x8), LMA_EQ_VMA)
>     SECTIONS_END
> }
>
> hal_vsr_table = 0x20000000;
> hal_virtual_vector_table = hal_vsr_table + 128*4;
> hal_startup_stack = 0x64800000;
>
> With this modification the sections of the eCos components (from vectors.o, extras.o and libtarget.a)
> are placed in the flash region when loaded with the RedBoot ROM monitor and GDB,
> but a Bus error occurs in the reset_vector function:
>
> Loading section .rom_vectors, size 0x8 lma 0x8010000
> Loading section .ecos.text, size 0x10bcc lma 0x8010008
> Loading section .ecos.rodata, size 0x49dc lma 0x8020bd8
> Loading section .ARM.exidx, size 0x10 lma 0x64008000
> Loading section .text, size 0x924 lma 0x64008010
> Loading section .rodata, size 0x108 lma 0x64008938
> Loading section .data, size 0xdcc lma 0x68000000
> Start address 0x8010009, load size 93624
> Transfer rate: 9 KB/sec, 300 bytes/write.
>
> Program received signal SIGBUS, Bus error.
> reset_vector () at [snip]/repo/ecos/packages/hal/cortexm/arch/current/src/vectors.S:100
> 100                ldr     sp,=hal_startup_stack
>
> Is there a chance to get this working?

I think so, yes.

AFAIK, GDB stubs don't know how to program flash (and there's no
indication it attempted to do so), so you're using some other
mechanism to load the flash portion of the code?

-- 
Grant Edwards               grant.b.edwards        Yow! Did I SELL OUT yet??
                                  at               
                              gmail.com            


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

[ECOS] Re: Different section placement for kernel and application

[Grant Edwards]

On 2011-01-28, Grant Edwards <grant.b.edwards@gmail.com> wrote:

>> With this modification the sections of the eCos components (from vectors.o, extras.o and libtarget.a)
>> are placed in the flash region when loaded with the RedBoot ROM monitor and GDB,
>> but a Bus error occurs in the reset_vector function:
>>
>> Loading section .rom_vectors, size 0x8 lma 0x8010000
>> Loading section .ecos.text, size 0x10bcc lma 0x8010008
>> Loading section .ecos.rodata, size 0x49dc lma 0x8020bd8
>> Loading section .ARM.exidx, size 0x10 lma 0x64008000
>> Loading section .text, size 0x924 lma 0x64008010
>> Loading section .rodata, size 0x108 lma 0x64008938
>> Loading section .data, size 0xdcc lma 0x68000000
>> Start address 0x8010009, load size 93624
>> Transfer rate: 9 KB/sec, 300 bytes/write.
>>
>> Program received signal SIGBUS, Bus error.
>> reset_vector () at [snip]/repo/ecos/packages/hal/cortexm/arch/current/src/vectors.S:100
>> 100                ldr     sp,=hal_startup_stack
>>
>> Is there a chance to get this working?
>
> I think so, yes.
>
> AFAIK, GDB stubs don't know how to program flash (and there's no
> indication it attempted to do so),

I posted too quickly.  It appears that gdb did try to load
.rom_vectors .ecos.text .ecos.rodata into flash.  After you do the
load (but before you "continue"), can you verify that the code
actually got loaded into flash?  I didn't think that the gdb stubs
knew how to write to flash.

-- 
Grant Edwards               grant.b.edwards        Yow! DIDI ... is that a
                                  at               MARTIAN name, or, are we
                              gmail.com            in ISRAEL?


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

Re: [ECOS] Re: Different section placement for kernel and application

[Martin Rösch]

Hi,

> > AFAIK, GDB stubs don't know how to program flash (and there's no
> > indication it attempted to do so),
> 
> I posted too quickly. It appears that gdb did try to load
> .rom_vectors .ecos.text .ecos.rodata into flash. After you do the
> load (but before you "continue"), can you verify that the code
> actually got loaded into flash? I didn't think that the gdb stubs
> knew how to write to flash.

Yes, you are right. Here is the log of how i tried to verify:
(gdb) set *((int*)0x8010000) = 0x00000000
(gdb) x/4 0x8010000
0x8010000 <hal_vsr_table_init>:	0x02e4f04f	0xf8df4b1d	0x47e0c078	0x491a4819
(gdb) x/4 0x68000000
0x68000000 <select_stop_bits>:	0x00001000	0x00000000	0x00003000	0x00002000
(gdb) set *((int*)0x68000000) = 0xDEADBEEF
(gdb) x/4 0x68000000
0x68000000 <select_stop_bits>:	0xdeadbeef	0x00000000	0x00003000	0x00002000
(gdb) load
Loading section .rom_vectors, size 0x8 lma 0x8010000
Loading section .ecos.text, size 0x10bcc lma 0x8010008
Loading section .ecos.rodata, size 0x49dc lma 0x8020bd8
Loading section .ARM.exidx, size 0x10 lma 0x64008000
Loading section .text, size 0x924 lma 0x64008010
Loading section .rodata, size 0x108 lma 0x64008938
Loading section .data, size 0xdcc lma 0x68000000
Start address 0x8010009, load size 93624
Transfer rate: 9 KB/sec, 300 bytes/write.
(gdb) x/4 0x8010000
0x8010000 <hal_vsr_table_init>:	0x02e4f04f	0xf8df4b1d	0x47e0c078	0x491a4819
(gdb)

It seem's like it is not working to write to the flash with the GDB stubs. But I
think there is an option in the RedBoot ROM monitor configuration to allow that.
But I will first try to load the image with openocd...

Thank you for your help!

Greetings,

Martin

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

[ECOS] Re: Different section placement for kernel and application

[Badreddine]

Martin Rösch <martin.roesch <at> neratec.com> writes:

> 
> Hi,
> 
> On 2011-01-28, Grant Edwards <grant.b.edwards <at> gmail.com> wrote:
> > I'm curious why you want to do this. What benefit does it provide?
> 
> I have to link a C++ Application to eCos (with FreeBSD Stack and uSTL) on 
a STM32 derived board. 
> The footprint is to big to run it from the internal flash. So we decided 
to run it from external RAM. 
> Unfortunately the performance regarding IRQ handling of a RAM Application 
is too bad:
> Using the timers test from the STM32 variant HAL, I've set only TIM1 
active and then varied the update
> interrupt period. It turned out, that with a period of 20msec. the IRQ 
handler run into an Assertion in
> the post_dsr() function:
> ASSERT FAIL: <5>intr.cxx[292]void Cyg_Interrupt::post_dsr() DSR list is 
not empty but its head is 0
> 
> Doing the same test with a ROM Application, the period can be lowered to 
50usec.
> 
> So I'm trying to move the eCos library that contains the ISRs, DSRs etc. 
to the Internal Flash while keeping
> the rest of the application (that has no ISRs and DSRs) still in the 
external RAM.
> 
> I hope this Setup will improve the IRQ handling.
> 
> Greetings,
> 
> Martin
> 

Hi Martin,

I am about to start a new project using ecos (need to posix os with tcp/ip 
stack) and I want to know roughly the footprint of the os.
Do you know how much does ecos with tcp/ip stack consume?

Thanks,
Badreddine


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