[meta-rockchip,v2,3/4] 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 and
sizes 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 and size 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, sizes, and
contents 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.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
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 | 12 ++++++++++++
 conf/machine/include/rockchip-wic.inc      | 20 ++------------------
 wic/rockchip.wks                           |  8 ++------
 4 files changed, 18 insertions(+), 24 deletions(-)
 create mode 100644 conf/machine/include/rockchip-extlinux.inc

Hi Trevor,

On 2/16/24 09:29, 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 and
> sizes 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 and size of the SPL partition is a hard dependency since the

Just because I like being pedantic, I don't thhink the size is a hard 
dependency. The location is (well there are a few possible though :) ), 
but the size is part of the header(s) that is parsed by the BootROM, the 
BootROM will only fetch what it needs as far as I remember. It's a bit 
of convoluted code but it's done in tools/rkcommon.c in U-Boot source code.

What we can say though is that the TPL+SPL has a maximum size, since it 
needs to fit inside the SRAM. But I don't think any SoC has been 
released by Rockchip that has 2.5MiB of SRAM, it's usually a few tens of 
KiB max only. Anyway, the message is fine, just wanted to give a bit 
more info there.

[...]

> diff --git a/conf/machine/include/rockchip-extlinux.inc b/conf/machine/include/rockchip-extlinux.inc
> new file mode 100644
> index 000000000000..3af7ed629e34
> --- /dev/null
> +++ b/conf/machine/include/rockchip-extlinux.inc
> @@ -0,0 +1,12 @@
> +UBOOT_EXTLINUX ?= "1"
> +UBOOT_EXTLINUX_ROOT ?= "root=PARTLABEL=root"
> +UBOOT_EXTLINUX_FDTDIR ?= "${@bb.utils.contains('KERNEL_IMAGETYPE', 'fitImage', '', '/boot', d)}"
> +NONFITDT ?= "${@d.getVar('KERNEL_DEVICETREE').split('/')[1]}"

Maybe keep the comment explaining the logic of this line?

> +UBOOT_EXTLINUX_FDT ?= "${@bb.utils.contains('KERNEL_IMAGETYPE', 'fitImage', '', '${NONFITDT}', d)}"
> +UBOOT_EXTLINUX_CONSOLE ?= "earlycon console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8"
> +UBOOT_EXTLINUX_KERNEL_ARGS ?= "rootwait rw rootfstype=ext4"
> +UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"
> +UBOOT_EXTLINUX_LABELS ?= "default"
> +UBOOT_EXTLINUX_MENU_DESCRIPTION:default ?= "${MACHINE}"
> +
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "u-boot-extlinux"

Going back to the mail I sent a few minutes ago on the v1 (which was 
sent after your v2 was sent :) ), I have a gut feeling we need _RDEPENDS 
here and not _RRECOMMENDS.

Cheers,
Quentin

On Fri 2024-02-16 @ 11:06:03 AM, Quentin Schulz wrote:
> Hi Trevor,
> 
> On 2/16/24 09:29, 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 and
> > sizes 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 and size of the SPL partition is a hard dependency since the
> 
> Just because I like being pedantic, I don't thhink the size is a hard
> dependency. The location is (well there are a few possible though :) ), but
> the size is part of the header(s) that is parsed by the BootROM, the BootROM
> will only fetch what it needs as far as I remember. It's a bit of convoluted
> code but it's done in tools/rkcommon.c in U-Boot source code.
> 
> What we can say though is that the TPL+SPL has a maximum size, since it
> needs to fit inside the SRAM. But I don't think any SoC has been released by
> Rockchip that has 2.5MiB of SRAM, it's usually a few tens of KiB max only.
> Anyway, the message is fine, just wanted to give a bit more info there.

I appreciate pedantic, so don't hesitate to jump in. In fact up until this
point we have been playing fast and loose with the partition sizes, so I
already had proof that the sizing was not a hard dependency. And I never mind
in-depth explanations and experiences.

> 
> [...]
> 
> > diff --git a/conf/machine/include/rockchip-extlinux.inc b/conf/machine/include/rockchip-extlinux.inc
> > new file mode 100644
> > index 000000000000..3af7ed629e34
> > --- /dev/null
> > +++ b/conf/machine/include/rockchip-extlinux.inc
> > @@ -0,0 +1,12 @@
> > +UBOOT_EXTLINUX ?= "1"
> > +UBOOT_EXTLINUX_ROOT ?= "root=PARTLABEL=root"
> > +UBOOT_EXTLINUX_FDTDIR ?= "${@bb.utils.contains('KERNEL_IMAGETYPE', 'fitImage', '', '/boot', d)}"
> > +NONFITDT ?= "${@d.getVar('KERNEL_DEVICETREE').split('/')[1]}"
> 
> Maybe keep the comment explaining the logic of this line?

Done. But tweaked a little. The reasons for having it before (as part of the
boot files is slightly different than the reason for keeping it for EXTLINUX,
but very similar.

> 
> > +UBOOT_EXTLINUX_FDT ?= "${@bb.utils.contains('KERNEL_IMAGETYPE', 'fitImage', '', '${NONFITDT}', d)}"
> > +UBOOT_EXTLINUX_CONSOLE ?= "earlycon console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8"
> > +UBOOT_EXTLINUX_KERNEL_ARGS ?= "rootwait rw rootfstype=ext4"
> > +UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"
> > +UBOOT_EXTLINUX_LABELS ?= "default"
> > +UBOOT_EXTLINUX_MENU_DESCRIPTION:default ?= "${MACHINE}"
> > +
> > +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "u-boot-extlinux"
> 
> Going back to the mail I sent a few minutes ago on the v1 (which was sent
> after your v2 was sent :) ), I have a gut feeling we need _RDEPENDS here and
> not _RRECOMMENDS.

Ah got it. I misunderstood your comments. I thought you had been asking
whether it was necessary at all and I was pointing out that without that
package being added to the rootfs it wouldn't work.

Not a problem, I've upgraded it from a recommendation to a dependency.