cc2538: Move SoC data to a dedicated section to save space

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 <benoit.thebaudeau@advansee.com>

cpu/cc2538/cc2538.lds

@@ -64,6 +64,11 @@ SECTIONS
         _etext = .;
     } > FLASH= 0
 
+    .socdata (NOLOAD) :
+    {
+        *(.udma_channel_control_table)
+    } > SRAM
+
     .data :
     {
         _data = .;

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()