* Rename Home Assistant Amber to Yellow
Rename the board from "amber" to "yellow" as Home Assistant Yellow is
the official name now.
* Add Home Assistant Yellow to the build matrix
* Use LSI Logic SCSI controller in vmdk descriptor as well
For some reason, the vmdk disk format's descriptor contains the
controller type as well. By default, qemu-img sets it to "ide", which
seems not optimal especially for VMware's ESXi. Set adapter type to
commonly supported "lsilogic".
* Move ova image generation to hdd-image.sh
* Use OpenSSL to generate OVA manifest file (#826)
It seems that sha256sum adds a space after the hash algorithm which
causes "Invalid OVF checksum algorithm" on certain VMware virtualization
products.
Using OpenSSL avoids the space and makes the manifest file compatible
wiht VMware products.
* Use Buildroot provided OpenSSL binary
* Use SCSI controller by default
* Update Linux kernel patches for Home Assistant Amber
Fix user LED polarity. Also rebase the patchset ontop of the Raspberry Pi
kernel 1.20211029.
* Add RTC as well
These boards support the rather ancient ARMv6 architecture only. We
officially stopped supporting them already two releases ago, its time to
say goodbye.
* Add Amber machine
Introduce a new machine for Amber. Store it under Raspberry Pi boards
since Amber is based on the Raspberry Pi Compute Module 4. This way we
can reuse existing scripts.
* Add kernel patches for Amber
Add kernel patches which add a custom device tree for Amber.
* Add device wipe support via GPIO button
Allow to wipe the device by pressing and holding the red button.
* Enable serial console by default
Enable serial console on the on-board USB-to-UART adapter as well as on
the GPIO header.
* Use 64-bit mode by default
Support only 64-bit for Amber, it is mature enough.
* Remove dt-utils patches applied upstream
All patches are now applied upstream. With 2021.03.0 release no more
downstream patches are required.
* Bump buildroot to fix linux-firmware build issues
* buildroot f10577b836...3c5f87185d (3):
> package/linux-firmware: add rtl8761b/rtl8761bu firmware
> package/linux-firmware: bump version to 20210919
> Revert "package/linux-firmware: add rtl8761b/rtl8761bu firmware"
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.
* 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.
* 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.
* 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.
The CRDA (Central Regulatory Domain Agent) utility has been used as a
user space helper to load regulatory information for WiFi drivers.
However, since Linux 4.15 the kernel can load the regulatory information
directly from a signed firmware file "regulatory.db".
The regulatory.db file is provided by the WIRELESS_REGDB package, which
has been already installed since its a dependency of CRDA.
Drop CRDA and select WIRELESS_REGDB package explicitly to make sure the
regulatory.db file is present.
* Add squashfs with LZ4 and LZO compression to Barebox
* Add squashfs with LZO compression to U-Boot
* Use squashfs for Linux kernel partition
Generate a squashfs image with LZO compression for the Linux kernel
partition. Adjust the boot scripts to be file system independent commands
to boot from squashfs.
The patches for ODROID-C2/C4 don't apply to Linux 5.12 used in
ODROID-N2. Move ODROID-C2/C4 patches to kernel version specific
directory so they don't get applied for ODROID-N2.
Use the latest Linux stable release 5.12 for ODROID-N2. This allows to
test if we see the random kernel crashes observed with 5.10 in latest
stable 5.12 as well.
It seems that the TPU (thermal monitoring) sometimes reports
unreasonable high temperatures, leading the kernel to trigger a thermal
shutdown. Add a patch which filters out such spurious temperature
readings.
* Remove CONFIG_CLOCKSOURCE_EFI configuration
It seems to cause messages like this on some machines:
EFI Event timer too slow freq = 100 Hz
The Barebox efi_defconfig configurationd doesn't enable it either.
Disable it by default as well.
* Enable CONFIG_CMD_ECHO_E to fix menutree
It seems that menutree needs CONFIG_CMD_ECHO_E to properly display the
boot menu.
Also enable other useful commands such as edit or reset.
* Bump Barebox to 2021.05.0
Since the move to 5.10 multiple users experience stability issues
leading to random crashes. All reboots follow a SError Interrupt:
[48112.247242] SError Interrupt on CPU5, code 0xbf000000 -- SError
...
Revert back to Linux 5.9.16 for now.
Using console focused virtualization environments such as virsh having
a serial console is the easiest way to interact with a virtual machine.
It also saves resources since no video memory needs to be allocated.
Enable serial console besides tty1 by default.
Note: The bootloader as well as the kernel shows its boot messages on
all consoles. However, only the last console is mapped to /dev/console,
which systemd is using to show service startup messages. Putting tty1 as
last console makes sure that systemd messages are still shown on the
console screen.
It seems that the crash of the Meson DRM driver on shutdown can also be
fixed by compiling it in. The driver is also built-in in LibreELEC,
hence this is better tested by the upstream community.
Note the underlying issue seems to be a disabled clock: Since the
introduction of meson_drv_shutdown some registers are touched at a very
late stage. Those clock get disabled in meson_ee_pwrc_shutdown. It seems
that when the driver is built-in, meson_drv_shutdown gets called before
meson_ee_pwrc_shutdown and hence sidesteps the problem.
Note: This increases the kernel by a bit since DRM needs to be built-in
as well. Configure some less common used file systems as modules
(ext3/NFS).
Since 0001-CMD-read-string-from-fileinto-env.patch is in the global
directory to be applied for U-Boot, drop it from the Raspberry Pi
specific patch directory.
In Linux 5.10.24 a regression has been introduced which broke reboot on
ODROID-N2(+). Interestingly the patch should improve reboot stability
for VIM3, which uses the same SoC. However, it seems that in the
ODROID-N2 case, this causes more problems then it fixes. Revert the
offending patch.
Virtual Disk images are often used on Windows and/or Mac platforms where
xz is not a widely known file ending and also not supported by dafault.
Use zip which is much better known.
Keep using xz for boards since those are not meant to be extracted by
users but directly used in Etcher. Also keep using xz for qcow2, since
qcow2 is mostly used on Linux platforms where xz is available by default
and zip usually needs an extra package.
