oe-core has completely re-written the fitImage support starting roughly at
commit [1], update meta-rockchip to match.
Most of the MACHINEs in meta-rockchip use a fitImage for the kernel, but
some don't. Create a boolean variable (RK_KERNEL_FITIMAGE), enabled by
default, to keep track of which ones do and which ones don't. Use this
variable to decide how to configure various image-related fields.
Build tested with all meta-rockchip MACHINEs both with and without RAUC.
Run tested on the following with RAUC configured:
- nanopi-m4b
- nanopi-r2s
- radxa-zero-3e
- rock-pi-4b
- rock-pi-e
- rock-pi-s
Run tested on the following without RAUC:
- radxa-zero-3e
- rock-pi-e
- rock-pi-s
[1] oe-core: 3442d9297dca ("oe-selftest: fitimage: test external dtb")
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
On systems where KERNEL_IMAGETYPE is not set to fitImage, one needs to
either pass an DTB or a path to a directory where DTBs are located on
the rootfs.
When FDT property in extlinux is provided, FDTDIR isn't used (and
actually u-boot-extlinux-config doesn't even write it to the
configuration file).
When relative paths are used, they are relative to the directory where
extlinux.conf is stored[1]. Since the DTBs are stored in /boot, just
providing the filename of the DTB won't work because extlinux in U-Boot
will search for it in /boot/extlinux. We should therefore either use ../
prefix for relative paths or use /boot to make it absolute. /boot is
more explicit and easily parseable, so let's use the latter.
[1] https://wiki.syslinux.org/wiki/index.php?title=Config#Working_directory
Fixes: d80fa46c42 ("rockchip-extlinux.inc: handle multiple DTs in KERNEL_DEVICETREE")
Fixes: 3b51866f22 ("remove /boot partition")
Fixes: 13316b7968 ("KERNEL_DEVICETREE: 32-bit re-org")
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
If an image doesn't include kernel-modules, the kernel-image package
won't be installed by default. This means that no
kernel-image-${KERNEL_IMAGETYPE} package will be pulled in, resulting in
neither fitImage nor Image (or uImage, or zImage, or...) making it to
the filesystem, rendering the image non-bootable.
For non-fitImage scenarios, we currently expect DTB-less kernel images
(no bundle, like in uImage) so we also need to pull in the DTB via the
kernel-devicetree package.
Those packages used to be pulled in by the wic plugin through the
IMAGE_BOOT_FILES variable.
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Fixes: 3b51866f22 ("remove /boot partition")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
KERNEL_DEVICETREE may contain more than one DTB, the first one being the
default one. Therefore, let's split on space first, to get the first DTB
before stripping the directory name from it.
This doesn't add support for creating multiple labels for each DTB in
KERNEL_DEVICETREE.
Reviewed-by: Trevor Woerner <twoerner@gmail.com>
Fixes: 3b51866f22 ("remove /boot partition")
Fixes: 13316b7968 ("KERNEL_DEVICETREE: 32-bit re-org")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
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>
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>
