* [ECOS] dividing the elf object file file in to two binary files
@ 2009-07-20 5:03 ganesh kr
2009-07-21 12:46 ` Martin Laabs
2009-08-05 13:07 ` [ECOS] " ganesh kr
0 siblings, 2 replies; 8+ messages in thread
From: ganesh kr @ 2009-07-20 5:03 UTC (permalink / raw)
To: ecos-discuss
Hi,
I am using ecos with lwip. I have two flash memory chips of 128 KB
each at addr 0x04000000 and 0x08000000. the binary file is 140KB. I
want to have two binary files from the elf object file so that i can
load one binary file in to each flash. Also I have two libraries
libapp.a and libtarget.a. please let me know how can i do this.
--
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] dividing the elf object file file in to two binary files
2009-07-20 5:03 [ECOS] dividing the elf object file file in to two binary files ganesh kr
@ 2009-07-21 12:46 ` Martin Laabs
2009-07-22 4:53 ` ganesh kr
2009-08-05 13:07 ` [ECOS] " ganesh kr
1 sibling, 1 reply; 8+ messages in thread
From: Martin Laabs @ 2009-07-21 12:46 UTC (permalink / raw)
To: ganesh kr, eCos Discuss
Hi,
ganesh kr wrote:
> Hi,
>
> I am using ecos with lwip. I have two flash memory chips of 128 KB
> each at addr 0x04000000 and 0x08000000. the binary file is 140KB. I
> want to have two binary files from the elf object file so that i can
> load one binary file in to each flash. Also I have two libraries
> libapp.a and libtarget.a. please let me know how can i do this.
You have to change the linker script to get two sections for .text.
However - you have to give every section an unique name. To assign
functions/files to each section you can use the linker script as well
as the __attribute__ ((section ("<section name>"))) attribute before
any function or variable.
At the end you get one elf file with different section that can be
separated by objcopy/objdump.
Here a short example from an old project:
#define INSRAM_DATA __attribute__ ((section (".sram_data")))
#define INSRAM_TEXT __attribute__ ((section (".sram_text")))
cyg_uint32 rawData[20][64] INSRAM_DATA; //[Channel][TimeSlot]
void INSRAM_TEXT
reader(cyg_addrword_t data)
{
...
}
Greetings,
Martin Laabs
PS: If you call function in one segment out of the other
segment you have to use far jumps like that:
void (*diag_printf_p)( const char *fmt, ... ) = &diag_printf;
and then call
diag_printf_p("calculating: %d %d %d\n", i, j, tap); instead of
diag_printf(....)
--
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] dividing the elf object file file in to two binary files
2009-07-21 12:46 ` Martin Laabs
@ 2009-07-22 4:53 ` ganesh kr
2009-07-22 11:22 ` ganesh kr
0 siblings, 1 reply; 8+ messages in thread
From: ganesh kr @ 2009-07-22 4:53 UTC (permalink / raw)
To: eCos Discuss
Thanks for the response Martin. Since I am new to ecos and GNU tools,
can any one please provide the reference linker script file to do the
same
On Tue, Jul 21, 2009 at 6:16 PM, Martin Laabs<info@martinlaabs.de> wrote:
> Hi,
>
> ganesh kr wrote:
>>
>> Hi,
>>
>> I am using ecos with lwip. I have two flash memory chips of 128 KB
>> each at addr 0x04000000 and 0x08000000. the binary file is 140KB. I
>> want to have two binary files from the elf object file so that i can
>> load one binary file in to each flash. Also I have two libraries
>> libapp.a and libtarget.a. please let me know how can i do this.
>
> You have to change the linker script to get two sections for .text.
> However - you have to give every section an unique name. To assign
> functions/files to each section you can use the linker script as well
> as the __attribute__ ((section ("<section name>"))) attribute before
> any function or variable.
>
> At the end you get one elf file with different section that can be
> separated by objcopy/objdump.
>
> Here a short example from an old project:
>
> #define INSRAM_DATA __attribute__ ((section (".sram_data")))
> #define INSRAM_TEXT __attribute__ ((section (".sram_text")))
>
> cyg_uint32 rawData[20][64] INSRAM_DATA; //[Channel][TimeSlot]
>
> void INSRAM_TEXT
> reader(cyg_addrword_t data)
> {
> ...
> }
>
> Greetings,
> Martin Laabs
>
> PS: If you call function in one segment out of the other
> segment you have to use far jumps like that:
>
> void (*diag_printf_p)( const char *fmt, ... ) = &diag_printf;
>
> and then call
> diag_printf_p("calculating: %d %d %d\n", i, j, tap); instead of
> diag_printf(....)
>
>
--
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: dividing the elf object file file in to two binary files
2009-07-20 5:03 [ECOS] dividing the elf object file file in to two binary files ganesh kr
2009-07-21 12:46 ` Martin Laabs
@ 2009-08-05 13:07 ` ganesh kr
1 sibling, 0 replies; 8+ messages in thread
From: ganesh kr @ 2009-08-05 13:07 UTC (permalink / raw)
To: ecos-discuss
Hi,
I am using ecos 3.0. I am not able to use malloc(). when I call
malloc very first time in my application, it returns null. I called
mallinfo() just before calling malloc. The values of different members
of the returned structure is as bellow:
struct mallinfo {
int arena = 00000000
int ordblks = 00000000
int smblks; = 00000000
int hblks; = 82630000
int hblkhd; = 01356353
int usmblks; = C0043602
int fsmblks; = 330150A8
int uordblks; = 51010004
int fordblks; = 00043A80
int keepcost; = 3BC0A800
int maxfree; = 27010004
};
all these numbers seems to be not correct.
My linker directive file is as bellow:
STARTUP(./lib/vectors.o)
ENTRY(reset_vector)
INPUT(./lib/extras.o)
GROUP(./lib/libtarget.a libgcc.a libsupc++.a)
MEMORY {
app_flash0_rsvd1 : ORIGIN = 0x0, LENGTH = 0x200
app_flash0_memory : ORIGIN = 0x200, LENGTH = 127K-0x200
app_flash0_rsvd2 : ORIGIN = 0x1fa00, LENGTH = 0x200
app_flash1_rsvd1 : ORIGIN = 0x08000000, LENGTH = 0
app_flash1_memory : ORIGIN = 0x08000000, LENGTH = 128K
sram_rsvd1 : ORIGIN = 0x04000000, LENGTH = 0
sram_memory : ORIGIN = 0x04000000, LENGTH = 192K
}
SECTIONS
{
.debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : {
*(.debug_pubnames) } .debug_info 0 : { *(.debug_info) } .debug_abbrev
0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : {
*(.debug_macinfo) } .note.arm.ident 0 : { KEEP (*(.note.arm.ident)) }
.rom_vectors 0x0000000 : { __rom_vectors_vma = ABSOLUTE(.); . = .;
KEEP (*(.vectors)) } > app_flash0_rsvd1 __rom_vectors_lma =
LOADADDR(.rom_vectors);
.text ALIGN (0x4) : { _stext = ABSOLUTE(.); PROVIDE (__stext =
ABSOLUTE(.)); *(.text*) *(.gnu.warning) *(.gnu.linkonce.t.*) *(.init)
*(.glue_7) *(.glue_7t) } > app_flash0_memory _etext = .; PROVIDE
(__etext = .);
.fini ALIGN (0x4) : { . = .; *(.fini) } > app_flash0_memory
.rodata ALIGN (0x4) : { . = .; *(.rodata*) *(.gnu.linkonce.r.*) }
> app_flash0_memory
.rodata1 ALIGN (0x4) : { . = .; *(.rodata1) } > app_flash0_memory
.fixup ALIGN (0x4) : { . = .; *(.fixup) } > app_flash0_memory
.gcc_except_table ALIGN (0x4) : { . = .; *(.gcc_except_table) } >
app_flash0_memory
.fixed_vectors 0x04000000 : { . = .; KEEP (*(.fixed_vectors)) } >
sram_memory
.data ALIGN (0x4) : AT ((LOADADDR (.gcc_except_table) + SIZEOF
(.gcc_except_table) + 4 - 1) & ~ (4 - 1)) { __ram_data_start =
ABSOLUTE (.); *(.data*) *(.data1) *(.gnu.linkonce.d.*) . = ALIGN (4);
KEEP(*( SORT (.ecos.table.*))) ; . = ALIGN (4); __CTOR_LIST__ =
ABSOLUTE (.); KEEP (*(SORT (.ctors*))) __CTOR_END__ = ABSOLUTE (.);
__DTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.dtors*))) __DTOR_END__ =
ABSOLUTE (.); *(.dynamic) *(.sdata*) *(.gnu.linkonce.s.*) . = ALIGN
(4); *(.2ram.*) } > sram_memory __rom_data_start = LOADADDR (.data);
__ram_data_end = .; PROVIDE (__ram_data_end = .); _edata = .; PROVIDE
(edata = .); PROVIDE (__rom_data_end = LOADADDR (.data) +
SIZEOF(.data));
.bss ALIGN (0x4) : { __bss_start = ABSOLUTE(.); *(.scommon)
*(.dynsbss) *(.sbss*) *(.gnu.linkonce.sb.*) *(.dynbss) *(.bss*)
*(.gnu.linkonce.b.*) *(COMMON) __bss_end = ABSOLUTE (.); } >
sram_memory
__heap1 = ALIGN (0x8);
. = ALIGN(4); _end = .; PROVIDE (end = .);
}
Please any one tell me whats the problem.
1. Is dynamic memory allocation dependent on linker directive and
memory layout?
2. What are the steps to be done to use malloc()? Like what are the
options need to choose in ecos config tool to use malloc()?
Please let me know if any more information is needed.
Regards,
Ganesh K R
--
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:[~2009-08-05 13:07 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-20 5:03 [ECOS] dividing the elf object file file in to two binary files ganesh kr
2009-07-21 12:46 ` Martin Laabs
2009-07-22 4:53 ` ganesh kr
2009-07-22 11:22 ` ganesh kr
2009-07-22 11:25 ` Simon Kallweit
[not found] ` <73f9997f0907222350y49e0773dr926c16b42518839c@mail.gmail.com>
2009-07-23 7:13 ` Simon Kallweit
[not found] ` <73f9997f0907282209l65073597m356c05a397bd3203@mail.gmail.com>
2009-07-29 6:18 ` Simon Kallweit
2009-08-05 13:07 ` [ECOS] " ganesh kr
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).