| Age | Commit message (Collapse) | Author |
|---|
|
Sending router advertisements should be done by systemd-networkd in the
future.
|
|
This is a security measure better fulfilled with a firewall.
The problem is when it is restricted to the `zeth` interface it cannot
be reliably started while the firmware is not running, since the
interface is not up.
But when the MQTT broker is not available it is hard to start the
firmware in the current state because it requires a running MQTT broker.
This is a chicken-egg-problem solved with this commit.
|
|
This avoids warnings and sets the focus to the IP version which is the
current focus.
|
|
This is the first minimal step towards MQTT: Connecting to a broker.
Wireshark validates that there is actually MQTT data flow in both
directions.
|
|
This folder should explain how to setup the network environment for the
firmware simulation.
|
|
|
|
This script requires root privileges. It is annoying to always type a
password for it and in general to start this script to test the native
sim firmware.
Thus the new approach is to provide the network infrastructure with a
system-wide NetworkManager connection and the required servers (IPv6
router advertisement, MQTT, IPv4 DHCP in the future) with systemd
services constantly.
That way the full network environment for the simulation is always just
there for the `zeth` interface and the firmware executable can just be
started with user privileges.
|
|
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 will be moved later to the user documentation so that the native
sim build of the application firmware can easily be used on Linux
machines using NetworkManager.
|
|
Everything else is implicitly build by default since it should
contribute to the tar archive.
|
|
This presents only the `factory-image.bin` and `update-image.bin` for
MCU firmware. A separate bootloader image is not available.
The reason is that the `factory-image.bin` is used during production
once (flashing at default boot address) to set up the device. Later only
the `update-image.bin` of future versions would be required to remotely
update devices.
|
|
|
|
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 prepares the upcoming `factory-image.bin` which can be flashed to
the default boot address of the microcontroller.
|
|
Using the installation step to copy selected artifacts into one folder
was anyway a hack.
This commit shows that the complexity can be reduced by adding copy
targets. The `build/artifacts` folder contains the selected artifacts,
they are always up to date, the user does not have to call the install
step separately and the target definitions do not require
install-related keyword arguments.
|
|
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.
|
|
This reverts commit 184a41809c66868992c90ce9d420b8e4dc46253b.
The change worked well for the `native_sim` board. Nevertheless the
application firmware for the real microcontroller was not usable at all
anymore.
This regression is fixed by simply reverting the commit. Later it could
be introduced only for the `native_sim` board with an overlay.
|
|
This disables compiler optimization and allows easier debugging.
|
|
|
|
|
|
|
|
|
|
|
|
From now on the mixed format with IP and port is not supported. The
settings system should keep them separate and first only the IP is
configurable.
Supporting this Kconfig option too is annoying and not necessary.
|
|
The old format contained `[<ip>]:<port>`. Nevertheless the format should
be as strict as possible. Thus only the IP is used in the setting.
|
|
|
|
|
|
|
|
This got lost during development but is an important option to
compensate the hardware issues present on Nucleo F767ZI.
|
|
This enables simple.css also for the device-hosted website and
restructures the HTML a bit.
|
|
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.
|
|
A static site generator is currently not really required. A static
index.html is currently sufficient.
|
|
Meson now handles this. CMake is only used as Meson external project to
build Zephyr firmwares.
|
|
|
|
Because of the Meson build system the application firmware is signed
automatically. Furthermore all artifacts required to flash the Nucleo
board are deployed to the website. Thus this script is not necessary
anymore.
|
|
This automates signing the application firmware image for the MCUboot
bootloader.
|
|
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.
|
|
|
|
This makes them re-usable for the application and native_sim firmwares.
|
|
|
|
This allows to re-use these scripts. Since they are currently used to
build Zephyr builds and three are intended (application, bootloader and
application as native_sim build) this makes sense.
|
|
Meson makes this relatively easy. The current approach is nevertheless a
bit hacky. For the first attempt it is still way better than CMake
ExternalProject.
|
|
|
|
To use a more readable scripting language and keep portability the POSIX
shell script for Zephyr configuration is replaced by Python.
|
|
|
|
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.
|
|
To reduce the number of Kconfig options the network hack was added two
both boards - the native_sim and nucleo_f767zi one. It reboots the
device if the network connection cannot be established since this is a
known bug of the nucleo board.
Nevertheless it seems that for the native_sim board this command is not
defined. Since it is a Linux application this makes somehow sense.
This commit introduces the boolean Kconfig option
`IOT_CONTACT_NETWORK_HACK` which is only enabled for the nucleo board
fixing the native_sim build.
|
|
This adds marking the application firmware image in the secondary slot
for a permanent update and rebooting the device.
It is a known bug that the corresponding HTTP request is never properly
closed since the device reboots while handling the request.
Nevertheless the current state works and enables remote updates.
|
|
This write the received firmware image data to the secondary MCUboot
slot. This prepares an update.
With the MCUboot shell it can be applied with:
mcuboot request_upgrade permanent
kernel reboot
If the signature is valid the device will permanently update to the new
application firmware. Otherwise it will refuse the new image and boot
the old one.
|
|
This implements a HTTP handler capable of receiving the full data of the
firmware image upload. The data is not handled at all and thus not
written to flash.
This is just an incremental step towards successful firmware image
upload to the secondary MCUboot slot.
|
