This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Memory initialization (not)
- From: Duane Ellis <duane-gcc-help at duaneellis dot com>
- To: j_dougherty at ecrm dot com, gcc-help at gcc dot gnu dot org
- Date: Tue, 30 Sep 2008 19:34:38 -0400
- Subject: Re: Memory initialization (not)
- Reply-to: duane-gcc-help at duaneellis dot com
jim> [I have an embedded system with special memory I do not want
initialized]
You have the following choices:
(A) Do you control the code at the reset vector?
(B) Or is your program "loaded" by some external boot loader?
If you control the code at the reset vector, you can change that code to
do what you want.
Typically in a bare-metal application the code sequence at hard reset is:
1) configure an initial stack pointer
2) program the clocks, plls, and enable SDRAM
[all of which is very chip/silicon specific code]
3) Copy data data from "ROM" to your initialized data area.
4) zero memory.
5) Call the "C++" constructors and initializers - (if you need C++)
6) Sometimes, call some OS dependent functions.
7) Call some function - example: EtherNut calls it "NutMain()" others -
just call it "main()"
8) often you find the above in a file called "crt0.s", other times it
is called "reset.s" it varies. I've also seen "vectors.s" -
You need to modify the file described above for your target board.
Here is an example from "lostarm" - for an Atmel ARM7 based AT91SAM7X256
http://lostarm.svn.sourceforge.net/viewvc/lostarm/release/rev0.1/chips/at91sam7x256/source/sam7_crt0.S?revision=53&view=markup
Here is an example from "ethernut" - for another ARM cpu.
http://ethernut.cvs.sourceforge.net/viewvc/ethernut/nut/arch/arm/init/crtat91_ram.S?view=markup
----
If your code is: "loaded" - ie: via UBOOT (a boot loader) over TCP/IP,
you might need to fiddle with the ELF flags that define what gets done
at load time, that is not always easy, and often one must resort to
"modifying the boot loader" so that it does not zap memory.
---