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, 5 insertions, 2 deletions

diff --git a/wirish/rules.mk b/wirish/rules.mk
index 6aa0904..1bf6245 100644
--- a/wirish/rules.mk
+++ b/wirish/rules.mk
@@ -12,8 +12,9 @@ WIRISH_INCLUDES := -I$(d) -I$(d)/comm -I$(d)/boards
 CFLAGS_$(d) := $(WIRISH_INCLUDES) $(LIBMAPLE_INCLUDES)
 
 # Local rules and targets
-cSRCS_$(d) :=  
 
+sSRCS_$(d) := start.S
+cSRCS_$(d) := start_c.c
 cppSRCS_$(d) := wirish_math.cpp		 \
                 Print.cpp		 \
 		boards.cpp               \
@@ -34,10 +35,12 @@ cppSRCS_$(d) := wirish_math.cpp		 \
 		ext_interrupts.cpp	 \
 		wirish_digital.cpp
 
+sFILES_$(d)   := $(sSRCS_$(d):%=$(d)/%)
 cFILES_$(d)   := $(cSRCS_$(d):%=$(d)/%)
 cppFILES_$(d) := $(cppSRCS_$(d):%=$(d)/%)
 
-OBJS_$(d)     := $(cFILES_$(d):%.c=$(BUILD_PATH)/%.o) \
+OBJS_$(d)     := $(sFILES_$(d):%.S=$(BUILD_PATH)/%.o) \
+                 $(cFILES_$(d):%.c=$(BUILD_PATH)/%.o) \
                  $(cppFILES_$(d):%.cpp=$(BUILD_PATH)/%.o)
 DEPS_$(d)     := $(OBJS_$(d):%.o=%.d)