| Age | Commit message (Collapse) | Author |
|---|
|
This partially reverts commit ce098756d79d8e4240bedc2bd74ff9a3a77fcedb.
The reverted commit dropped the build logic for all
nucleo_f767zi-related artifacts and thus for everything except the
native sim firmware.
Instead this commit reverts this change but comments out the
`update_image` and `factory_image` targets from the `artifacts` variable
in the top-level `meson.build`.
This allows to build these two targets explicitly with `ninja -C build
<target>` but does not include it into the deploy tar archive.
Since this archive is the only target of the project with
`build_by_default: true` this effectively disables the build with
minimal code changes.
|
|
The bootloader and application firmware resulting in the factory- and
update-image are removed from the build.
The reason is a planned first release of this project with hardware
design files for a first `iot-contact` board. The release is required to
build this board with matching version specifiers.
Since the release should contain a consistent set of hardware and
firmware the firmware targeting the development board is removed.
Handling firmware for multiple boards is also an option but has no use
since the biggest part of the firmware features can be developed using
the simulation only which should stay in long term.
|
|
This automatically creates `build/artifacts/factory-image.bin` with the
Meson build system. The resulting file can simply be moved to the
virtual file system of the `nucleo_f767zi` board to flash bootloader and
application making the board ready for operation and remote updates.
|
|
This was used since flashing was complex. Thus the build system should
help making it easier.
The new approach is more to provide artifacts by the build system which
are easy to flash / remote-update. A `factory-image.bin` and
`update-image.bin` should be provided.
|
|
These targets are added:
- fw/erase
- fw/app/flash
- fw/btl/flash
They make it easier to perform a mass-erase, flashing of the bootloader
and flashing of the application for development.
|
|
This adds a build for the native_sim board of the application firmware
to the default Meson build.
The resulting Linux binary is also added to the webpage.
|
|
|
|
CMake ExternalProject creates a pretty confusing build tree. Since the
rest of the project anyway starts moving to Meson the bootloader is
configured via Meson as a first step.
|
