Rename the root partition to "rootfsA" in the off-chance the user may someday
be interested in implementing some sort of whole-partition update mechanism.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
U-Boot has the ability to store its environment variables to a permanent
storage device. Whether or not it does so for any one specific device
depends on whatever settings are enabled in that specific device's
defconfig. In order to definitively configure U-Boot to be able to store
its environment into the device from which it boots, for any device
supported in this BSP, simply add the following to MACHINE_FEATURES:
rk-u-boot-env
If enabled, there is now a second choice to make: should the build also
include the U-Boot environment in the image or not? The default environment,
as generated by U-Boot, can be included in the generated wic image. If it
is included, then flashing the image will also flash the default U-Boot
environment variables and settings, wiping out anything that might have been
there already. If it is not included then your device will either continue
using whatever environment happens to be there (if valid), or will not use any
stored environment if the stored environment has not been set or is invalid.
The variable which governs this behaviour is:
RK_IMAGE_INCLUDES_UBOOT_ENV
By default this is set to "0", meaning that by default the image does not
contain the U-Boot environment. To enable this behaviour, enable this
variable. This variable only takes effect if rk-u-boot-env is listed in
MACHINE_FEATURES, and has no effect otherwise.
The script:
scripts/dump-uboot-env-from-yocto-image.sh
can be used on a rockchip wic image to see the contents of the U-Boot
environment partition at build time.
Tested by booting the same image on both eMMC and SDcard with the following
devices, verifying the ability to read and write the U-Boot environment in
both U-Boot and Linux user-space, and that changes made in one are seen in the
other:
rock-3a
rock-5a
rock-5b
rock-pi-4b
rock-pi-e
rock64
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
A filesystem label (/dev/disk/by-label) is a property of, and stored in, the
filesystem itself. Partitions that are not destined to hold filesystems are
not formatted, therefore it is not possible to assign filesystem labels to
such partitions.
However, if GPT partitioning is being used, GPT supports the notion of
assigning labels/names to the partitions which are stored as part of the GPT
partition table itself (instead of being stored in the filesystem in the
partition). The naming is a bit confusing (different tools use different
names) but `wic` calls this "--part-name", `lsblk` calls this "PARTLABEL", and
`parted` calls this "name".
In Linux user-space these partition labels are referenced via
/dev/disk/by-partlabel and provide an excellent way of finding these GPT
partitions regardless of which backing device is actually being used (e.g.
mmcblk0, mmcblk1... i.e. emmc, sdcard...).
An example where this would be handy is for interacting with a stored U-Boot
environment. Another potential use would be to use one of the unused raw
partitions to store information such as MAC addresses, serial numbers, etc.
which could be set/updated "at the factory" as images are flashed.
Tested with both systemd and sysvinit on both rock-pi-e and rock-pi-s.
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
These patches were back-ported from upstream to fix an issue with automatically
handling different ethernet PHY chips on different spins of the rock-pi-e
board. Now that the version of U-Boot has been updated in oe-core master,
these pack-ports are no longer required to be applied explicitly.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The project now has a new mailing list dedicated to patches for projects that
don't warrant their own mailing list. Please use this new mailing list when
sending patches so as to not clutter up the main discussion mailing list and
potentially deterring newcomers.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Upstream kernel support for both the rock-5a and rock-5b landed in version
6.5. Nanbield contained linux-yocto recipes for both 6.1 and 6.5 so it
was best to simply have these MACHINEs use linux-yocto-dev. Post-nanbield
oecore master only has a recipe for 6.6 (so far), therefore these two
MACHINEs can use linux-yocto by default, instead of linux-yocto-dev.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Cleanup the elements of the wic/rockchip.wks file so that they take up less
horizontal space.
Reviewed-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
In order to boot successfully, most Rockchip SoCs require a specific
partitioning scheme which was defined many years (and many SoCs) ago. That
partitioning scheme places the SPL and U-Boot at specific offsets at the
start of the boot block device:
https://opensource.rock-chips.com/wiki_Partitions
The Rockchip partitioning scheme goes on to also define the locations
of a number of additional partitions, including the "boot" and "root"
partitions.
Since both the SPL and U-Boot have already been placed on the block device,
the "boot" partition only contains the extlinux config file and the
kernel+dtb/fitImage; it doesn't contain any bootloader artifacts (other
than the extlinux config).
The location of the SPL partition is a hard dependency since the BOOTROM
etched inside the Rockchip SoCs is programmed to load and run a validated
binary it finds at this location. The locations of the "boot" and "root"
partitions are not so rigid since it is U-Boot which interacts with them.
U-Boot is very flexible with how it finds boot components, and in its
support for various devices, filesystems, sizes, etc.
Both oe-core's U-Boot metadata and wic's bootimg-partition script contain
logic to generate the extlinux pieces required for a bootloader to boot
a Linux system. If both are enabled, the wic pieces silently clobber the
U-Boot pieces. However, the mechanisms contained in the U-Boot metadata are
much more flexible, from a user's point of view, than the mechanisms in
wic's bootimg-partition.
If a user wishes to setup some sort of A/B redundant update mechanism, they
must have redundant root partitions (in order to update their filesystem
contents) but they also need to have redundant boot partitions if they
wish to update the kernel as part of their update mechanism. Pairing
redundant kernel partitions with redundant filesystem partitions becomes
unnecessarily complicated. Therefore it makes sense to combine the kernel
and the filesystem into the same partition so that both the kernel and
filesystem are updated, or rolled back, in lock-step as one unit. Specific
kernel versions and configurations often have dependencies on user-space
components and versions.
The /boot location is not going away. This patch simply transfers
responsibility for its creation to the more flexible U-Boot mechanism
and includes the kernel as part of the same partition as the root
filesystem. Not only does it add flexibility, it also makes update schemes
more straightforward. Although having a separate /boot partition is a
"requirement" of the Rockchip partitioning scheme, it is not an actual
hard requirement when using a flexible, open-source bootloader (such as
U-Boot) instead of using Rockchip's proprietary miniloader, preloader, and
trust.img.
Build-tested for all boards.
Run-tested on:
nanopi-m4-2gb, nanopi-m4b, nanopi-r2s, nanopi-r4s, roc-rk3328-cc,
rock-3a, rock-5a, rock-5b, rock-pi-4b, rock-pi-e, rock-pi-s,
rock64
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Rockchip defines the expected layout/map of the default storage device.
Fill out the wks description so it matches.
https://opensource.rock-chips.com/wiki_Partitions
There are 2 partitions at the start that can not be specified in
rockchip.wks due to a limitation in wic which assumes all sizes (e.g.
--size or --fixed-size) are specified in units of 1024 bytes. Since these
partitions don't fall on 1024-byte boundaries, they can not be specified at
this time.
Note: in the Rockchip layout, not all partitions are expected to show up
in the gpt partition table. While --no-table could be used to hide these
partitions from the partition table, as specified in the wiki, there's
no practical reason to do so. In fact, exposing these partitions in the
partition table makes it easier and safer for users to interact with them.
For example, a user dd'ing some data to a particular area would need to
ensure they're using the correct offset and size values when accessing the
raw disk directly. However being able to specify a partition ensures data
won't accidentally "spill" out into adjacent regions.
Note: there is a mistake in the Rockchip table (which I've copied verbatim
here in this commit message but corrected in rockchip.wks). Going by the
values of the "Start Sector", the size of the "reserved1" partition is
listed as being 2x its actual size/number of sectors.
Expected:
Partition Start Sector Number of Sectors Partition Size PartNum in GPT Requirements
MBR 0 00000000 1 00000001 512 0.5KB
Primary GPT 1 00000001 63 0000003F 32256 31.5KB
loader1 64 00000040 7104 00001bc0 4096000 2.5MB 1 preloader (miniloader or U-Boot SPL)
Vendor Storage 7168 00001c00 512 00000200 262144 256KB SN, MAC and etc.
Reserved Space 7680 00001e00 384 00000180 196608 192KB Not used
reserved1 8064 00001f80 128 00000080 65536 64KB legacy DRM key
U-Boot ENV 8128 00001fc0 64 00000040 32768 32KB
reserved2 8192 00002000 8192 00002000 4194304 4MB legacy parameter
loader2 16384 00004000 8192 00002000 4194304 4MB 2 U-Boot or UEFI
trust 24576 00006000 8192 00002000 4194304 4MB 3 trusted-os like ATF, OP-TEE
boot 32768 00008000 229376 00038000 117440512 112MB 4 kernel, dtb, extlinux.conf, ramdisk
rootfs 262144 00040000 - - - -MB 5 Linux system
Prior to this patch:
# fdisk -l /dev/mmcblk1
GPT PMBR size mismatch (1504727 != 30375935) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/mmcblk1: 14.48 GiB, 15552479232 bytes, 30375936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 00000000-0000-0000-0000-00004D9B9EF0
Device Start End Sectors Size Type
/dev/mmcblk1p1 64 8063 8000 3.9M Microsoft basic data
/dev/mmcblk1p2 8064 8191 128 64K Microsoft basic data
/dev/mmcblk1p3 8192 16383 8192 4M Microsoft basic data
/dev/mmcblk1p4 16384 24575 8192 4M Microsoft basic data
/dev/mmcblk1p5 24576 32767 8192 4M Microsoft basic data
/dev/mmcblk1p6 32768 330955 298188 145.6M Microsoft basic data
/dev/mmcblk1p7 330956 1504693 1173738 573.1M Linux filesystem
New:
# fdisk -l /dev/mmcblk1
GPT PMBR size mismatch (1504473 != 30375935) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/mmcblk1: 14.48 GiB, 15552479232 bytes, 30375936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 00000000-0000-0000-0000-00004D9B9EF0
Device Start End Sectors Size Type
/dev/mmcblk1p1 64 7167 7104 3.5M Linux filesystem
/dev/mmcblk1p2 7168 7679 512 256K Linux filesystem
/dev/mmcblk1p3 7680 8063 384 192K Linux filesystem
/dev/mmcblk1p4 8064 8127 64 32K Linux filesystem
/dev/mmcblk1p5 8128 8191 64 32K Linux filesystem
/dev/mmcblk1p6 8192 16383 8192 4M Linux filesystem
/dev/mmcblk1p7 16384 24575 8192 4M Linux filesystem
/dev/mmcblk1p8 24576 32767 8192 4M Linux filesystem
/dev/mmcblk1p9 32768 330955 298188 145.6M Microsoft basic data
/dev/mmcblk1p10 330956 1504439 1173484 573M Linux filesystem
Reviewed-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
If the wks file doesn't specify, the assumption is that each partition
contains a vfat-formatted filesystem. Most of the partitions in the
Rockchip layout don't have filesystems. Implicitly setting the fstype to
vfat causes wic to format the partitions. It doesn't make sense to format
the rawcopy partitions as vfat just to immediately overwrite them with
binaries, and it wastes time formatting partitions that won't ever be used
as filesystems.
Reviewed-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
In WIC, size arguments can be optionally specified using one of a variety
of suffixes (e.g. K, M, G, etc.) thanks to sizetype(). One such suffix being
"s/S" for handling sector sizes which are assumed to be 512 bytes, rather than
the other size suffixes which are multiples of 1024 bytes.
Using the s/S sizetype allows the definition to match the documentation.
Unfortunately we can not use the s/S suffix for --fixed-size.
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The bbappend provided in this layer only needs to apply to the
u-boot_<version> file itself and not all u-boot files in oe-core.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Allow the user to provide their own WKS_FILE in situations where they want a
different layout (e.g. to support A/B updates).
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The U-Boot patches that were added recently are only for the rock-pi-e
MACHINE, therefore only apply them when building for rock-pi-e.
Fixes: b5bba3a011 ("rock-pi-e: apply upstream PHY fix")
Reviewed-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The upstream kernel reorganized the 32-bit arch/arm device-tree directory
structure to separate out the device-trees by manufacturer (similar to the
organization of the arch/arm64 device-trees). Update the references to
32-bit arm device-trees to match.
This patch can now be applied since all pre-6.5-rc1 kernels have been
removed from oe-core.
NOTE: trying to build a post-6.5-rc1 32-bit kernel with this patch applied
will fail
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Stephen Chen <stephen@radxa.com>
ROCK 4C Plus is a Rockchip RK3399-T based SBC from Radxa.
Specs:
- Rockchip RK3399-T, 2x Cortex-A72 @ 1.5GHz, 4x Cortex-A53@1GHz
- Mali T860MP4 GPU
- RaspberryPi 4 form factor
- 64bit LPDDR4
- eMMC
- Micro SD
- SPI Nor Flash
- Two Micro-HDMI (HDMI 4K and HDMI 2K)
- 4-lane MIPI DSI
- MIPI CSI
- GbE LAN with Power over Ethernet (PoE) support
- Wi-Fi 5 and BT5.0 wireless module
- 3.5mm headphone jack
- Four USB ports (two USB2.0 and two USB3.0)
- RTC
- LEDs
- Power button
- Pwm fan
- 40-pin color expansion header
https://wiki.radxa.com/Rock4/4cplus
Signed-off-by: Stephen Chen <stephen@radxa.com>
The ROCK 3A has an rpi form factor and features:
- 4x Cortex-A55 ARM processor
- Mali G52 GPU
- 0.8TOPS NPU
- 32bit 3200Mb/s LPDDR4, up to 4K@60
- HDMI, MIPI DSI, MIPI CSI
- 3.5mm jack with mic
- USB Port
- GbE LAN
- PCIe 3.0, PCIe 2.0
- 40-pin color expansion header
- RTC
- supports USB PD and QC powering
https://wiki.radxa.com/Rock3/3a
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Anthony Davies <anthony.t.davies@gmail.com>
This patch was submitted to the U-Boot mailing list to fix an issue
initializing the PHY on the rock-pi-e.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The T-Firefly ROC-RK3308-CC is a miniature and compact main board which is
equipped with a cost-effective RK3308 Core Processor and a high-performance
CODEC.
Features:
- Rockchip RK3308, 64-bit, quad-core, Arm Cortex-A35 processor @ 1.3GHz
- 100M ethernet
- PoE
- USB 2.0 and Type-C (OTG and power)
- 802.11 b/g/n WiFi and Bluetooth 4.2
https://en.t-firefly.com/product/rocrk3308cc
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
In upstream mainline U-Boot commit 9e13fef00b8d ("rockchip: Kconfig: Enable
external TPL binary for rk3308") U-Boot was changed to incorporate the DDR TPL
using the same mechanism as the RK3568 and RK3588 platforms.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
AKA the "renegade"
The ROC-RK3328-CC platform is built on the Rockchip RK3328 system-on-chip
optimized for low cost, low power, and high performance IO. It features a
high performance native USB 3.0 interface and Gigabit MAC.
Specs:
- RaspberryPi 2/3 form factor
- quad-core ARM Cortex-A53 @ 1.5GHz
- ARM Mali-450 MP2
- DDR4 RAM
- USB 3.0
- GbE MAC
https://libre.computer/products/roc-rk3328-cc/https://wiki.t-firefly.com/ROC-RK3328-CC/intro.html
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The Radxa ROCK 5 Model A is an SBC in roughly a RaspberryPi-ish form factor
packed with a wide range of class-leading functionality, features and
expansion options. The ROCK 5A board comes in several LPDDR4x RAM memory
options: 4GB, 8GB, 16GB, and 32GB.
It uses the Rockchip RK3588S SoC (quad A76 @ 2.2GHz + quad A55 @ 1.8GHz,
Mali G610mp4 GPU), has both 8k and 4k HDMI, Gb ethernet with PoE support,
USB2/3, M.2 E Key (NVMe or SATA), a 40-pin RaspberryPi-ish 3V3 GPIO header,
USB Type-C power, MIPI DSI/CSI, SDcard slot, optional eMMC, and more.
https://wiki.radxa.com/Rock5/5bhttps://radxa.com/products/rock5/5a/
[
with the following tweaks by Trevor:
- switch to information URL to one that points to information in english
- improved the commit message
- add rock-5a to README
]
Signed-off-by: Stephen Chen <stephen@radxa.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Update machine include files to allow overriding of KERNEL_IMAGETYPE.
[
with the following 2 tweaks by Trevor:
- remove the "v3" from the commit's subject
- extended patch to rk3308 and rk3588s, which were added in between this patch
being submitted, and this patch being applied
]
Signed-off-by: Anthony Davies <anthony.t.davies@gmail.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
ROCK Pi S is a Rockchip RK3308 based SBC from Radxa. It contains a 64-bit
quad core processor, USB, ethernet, wireless connectivity, and voice
detection engine in 1.7-inches square. The ROCK Pi S comes in two RAM sizes
256MB or 512MB DDR3, and uses an sdmmc card for OS and storage. Optionally,
some versions of the ROCK Pi S provide on-board storage via 1Gb/2Gb/4Gb/8Gb
of SLC NAND flash.
"S" stands for "small square" since the total board size of the rock-pi-s
is 1.7-inches square.
This BSP assumes booting from sdmmc, and using ttyS0 for the serial console
(similar to Raspberry Pi).
The latest version of the binary ddr initializer code from rkbin does not
provide a uart0 option, therefore all diagnostic output from rkbin and u-boot
is lost on the console (and replaced with a stream of gibberish until the
Linux kernel starts). Therefore, by default, the build assumes the user would
prefer to see this information and have the option to interact with U-Boot,
which means an older version of rkbin is used. The user can override this
decision by setting:
RKBIN_RK3308_LATEST = "1"
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
NanoPi M4B is a RK3399-based (dual-core A72, quad-core A53 with NEON) board
in the same form factor as the RPi B3+ (including compatible connectors) with
onboard 2.4/5.0 dual-band WiFi + Bluetooth 5.0 with USB type-C power from
FriendlyElec.
https://www.friendlyelec.com/index.php?route=product/product&product_id=275
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Looking forward, rkbin should only be used by specific Rockchip platforms
for which TF-A support is not (yet?) available. If rkbin gets added by
accident without an override, add a bbfatal to let the user know an
override is required.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The goal of the default COMPATIBLE_MACHINE was to not allow
rockchip-rkbin to be even parsed if a MACHINE isn't part of the
COMPATIBLE_MACHINE.
However, COMPATIBLE_MACHINE is a regexp checked using Python's re module
approximately like:
"""
if re.match(COMPATIBLE_MACHINE, MACHINE):
return True
"""
and re.match() returns a match whatever MACHINE is if COMPATIBLE_MACHINE
is the empty string.
Therefore, let's change it to `^$` which only matches the empty string,
which shouldn't be possible for anything in MACHINEOVERRIDES, and if it
is there are probably bigger problems than parsing rockchip-rkbin.
Fixes: f8af59dd7c ("rock-5b: add")
Cc: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Group the EXTRA_OEMAKE items together and sort.
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Group the INIT_FIRMWARE_DEPENDS together and sort.
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The NanoPi R2S is a mini router with edge computing and dual GbE ports by
FriendlyElec. It is based on the Rockchip RK3328 - a quad A53 core, 64-bit SoC
running at 1.2GHz with at least 1GB of DDR4 RAM. It has one USB 2.0 host and
is powered via a USB type-C connector (5V/2A).
https://www.friendlyelec.com/index.php?route=product/product&product_id=282
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The MACHINE name is already added to the MACHINEOVERRIDES implicitly, no need
to add it explicitly.
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Add support for the Radxa Rock 5B
https://wiki.radxa.com/Rock5/5b
The device-tree for this board is better in the 6.5 (and later) kernels,
therefore set the kernel to linux-yocto-dev for now (eventually this won't be
needed as linux-yocto moves forward).
Unfortunately the TF-A project does not currently have support for
the rk3588. Therefore, for the time-being, the only way to supply a
TPL/DDR-init for the rk3588 is to use the closed-source rkbin binaries
from Rockchip. If/when TF-A adds support for the rk3588 we can investigate
switching.
The rk3588 comes in two variants: rk3588 and rk3588s. The "s" option is a
stripped-down version of the rk3588. In the Linux kernel these two SoCs are
kept separate, with the rk3588 building on the rk3588s, so we've mimicked that
same behaviour here.
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
In anticipation of Rockchip SoC families to which the TF-A project has not
been ported, the initial boot firmware needs to come from other sources (e.g.
Rockchip's rkbin binaries). Update the variable used to describe this
dependency to be more generic and not TF-A specific.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Remove the non-rockchip architectures from the kernel build since these are
all a waste of build time, filesystem space, and runtime memory.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Change virtual/arm-none-eabi-gcc-native to gcc-arm-none-eabi-native
following the recent modification in layer meta-arm (git commit
a64fb4a40d707795d9adb7736920fcbeaa7ce5e2) to remove provides.
Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
Various machines require pyelftools Python3 library for parsing dtb files
so it should be added to DEPENDS.
Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The last kernel to not split the rock-pi-4[abc] MACHINEs into separate
device trees was 5.10. The linux-yocto kernels supported in this release
are all after 5.10. Therefore remove the rock-pi-4 MACHINE. By now, on master,
everyone should be selecting specific MACHINEs from one of the variants and
not using "rock-pi-4".
NOTE: this layer will continue to use "rock-pi-4" as a MACHINEOVERRIDE when
the specific variant doesn't matter
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
The U-Boot build for rock-pi-4[abc] was recently changed to add information
for UEFI. The build now DEPENDS on gnutls-native.
U-Boot: e86c789ca372 ("rockpi4: board: Add firmware image information for capsule updates")
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
