[meta-rockchip,v3,4/5] remove /boot partition

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

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
changes in v3:
- add back the comment explaining the need for NONFITDT
- change the inclusion of the u-boot-extlinux package from RRECOMMENDS
  to RDEPENDS
- clarify the commit message to remove the un-true statement that sizes
  are hard requirements
- add back the "--ptable gpt" line to rockchip.wks

changes in v2:
- add UBOOT_EXTLINUX_FDT and tweak UBOOT_EXTLINUX_FDTDIR to modify their
  behaviour based on whether or not KERNEL_IMAGETYPE is fitImage
- remove extraneous WKS_FILE_DEPENDS
- remove "--ptable gpt" from wks
- move newly added "earlycon" to UBOOT_EXTLINUX_CONSOLE
- re-word the commit message to better explain the behaviour of the
  Rockchip BootROM
---
 conf/machine/include/rockchip-defaults.inc |  2 ++
 conf/machine/include/rockchip-extlinux.inc | 24 ++++++++++++++++++++++
 conf/machine/include/rockchip-wic.inc      | 20 ++----------------
 wic/rockchip.wks                           | 12 +++++------
 4 files changed, 33 insertions(+), 25 deletions(-)
 create mode 100644 conf/machine/include/rockchip-extlinux.inc

Hi Trevor,

On 2/19/24 18:48, Trevor Woerner via lists.yoctoproject.org wrote:
> 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
> 
> Signed-off-by: Trevor Woerner <twoerner@gmail.com>

Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Thanks,
Quentin