This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

AT91 extended internal SRAM


Hello,

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

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?

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? 


If anyone is still reading down here, I have a general
question.  I am doing everything under Linux so I do
not have access to the MLT.  To test out things on my
machine, I have been modifying the memory layout .ldi
and .h files by hand.  Of course, there are big
warnings about modifying these by hand.  Is there a
MLT replacement script that runs under Linux?  If not,
are there any suggestions on how to get the memory
layout modified in a sanctioned way.  I am happy
modifying the files by hand for myself but that would
presumably not be good for anyone using the Win32
tool.

Regards,
Rob
------
Robert Martin
Sonoran Foothills Engineering
rmartin@sonoranfoothillseng.com


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]