The /etc/usb_modeswitch.d is present and empty but it can't be written to allow
user modification. Bind-mount it like other /etc folders to make it possible to
adjust usb_modeswitch config.
Fixes#3785
Zynq GPIO driver is used on AMD/Xilinx Kria platform for ETH phy reset.
Macb and PHY drivers are already enabled.
1 wire IP can be used for reading sensors via PMOD connector.
Similarly to #3705, enabled CQE triggers I/O freezes usually on the first boot
when the swapfile is being created. While we disabled it for Yellow, with #3782
the issue started to appear on generic CM5 targets with the rpi5-64 image.
In the meantime it was discovered that there seems to be some relation with the
ext4lazyinit task, which happens as a result of data partition resize, yet it's
still unclear if the pattern of the access triggered by the concurrent FS
initialization is somehow responsible, or if another factor comes in play.
Disabling CQE yet makes the issue go away and serves as an acceptable
workaround.
RPi 5 images container only device tree for Pi 5 Model B. Add the other
remaining BCM2712 device trees to enable running on CM5 and other variants
supported upstream.
Fixes#3766
With "cgroup: Use kernel command line to disable memory cgroup" merged to RPi
kernel as 86099de [1], the device tree now contains "cgroup_disable=memory"
parameter. The parameters are parsed in the order defined in the cmdline and
with the previous order, the memory CG ends up disabled. Switching the order
fixes that and makes the order similar to what we get with standard bootloader
and parameters in cmdline.txt only.
The possible downside is that it won't be possible to override parameters from
hardcoded bootargs_hassos using cmdline.txt anymore, however, it's unlikely any
of these parameters will need to be adjusted by users.
Fixes#3765
[1] 86099deff5
The z3fold allocator was deprecated with the reasoning explained in [1] and
this patch was backported to stable 6.6.y as well. We enable zsmalloc in shared
hassos.config and the enabled option in the Tinker config was probably just
some remnant from the past.
[1] https://lore.kernel.org/linux-mm/20240904233343.933462-1-yosryahmed@google.com/
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 9d643edb54d25be404b1cc92b64f1eddf48e6a86)
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 c514d6b4825e4d72a0f3bfac26a5d3a203390e08)
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 489de0b2fb06aa6477c2c4ad34d4b9440e5a21ae)
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 d57e50776499f209e013efa0db6cb3c7f46f51c3)
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 b288cd212ae82d78de707009d61265d9d950497c)
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 98ac7f017089f28d7f231eed1a51533dfa62a475)
