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

Gary Thomas gthomas@redhat.com
Mon Oct 30 06:57:00 GMT 2000


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.


More information about the Ecos-discuss mailing list