When follow request for logs is issued that points to/beyond the end of logs, a
busy loop in systemd-journal-gatewayd can be triggered which manifests as
systemd-journal-gatewayd consuming 100% CPU. Since threads are used for each
request, the logs may still work but the CPU will be hogged until the restart
of systemd-journal-gatewayd, Supervisor, or the whole system.
Backport the patch submitted upstream that addresses this issue.
Fixes#4190
As there is VirtualBox available for aarch64 on Apple Macs, provide OS images
also in the native VirtualBox format, which also grants the ability to resize
existing disk images, unlike VMDK.
Fixes#4171 & fixes#4172
Enable option for the netfilter NETMAP target, as it can be useful for some
users. Until now it's been enabled only for some targets as an option coming
from upstream defconfigs; make sure it's available for all targets.
Fixes#4183
The ip6tables configuration is now enabled by default since Docker 27
(see https://github.com/moby/moby/pull/47747). The experimental config
got introduced with the ip6tables flag in #2051. There is no other
experimental feature used from what I am aware of, so lets remove the
experimental flag as well.
Unbind the Bluetooth driver for Broadcom HCI module before the bluetooth
service starts if running on board without WiFi module. This is a replacement
for #2948 but using a more targeted approach for removing the particular driver
and better detection of no-WiFi (thus no-Bluetooth) models.
This still means the driver will be probed and couple of lines printed when it
fails to set baudrate and reset the module, yet this should be benign, at least
the all-zero MAC device no longers appears in Bluetooth stack.
Backport patch for traces appearing since v4.21.0 bump, introduced in #4095.
This change is not available in any newer tagged release of the driver and the
commit message upstream is messed up, hence the reworded patch.
Make sure that all LAN drivers used on Raspberry Pi boards are built-in.
Although they are defined as such in the base defconfig, we change them to
modules in device support includes. For simplicity and keeping kernel config
close to the RPi OS config, change them all to built-in in the main RPi include
for all RPi targets.
This is not only a formal change - at least one regression is known if the PHY
driver on RPi 5 is not built-in and MAC driver is - in that case the PHY hooked
up to the RP1 isn't initialized properly, and it is reported as "Generic PHY"
instead, e.g. breaking the control of LEDs through dtparams. Relevant dmesg log
before the change:
macb 1f00100000.ethernet end0: PHY [1f00100000.ethernet-ffffffff:01] driver [Generic PHY] (irq=POLL)
And after the change:
macb 1f00100000.ethernet eth0: PHY [1f00100000.ethernet-ffffffff:01] driver [Broadcom BCM54213PE] (irq=POLL)
Fixes#3333
Bind-mount Systemd Journal socket to the Supervisor container. This way
Supervisor can use the socket directly for writing log entries using the
Systemd native Journal protocol [1] instead of logging to stderr of the
container.
[1] https://systemd.io/JOURNAL_NATIVE_PROTOCOL/
This reverts commit eab18076ad.
This change was added in #2948 as a workaround for all-zero adapter appearing
in the HA frontend (#2944). With changes implemented in [1], this is no longer
needed, the only minor issue is that the ghost adapter still appears in
hciconfig (and other utilities') output as reported in [2]. However, this
should be less problematic than the Bluetooth being unavailable if WiFi is
disabled through disable-wifi DT overlay, so let's start with removing the
workaround.
Fixes#2975
[1] https://github.com/Bluetooth-Devices/bluetooth-adapters/pull/105
[2] https://github.com/raspberrypi/linux/issues/5756
When following logs in Home Assitant frontend, the last line may be duplicated
over time when no new lines are added. This is because systemd-journal-gatewayd
incorrectly processed the num_skip part of the Range header, always returning
the last entry even when it should have been skipped.
Backport the patch for Systemd that processes the header correctly.
Fixes#4101
* Bump buildroot to update package/pigz
* Enable parallel gzip for faster Docker pulls
Docker checks if unpigz is available, and if so uses it to unpack
container layers with multiple CPU cores. This should make Docker pulls
faster, especially on lower end hardware.
Since update to Systemd v256.x the Range header requires the num_entries part
and fails if it's not provided, which we worked around by [1]. With this patch
that was already accepted upstream, the workaround shouldn't be necessary
anymore.
[1] https://github.com/home-assistant/supervisor/pull/5827
Add driver for Marvell PHYs, such as 88E1543(4L) on an ASRock C3758D4I-4L
board. Adding it to x86 config only, as it seems it's not widely used anywhere
else.
Fixes#4025
Bump Hailo stuff to the latest version. While this is a breaking change for
add-ons depending on the driver, the most commonly used one (i.e. Frigate)
didn't bump to v4.20.1 on their stable channel either, so it shouldn't have
significant impact. We agreed with @blakeblackshear that once HAOS bumps the
Hailo driver in HAOS 16, Frigate will follow.
Backport /boots endpoint for Systemd so we can use it in Supervisor to get the
actual list of boots. Should be available upstream since Systemd v258, for v256
minor tweaks were needed.
When creating OVA image, the CPU is slacking at the end of the build because it
is creating three ZIP archives, each one on a single CPU only. As we're
creating only single-entry archives, we can use pigz to use all cores.
The actual speedup on my machine (16C/32T) reflects the number of cores - it
takes around 2 seconds instead of 1 minute.
* package/vcgencmd: add tool for RPi VideoCore commands
This tool is used by rpi-eeprom-update and is fairly lightweight binary without
dependencies. Use it as-is from raspberry/utils repo.
* package/rpi-eeprom: change package to install EEPROM userspace scripts
* configs: enable rpi-eeprom for rpi4, rpi4-64, rpi5-64 and yellow
On Pi5 and Yellow also enable flashrom so the firmware can be installed
directly without recovery being involved. On Yellow/CM4 this can't be done
without config.txt changes though (SPI and pinmuxing needs to be enabled) but
the image is shared there and users may eventually use the tools if they want,
so install BCM2711 on Yellow too. The "officially recommended" method is
rpiboot though, which is also documented in Yellow docs.
Because we use custom compatible strings in Yellow DTS's, the firmware loader
first attempts to load a firmware with this compatible in its name. Because it
doesn't exists, it shows error like this one before falling back to a more
generic one:
brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,5-compute-module-ha-yellow.bin failed with error -2
While these errors are mostly harmless, add symlinks with our compatible in the
name to suppress them. Instead of patching upstream
package/brcmfmac_sdio-firmware-rpi which installs the firmware files, add them
to yellow overlay to make maintenance easier.
Latest RPi firmware package contains module options that supposedly improve
stability, with details described in [1].
Since the feature_disable mask also disables the dump_obss feature, this change
would also mitigate `brcmf_set_channel: set chanspec ... fail` messages still
seen in some environments even after #3719.
Fixes#3367
[1] https://github.com/RPi-Distro/firmware-nonfree/commit/2788cb549a19bf2e77901c4071ef88c2ad683b7c
* Fix U-Boot config to access all RAM on 16 GB CM5
U-Boot defconfig used for Yellow checks only 4 DRAM banks, however, CM5 with 16
GB has the memory spread across 8 banks. Add a patch (submitted upstream) to
the defconfig to get access to the whole RAM.
Fixes#3989
* Add Upstream tag with link to uboot patchwork
* Update RPi kernel to 6.12.20
Update to latest stable RPi kernel and remove unnecessary 6.6.y kernel config
fragments.
* Refresh RPi and Yellow patches
Rebase all patches on 6.12.20, remove patches that are already present
upstream.
* Update Yellow device trees for 6.12.20
Upstream changes broke our downstream device trees. While the CM4 fix was
trivial, there were more changes in the CM5 device tree due to adaptation to
upstream code. To simplify future maintenance, DTS was refactored to reuse CM5
DTS include and override only what's necessary.
* Bump buildroot to update to matching package/rpi-firmware
* buildroot ead21eb6d2...cd82256125 (1):
> package/rpi-firmware: bump version to f49a396 (1.20250326)