| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Grégoire Passault <g.passault@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having separate linker scripts for all the boards is a bad idea. Most
boards really only need to specify MEMORY and the appropriate
REGION_ALIASES() so that support/ld/common.inc can do its work. Not
having infrastructure for this leads to duplication -- viz. the Maple
Mini linker scripts are identical to the Maple's, and the
olimex_stm32_h103 linker directory is just a symlink to
Maple's. Clearly, the current structure is wrong.
To fix it, instead of having per-board subdirectories of support/ld/,
add per-MEMORY subdirectories of (new) support/ld/stm32/mem/. The
per-board .mk files under support/mk/board-includes/ now reference
these directly, and target-config.mk and the Makefile handle this
appropriately. We move some other stuff around in target-config.mk to
make this all more convenient, and even allow more overriding of the
libmaple defaults on a per-board basis. Custom board hacks will be
easier now.
Unfortunately, lots of duplication under support/ld/stm32/mem/ is
necessary, as the LENGTH attribute in a MEMORY region specification
doesn't support arithmetic expressions, and ld doesn't seem to have
any way to specify MEMORY at the command line (why?!). If we find a
better way than this, we should do it.
If a board (e.g. Maple Native) _does_ really need special
memory-related configuration, you can always put a per-board
subdirectory of support/ld/stm32/mem. We do this here to configure the
heap.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The good news is that <libmaple/usb.h> and <libmaple/usb_cdcacm.h> did
turn out generic enough in what they specify to go on unchanged.
However, we can't just go on assuming that there's USB just because
we're on an F1. Now that there's value line in the tree, we need to be
more careful (value line F1s don't have USB peripherals). To that end,
make all the F1 board-includes/*.mk files specify what line their MCU
is with an MCU_F1_LINE variable. Use that to hack
libmaple/usb/rules.mk so we only try to build the USB module under
appropriate circumstances.
While we're at it, add a vector_symbols.inc for value line MCUs under
support/ld/. We need this to get the target-config.mk modifications
implied by the addition of MCU_F1_LINE. We'll fix up some other
performance-line-isms under libmaple/stm32f1 in a separate commit.
Also in libmaple/usb/:
- Move everything into a new stm32f1 directory. Due to aforementioned
rules.mk hacks, there is no immediate need for an stm32f2
directory (USB support doesn't exist there).
- Update the README for style and content.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
|
|
| |
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an MCU_SERIES variable to each of the files under
support/make/board-includes, which declares the series as "stm32f1" in
each case.
Use this in target-config.mk when determining LD_SERIES_PATH (with a
hack since we only support performance line) and
LIBMAPLE_MODULE_SERIES. We must move support/ld/stm32/series/f1 to
.../series/stm32f1 as a side-effect.
Adding support for other series (e.g. "stm32f2") should now be a
matter of filling in the contents of libmaple/<series>/ and
support/ld/stm32/<series>/ appropriately (along with moving the rest
of the nonportable code out of the libmaple core and into the STM32F1
series submodule).
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is for greater consistency with the ST application notes, which
refer to migrating "across" series (e.g. F1 to F2), but compatibility
"within" a family (e.g. F1).
So:
- Move libmaple/stm32x/include/family to .../include/series/ and fix
up includes appropriately.
- Refer to "family" headers as "series" headers in comments.
- Make similar "find and replace"-style changes to build system
variable names and comments.
- Move support/ld/stm32/family to .../stm32/series.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Move
support/ld/stm32/f1/performance/vector_symbols.inc
to
support/ld/stm32/family/f1/performance/vector_symbols.inc
Creating directory "family" under support/ld/stm32 will allow parallel
directories (e.g. support/ld/stm32/mcu) to exist, which allows an
eventual linker script cleanup to go much more smoothly.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're no longer even marginally compatible with CS3, so it's
inappropriate to use that prefix in our names.
Rename:
__cs3_stm32_vector_table -> __stm32_vector_table.
__cs3_stack -> __msp_init
__cs3_reset -> __exc_reset
__cs3_start_c -> start_c
Also add an MIT license header and assert LeafLabs copyright over
wirish/start.S and wirish/start_c.c. These files are modified from
the original CodeSourcery versions, which were distributed under a
license that permits modifications to be distributed under a different
copyright and licensing terms than the originals.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
|
|
- support/make/target-config.mk: add LD_FAMILY_PATH, the directory to
search for STM32 family-specific link configuration files. For now,
this is just a stub which points to support/ld/stm32/f1/performance,
since that's all we currently support. We can add the logic to
support different STM32 families here later.
- Makefile: Pass -L $(LD_FAMILY_PATH) to linker.
- Rename support/ld/names.inc to
support/ld/stm32/f1/performance/vector_symbols.inc.
- common.inc: INCLUDE vector_symbols.inc instead of names.inc.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
|
