From e1147ec787b177b1126d4984676804a443a8f295 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Beno=C3=AEt=20Th=C3=A9baudeau?= Date: Fri, 13 Dec 2013 17:06:48 +0100 Subject: [PATCH 1/4] cc2538: Set the type of the .nrdata output section to NOLOAD MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The .nrdata section is volatile, so its initialization must be controlled by the application, and not be automatically done by the startup code. It should neither be zeroed like .bss, nor be initialized from data in flash memory like .data. This was already supposed to be the case, but the output section type of .nrdata was not set to NOLOAD, causing the generated ELF .nrdata section header to be of type PROGBITS instead of NOBITS, i.e. load data was generated to be programmed in RAM, thus producing huge unprogrammable .bin files. Signed-off-by: Benoît Thébaudeau --- cpu/cc2538/cc2538.lds | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpu/cc2538/cc2538.lds b/cpu/cc2538/cc2538.lds index 635ec454b..df4fa2784 100644 --- a/cpu/cc2538/cc2538.lds +++ b/cpu/cc2538/cc2538.lds @@ -86,7 +86,7 @@ SECTIONS } > SRAM #if (LPM_CONF_MAX_PM==2) && (LPM_CONF_ENABLE != 0) - .nrdata : + .nrdata (NOLOAD) : { _nrdata = .; *(.nrdata*) From ab4b955f172cc14870a3f91f995d07e36cea533a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Beno=C3=AEt=20Th=C3=A9baudeau?= Date: Thu, 19 Dec 2013 21:11:04 +0100 Subject: [PATCH 2/4] cc2538: Sort link input sections by alignment to optimize size MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Normally, the linker does not sort files and sections matched by wildcards, so they are placed in the order in which they are seen during link. If numerous objects with different alignments are mixed, or if objects with unusually large alignments are present, this very likely leads to a lot of space being wasted because of accumulated alignment gaps. This commit forces input sections to be sorted by alignment (unless this is overridden by the linker script), which decreases the number and the size of alignment gaps, thus saving space. For a typical Contiki project, this change saves nearly 1 kiB, mainly in .bss. Note that this behavior is only enabled if the SMALL make variable is set to 1, because this makes more sense for a size optimization. Signed-off-by: Benoît Thébaudeau --- cpu/cc2538/Makefile.cc2538 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpu/cc2538/Makefile.cc2538 b/cpu/cc2538/Makefile.cc2538 index 103e177fc..537036034 100644 --- a/cpu/cc2538/Makefile.cc2538 +++ b/cpu/cc2538/Makefile.cc2538 @@ -21,7 +21,7 @@ OBJCOPY_FLAGS += -O binary --gap-fill 0xff ### Are we building with code size optimisations? ifeq ($(SMALL),1) CFLAGS += -ffunction-sections -fdata-sections - LDFLAGS += -Wl,--gc-sections + LDFLAGS += -Wl,--gc-sections,--sort-section=alignment endif ### If the user-specified a Node ID, pass a define From 37e73894f1308cb39953a76cca34e1c06fa05519 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Beno=C3=AEt=20Th=C3=A9baudeau?= Date: Thu, 19 Dec 2013 21:30:35 +0100 Subject: [PATCH 3/4] cc2538: Move SoC data to a dedicated section to save space MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Some SoC data requires huge alignments. E.g., the µDMA channel control table has to be 1024-byte aligned. This table was simply aligned to 1024 bytes in the C code, which had the following consequences, wasting a lot of RAM: - As this table could be placed anywhere in .bss, there could be an alignment gap of up to 1023 bytes between the preceding data and this table. - The size of this table was also aligned to 1024 bytes, regardless of UDMA_CONF_MAX_CHANNEL, making this configuration option supposed to save RAM just useless. - .bss was also aligned to at least 1024 bytes, creating a huge alignment gap between .data and .bss. Instead of relying on the compiler to force this alignment, and on the linker to automatically place data, this change places carefully such SoC data in RAM using the linker script. A dedicated section is created to place such SoC data requiring huge alignments, and it is put at the beginning of the SRAM in order to ensure a maximal alignment without any gap. In this way, the alignment of .bss also remains normal, and the size of this table is not constrained by its alignment, but only by its contents (i.e. by UDMA_CONF_MAX_CHANNEL). In the case of the µDMA channel control table, the data is still zeroed by udma_init() (instead of also being zeroed as part of .bss). Signed-off-by: Benoît Thébaudeau --- cpu/cc2538/cc2538.lds | 5 +++++ cpu/cc2538/dev/udma.c | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/cpu/cc2538/cc2538.lds b/cpu/cc2538/cc2538.lds index df4fa2784..fd09ee9b7 100644 --- a/cpu/cc2538/cc2538.lds +++ b/cpu/cc2538/cc2538.lds @@ -64,6 +64,11 @@ SECTIONS _etext = .; } > FLASH= 0 + .socdata (NOLOAD) : + { + *(.udma_channel_control_table) + } > SRAM + .data : { _data = .; diff --git a/cpu/cc2538/dev/udma.c b/cpu/cc2538/dev/udma.c index af30b1436..c285d1b11 100644 --- a/cpu/cc2538/dev/udma.c +++ b/cpu/cc2538/dev/udma.c @@ -51,7 +51,7 @@ struct channel_ctrl { }; static volatile struct channel_ctrl channel_config[UDMA_CONF_MAX_CHANNEL + 1] - __attribute__ ((aligned(1024))); + __attribute__ ((section(".udma_channel_control_table"))); /*---------------------------------------------------------------------------*/ void udma_init() From fe4eb545c0b213537eef754c6adc836a5e5bdaea Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Beno=C3=AEt=20Th=C3=A9baudeau?= Date: Thu, 19 Dec 2013 21:53:03 +0100 Subject: [PATCH 4/4] cc2538: Remove the unused vtable section MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Benoît Thébaudeau --- cpu/cc2538/cc2538.lds | 1 - 1 file changed, 1 deletion(-) diff --git a/cpu/cc2538/cc2538.lds b/cpu/cc2538/cc2538.lds index fd09ee9b7..71115fbe3 100644 --- a/cpu/cc2538/cc2538.lds +++ b/cpu/cc2538/cc2538.lds @@ -72,7 +72,6 @@ SECTIONS .data : { _data = .; - *(vtable) *(.data*) _edata = .; } > SRAM AT > FLASH