Re: [ECOS] memory address for redboot and application

[Andrew Lunn <andrew at lunn dot ch>]

On Thu, Sep 14, 2006 at 11:45:33AM +0200, qin zhao wrote:
> Hi,
> 
> I did look at xxx_ram.ldi and it has the following lines:

this is for the application.
 
 
> MEMORY
> {
>    ram : ORIGIN = 0, LENGTH = 0x800000
>    sram : ORIGIN = 0x70000000, LENGTH = 0x4000

These two tell you where you have RAM and SRAM. Not very interesting
in its own.

> }
> 
> SECTIONS
> {
>    SECTIONS_BEGIN
>    SECTION_fixed_vectors (ram, 0x20, LMA_EQ_VMA)
>    SECTION_rom_vectors (ram, 0x40000, LMA_EQ_VMA)

This is saying that the application is loaded at address 0x40000. The
memory below that, except a small amount at 0x20 is not being used by
the application. However RedBoot is probably using that memory.

> where I could not find the information for redboot and application.
> 
> Also I did use arm-elf-objdump --headers and got the following:
> 
> a.out:     file format elf32-littlearm
> 
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>  0 .debug_aranges 000017a0  00000000  00000000  00018830  2**3
>                  CONTENTS, READONLY, DEBUGGING
>  1 .debug_pubnames 000037ef  00000000  00000000  00019fd0  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  2 .debug_info   00059e38  00000000  00000000  0001d7bf  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  3 .debug_abbrev 00009702  00000000  00000000  000775f7  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  4 .debug_line   0000de71  00000000  00000000  00080cf9  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  5 .debug_frame  00003824  00000000  00000000  0008eb6c  2**2
>                  CONTENTS, READONLY, DEBUGGING
>  6 .debug_str    00009a15  00000000  00000000  00092390  2**0
>                  CONTENTS, READONLY, DEBUGGING

All the sections above contain debug information and are not loaded
onto the target.

>  7 .fixed_vectors 00000140  00000020  00000020  0009bdc0  2**5
>                  CONTENTS, READONLY

This shows that 0x140 bytes are loaded to address 0x20.

>  8 .rom_vectors  00000040  00040000  00040000  00008000  2**0
>                  CONTENTS, ALLOC, LOAD, READONLY, CODE

0x40 bytes at address 0x40000

>  9 .text         0000feb0  00040040  00040040  00008040  2**2
>                  CONTENTS, ALLOC, LOAD, READONLY, CODE

0xfeb0 bytes at 0x40040

> 10 .fini         00000000  0004fef0  0004fef0  0009bf00  2**0
>                  CONTENTS
> 11 .rodata       00000450  0004fef0  0004fef0  00017ef0  2**2
>                  CONTENTS, ALLOC, LOAD, READONLY, DATA
> 12 .rodata1      00000000  00050340  00050340  0009bf00  2**0
>                  CONTENTS
> 13 .got          00000000  00050340  00050340  0009bf00  2**0
>                  CONTENTS
> 14 .fixup        00000000  00050340  00050340  0009bf00  2**0
>                  CONTENTS
> 15 .gcc_except_table 00000000  00050340  00050340  0009bf00  2**0
>                  CONTENTS
> 16 .eh_frame     00000008  00050340  00050340  00018340  2**0
>                  ALLOC
> 17 .data         000004e4  00050348  00050348  00018348  2**2
>                  CONTENTS, ALLOC, LOAD, DATA
> 18 .bss          0000651c  0005082c  0005082c  0001882c  2**4
>                  ALLOC

This is the last section which uses memory, ie 0x651c bytes at
0x5082c. The heap will start at (0x5082c + 0x651c) and go to the top
of memory.

   Andrew

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