Build of pam_lastlog.so was disabled by updating to v1.5.3 [1] yet the line
wasn't removed from the login modules. In upstream this was resolved by adding
a config option for turning the lastlog module and dynamic disabling of the
line including it. These changes neither a fix removing the config line were
not applied to 2024.02, so cherry-pick them here to fix the issue.
* buildroot ff563b383d...3784884466 (2):
> package/linux-pam: adjust login pam file for lastlog
> package/linux-pam: add menuconfig option to build pam_lastlog.so
Fixes#3789
[1] https://github.com/linux-pam/linux-pam/releases/tag/v1.5.3
(cherry picked from commit af7b36e1007981ccd04c75d60ee24e487d836a04)
* Enable USB-SD convertor on AMD/Xilinx Kria KD240 platform
Kria KD240 board is using SD card but SD is connected via onboard USB HUB.
USB controller is DWC3 with Xilinx glue logic. Both of these options are
enabled but board is using slg7xl45106 for driving usb-hub reset (PCA9570
driver) and USB3.0 requires initialization via PHY_XILINX_ZYNQMP driver.
All options should be enabled (=y) and can't be kernel modules because
provide access to rootfs.
* Add a note for config symbol change in 6.12
Changed in mainline commit 31e7f6c015d9eb35e77ae9868801c53ab0ff19ac
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
(cherry picked from commit 64ee53579b32fae80f02d15b88d1ef4016abc2c0)
* buildroot 00e8f09356...ff563b383d (1):
> Merge tag '2024.02.10' into 2024.02.x-haos
(cherry picked from commit a7cdebf03217c7d6b44ff64ab2aa93a7a7fc0237)
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
