Remove CS3-style initialization.

Remove libcs3-related bits from support/ld. Break them out into
libmaple proper and Wirish as appropriate: vector table definition and
ISR declarations go into libmaple proper, and startup code goes into
Wirish. Vector table symbols are included into common.inc from an
STM32 family-specific directory under support/ld/stm32.

This is a combination of 5 commits. Individual commit messages follow:

libcs3_stm32_src: Don't depend on cs3.h.

So we can use the existing toolchain.

Move ISR decls/vector table into libmaple proper.

This allows us to configure the vector table on a per-family basis.

- Move
        support/ld/libcs3_stm32_src/stm32_isrs.S
                                    stm32_vector_table.S
  to
        libmaple/stm32f1/isrs_performance.S
                         vector_table_performance.S,
  respectively.

  The directory libmaple/stm32f1/ is intended to hold all
  STM32F1-specific code within libmaple. Obviously, there's a lot of
  work to do before this becomes true.

- support/ld/libcs3_stm32_src/Makefile: Don't try to compile
  stm32_isrs.S and stm32_vector_table.S anymore.

- Add libmaple/stm32f1/rules.mk to include these new files in the
  standard libmaple build.

- support/make/target-config.mk: Add LIBMAPLE_MODULE_FAMILY, which
  selects a directory to use as a family-specific libmaple
  submodule.

- Makefile: Add LIBMAPLE_MODULE_FAMILY to LIBMAPLE_MODULES.

Remove support/ld/libcs3_stm32_src and derived object files.

From support/ld/libcs3_stm32_src, move start.S and start_c.c into
Wirish. Modify wirish/rules.mk accordingly.

Delete support/ld/libcs3_stm32_*_density.a. These are no longer
necessary, as the relevant objects are included in the standard Wirish
build. Remove the GROUP statements from the board linker scripts
accordingly.

Remove SEARCH_DIR(.) from common.inc; it's no longer necessary. Also
fix up some comments that are now out of date.

wirish/start_c.c: Don't use CS3-style memory initialization.

Switch memory initialization to a simpler style of initializing .data
if necessary, then zeroing .bss. Initializing .data is only necessary
during Flash builds, since during RAM builds, LOADADDR(.data) ==
ADDR(.data).

This makes libmaple completely incompatible with the CS3 startup
sequence. Subsequent commits will clean up the namespace to reflect
that fact.

Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>

1 files changed, 0 insertions, 35 deletions

diff --git a/support/ld/libcs3_stm32_src/Makefile b/support/ld/libcs3_stm32_src/Makefile
deleted file mode 100644
index 834cdad..0000000
--- a/support/ld/libcs3_stm32_src/Makefile
+++ /dev/null
@@ -1,35 +0,0 @@
-# setup environment
-
-TARGET_ARCH = -mcpu=cortex-m3 -mthumb
-
-CC = arm-none-eabi-gcc
-CFLAGS =
-
-AS = $(CC) -x assembler-with-cpp -c $(TARGET_ARCH)
-ASFLAGS =
-
-AR = arm-none-eabi-ar
-ARFLAGS = cr
-
-LIB_OBJS = stm32_vector_table.o stm32_isrs.o start.o start_c.o
-
-help:
-	@echo "Targets:"
-	@echo "\t medium-density: Target medium density chips (e.g. Maple)"
-	@echo "\t high-density: Target high density chips (e.g. Maple-native)"
-
-.PHONY: help medium high
-
-medium-density: $(LIB_OBJS)
-	$(AR) $(ARFLAGS) libcs3_stm32_med_density.a $(LIB_OBJS)
-	rm -f $(LIB_OBJS)
-
-high-density: CFLAGS := -DSTM32_HIGH_DENSITY
-high-density: $(LIB_OBJS)
-	$(AR) $(ARFLAGS) libcs3_stm32_high_density.a $(LIB_OBJS)
-	rm -f $(LIB_OBJS)
-
-# clean
-.PHONY: clean
-clean:
-	-rm -f $(LIB_OBJS) *.a