[ECOS] porting to Atmel-AT91, stub memory-layout, .bss does not fit

[ECOS] porting to Atmel-AT91, stub memory-layout, .bss does not fit

[Andreas Bürgel]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

Hi,

I'm porting eCos to a custom board with the Atmel AT91 processor
(ARM7TDMI-core, 8kB on-chip SRAM), using the edb7xxx as template.
After processor-reset the processor has the following memory map:

0x00000000 - 0x000FFFFF  external device such as boot-PROM/Flash
0x00300000 - 0x0031FFFF  8kB on-chip SRAM
0xFFC00000 - 0xFFFFFFFF  on-chip peripherals I/O
other address-space is reserved

So I wrote the following ldi-file:
MEMORY
{
    rom : ORIGIN = 0, LENGTH = 0x80000
    reserved : ORIGIN = 0x100000, LENGTH = 0x200000
    onchip_ram : ORIGIN = 0x300000, LENGTH = 0x2000
    reserved2 : ORIGIN = 0x302000, LENGTH = 0xff8fe000
    peripheral : ORIGIN = 0xffc00000, LENGTH = 0x3fffff
}

SECTIONS
{
    SECTIONS_BEGIN
    SECTION_rom_vectors    (rom, 0,           LMA_EQ_VMA)
    SECTION_rodata         (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_text           (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_data           (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_bss            (onchip_ram, 0x300000, LMA_EQ_VMA)
    SECTIONS_END
}

When I'm compiling the GDB-Stub, the linkers says
"/tools/H-i686-pc-linux-gnu/arm-elf/bin/ld: address 0x302dbc of
/boeller/home/andreas/develop/eCos/AT91/install/bin/gdb_module.img
section .bss is not within region onchip_ram"

Who eats up the on-chip ram space? The stub isn't much more than a
skeleton.

Thanks in advance.
-- 
--------------------------------------------------
Andreas Bürgel   Software Engineer
ab@genologic.de  GenoLogic GmbH, Dortmund, Germany

RE: [ECOS] porting to Atmel-AT91, stub memory-layout, .bss does

[Gary Thomas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

On 30-Oct-2000 Andreas Bürgel wrote:
> Hi,
> 
> I'm porting eCos to a custom board with the Atmel AT91 processor
> (ARM7TDMI-core, 8kB on-chip SRAM), using the edb7xxx as template.
> After processor-reset the processor has the following memory map:
> 
> 0x00000000 - 0x000FFFFF  external device such as boot-PROM/Flash
> 0x00300000 - 0x0031FFFF  8kB on-chip SRAM
> 0xFFC00000 - 0xFFFFFFFF  on-chip peripherals I/O
> other address-space is reserved
> 
> So I wrote the following ldi-file:
> MEMORY
> {
>     rom : ORIGIN = 0, LENGTH = 0x80000
>     reserved : ORIGIN = 0x100000, LENGTH = 0x200000
>     onchip_ram : ORIGIN = 0x300000, LENGTH = 0x2000
>     reserved2 : ORIGIN = 0x302000, LENGTH = 0xff8fe000
>     peripheral : ORIGIN = 0xffc00000, LENGTH = 0x3fffff
> }
> 
> SECTIONS
> {
>     SECTIONS_BEGIN
>     SECTION_rom_vectors    (rom, 0,           LMA_EQ_VMA)
>     SECTION_rodata         (rom, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_text           (rom, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_data           (rom, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_bss            (onchip_ram, 0x300000, LMA_EQ_VMA)
>     SECTIONS_END
> }
> 
> When I'm compiling the GDB-Stub, the linkers says
> "/tools/H-i686-pc-linux-gnu/arm-elf/bin/ld: address 0x302dbc of
> /boeller/home/andreas/develop/eCos/AT91/install/bin/gdb_module.img
> section .bss is not within region onchip_ram"
> 
> Who eats up the on-chip ram space? The stub isn't much more than a
> skeleton.

The two largest contributors here seem to be the startup stack (4K)
and the GDB remote communication buffers (4K).  Even if you could 
totally eliminate them, which you can't, you'd barely be under 
your 8K total.

But then what?  What do you expect to do with a system that has
no other memory?

Re: [ECOS] porting to Atmel-AT91, stub memory-layout, .bss does not fit

[Jesper Skov]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

>>>>> "Andreas" == Andreas Bürgel <ab@genologic.de> writes:

Andreas> Who eats up the on-chip ram space? The stub isn't much more
Andreas> than a skeleton.

But it has various buffers for packet creation/decoding. It's a real
memory pig, actually (at least if you try to squeeze it into 8kB).

You should look at the nm output to see what buffers take up the
space, and reduce their size accordingly. Beware that you cannot make
them smaller than whichever is smaller of (a) 400 bytes or (b) the
number of bytes it takes to encode the register information (IIRC).

Also, the stub stack probably defaults to a couple of k.

I assume you have more RAM available?!?  You cannot expect to be able
to debug anything in 8kB of RAM. Both stub and application need space.

Jesper

Re: [ECOS] porting to Atmel-AT91, stub memory-layout, .bss does notfit

[Shaun Jackman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2183 bytes --]

You should know Carl van Schaik was working on a port for the AT91. I
believe was well on his way to a working port last I heard from him
(are you still out there?).

Our product uses an AT91M40400 (4k internal SRAM). We're not using an
RTOS. Just the standard GNU tool chain (linux-x-arm) + newlib. I'd be
happy to share my crt0.S and .ld script. They'll definately have to be
rewritten for your specific board (and the .ld changed to an .ldi for
ecos) but they might provide a good starting point.

Cheers,
Shaun


 On Mon, 30 Oct 2000, Andreas [iso-8859-1] Bürgel wrote:

> Hi,
> 
> I'm porting eCos to a custom board with the Atmel AT91 processor
> (ARM7TDMI-core, 8kB on-chip SRAM), using the edb7xxx as template.
> After processor-reset the processor has the following memory map:
> 
> 0x00000000 - 0x000FFFFF  external device such as boot-PROM/Flash
> 0x00300000 - 0x0031FFFF  8kB on-chip SRAM
> 0xFFC00000 - 0xFFFFFFFF  on-chip peripherals I/O
> other address-space is reserved
> 
> So I wrote the following ldi-file:
> MEMORY
> {
>     rom : ORIGIN = 0, LENGTH = 0x80000
>     reserved : ORIGIN = 0x100000, LENGTH = 0x200000
>     onchip_ram : ORIGIN = 0x300000, LENGTH = 0x2000
>     reserved2 : ORIGIN = 0x302000, LENGTH = 0xff8fe000
>     peripheral : ORIGIN = 0xffc00000, LENGTH = 0x3fffff
> }
> 
> SECTIONS
> {
>     SECTIONS_BEGIN
>     SECTION_rom_vectors    (rom, 0,           LMA_EQ_VMA)
>     SECTION_rodata         (rom, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_text           (rom, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_data           (rom, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_bss            (onchip_ram, 0x300000, LMA_EQ_VMA)
>     SECTIONS_END
> }
> 
> When I'm compiling the GDB-Stub, the linkers says
> "/tools/H-i686-pc-linux-gnu/arm-elf/bin/ld: address 0x302dbc of
> /boeller/home/andreas/develop/eCos/AT91/install/bin/gdb_module.img
> section .bss is not within region onchip_ram"
> 
> Who eats up the on-chip ram space? The stub isn't much more than a
> skeleton.
> 
> Thanks in advance.
> -- 
> --------------------------------------------------
> Andreas Bürgel   Software Engineer
> ab@genologic.de  GenoLogic GmbH, Dortmund, Germany
> 
> 
> 

Re: [ECOS] porting to Atmel-AT91, stub memory-layout, .bss does notfit

[Carl van Schaik]

Hi all

I see there is some renewed intreset inthe AT91

I have not worked on the port for a while mainly because my port is stable
and running (I've had >15 days up time). I'll see if I can sort out the
code and release it. I have a lot of contract work at the moment so it may
take a few days.

regards

Carl van Schaik   <carl@leg.uct.ac.za>
-----------------------------------------------------
Dept. Electrical Engineering, UCT

Tel: +27 21 650-3467
Fax: +27 21 650-3465