| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The core issue is that JSON_TOK_STRING as last argument to
JSON_OBJ_DESCR_PRIM issues the SEGFAULT.
Using JSON_TOK_NUMBER instead is the minimal change to avoid the
SEGFAULT temporarily. Obviously this leads to nonsense output since the
string is printed out as number.
|
|
This was caused by a body_len set to 0 because of changed semantics in
the return value of settings_to_json().
|
|
TODO: Only JSON numbers seem to be encodable. Strings lead to SEGFAULT
TODO: For some reason the encoded string is not part of the HTTP
response.
|
|
TODO: SEGFAULT in json_escape_internal (grrrrr)
|
|
|
|
|
|
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.
|
|
This adds the HTTP PUT /update handler which just returns HTTP 204 No
Content.
This is the minimal first step towards a working /update handler.
|
|
This allows to use all MCUboot related functionality during the
development via the shell. Furthermore it allows to inspect the current
state of the primary and secondary slot.
Both traits are very valuable especially during the development of the
remote update system.
|
|
Because of an issue likely related to hardware design on the
nucleo_f767zi board (see issue [1] for details) the firmware should
reboot in case network access cannot be established after 4 seconds.
This makes the firmware more robust at the moment. As soon as
iot-contact hardware without this issue exists the behavior can be
changed again.
[1]: https://github.com/zephyrproject-rtos/zephyr/issues/77794
|
|
This made the `menuconfig` target disappear. Since the application has a
quite complex configuration compared to the bootloader it is embedded to
the primary CMake project while the bootloader stays an external
project.
|
|
This allows to keep the serial port open for a longer time and use the
nucleo.sh script only for signing and flashing.
|
|
This makes it faster and build can be easily executed by adding
`-DBOARD=nucleo_f767zi` to the CMake call.
|
|
This adopts this pattern from the bootloader build. It adds more
flexibility. It is assumed that in this way multiple builds for
different boards can easily be achieved.
|
|
This moves the definition of ZEPHYR_MODULES and ZEPHYR_BASE to this rtos
folder where it fits best.
|
|
This key is only relevant for firmware. Thus it should be set in the
CMakeLists.txt file of the `fw` folder.
|
|
This submodule is called `hal_stm32` upstream. Thus the submodule
directory should here be called exactly the same to reduce confusion
compared to `stm32`.
|
|
The mcuboot Git submodule used to be located in `fw/btl`. Nevertheless
since it is also a Zephyr module it should go to `fw/rtos/modules`. This
makes sure all Zephyr modules are at the same place.
|
|
Previously a folder `build/fw/bootloader` was used in addition. This
change removes this and puts everything bootloader-related in
`build/fw/btl` to make this consistent to `build/fw/app`.
|
|
This was not explicitly set to the kernel located at `fw/rtos/zephyr`.
Thus depending on the environment other kernel checkout might be picked
like `~/zephyrproject/zephyr`.
This was not notices so far since there the exact same checkout was
used.
|
|
This makes the structure of the `fw` folder more clear and separates
application-related code from bootloader- or rtos-related code.
|
|
Handling this in the nucleo.sh script was never necessary.
|
|
This reduces nesting and makes the directory structure simpler.
|
