In case of MCU with multiple firmware slots support, change of active
slot requires reset. This obviously results in MCU entering the serial
recovery mode in bootloader, with 5 sec timeout, which in case of UART
based MCUs isn't automatically detected and handled in the same way as
USB based devices (hotplug).
Starting host side support script when the MCU is waiting for MCUmgr
commands during recovery is wrong. This fixes the problem by requesting
UART based MCU to boot the firmware after active slot change followed by
reset. While at it, change also how single slot type MCUs are handled
during upgrade (always request reset after the upgrade).
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
This includes shell script for host side support of the 'hci_uart' MCU
firmware type. The script calls 'btattach' with matching tty interface
and baud rate as arguments, resulting in new Bluetooth HCI controller
registration in the system. Both UART and USB interfaces are supported.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
This adds support for executing a host side support script per firmware
type (in our case, full MCU firmware name is a combination of two terms:
'version__type', e.g. 'zephyr-v3.3.x__hci_uart') which currently runs on
the MCU. Additionally, support for calling the init script with 'stop'
argument is included.
The host side support scripts will be placed in '/etc/mcu.d/' and should
have executable flag set and be named after the firmware type, with 'sh'
extension (e.g. 'hci_uart.sh'). This solution assumes also that PID of a
running, related service will be stored in '/var/run/mcu.SN.pid' where
'SN' is the associated MCU serial number.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
In case of some of the MCU firmware types, additional setup on the host
side is required before the target application can be used. Example of
such a requirement is a BLE HCI controller on UART bus (firmware type:
'hci_uart') which, before can be registered in system, needs to be
attached to Bluetooth stack (with e.g. 'btattach').
This includes code for generating hidden packages under 'mcu-firmware'
with all the files required for host side support (stored in directory
with the same name as firmware type, under local 'files' directory),
for a selected MCU firmware. For example, below tree:
./feeds/mcu/mcu-firmware/files/hci_uart/etc/...
would result in creation of new package 'zephyr-hci_uart-host-support',
included in dependencies lists for all MCU firmware versions of the
'hci_uart' type, with everything from '.../files/hci_uart/'.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
This reduces amount of helper functions and fixes also global variables
handle inside 'mcu.sh' and 'mcu.hotplug' shell scripts. While at it,
provide additional debug information when fetching images list and
system information.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
This includes simple upgrade (downgrade) capability in the MCU support
package. If hash of firmware installed on the MCU doesn't match the one
available on host's local file system, it will get upgraded.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
Copy 'bluez' package from OpenWrt's packages master branch to 'ucentral'
feed so that we can use latest version and add custom, local changes.
Keep this within 'ucentral' feeds directory to override version provided
by community based 'packages' feed from OpenWrt 21.02.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
54453a6 cmd_script: custom scripts with no uri failed to send the stdout to the server
Fixes: WIFI-12358
Signed-off-by: John Crispin <john@phrozen.org>
In case of some types of MCU firmware, additional tools, daemons, kernel
drivers, etc. are required on the host side. For example, for Bluetooth
HCI controller, at least kernel module and BlueZ should be included.
This adds a simple recipe which generates dependencies list per firmware
type/name and for existing 'hci_usb' and 'hci_uart', selects 3 packages:
'bluez-daemon', 'kmod-bluetooth' and 'kmod-crypto-user'.
Kernel crypto interface in user space has to be also included because
the BlueZ isn't able to create static address for LE-only controller
without it, which results in no registration of new BT interface:
bluetoothd[668]: src/adapter.c:get_static_addr() Failed to open crypto
bluetoothd[668]: No Bluetooth address for index 0
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
This includes default configuration for the on-board Nordic nRF52833 MCU
in CIG WF-196. A Zephyr based sample 'hci_uart' firmware is selected.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
Include Zephyr v3.3.x based Bluetooth LE HCI UART firmware package in
default packages list for the CIG WF-196. This brings initial support
for the on-board nRF52833 MCU.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
This includes default configuration for the on-board Nordic nRF52840 MCU
in EdgeCore EAP102. A Zephyr based sample 'hci_usb' firmware is selected.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
Include Zephyr v3.3.x based Bluetooth LE HCI USB firmware package in
default packages list for the EdgeCore EAP102. This brings initial
support for the on-board nRF52840 MCU.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
This adds Zephyr firmware builds from custom git branch based on the
latest's upstream branch name 'main': 'main__mcu-on-wifi-boards'.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
