With U-Boot 2023.01 booting on Raspberry Pi 4 32-bit (at least with 4
or 8GB of memory) freezes when trying to enumerate USB devices. It seems
that the PCIe initialization partially fails, which causes the USB XHCI
initialization to fail.
It seems that a new restriction on viable addresses for PCIe
initialization causes the problem. Revert the offending commit to make
U-Boot properly detect USB devices again.
The new U-Boot 2023.01 requires an additional config which is missing
from the generic Raspberry Pi U-Boot configuration (see #2234). Add
it to the generic Raspberry Pi U-Boot configuration so Yellow as well as
other CM4 based systems can boot from NVMe SSD again.
* Enable Multi-Gen LRU
Multi-Gen LRU should improve performance under memory pressure. This is
especially useful for embedded platforms where memory is scarce.
* Add service to configure Multi-Gen LRU
Use min_ttl_ms of 1 which is the least aggressive in terms of lag. Since
we are a server application, we can tune trashing prevention with a
higher acceptable lag.
* Add multiple routes support in NetworkManager
Support multiple routes to the same network learned via Router
Information Option. With this change, the kernel will have multiple
routing table entries to a given Thread network. The routes gateway
won't be updated with every new RIO any longer since every gateway
has its own entry.
* Enable IPv6 router reachability probing
Currently router reachability probing is disabled since HAOS enables
IPv6 forwarding and the necessary kernel options are not enabled. With
this change router reachability probing is enabled even though we are
a router on our own.
Note that Linux commit ea659e077528 ("[IPV6] ROUTE: Do not enable router
reachability probing in router mode.") by default disabled this
behavior. But since we are acting as a router as well as a host device,
we rather want this reachability probing.
See also: https://lore.kernel.org/netdev/b9182b02829b158d55acc53a0bcec1ed667b2668.1680000784.git.stefan@agner.ch/T/#u
* Fix swapfile creation for all memory sizes
In certain situation awk prints the swapfile size in scientific
notation. The script can't deal with that, in which case swap file
creation fails.
Use int to convert the number to an integer.
Since pages are 4k, also make sure swapsize is aligned to 4k blocks.
* Add info message
Drop PCIe hotplug since this causes network interfaces name changes
which aren't handled gracefully right now. People are left with no
network configuration.
By default systemd kills the service which causes an OOM. That make
sense for a typical service, however, for SSH we don't want this
behavior: The connection should continue, just the command which caused
OOM should be killed.
* Use zswap instead of swap in zram
This requires a swap file which will get generated automatically on
startup.
* Fix file size and free disk space comparison
* Set zswap factor to 33%
* Set vm.swappiness to 1
Decrease swapping to a minimum. This is also recommended for database
work loads by the MariaDB documentation. In practice it causes the least
amount of writes to disk when under memory pressure, while still making
swap available when needed.
* Avoid moving data to same device
When a data disk move is triggered when the data disk is already in use
the script currently renames that only data disk, rendering the system
unusable.
Don't continue if source and destination happens to be the same device.
* On failure rename to hassos-data-fail
The label hassos-data-failed is too long.
* Deactivate any external data disk device on first boot (#2390)
* Use lsblk to determine the underlying device file
Comparing major number is not reliable, e.g. virtio disks have the same
major number despite being different devices. Use lsblk to find the
underlying device, and compare the device name instead.
By default ConditionFirstBoot is ankered to the presence of
/etc/machine-id. However, in our case /etc/machine-id is a bind mount,
which makes the first boot condition non-working.
Since machine-id is stored by the bootloader on HAOS, use the boot
loaders knowledge and pass the information to systemd.
It seems that Raspberry Pi enabled Multi-Gen LRU by default. By my
testing, it performs worse in some situation. Add it by default for all
platforms, but disable it by default for now.
* Add ODROID-M1 board support
* Add Rockchip kernel config for ODROID-M1
Kernel defconfig for Rockchip is based on Armbian kernel defconfig
from config/kernel/linux-rk3568-odroid-edge.config (git hash
95c829f9e664).
* Add U-Boot/Kernel patches
* Add Rockchip blob support
Add package which provides Rockchip TPL and ATF firmware binaries.
* Use latest U-Boot for ODROID-M1
* Fix Rockchip blob support
* Update defconfig
* Use GPT by default
* Create uboot partition to support non-recovery boot
* Enable eMMC boot in U-Boot SPL
* Drop unnecessary mmc device selection
Distro boot already activates the right mmc device. The extra selection
seems to actually cause problems for eMMC boot.
* Make sure driver for eMMC is built-in
* Use odroid-m1 as Supervisor machine
* Add ODROID-M1 to CI pipeline and issue template
* Bump to Linux 6.1.16
* Add security library libseccomp
Enable libseccomp to activate seccomp support in HAOS. This will compile
systemd and Docker with seccomp support.
Note: Traditionally Supervisor required to disable seccomp. This seems
no longer to be the case with current Supervisor, but it needs further
testing. All containers started by Supervisor get currently started with
seccomp disabled.
* Enable seccomp in the kernel
Currently the only board supporting GPT partition table and SPL is the
ASUS Tinker board. Its Rockchip boot loader is stored at LBA 0x40 (64)
which is well past the last LBA of a regular GPT partition table which
is at LBA 33). Therefor a custom GPT main partition table location (via
sgdisk -j, --adjust-main-table=sector) is not necessary.
Technically we could copy anything after LBA 34 from the SPL image, but
since we don't support a board which needs that space for its SPL let's
stick with the well aligned Rockchip start at LBA 64.
Note: To preserve the layout we still add the SPL size to the regular
offset. Technically we could start the boot partition at LBA 16384, but
this would mean a different partition table compared to before and
different offset of subsequent partitions compared to other GPT
platforms.
