Fix compiling error due to wrong name of updated uboot for turris1x

Martin Pecka authored 5 months ago and Michal Hrusecky committed 5 months ago

Changed the names of 5G kit tty and net devices to be deterministic and
unique.

In case when U-Boot is already updated, but router went through factory
reset, it might not be set where to look for U-Boot environment. To be
sure, let's make configuring it part of the init script.

Shouldn't be needed as we update rescue only with U-Boot but just in
case let's keep all three options there.

To be on the safe side, use slower speed when updating from prehistoric
U-Boot.

Marek Behun authored 8 months ago and Michal Hrusecky committed 7 months ago

* The `--upgrade` option will now work even if MCU is in bootloader (for
  example if previous upgrade was aborted).

* On boards with GD32 MCUs, `omnia-mcutool` will now refuse to upgrade
  application firmware to version lower than 4.1 if bootloader version
  is `2.0` (the original for first batch of boards with GD32 MCUs)
  since these versions of application and bootloader are not compatible.

  If user already upgraded to such a combination, an upgrade of
  bootloader firmware is required.

  The `--upgrade` option will inform about this and will automatically
  upgrade bootloader firmware if the `--force` option is given.

  (Note that version 4.1 of the MCU firmware was will be released soon,
   once it is properly tested.)

* Various other improvements.

Marek Behun authored 8 months ago and Michal Hrusecky committed 7 months ago

Bump `omnia-mcu-firmware` to version 4.1.

This version fixes the following issue on boards with GD32 MCU:
* the user has old GD32 MCU bootloader and application (version 2.0)
* the user upgraded MCU application firmware to newer version (from
  2.99 to 4.0)
* the user wants to upgrade application again, but it is impossible,
  because when MCU application firmware jumps into the old MCU
  bootloader firmware (2.0), the old bootloader firmware gets stuck in
  exception
* the user has to restart the board and upgrade the bootloader firmware
  first, which is not ideal, since if bootloader firmware upgrade is
  interrupted, the board gets bricked

Therefore the `omnia-mcutool` utility version 0.3-rc3 will refuse to
upgrade MCU application firmware to versions 2.99 to 4.0 if the MCU
bootloader firmware is at version 2.0.

For users to be able to upgrade MCU application firmware on GD32
boards, they will need this new 4.1 version.

Users that already upgraded the MCU application firmware to a version
between 2.99 and 4.0 (using a previous version of the `omnia-mcutool`
utility) have no other choice but to upgrade MCU bootloader firmware as
well.

Marek Behun authored 8 months ago and Richard Muzik committed 8 months ago

Bump `omnia-mcu-firmware` to version 4.1.

This version fixes the following issue on boards with GD32 MCU:
* the user has old GD32 MCU bootloader and application (version 2.0)
* the user upgraded MCU application firmware to newer version (from
  2.99 to 4.0)
* the user wants to upgrade application again, but it is impossible,
  because when MCU application firmware jumps into the old MCU
  bootloader firmware (2.0), the old bootloader firmware gets stuck in
  exception
* the user has to restart the board and upgrade the bootloader firmware
  first, which is not ideal, since if bootloader firmware upgrade is
  interrupted, the board gets bricked

Therefore the `omnia-mcutool` utility version 0.3-rc3 will refuse to
upgrade MCU application firmware to versions 2.99 to 4.0 if the MCU
bootloader firmware is at version 2.0.

For users to be able to upgrade MCU application firmware on GD32
boards, they will need this new 4.1 version.

Users that already upgraded the MCU application firmware to a version
between 2.99 and 4.0 (using a previous version of the `omnia-mcutool`
utility) have no other choice but to upgrade MCU bootloader firmware as
well.

Marek Behun authored 8 months ago and Richard Muzik committed 8 months ago

* The `--upgrade` option will now work even if MCU is in bootloader (for
  example if previous upgrade was aborted).

* On boards with GD32 MCUs, `omnia-mcutool` will now refuse to upgrade
  application firmware to version lower than 4.1 if bootloader version
  is `2.0` (the original for first batch of boards with GD32 MCUs)
  since these versions of application and bootloader are not compatible.

  If user already upgraded to such a combination, an upgrade of
  bootloader firmware is required.

  The `--upgrade` option will inform about this and will automatically
  upgrade bootloader firmware if the `--force` option is given.

  (Note that version 4.1 of the MCU firmware was will be released soon,
   once it is properly tested.)

* Various other improvements.

The behaviour of binutils changed, causing this package to fail to
build. The new version adds support for this.

Marek Behun authored 11 months ago and Michal Hrusecky committed 11 months ago

Fixes the "too many operands" error in the sign subcommand.

Marek Behun authored 1 year ago and Michal Hrusecky committed 1 year ago

Version 0.5 adds support for cryptography provided by omnia-mcutool.
Newer Omnia boards do not have Atsha chip, instead cryptography and
board information is provided by the MCU.

Marek Behun authored 1 year ago and Michal Hrusecky committed 1 year ago

The dependency on underlying driver (libatsha204, mox-otp) is about to
get more complicated and the PROVIDES mechanism won't be enough.

Changing mtdblock to mtd, to usage of unnecessary mtdblock layer

Make sure that we have configuration file for fw_printenv before
actually trying to dump the U-Boot configuration.

As we are installing packages manually without updater, we need to track
dependencies manually.

Filip Hron authored 1 year ago and Michal Hrusecky committed 1 year ago

Adjust server.username and server.groupname on reForis-only devices
(like Turris Shield) to run lighttpd under proper user.

Signed-off-by: Filip Hron <filip.hron@nic.cz>

The correct encryption is psk2+ccmp

This is related to the upstream change in U-boot repository [1]

[1] https://source.denx.de/u-boot/u-boot/-/commit/87ac4b4b4ca5f00e2ddcdac41c9dc691ab2aecf1

Include in system the overrides that make SDIO Wi-Fi card work again.

Michal Hrusecky authored 2 years ago and Michal Vasilek committed 2 years ago

For some reason procd library that gets preloaded breaks the rainbow.
Disable it for now to make things work again and maybe we will
investigate later.

Fixes: 8052af35 ("rainbow: update to
0.1.3")

* use subpackages for backends
* refresh patches
* add dependencies on kmods