This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: RE: RE: porting to Atmel-AT91, stub memory-layout, .b
- To: Andreas Bürgel <ab at genologic dot de>
- Subject: RE: [ECOS] RE: RE: porting to Atmel-AT91, stub memory-layout, .b
- From: Gary Thomas <gthomas at redhat dot com>
- Date: Mon, 30 Oct 2000 08:23:15 -0700 (MST)
- Cc: ecos-discuss at sources dot redhat dot com
- Organization: Red Hat, Inc.
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.