The TCPMSS target module for iptables was enabled in some kernel defconfigs but
not for all targets. It is used e.g. in default config of @bigmoby's WireGuard
Client add-on. Enable it globally in the HAOS kernel config to make sure it's
always present.
Fixes#3730
If data disk is adopted on Yellow using the mechanism added in #3686, it
contains RAUC version information that is very likely invalid. In such case,
remove the file on first boot and have it recreated by the raucdb-update
service.
Hailo modules are usable also in other generic targets, so enable them also on
generic x86 and ARM targets. Runtime tested only on x86-64 (Beelink with Intel
N100).
The PCIe card from the RPi AI Kit (and probably other M.2 cards using the
Hailo-8 chip) can be used on Yellow - the driver initializes correctly and
creates a /dev/hailo0 device on Yellow both with CM4 and CM5.
* Add HA Yellow image to RPi Imager index update action
Update the action to also bump HA Yellow image added in
home-assistant/version#402.
* Sync image name with the current JSON PR
Instead of using in-tree module on RPi 5, build it as a module from the
original sources. This will give us better control over the version used and
will also allow us for easier way to add the module to other platforms.
This also makes 017d172 unnecessary anymore.
* buildroot c65b0306bb...b2077df873 (1):
> package/brcmfmac_sdio-firmware-rpi: bump version to 4c1789e
Raspberry Pi kernel 6.6 driver for BCM43455 (used in RPi 3B+/4B) calls new API
which uses the DUMP_OBSS feature for channel selection. If it's not preset, it
results in drivers reporting errors, e.g.:
brcmf_set_channel: set chanspec 0xd099 fail, reason -52
The RPi OS firmware was updated but the package we use for this firmware
contains an old version that lacks this support. Update to latest version
synced from RPi upstream to fix the issues. The root cause is explained in [1]
by @ragazenta. Both disabling the DUMP_OBSS and updating the firmware makes the
errors go away.
[1] https://github.com/raspberrypi/linux/issues/6049#issuecomment-2485431104Fixes#3367
With both RTCs enabled, the rpi_rtc is probed as the first one, making the
on-board RTC unused by default. Since the CM5's RTC peripheral can't be used on
Yellow, as the VBAT pin is not connected, disable it completely to fix RTC.
(cherry picked from commit 9d643edb54)
The I/O operations on the eMMC can sometimes fail and lock up completely, and
disabling CQE on the sdio1 (mmc0) interface seems to solve the issue. While it
is a known (and potentially resolved) issue [1] for SD cards in Raspberry Pi's
Linux fork, it is not acknowledged neither resolved for CM5's eMMC. With CQE
enabled, the device usually locks up within the first 10 first boots, when the
swap file is being created. After disabling CQE, no error occurred after more
that 100 cold boots (every time with swap file removed).
[1] https://github.com/raspberrypi/linuxissues/6349
(cherry picked from commit c514d6b482)
For yet unknown root cause, the eMMC interface sometimes fails to initialize
properly, delaying boot for up to 130 seconds. This can be reduced by ~100s by
disabling SD and SDIO modes on the sdio1 interface used for mmc0 before a
better patch is found.
(cherry picked from commit 489de0b2fb)
With both RTCs enabled, the rpi_rtc is probed as the first one, making the
on-board RTC unused by default. Since the CM5's RTC peripheral can't be used on
Yellow, as the VBAT pin is not connected, disable it completely to fix RTC.
The I/O operations on the eMMC can sometimes fail and lock up completely, and
disabling CQE on the sdio1 (mmc0) interface seems to solve the issue. While it
is a known (and potentially resolved) issue [1] for SD cards in Raspberry Pi's
Linux fork, it is not acknowledged neither resolved for CM5's eMMC. With CQE
enabled, the device usually locks up within the first 10 first boots, when the
swap file is being created. After disabling CQE, no error occurred after more
that 100 cold boots (every time with swap file removed).
[1] https://github.com/raspberrypi/linuxissues/6349
For yet unknown root cause, the eMMC interface sometimes fails to initialize
properly, delaying boot for up to 130 seconds. This can be reduced by ~100s by
disabling SD and SDIO modes on the sdio1 interface used for mmc0 before a
better patch is found.
Build cypress_m8 driver as module for all targets - some of them had it in
their base defconfig while some not. It is required e.g. for UPB PIM (Powerline
Interface Module).
Fixes#3690
(cherry picked from commit d57e507764)
Sync the DTS with changes added in newer commits merged after the initial
Yellow/CM5 DTS was written. The sdio1 node now has HS400 mode enabled and
sd_io_1v8_reg has been changed to regulator-fixed.
(cherry picked from commit b288cd212a)
If HAOS on Yellow is booted for the first time with NVMe data disk present, it
should be preferred over the empty eMMC data partition. This will ease
reinstall of the system and migration from CM4 to CM5. All other data disks
(e.g. if a USB drive is used for them) are still treated as before, requiring
manual adoption using the Supervisor repair.
(cherry picked from commit 98ac7f0170)
Build cypress_m8 driver as module for all targets - some of them had it in
their base defconfig while some not. It is required e.g. for UPB PIM (Powerline
Interface Module).
Fixes#3690
Sync the DTS with changes added in newer commits merged after the initial
Yellow/CM5 DTS was written. The sdio1 node now has HS400 mode enabled and
sd_io_1v8_reg has been changed to regulator-fixed.
If HAOS on Yellow is booted for the first time with NVMe data disk present, it
should be preferred over the empty eMMC data partition. This will ease
reinstall of the system and migration from CM4 to CM5. All other data disks
(e.g. if a USB drive is used for them) are still treated as before, requiring
manual adoption using the Supervisor repair.
Add Hailo-8 firmware binary for Rasperry Pi AI accelerators. The version needs
to be determined from the Git history of the kernel sources, as the driver
source code is included in the RPi downstream kernel and the version string
can't be found in the code directly.
Fixes#3663
* Add Makefile variable for Supervisor channel
Allow to set the release channel pre-installed Home Assistant components
like Supervisor and add-on are fetched from. This channel is then also
used at runtime.
* Use choice instead of string variable
* Fix channel in Supervisor updater.json config
* Add newlines
As stated in the docs [1], post-install hook is not executed if the slot
already has an install hook defined. Merge the post-install hook with the
install hook to fix CM5 migration for Yellow.
[1] https://rauc.readthedocs.io/en/latest/using.html#slot-hooks
