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.
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.
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
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
The timeout of 90s was introduced before it was ensured that the timesync
systemd unit starts after network is online. Now with that, it makes less sense
to wait that long - if network is unreachable at the point the time
synchronization starts, and the server fails to reply on the first sync, the
polling interval is exponentially increased and the benefit of waiting for more
attempts is doubtful.
Since another synchronization attempt is done after network changes its state,
we should rely on that instead of having the 90 seconds interval as a waiting
period for plugging the network cable. Worst case, there are other mechanisms
that should set the time to a reasonably accurate value, making the NTP sync
less importart for most of the cases.
* Move RPi U-Boot patches to version-specific directory
We will need to use different series for 2024.10 which would be used as the
base for CM5 support.
* Remove common.h include from the fileenv cmd
It doesn't seem to be used and common.h has been removed in newer U-Boot.
* Use U-Boot 2024.10 with BCM2712 PCIe patches for Yellow
Use rebased patchset from v2024.01 with the first patch removed. Add patches
needed for PCIe initialization and use rpi_arm64_defconfig as the base config
for both CM4 and CM5.
* Add device tree for CM5 on HA Yellow and adjust config
Add device tree definition based on the CM5 device tree with BCM2712D0 changes
applied, and add nodes required for the on-board peripherals of Yellow.
Currently the difference in serial numbering still requires either changes in
this device tree, or userspace changes to create correct symlinks to make HA
configuration directly compatible with CM4 on Yellow.
* Add config.txt migration for conditional device_tree options
* Fix typos and minor issues found by CodeRabbit
* RaspberryPi: Update kernel to 6.6.51 - stable_20241008
* Update rpi-firmware to version for kernel 6.6.51
* buildroot 2ffac68a74...19027bc796 (1):
> package/rpi-firmware: bump to version 1.20241008 for kernel 6.6.51
