Preemptively enable larger set of WiFi drivers for all platforms and add more firmwares for them with the aim to harmonize WiFi device support among all boards and to have implicit support of devices that users might want to use. Targets `generic_aarch64`, `generic_x86_64` and `ova` also include options and firmwares for cards that are using PCI/PCIe bus - support for these is in a separate config fragment.
Especially the `generic_x86_64` is currently very tight with the rootfs space, so I had to do some triaging and select only sensible drivers and firmwares - especially archaic PCMCIA devices or devices not supporting only 802.11g or lower standards were among the first that I removed during the triaging - we can consider enabling those but this time on an someone's explicit need to have them enabled.
This closes#2815 and replaces large part of #2761, also potentially addresses (at least) these: #2806, #2783, #2841, #2776, #2725, #2600
-------------
* Remove WiFi options from generic and board kernel config fragments
* Enable MMC in OVA kernel
This is needed for SDIO drivers to work. Use the same options as we
currently use for generic_x86_64.
* Add CRYPTO_MICHAEL_MIC to the common kernel config
This is requirement for TKIP and is a dependency of ATH11K driver.
* Add kernel config fragments with wireless cards support
* Add firmwares for WiFi cards
* Enable more Bluetooth device drivers
* Remove kernel HCI driver if no WiFi/Bluetooth module present (#2944)
If the WiFi/Bluetooth module is not present on the SDIO bus, remove the
HCI driver. This avoids hci0 interface to be present. Current Home
Assistant Core versions show a Bluetooth device as soon as a hci device
is present. With this change there won't be a Bluetooth device shown.
* Update buildroot-external/package/pi-bluetooth/hcidisable.service
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Do not start hciuart.service if krnbt is used
Avoid starting (and failing to start) hciuart.service if krnbt is used.
This avoid unnecessary failed services showing up.
* Update buildroot-external/package/pi-bluetooth/hciuart.service
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Drop duplicate bluetooth in path
* Avoid bthelper@hci0.service failing
* Revert "Avoid bthelper@hci0.service failing"
This reverts commit f79777e63ec83ab45f27fbecb2da8b0c97992c64.
* Add ExecConditiono to bthelper@.service as well
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Remove kernel HCI driver if no WiFi/Bluetooth module present (#2944)
If the WiFi/Bluetooth module is not present on the SDIO bus, remove the
HCI driver. This avoids hci0 interface to be present. Current Home
Assistant Core versions show a Bluetooth device as soon as a hci device
is present. With this change there won't be a Bluetooth device shown.
* Update buildroot-external/package/pi-bluetooth/hcidisable.service
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Do not start hciuart.service if krnbt is used
Avoid starting (and failing to start) hciuart.service if krnbt is used.
This avoid unnecessary failed services showing up.
* Update buildroot-external/package/pi-bluetooth/hciuart.service
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Drop duplicate bluetooth in path
* Avoid bthelper@hci0.service failing
* Revert "Avoid bthelper@hci0.service failing"
This reverts commit f79777e63ec83ab45f27fbecb2da8b0c97992c64.
* Add ExecConditiono to bthelper@.service as well
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Generate self-signed certificates for development
To simplify development generate a self-signed certificate on first
build. Also make sure that the self-signed certificate is being added
the RAUC keyring so that manual updates can be performed.
* Add self-signed certificat independent of deployment type
* Add a warning when building with self-signed certificate
Bluetooth initialization was broken on Yellow because RPi's kernel
started to use initialization by the kernel driver by default, yet
changes from the miniuart-bt overlay are applied directly to Yellow
DTS and had to be updated too. This commit replaces the previous
patch forcing the miniUART usage for Bluetooth with a new one which
is based on the current miniuart-bt-overlay.dts.
Also added a little warning to the RPi kernel bump script, so the
future me/us don't do the same mistake as I did.
* buildroot 20ea6bedda...a48cc458e7 (1):
> package/rpi-firmware: bump to version for stable_20231030 kernel
Reduce fully-expanded configs versioned in our repository to defconfigs
containing only the necessary options. Just like #2923, this change does
not alter the resulting kernel .config in any way for the affected
platforms (Tinker, Odroid C2/C4/N2).
For tinker and amlogic-based targets we're using checked-in kernel
configs generated by kconfig for some old kernel revisions. Check in
current config before we clean it up and reduce to a smaller stub later.
Clean up all kernel configs and fragments from non-existing kernel
options, invalid choice values and choices that trigger warnings
during kernel package configuration.
Here's an example of warnings triggered for Yellow:
.config:8531:warning: override: MODULE_COMPRESS_NONE changes choice state
.config:8536:warning: override: ZSWAP_COMPRESSOR_DEFAULT_LZ4 changes choice state
.config:8537:warning: override: ZSWAP_ZPOOL_DEFAULT_ZSMALLOC changes choice state
.config:8543:warning: override: CPU_FREQ_DEFAULT_GOV_ONDEMAND changes choice state
.config:8717:warning: override: reassigning to symbol CGROUP_HUGETLB
.config:8767:warning: symbol value 'm' invalid for XFRM
.config:8852:warning: symbol value 'm' invalid for MEDIA_CONTROLLER_DVB
.config:8972:warning: symbol value 'm' invalid for SND_HDA_I915
There were also some options that are set in our or default configs
but end up patched by `KCONFIG_(DIS|EN)ABLE_OPT` in package makefiles,
these options are now explicitly set in our fragments too. For example
this was toggled for `generic_aarch64`:
CONFIG_DEFAULT_SECURITY_APPARMOR n -> y
CONFIG_DEFAULT_SECURITY_DAC y -> n
CONFIG_GCC_PLUGINS y -> n
The only goal of this commit is to make sure no warnings appear
anymore and the resulting kernel configs remain unchanged. This will
allow us to create tools for sanity checks of our kernel config
overrides. There is one single change in `ova` config resulting from
previously invalid `m` option for a bool value:
-# CONFIG_9P_FS_POSIX_ACL is not set
+CONFIG_9P_FS_POSIX_ACL=y
* Use kernel local version for HAOS compiled Linux kernel
Use the local version config option to add "haos" to the system's Linux
kernel version to indicate the kernel is built specifically for Home
Assistant OS. This makes sure to overwrite any other local version (e.g.
provided by Raspberry Pi kernel's defconfig) and makes it easier to
verify something is running on HAOS since the string will be visible in
any Container using `uname -a`.
* Add dash in front
This reverts commit 49f26c3d2e685e3f7e9135f8e10efaa6a40526df.
The steps is not valid in that context. Let's revert the commit to get a
green build first.
* Add missing dependency to kernel.config
* Move CONFIG_IIO up to follow Kconfig hieararchy
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
* Improve handling of timeouts in tests
Make timeout handling in tests more transparent. Added a custom shell
driver that allows to define global timeout for commands in the config
file, and replaced for/sleep constructs with infinite loops that will be
eventually terminated by pytest-timeout plugin. Current timeouts taken
from last runs on Github CI with some extra headroom.
* test_supervisor_is_updated shouldn't be skipped if no update was needed
* Allow more time for system startup
* Allow even more time for system startup
* Separate artifacts index update into separate workflow
* Apply suggestions from code review
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
If a reusable workflow is called from another workflow, the event_type
in the child workflow is still the same as parent's. This is a known
"feature": https://github.com/actions/runner/discussions/1884
Add a flag to inputs that has default value set to true. This is in turn
set only if the workflow is called from another one, chosing the correct
step for obtaining the OS image.
* Add test suite for Supervisor tests
* test_supervisor_is_updated should depend on test_update_supervisor
Co-authored-by: Stefan Agner <stefan@agner.ch>
---------
Co-authored-by: Stefan Agner <stefan@agner.ch>
