[ECOS] AT91 extended internal SRAM

[Jonathan Larmour]

Robert Martin wrote:
> 
> I would like to add support for the 128k of internal
> SRAM on the AT91R40807, the CPU on the AT91EB40. I
> would like to do this so that I can have access to the
> only large chunk of 32 bit wide memory available for
> this chip and to bump up the memory available on the
> board by 25%.  From what I can tell so far, to do this
> I need to modify the AT91 startup code to disable
> write protection of this region, modify the linker
> map(s) for the configuration(s) that would use this,
> and modify RedBoot so that it will know about this
> additional region of memory. (I have done the first
> two and found out about RedBoot not allowing the load
> the hard way.)   I have no problem doing all of this
> in my local copy.  I would like to be able to feed the
> modifications back into the mainline sources.  I have
> a few questions on the best way to do this.
> 
> 1) Is there a standard name for this that I should use
> in the overlays?  Atmel uses "extended SRAM" in their
> documentation.  If there is no standard name for this,
> is there a problem with me calling this region
> "esram"?

Nope. However you could also consider using the MMU to map it contiguously
with the rest of RAM that also has the advantage of solving the "allow
RedBoot to know about it" problem.

> 2) Should this be added to the ROMRAM mode or to a new
> mode?  With only 128k, it is a bit dangerous to use
> this in the default RAM mode since it is easy (too
> easy?) to have a text region that blows through the
> 128k barrier.  The ROMRAM mode has the advantage the
> FLASH is less than 64k in the default configuration.
> There are a few options for new modes :
>    a) use the 128k for .text segment (dangerous, see
> above)
>    b) use this region for the heap and stack
>    c) use it for .data and .bss (too easy to have bss
> over 128k.  Maybe this could impose some discipline ;)
> 
> I will likely play with all three.  Is there any
> desire to have any of those options in the main eCos
> tree?

Again not an issue if mapped contiguously. But otherwise, I wouldn't worry
about adding a new mode - if someone wants to use it they easily can.
 
> 3) Atmel suggests using the write protection feature
> of this region to test ROMable code, especially for
> their AT91M40807 (same as `R40807 but with this region
> masked).   I was thinking of providing an option to
> set the memory protection in ROMRAM mode after the
> code has been transfered to the internal SRAM.  Does
> the eCos community consider this something that is
> worthwhile or a pollution of the configuration space?

Indeed most MMUs support this type of thing (to support copy-on-write) - it
isn't specific to this region. I think if anyone wants it, they'd want to
do it in their application as it depends what they're putting in it (and
after all as you say it's only 128k).
 
Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine