The BCM2711 has two USB 2.0 IPs: A Broadcom XHCI USB 2.0 controller and
a Synopsys DWC2 USB 2.0 Host/Device controller. When USB boot is used
the former is active. Make sure the driver has the correct device tree
compatible.
We only have a single U-Boot version currently, so there is no value in
storing the patch file in a version specific directory. This makes sure
U-Boot 2021.10 final release also has fileenv support.
* Add NVMe and XHCI USB driver fix for Raspberry Pi
Add patch which fixes NVMe read reliability and allows to compile the
XHCI USB driver (for Compute Module 4).
* Enable Broadcom XHCI driver for Compute Module 4
The BCM2711 has two USB 2.0 IPs: A Broadcom XHCI USB 2.0 controller and
a Synopsys DWC2 USB 2.0 Host/Device controller. When USB boot is used
the former is active. Make sure U-Boot has the driver built-in for that
IP.
* Remove duplicate config.txt copy statement
* Use static cmdline.txt file
Instead of dynamically creating cmdline.txt use a static version of it.
This aligns with other boot loader/firmware configuration files and makes
it easier to customize the file per board.
Support optional board specific default RPi firmware configuration file
(config.txt). Also rename from boot-env.txt to config.txt since this
file is not read by the U-Boot boot loader but the Raspberry Pi specific
boot firmware.
* Use skopeo to download container images
Separate container download from image build. This will allow to share
the downloaded images between multiple builds.
We won't store the Supervisor container with the version tag, just with
the latest tag. This allows to simplify the procedure a bit. It seems
there is no downside to this approach.
* Use official Docker in Docker images to build data partition
Instead of building our own Debian based image let's use the official
Docker in Docker image. This avoids building an image for the hassio
data partition and speeds up build as well.
This calls mount commands using sudo to mount the data partition as part
of the buildroot build now. This is not much different from before as
mount has been called as root inside the container, essentially equates
to the same "isolation" level.
* Use image digest as part of the file name
The landing page has no version information in the tag. To avoid
potentially source caching issues, use the digest as part of the file
name.
CONFIG_BT_HCIBTUSB selects CONFIG_BT_INTEL. That causes CONFIG_BT_INTEL
to be built-in instead of being built as a kernel module.
When the driver is built-in, loading firmware fails during early boot
with the following error message:
[ 1.058941] bluetooth hci0: Direct firmware load for intel/ibt-17-16-1.sfi failed with error -2
Make sure the driver is built as a module which should fix firmware
loading.
* Add U-Boot patches for NVMe boot support
Add NVMe to boot order. Fix NVMe support on 64-bit Raspberry Pi devices.
This is useful for Raspberry Pi Compute Module 4 IO Board where a native
NVMe can be plugged in.
* Enable NVMe support for Raspberry Pi 4
Our machine configuration rpi4 and rpi4_64 work on the Compute Module IO
Board. In this configuration a NVMe SSD can be used. Therefor, enable
support for NVMe in the Raspberry Pi 4 configurations.
Note: Regular Raspberry Pi devices will not notice a difference as the
"nvme scan" command will return very quickly and not find a NVMe on the
PCIe bus.
* Use built-in NVMe support in Kernel for NVMe boot support
The bump to U-Boot 2021.10-rc5 also makes quite some patches obsolete
since they are already part of U-Boot.
This also removes a patch which disables framebuffer support on
Raspberry Pi: Framebuffer support seems to work fine in todays
U-Boot/Linux combination. It can help debug boot problems on Raspberry
Pi devices. Without the patch framebuffer support will be enabled by
default.
Some USB devices cause the USB stack to get stuck with a stall error.
This adds a patch which recovers from this situation.
This avoids an U-Boot crash when Arduino Mega R3 devices are connected,
which cause an USB stall when trying to read the product string.
When a USB keyboard is connected to Raspberry Pi 32-bit versions of
U-Boot crashed in certain situations just before booting Linux. This
seems to be cause by a buffer overflow when removing the USB keyboard
before hand-over to Linux.
Add buildroot utils/check-package check to the pr-checks.yml workflow.
It checks for common errors/mistakes when creating own buildroot
packages. Also fixed all warnings this utility output for our existing packages.
* Linux: Update kernel 5.10.61 for ODROID-N2 (#1512)
Update the kernel to 5.10.61 for ODROID-N2 and fix the update script
to update kernel for ODROID-N2 next time too.
* Move ODROID kernel patches to non-kernel version specific directory
The minimal memory reserved parameter vm.min_free_kbytes should be
between 1-3% according to RedHat.
However, the kernel by default reserves around 3MB (e.g. only 3285 on a
32-bit Raspberry Pi 4 2GB installation). This seems to be too low for
network intensive applications such as ours: Under memory pressure
"page allocation failure" on various orders have been observed.
Raspberry Pi OS uses a fixed value of 16MB. Follow this setting for now.
Note: We cannot set this globally for Home Assistant: x86-64 machines
can have quite a bit more memory, which also requires increased
min_free_kbytes parameter. ODROID-N2 on the other hand uses transparent
huge pages: If enabled, the kernel requires higher min_free_kbytes
values, and sets those also by default (e.g. on ODROID-N2+ with 4GB
memory its set to 22528 by default).
Don't fail adding reserved memory when a memory region already has been
reserved (e.g. via memreserve). This avoids conflicting no-map setting
and makes sure memory is properly reserved.
* Enable some useful kernel configurations
* Add xe-guest-utilities for better Xen support
Add guest utilities and make sure the Xen guest daemon gets started
when running under Xen virtualization.
* Avoid using tar when uploading dev builds
The GitHub action to upload the images to the os-builds server uses
tar before uploading. This creates unnecessary copies and takes a while.
Switch to a GitHub action which uploads the images using rsync instead.