Use the official rkbin repository for Rockchip binaries. Use the
binaries from an older git hash which provide the very same binaries
(by hash). This makes sure we use the same DDR version as currently used
by the Hardkernel in their SPI flash bootloader (DDR v1.09).
* Including the RTW8821ce driver module to support Wifi on the KAMRUI AK1 PRO micro PC. It is a low-cost Intel Celeron N5105 that I think should work well for Home Assistant. However, it does not use Intel radios, it needs Realtek drivers.
* also need the firmware for the rtl8821ce
* Use hosted GitHub Action runners
Instead of using self-hosted runners use the hosted GitHub Action
runners. Officially the GitHub Action runners have a maximum of 14GB
free space available. However, a single Home Assistant OS build requires
up to 23GB (the ova board seems to require most because of the various
output image formats).
This PR adds some tricks to make use of the GitHub hosted GitHub Action
runners still, namely:
- Build and download cache is stored on /mnt which offers an additional
10GB of disk space
- Some tools/SDKs on the runner get removed from the root disk to free
up some disk space.
Other than that building on the hosted GitHub Action runners seems
straight forward. The build time is significantly longer (from ~30
minutes on the current AMD Ryzen 7950X build machine to 1 hours 30
minutes even with cache). But since we can build all boards in parallel
now, the overall build time will likely be shorted.
* Remove top-level release directory
The top-level release directory adds another copy of the images. This is
unnecessary for our release process now. Save the additional space and
time requirement. It comes with a slight downside for developers, but
also helps to save disk space on dev machines.
The chosen GitHub action sets MIME types correctly and allows glob
uploads. Also upload directly from the output directory. This way we can
remove the unnecessary copy to the release directory in the future.
Add patches for the hardware random number generator part of the
Rockchip RK3568. This avoids dbus-broker startup failure seen on some
Hardkernel ODROID-M1 devices due to lack of entropy.
On some platforms (it seems to be pronounced on Intel NUC systems)
Bluetooth advertisements suddenly stop after a short while. Currently
there are work arounds in place to restart the HCI controller to keep
receiving the advertisements.
Advertisements have been received fine with Linux 5.15. This change
reverts a commit which has been isolated to be the culprit.
In case a system takes a bit longer to boot (e.g. due to SWAP
initialization on first boot, especially on a system with lots of memory
and not very fast strage, e.g. an ODROID-M1 using an SD card) we might
time-out waiting for time synchronization before the time
synchronization service even got started. By ordering the
systemd-time-wait-sync.service after the network is online, the timeout
of this service should be started much later. With that the
systemd-time-wait-sync.service shouldn't timeout any longer.
To read the current LED configuration correctly /mnt/boot is required.
This change makes sure that the boot partition is mounted when the OS
Agent starts.
Many x86_64 tablets (e.g. Cherry View) use SDIO WiFi modules, this
enables the driver for a common one I've come across in the wild.
This module requires firmware from the following, which are already
enabled for this platform:
- BR2_PACKAGE_LINUX_FIRMWARE_RTL_87XX
- BR2_PACKAGE_LINUX_FIRMWARE_RTL_87XX_BT
fixes#2422
* Yellow: Always use mini-UART for Bluetooth
Unfortunately, the mini-UART device tree adjusts the alias for serial1,
which we need to make ttyAMA1 the Zigbee UART (UART4).
However, we can no simply adjust that overlay, as the overlays are not
built as part of the Buildroot build. Instead, they are directly copied
from Raspberry Pi's Firmware repostiory.
Instead of using device tree overlays, just apply the changes to our
Yellow specific device tree. To avoid that the device tree gets loaded
anyhow, we could adjust config.txt but that has complications on its
own. Since the overlay might be conflicting with the Yellow device tree
anyways, just remove all of them.
Note: The miniuart-bt.dtbo overlay won't be present, while config.txt
of upgraded instances still reference it. It seems that this doesn't
cause problems at boot time. Leaving the dtoverlay=miniuart-bt present
also allows user to downgrade in case needed.
* Avoid duplicating 98-rpi.conf
