To read the current LED configuration correctly /mnt/boot is required.
This change makes sure that the boot partition is mounted when the OS
Agent starts.
Many x86_64 tablets (e.g. Cherry View) use SDIO WiFi modules, this
enables the driver for a common one I've come across in the wild.
This module requires firmware from the following, which are already
enabled for this platform:
- BR2_PACKAGE_LINUX_FIRMWARE_RTL_87XX
- BR2_PACKAGE_LINUX_FIRMWARE_RTL_87XX_BT
fixes#2422
* Yellow: Always use mini-UART for Bluetooth
Unfortunately, the mini-UART device tree adjusts the alias for serial1,
which we need to make ttyAMA1 the Zigbee UART (UART4).
However, we can no simply adjust that overlay, as the overlays are not
built as part of the Buildroot build. Instead, they are directly copied
from Raspberry Pi's Firmware repostiory.
Instead of using device tree overlays, just apply the changes to our
Yellow specific device tree. To avoid that the device tree gets loaded
anyhow, we could adjust config.txt but that has complications on its
own. Since the overlay might be conflicting with the Yellow device tree
anyways, just remove all of them.
Note: The miniuart-bt.dtbo overlay won't be present, while config.txt
of upgraded instances still reference it. It seems that this doesn't
cause problems at boot time. Leaving the dtoverlay=miniuart-bt present
also allows user to downgrade in case needed.
* Avoid duplicating 98-rpi.conf
* Make it clearer that the image file needs to be renamed
- add information that the update was only successful if version 20230328 is visible.
* Update Documentation/boards/hardkernel/odroid-m1.md
---------
Co-authored-by: Stefan Agner <stefan@agner.ch>
* buildroot 8e1c933e7f...21edbd975f (4):
> package/docker-cli: bump version to v23.0.6
> package/docker-engine: bump version to v23.0.6
> package/containerd: Bump to containerd 1.6.21
> package/runc: bump to version 1.1.7
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.
