RIOT-OS/RIOT
RIOT-OS/RIOT
1
0
Fork 0
mirror of https://github.com/RIOT-OS/RIOT.git synced 2024-12-29 04:50:03 +01:00
Code Releases Activity
c507ebff43
RIOT/makefiles/arch/msp430.inc.mk

37 lines
1.4 KiB
Makefile
Raw Normal View History

cpu/msp430: update to modern gcc & newlib
2019-02-22 23:42:08 +01:00
# Target architecture for the build. Use msp430-elf if you are unsure.
build system: Overwrite TARGET_ARCH per arch Add `TARGET_ARCH_<ARCH>` for each architecture (e.g. `TARGET_ARCH_CORTEX` for Cortex M) to allow users to overwrite the target triple for a specific arch from ~/.profile or ~/.bashrc (or the like) without overwriting it for all others as well.
2020-09-08 22:28:41 +02:00
TARGET_ARCH_MSP430 ?= msp430-elf
TARGET_ARCH ?= $(TARGET_ARCH_MSP430)
cpu/msp430: update to modern gcc & newlib
2019-02-22 23:42:08 +01:00
cpu/msp430: reorganize code RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this: #ifndef UART_USE_USCI /* implementation of x1xx peripheral ... */ #else /* implementation of F2xx/G2xx peripheral ... */ #endif /* zero shared code between both variants */ This splits the peripheral drivers for USCI and USART serial IP blocks into separate files and relocates everything in cpu/msp430, similar to how cpu/stm32 is organized. [MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf [MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
2023-06-13 15:56:24 +02:00
MSP430_SUPPORT_FILES ?= $(RIOTCPU)/msp430/vendor/msp430-gcc-support-files
boards: added shared Makefile.inc for msp430 boards
2015-09-16 17:06:08 +02:00
# define build specific options
cpu/msp430: update to modern gcc & newlib
2019-02-22 23:42:08 +01:00
CFLAGS_CPU = -mmcu=$(CPU_MODEL) -isystem $(MSP430_SUPPORT_FILES)/include
boards: msp430-common: remove dead code when linking.
2016-07-31 00:17:55 +02:00
CFLAGS_LINK = -ffunction-sections -fdata-sections
cpu/msp430: update to modern gcc & newlib
2019-02-22 23:42:08 +01:00
CFLAGS_DBG ?= -g -gdwarf-2
boards: added shared Makefile.inc for msp430 boards
2015-09-16 17:06:08 +02:00
CFLAGS_OPT ?= -Os
cpu/msp430: update to modern gcc & newlib
2019-02-22 23:42:08 +01:00
makefiles: do not locally export compilation variables These are already exported by `makefiles/vars.inc.mk`. It is a prerequisite to allow handling compilation without global exports.
2019-08-27 16:06:41 +02:00
CFLAGS += $(CFLAGS_CPU) $(CFLAGS_LINK) $(CFLAGS_DBG) $(CFLAGS_OPT)
ASFLAGS += $(CFLAGS_CPU) --defsym $(CPU_MODEL)=1 $(CFLAGS_DBG)
cpu/msp430: update to modern gcc & newlib
2019-02-22 23:42:08 +01:00
cpu/msp430: fix for ti's msp430-gcc-opensource package ld version
2023-07-01 12:29:19 +02:00
BINUTILS_VERSION := $(shell $(PREFIX)ld --version | grep -Eo '[0-9]\.[0-9]+$$')
cpu/msp430_common: Fix linking with binutils 2.40 An `INSERT AFTER` directive no longer can refer to a different linker script included with `-T path/to/script.ld`. Instead, this adds wrapper linker scripts that just `INCLUDE` the three individual linker scripts. This way, the xfa.ld can safely refer back to sections defined in the vendor linker script. For some reason, this approach cause the exact issue it fixes for binutils 2.40 with the binutils in the CI. We stick with the old linker flags with binutils prior 2.40 to be compatible with both conflicting behaviors. The best approach would be to come up with something that works across different versions of binutils; but no such solution materialized.
2023-04-19 17:46:17 +02:00
NEEDS_NEW_LINKER_SCRIPT := $(call version_is_greater_or_equal,$(BINUTILS_VERSION),2.40)
cpu/msp430: update to modern gcc & newlib
2019-02-22 23:42:08 +01:00
LINKFLAGS += $(CFLAGS_CPU) $(CFLAGS_DBG) $(CFLAGS_OPT)
cpu/msp430_common: Fix linking with binutils 2.40 An `INSERT AFTER` directive no longer can refer to a different linker script included with `-T path/to/script.ld`. Instead, this adds wrapper linker scripts that just `INCLUDE` the three individual linker scripts. This way, the xfa.ld can safely refer back to sections defined in the vendor linker script. For some reason, this approach cause the exact issue it fixes for binutils 2.40 with the binutils in the CI. We stick with the old linker flags with binutils prior 2.40 to be compatible with both conflicting behaviors. The best approach would be to come up with something that works across different versions of binutils; but no such solution materialized.
2023-04-19 17:46:17 +02:00
LINKFLAGS += -Wl,--gc-sections
LINKFLAGS += -Wl,-L$(MSP430_SUPPORT_FILES)/include
cpu/msp430: reorganize code RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this: #ifndef UART_USE_USCI /* implementation of x1xx peripheral ... */ #else /* implementation of F2xx/G2xx peripheral ... */ #endif /* zero shared code between both variants */ This splits the peripheral drivers for USCI and USART serial IP blocks into separate files and relocates everything in cpu/msp430, similar to how cpu/stm32 is organized. [MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf [MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
2023-06-13 15:56:24 +02:00
LINKFLAGS += -Wl,-L$(RIOTCPU)/msp430/ldscripts
cpu/msp430_common: Fix linking with binutils 2.40 An `INSERT AFTER` directive no longer can refer to a different linker script included with `-T path/to/script.ld`. Instead, this adds wrapper linker scripts that just `INCLUDE` the three individual linker scripts. This way, the xfa.ld can safely refer back to sections defined in the vendor linker script. For some reason, this approach cause the exact issue it fixes for binutils 2.40 with the binutils in the CI. We stick with the old linker flags with binutils prior 2.40 to be compatible with both conflicting behaviors. The best approach would be to come up with something that works across different versions of binutils; but no such solution materialized.
2023-04-19 17:46:17 +02:00
ifeq (1,$(NEEDS_NEW_LINKER_SCRIPT))
LINKFLAGS += -T riot-$(CPU_MODEL).ld
else
LINKFLAGS += -T $(MSP430_SUPPORT_FILES)/include/$(CPU_MODEL).ld
cpu/msp430: reorganize code RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this: #ifndef UART_USE_USCI /* implementation of x1xx peripheral ... */ #else /* implementation of F2xx/G2xx peripheral ... */ #endif /* zero shared code between both variants */ This splits the peripheral drivers for USCI and USART serial IP blocks into separate files and relocates everything in cpu/msp430, similar to how cpu/stm32 is organized. [MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf [MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
2023-06-13 15:56:24 +02:00
LINKFLAGS += -T $(RIOTCPU)/msp430/ldscripts/msp430_common.ld
cpu/msp430: make use of vendor header files The MSP430 vendor files already provide macros containing register constants and symbols (provided via linker scripts) containing addresses of peripheral registers. So lets make use of that rather than maintaining a long list of constants.
2023-06-14 16:18:15 +02:00
LINKFLAGS += -T $(RIOTCPU)/msp430/ldscripts/$(CPU_FAM).ld
cpu/msp430: reorganize code RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this: #ifndef UART_USE_USCI /* implementation of x1xx peripheral ... */ #else /* implementation of F2xx/G2xx peripheral ... */ #endif /* zero shared code between both variants */ This splits the peripheral drivers for USCI and USART serial IP blocks into separate files and relocates everything in cpu/msp430, similar to how cpu/stm32 is organized. [MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf [MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
2023-06-13 15:56:24 +02:00
LINKFLAGS += $(RIOTCPU)/msp430/ldscripts/xfa.ld
cpu/msp430_common: Fix linking with binutils 2.40 An `INSERT AFTER` directive no longer can refer to a different linker script included with `-T path/to/script.ld`. Instead, this adds wrapper linker scripts that just `INCLUDE` the three individual linker scripts. This way, the xfa.ld can safely refer back to sections defined in the vendor linker script. For some reason, this approach cause the exact issue it fixes for binutils 2.40 with the binutils in the CI. We stick with the old linker flags with binutils prior 2.40 to be compatible with both conflicting behaviors. The best approach would be to come up with something that works across different versions of binutils; but no such solution materialized.
2023-04-19 17:46:17 +02:00
endif
cpu/arch: blacklist incompatible CFLAGS Blacklist incompatible CFLAGS that are currently "optionally" included in 'cflags.inc.mk'. This prepares for the migration to 'OPTIONAL_CFLAGS'.
2019-08-28 19:43:17 +02:00
OPTIONAL_CFLAGS_BLACKLIST += -fdiagnostics-color
OPTIONAL_CFLAGS_BLACKLIST += -Wformat-overflow
OPTIONAL_CFLAGS_BLACKLIST += -Wformat-truncation
toolchain/cflags: enable dwarf compression. Use the -gz option to compress ELF sections containing DWARF information. This saves around 50% of disk space, without any side effects. See https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Debugging-Options.html#Debugging-Options for more infomation on this option. Some platforms have an outdated toolchain that does not support -gz so the flag is blacklisted there. Even then, the results are quite impressive. I used @cladmi's `buildtest` branch (https://github.com/cladmi/RIOT/tree/wip/du/buildtest) with this change and compiled the `examples/default` application: ``` $ BUILD_IN_DOCKER=1 DOCKER="sudo docker" make -C examples/default buildtest-indocker ``` The size was obtained with: ``` $ find output -name "*.bin.bindirsize" -type f -exec tail -n1 '{}' \; | cut -f 1 | awk '{s+=$1} END {printf "%.0f", s}' ``` Results: - Vanilla: 10328112 KB (~10GB). - with -gz: 4982788 KB (~5GB). This was inspired by #8496.
2019-08-28 18:40:38 +02:00
OPTIONAL_CFLAGS_BLACKLIST += -gz
Copy Permalink