* [ECOS] Different section placement for kernel and application [not found] <2815371.163.1296147619546.JavaMail.neratec@martin-lucid32> @ 2011-01-27 17:56 ` Martin Rösch 2011-01-27 18:24 ` Christophe Coutand 2011-01-27 22:01 ` [ECOS] " Grant Edwards 0 siblings, 2 replies; 8+ messages in thread From: Martin Rösch @ 2011-01-27 17:56 UTC (permalink / raw) To: discuss, eCos 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [ECOS] Different section placement for kernel and application 2011-01-27 17:56 ` [ECOS] Different section placement for kernel and application Martin Rösch @ 2011-01-27 18:24 ` Christophe Coutand 2011-01-27 22:01 ` [ECOS] " Grant Edwards 1 sibling, 0 replies; 8+ messages in thread From: Christophe Coutand @ 2011-01-27 18:24 UTC (permalink / raw) To: Martin Rösch, discuss, eCos 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [ECOS] Re: Different section placement for kernel and application 2011-01-27 17:56 ` [ECOS] Different section placement for kernel and application Martin Rösch 2011-01-27 18:24 ` Christophe Coutand @ 2011-01-27 22:01 ` Grant Edwards 2011-01-28 16:19 ` Martin Rösch 1 sibling, 1 reply; 8+ messages in thread From: Grant Edwards @ 2011-01-27 22:01 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ECOS] Re: Different section placement for kernel and application 2011-01-27 22:01 ` [ECOS] " Grant Edwards @ 2011-01-28 16:19 ` Martin Rösch 2011-01-28 16:25 ` Grant Edwards 0 siblings, 1 reply; 8+ messages in thread From: Martin Rösch @ 2011-01-28 16:19 UTC (permalink / raw) To: discuss, eCos 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [ECOS] Re: Different section placement for kernel and application 2011-01-28 16:19 ` Martin Rösch @ 2011-01-28 16:25 ` Grant Edwards 2011-01-28 17:07 ` Grant Edwards [not found] ` <2029563421.8440.1296480614291.JavaMail.root@idefix> 0 siblings, 2 replies; 8+ messages in thread From: Grant Edwards @ 2011-01-28 16:25 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [ECOS] Re: Different section placement for kernel and application 2011-01-28 16:25 ` Grant Edwards @ 2011-01-28 17:07 ` Grant Edwards 2011-01-30 9:31 ` Martin Rösch [not found] ` <2029563421.8440.1296480614291.JavaMail.root@idefix> 1 sibling, 1 reply; 8+ messages in thread From: Grant Edwards @ 2011-01-28 17:07 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ECOS] Re: Different section placement for kernel and application 2011-01-28 17:07 ` Grant Edwards @ 2011-01-30 9:31 ` Martin Rösch 0 siblings, 0 replies; 8+ messages in thread From: Martin Rösch @ 2011-01-30 9:31 UTC (permalink / raw) To: discuss, eCos 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <2029563421.8440.1296480614291.JavaMail.root@idefix>]
* [ECOS] Re: Different section placement for kernel and application [not found] ` <2029563421.8440.1296480614291.JavaMail.root@idefix> @ 2014-05-19 9:45 ` Badreddine 0 siblings, 0 replies; 8+ messages in thread From: Badreddine @ 2014-05-19 9:45 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-05-19 9:45 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <2815371.163.1296147619546.JavaMail.neratec@martin-lucid32> 2011-01-27 17:56 ` [ECOS] Different section placement for kernel and application Martin Rösch 2011-01-27 18:24 ` Christophe Coutand 2011-01-27 22:01 ` [ECOS] " Grant Edwards 2011-01-28 16:19 ` Martin Rösch 2011-01-28 16:25 ` Grant Edwards 2011-01-28 17:07 ` Grant Edwards 2011-01-30 9:31 ` Martin Rösch [not found] ` <2029563421.8440.1296480614291.JavaMail.root@idefix> 2014-05-19 9:45 ` Badreddine
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).