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.
Since
127c420335
change in package/systemd, this option is patched by systemd build because
userspace FW loading has never been supported with Systemd. This should have no
runtime effect, just clear the warning about disabled option.
Fix build job to write config option for channel switching from #4043 to the
actual config. As it was written to .config in the top-level build directory,
it was never correctly applied.
* 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] 2788cb549a
Update to latest binary of 43455 firmware and add missing symlinks which
suppress warnings/file not found errors when loading the firmware on CM5.
* buildroot 50fcf58bfa...62bf5c5af5 (2):
> package/brcmfmac_sdio-firmware-rpi: add CM5/Pi 500 symlinks to 43455 FW
> package/brcmfmac_sdio-firmware-rpi: bump version to 4eec7f2
* 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
Add input allowing to override the channel that's used for hassio image
downloads and in runtime for Supervisor updates, building on the option added
in #3618.
The new default is dev for dev builds, for GH releases keep using the stable
channel both for releases and pre-releases (so we could catch any stable issues
before beta is moved to stable).
To keep it DRY and idiomatic, create a new in-repo GH action for running
commands in the build container.
* Make usage of top-level make easier, drop 'all' target
Make it easier when using top-level make - proxy all possible commands to
Buildroot make and only wrap build for individual target builds. This way it's
still possible to run e.g. 'make ova' which would read the defconfig and run
the build, while we can also use the top-level make in the same way as it's in
vanilla Buildroot.
Target 'all' was dropped in favor of Buildroot 'make' without any arguments -
as it's fairly pointless to run all builds sequentially. With the current 19
targets it would take about a day even on a decent hardware and the build
artifacts would be lost in the process.
* Show warning only if BR2_DEFCONFIG changes
* Wait for 10s or input if defconfig differs
* Fall back to buildroot make in top-level make
To make running Buildroot commands easier, define .DEFAULT rule and fall back
to targets from Buildroot with necessary variables set. This makes
"savedefconfig" redundant as it's been simply passed to BR.
* Also implicitly fall back to 'clean' target
* Fix typo
* 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)
* Update Buildroot base to v2025.02
Packages updated:
* Added host-blake3 1.5.4
* Added host-go-src
* Added host-libxcrypt 4.4.38
* Added host-tar 1.35
* Added host-xxhash 0.8.3
* Added libtalloc 2.4.2
* Added libxcrypt 4.4.38
* apparmor updated from 3.1.2 to 3.1.7
* busybox updated from 1.36.1 to 1.37.0
* cifs-utils updated from 6.15 to 7.1
* containerd updated from 1.7.26 to 2.0.2
* dbus-broker updated from 35 to 36
* dropbear updated from 2024.85 to 2024.86
* e2fsprogs updated from 1.47.0 to 1.47.2
* expat updated from 2.6.4 to 2.7.0
* gcc-final updated from 12.4.0 to 13.3.0
* glibc updated from 2.38-81-gc8cb4d2b86ece572793e31a3422ea29e88d77df5 to 2.41-5-gcb7f20653724029be89224ed3a35d627cc5b4163
* gptfdisk updated from 1.0.9 to 1.0.10
* host-binutils updated from 2.40 to 2.43.1
* host-ccache updated from 4.8.2 to 4.10.2
* host-cmake updated from 3.28.3 to 3.31.5
* host-dtc updated from 1.7.0 to 1.7.2
* host-e2fsprogs updated from 1.47.0 to 1.47.2
* host-elfutils updated from 0.189 to 0.192
* host-expat updated from 2.6.4 to 2.7.0
* host-fakeroot updated from 1.32.1 to 1.36
* host-gawk updated from 5.3.0 to 5.3.1
* host-gcc-final updated from 12.4.0 to 13.3.0
* host-gcc-initial updated from 12.4.0 to 13.3.0
* host-genimage updated from 17 to 18
* host-go updated from 1.22.12 to unknown
* host-gptfdisk updated from 1.0.9 to 1.0.10
* host-kmod updated from 31 to 33
* host-libcap updated from 2.69 to 2.73
* host-libffi updated from 3.4.4 to 3.4.6
* host-libglib2 updated from 2.76.1 to 2.82.5
* host-libopenssl updated from 3.2.4 to 3.4.1
* host-libtirpc updated from 1.3.4 to 1.3.6
* host-libxml2 updated from 2.12.9 to 2.13.6
* host-lz4 updated from 1.9.4 to 1.10.0
* host-lzip updated from 1.23 to 1.25
* host-meson updated from 1.3.1 to 1.7.0
* host-mpc updated from 1.2.1 to 1.3.1
* host-mtools updated from 4.0.43 to 4.0.47
* host-nfs-utils updated from 2.6.4 to 2.8.2
* host-pcre2 updated from 10.42 to 10.44
* host-pkgconf updated from 1.6.3 to 2.3.0
* host-python3 updated from 3.11.11 to 3.12.9
* host-python-flit-core updated from 3.9.0 to 3.10.1
* host-python-jinja2 updated from 3.1.2 to 3.1.5
* host-python-markupsafe updated from 2.1.3 to 3.0.2
* host-python-packaging updated from 23.2 to 24.2
* host-python-pypa-build updated from 1.0.3 to 1.2.2
* host-python-pyproject-hooks updated from 1.0.0 to 1.2.0
* host-python-setuptools updated from 69.0.3 to 75.8.0
* host-python-wheel updated from 0.40.0 to 0.45.1
* host-rauc updated from 1.11.3 to 1.13
* host-sqlite updated from 3.44.2 to 3.48.0
* host-systemd updated from 254.13 to 256.7
* host-util-linux updated from 2.39.3 to 2.40.2
* host-xz updated from 5.4.5 to 5.6.4
* host-zstd updated from 1.5.5 to 1.5.7
* iproute2 updated from 6.7.0 to 6.13.0
* iptables updated from 1.8.9 to 1.8.11
* json-c updated from 0.17 to 0.18
* kmod updated from 31 to 33
* libapparmor updated from 3.1.2 to 3.1.7
* libblockdev updated from 3.1.1 to 3.3.0
* libbytesize updated from 2.7 to 2.10
* libcap-ng updated from 0.8.4 to 0.8.5
* libcap updated from 2.69 to 2.73
* libdnet updated from 1.16.4 to 1.18.0
* libffi updated from 3.4.4 to 3.4.6
* libglib2 updated from 2.76.1 to 2.82.5
* libgudev updated from 237 to 238
* libmicrohttpd updated from 0.9.77 to 1.0.1
* libnftnl updated from 1.2.6 to 1.2.7
* libnl updated from 3.9.0 to 3.11.0
* libnvme updated from 1.7.1 to 1.11.1
* libopenssl updated from 3.2.4 to 3.4.1
* libtirpc updated from 1.3.4 to 1.3.6
* libunistring updated from 1.1 to 1.3
* libusb updated from 1.0.26 to 1.0.27
* lvm2 updated from 2.03.14 to 2.03.27
* nettle updated from 3.9.1 to 3.10.1
* network-manager updated from 1.44.2 to 1.50.2
* nfs-utils updated from 2.6.4 to 2.8.2
* pcre2 updated from 10.42 to 10.44
* procps-ng updated from 4.0.4 to 4.0.5
* rauc updated from 1.11.3 to 1.13
* rpcbind updated from 1.2.6 to 1.2.7
* rtl8821cu updated from 1597dfeda6cefd2e603fc7020ceca226d05fb108 to 96c65c58b544241178638e810b333dcc9aa26b91
* sqlite updated from 3.44.2 to 3.48.0
* systemd updated from 254.13 to 256.7
* util-linux-libs updated from 2.39.3 to 2.40.2
* util-linux updated from 2.39.3 to 2.40.2
* wireless-regdb updated from 2023.09.01 to 2024.10.07
* wpa_supplicant updated from 2.10 to 2.11
* patches/genimage: drop upstreamed patches
* patches/systemd: drop merged patch
* patches/network-manager: drop upstreamed patch
* Add BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_* to defconfigs
As the reported MemTotal can fluctuate a bit on some systems, e.g. because the
reserved memory changes between kernel version or other factors affect it like
VRAM, the swap file can be recreated unnecessarily between boots. Allow for
some fluctuation (up to +-32MB) before the swapfile is recreated.
This was a problem already before the recent haos-swapfile changes, however,
before it checked if the existing swapfile isn't smaller than the desired
value. If the MemTotal fluctuated there, the swapfile size eventually settled
on the highest value seen and it wasn't recreated anymore. With this change,
things should be stable even more.
As pointed out in [1] by @cdce8p, the RTL8125D has an internal PHY that also
needs some changes to be backported.
Also, move the patches to more targeted directories is it would be otherwise
applied to RPi 6.6 kernel with failures. We can move it back to the top-level
patches directory once RPi moves to kernel 6.12.
[1] https://github.com/home-assistant/operating-system/issues/3880#issuecomment-2790105503
As we enabled SI/CIK support to fix crashes on bunch of AMD SoCs in #3957, the
amdgpu driver still crashes on some hardware. It seems to be some GX-217GA SoCs
or even GX-425GA in Fujitsu thin clients (even though the same SoC is fine on
T620).
To get to the state before update to kernel 6.12, disable amdgpu for these
platforms again (as it couldn't work properly there before OS 15.0) and just
backport the patch that fixes the crashes during probing when the driver isn't
compiled with SI/CIK support.
Fixes#4012
* Backport RTL8125D (rev C, XID 688) support
Apply mainline patch adding support for NIC present e.g. on ASUS NUC 14
Essential.
Fixes#3880
* Update buildroot to add RTL8125D firmware
* buildroot 4cd211162d...5379c358bf (1):
> linux-firmware: add RTL8125D firmware
When there's a problem with connectivity, it may result in obscure errors later
in the testing. Add checks testing three scenarions:
* connectivity in host - both using curl and nmcli
* connectivity in Supervisor container (uses docker0 as default via)
* connectivity in CLI container (uses hassio as default via)
Also make sure that Supervisor upgrade isn't attempted when the version
information is missing.
To avoid necroposting to old issues that's usually left unnoticed, add workflow
for locking issues similar to the one that Core has.
The PR locking limit can be increased as the traffic is much lower compared to
Core. Issues before 2025 have been locked manually via the API.
Update of OpenSSL in OS 12.2 from 1.1.1 to 3.2 changed the output of `openssl
sha256` command. It seems that some hypervisors don't like this and fail if
it's not plain "SHA256".
Fixes#3654
Update Docker and its dependencies to versions packaged in last bugfix release.
* buildroot 3914f8cad5...4cd211162d (4):
> package/runc: bump version to v1.2.6
> package/docker-cli: bump version to v28.0.4
> package/docker-engine: bump version to v28.0.4
> package/containerd: bump version to v1.7.26
Firmware change that set initial_turbo to 60 from the previous 0 has broken
initialization of some SD cards in U-Boot. Adjust the value in config.txt on OS
update if the value is not already set by the user, and put it to the default
config.txt.
The config.txt also contains a short comment explaining the purpose. The
purpose of it is also to make it easier to revert this change in the future if
the problem is fixed in the firmware or U-Boot.
Fixes#3965
One of the reason for failures after update to OS 15.0 was missing support for
the kernel PIO driver in EEPROM firmware. Backport upstream patches from
raspberrypi/linux#6645 and raspberrypi/linux#6642 that handle this situation
more gracefully. These patches could be dropped after the next RPi kernel
release.
Refs #3943
