- _rom_start_addr, _ram_start_addr, _rom_length and _ran_length are
already defined in cortexm_common/Makefile.included and can therefore
be removed from kinetis/Makefile.include
- _ram_base_addr is never used and was not in commit history so
is also removed
- To be able to flash at an offset the vector table must be
relocated accordingly to the IMAGE_OFFSET, therefore linkage
needs to take the offset into account.
The toolchain variables were overwritten anyway in
`makefiles/toolchain/gnu|llvm.inc.mk` as they use `=` affectation,
except for `OBJCOPY`.
On my Linux ubuntu bionic machine, the only difference for `info-build`
with both gnu/llvm and also with LTO=1
is that it now uses an absolute path for `objcopy`
-OBJCOPY: objcopy
+OBJCOPY: /usr/bin/objcopy
On the OSX 17.7.0 I tested, there was no difference.
When using BUILD_IN_DOCKER only make 'all' execute 'mcuboot' target when
inside the container. Otherwise it will execute it using your host
toolchain.
This is a hack and could be prevented by having a file target put in
FLASHFILE.
This does currently not allow flashing after building in docker as
flashing should be done with `mcuboot-flash` which will not be done in
docker. It would require the `FLASHFILE` fix to be done properly.
The example in the tool documentation contains several things that are
wrong:
- exports PORT.
- Defines the port using :=.
- Defines PORT instead of PORT_LINUX, PORT_DARWIN
- ifeq-based logic (which will force an evaluation).
I have not tested the new example script.
This variable is only used for the term recipe (and maybe for flashing). They
should not be evaluated if they are not needed and the user should not see a
warning that the port is not set if he does not use port (for example in make
all.)
PORT_LINUX and PORT_DARWIN are evaluated by
`makefiles/tools/serial.inc.mk` and some boards Makefile.include.
Their value does not need to be exported.
This also globally removes the line saying that the exports are needed
for flash rule.
Rational: the periph_common module is required by (most) other periph drivers
and also during startup of the CPU/MCU to run periph_init. The latter is only
required if other periph drivers are used, hence periph_common should be a
depency of periph_* modules and *not* of the CPU/MCU. This PR fixes that
by making periph_common a depency of periph_* and removing the explicit
include in the CPU/MCU implementation.
