* added: Linker script adds support for RAM4 and RAM5 memory regions, so
that those are usable by code. This also fixes the fact that RAM4 was
declared, but inaccessible previously
* changed: RAM1 is renamed to RAM2, shifting numbering of all regions.
This is done in order to be in line with other STM32 definitions,
similarly ROM1 became ROM2.
We already had the hooks for ccmram and ram1 and ram2 and ram3 and xsram
for "other" ram sections, but there was no method, out of the box, for
placing a function in "normal" ram. The "easy" method of labelling a
function as ".data.someramfunc" causes warnings because code isn't meant
to have a name like ".data*" so we must explicitly add a new code
section.
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
Add support for a section(s) ".noinit*" that will be allocated in ram,
but not cleared or initialized. This can be used for passing variables
between a bootloader and an app for instance, or even just between
restarts of your application.
Without any assigned usages of the section, there is zero change in ram
usage. The align does nothing when the prior section was already
aligned.
While the NOLOAD variant sometimes worked with some toolchains, the
version in the generator scripts could never work, as neither the
startup code, nor gdb know how to load those sections properly.
Originally added in: eb18cc19cb
The original scripts allowed you to place variables in eeprom space for
reading only. However, the last toolchain that generated working code
with this linker script was the gcc-arm-none-eabi-4_9-2014q4 release.
Subsequent releases treat the directives differently, and can lose track
of where variables are. One known symptom is constants getting bad
addresses, so for instance, "printf("asdfad")" will end up passing the
wrong address of the string constant into the eventual _write() call.
This commit removes the problematic directives until a more fully
correct system can be found that more properly follows the linker
script rules.
This makes possibility for the script to append the definitions to CFLAGS
and LDFLAGS, and with the feature of disabling of -D prependation it will
make possible to generate ARCH_FLAGS generic to each specific chip.