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.
Thoughts: should this be a "sam0" family rather than samd? (Much like Atmel's
own software package lumps all the cortex-m0+ devices in one family)
This was enough to get a basic blinky working at least.
this is the part on the f072 discovery board. The devices.data file is
expected to be already lowercased, while the user provided DEVICE= variable is
then lowercased.
Added lpc43xx to devices.data
For now all lpc43 chips resolve to their cortex-m4 variant. How m0 should
be handled is to be determined later.
devices.data: add some vf6xx and lm4f support. fix typos
devices.data: added missing lpc13 family group
devices.data: fix lm4f with info from examples
devices.data: add some vf610 info
devices.data: add some entries for examples
As discussed with karlp on irc the devices.data file should not contain
gcc specific command line options.
For that reason the command line options for gcc are now generated from
the variables CPU and FPU by the rules in the mk directory.
This breaks the genlink tests.
genlink: simplified devices.data
devices.data already had the information about the family name.
By using the first field (by the pattern used to match it) as family name information that data doesn't
have to be provided explicitly. The same data is used to generate the
CPPFLAGS, such as -DSTM32F1
The architectures block of the devices.data file was redundant.
genlink-config.mk uses family and subfamily to figure out which libopencm3
variant actually exists.
f7 has -mfpu=fpv5-sp-d16 in the lib makefile, devices.data should have
the same setting.
l0 is a cortex m0+, not a cortex m0, and uses cortex-m0plus in the
library makefile, and should have the same setting in the devices.data
file.
Most changes are noise from doxygen.
Readme udpated to explain newer FP_FLAGS for m7
stm32f7 library is skipped if the toolchain doesn't support it yet.
Correct memory sizes in ld/devices.data for:
* stm32f3[01]3?c from RAM=48K to RAM=40K.
* stm32f303?b from RAM=40K to RAM=32K.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
These devices have 32kiB RAM and 256kiB flash and are otherwise
register compatible with the f373x8 and f373xc devices.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
in ARCH, there are all -m flags (will be expanded into ARCH_FLAGS in Makefile)
in DEFS, there are all -D flags (will be expanded into DEFS in Makefile)
in LIB, there are all -l flags (will be expanded into LIBNAME in Makefile)
If no MODE option specified, the generator behaves as in previous version.
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.
Karl Palsson
Garret Kelly
Matthew Lai
Karl Palsson
Jonas Meyer
Karl Palsson
Constantine Verutin
Frantisek Burian
Hunz
Hanspeter Portner
Jeff Epler
Felix Held
Piotr Esden-Tempski