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

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

[Andreas Bürgel]

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

> 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?

The system has 2MB of RAM additionally, but between the RAM and the CPU
there's a FPGA used as DRAM-Controller ( Refresh ...). This means that
the stub-platform-init-code has to initialize the FPGA before this
memory is usable. The init-code has also to call the remap
command-sequence of the AT91, which maps the on-chip-SRAM to 0x00000000
and the boot-flash to some other start address.

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

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

[Gary Thomas]

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

On 30-Oct-2000 Andreas Bürgel wrote:
>> 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?
> 
> The system has 2MB of RAM additionally, but between the RAM and the CPU
> there's a FPGA used as DRAM-Controller ( Refresh ...). This means that
> the stub-platform-init-code has to initialize the FPGA before this
> memory is usable. The init-code has also to call the remap
> command-sequence of the AT91, which maps the on-chip-SRAM to 0x00000000
> and the boot-flash to some other start address.

Fair enough, we do this sort of thing all the time.  Look at the file
  hal/arm/ebsa285/current/include/hal_platform_setup.h
for an example of how it might be done.  This file includes routines
which set up the DRAM controller, etc, and then remaps memory (using
the ARM MMU) before starting up the eCos environment, including the 
GDB stubs.