From: Trevor Woerner <twoerner@gmail.com>
To: yocto@lists.yoctoproject.org
Subject: [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition
Date: Mon, 12 Feb 2024 15:23:41 -0500 [thread overview]
Message-ID: <20240212202342.37778-3-twoerner@gmail.com> (raw)
In-Reply-To: <20240212202342.37778-1-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 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 locations and sizes of the SPL and U-Boot partitions are hard
dependencies since the BOOTROM etched inside the Rockchip SoCs is
programmed to blindly load and run what it finds at these locations. 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
bootimg-partition.
Also, 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 partition 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.
Boot-tested on:
nanopi-m4b, nanopi-r2s, nanopi-r4s, roc-rk3328-cc, rock-3a,
rock-pi-4b, rock-5a, rock-5b, rock-pi-e, rock-pi-s, rock64
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
conf/machine/include/rockchip-defaults.inc | 2 ++
conf/machine/include/rockchip-extlinux.inc | 10 ++++++++++
conf/machine/include/rockchip-wic.inc | 17 ++---------------
wic/rockchip.wks | 5 ++---
4 files changed, 16 insertions(+), 18 deletions(-)
create mode 100644 conf/machine/include/rockchip-extlinux.inc
diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc
index 3ce2e246ab0b..2387eb909934 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -19,3 +19,5 @@ XSERVER = " \
# misc
SERIAL_CONSOLES ?= "1500000;ttyS2"
+RK_CONSOLE_BAUD ?= "${@d.getVar('SERIAL_CONSOLES').split(';')[0]}"
+RK_CONSOLE_DEVICE ?= "${@d.getVar('SERIAL_CONSOLES').split(';')[1].split()[0]}"
diff --git a/conf/machine/include/rockchip-extlinux.inc b/conf/machine/include/rockchip-extlinux.inc
new file mode 100644
index 000000000000..c73fb7d17e02
--- /dev/null
+++ b/conf/machine/include/rockchip-extlinux.inc
@@ -0,0 +1,10 @@
+UBOOT_EXTLINUX ?= "1"
+UBOOT_EXTLINUX_ROOT ?= "root=PARTLABEL=root"
+UBOOT_EXTLINUX_FDTDIR ?= ""
+UBOOT_EXTLINUX_CONSOLE ?= "console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8"
+UBOOT_EXTLINUX_KERNEL_ARGS ?= "rootwait rw rootfstype=ext4 earlycon"
+UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"
+UBOOT_EXTLINUX_LABELS ?= "default"
+UBOOT_EXTLINUX_MENU_DESCRIPTION:default ?= "${MACHINE}"
+
+MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "u-boot-extlinux"
diff --git a/conf/machine/include/rockchip-wic.inc b/conf/machine/include/rockchip-wic.inc
index 67a8310f7d6a..cae14c90e1db 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -1,5 +1,7 @@
# common meta-rockchip wic/wks items
+require conf/machine/include/rockchip-extlinux.inc
+
SPL_BINARY ?= "idbloader.img"
IMAGE_FSTYPES += "wic wic.bmap"
@@ -11,23 +13,8 @@ WKS_FILE_DEPENDS ?= " \
virtual/bootloader \
virtual/kernel \
"
-# KERNEL_DEVICETREE follows the pattern of 'rockchip/${SOC_FAMILY}-${BOARD}.dtb'
-# but is placed in the deploy directory as simply '${SOC_FAMILY}-${BOARD}.dtb'
-# therefore we have to strip off the 'rockchip/' for IMAGE_BOOT_FILES
-NONFITDT="${@d.getVar('KERNEL_DEVICETREE').split('/')[1]}"
-IMAGE_BOOT_FILES = " \
- ${KERNEL_IMAGETYPE} \
- ${@bb.utils.contains('KERNEL_IMAGETYPE', 'fitImage', '', '${NONFITDT}', d)} \
- "
-
-# use the first-defined <baud>;<device> pair in SERIAL_CONSOLES
-# for the console parameter in the wks files
-RK_CONSOLE_BAUD ?= "${@d.getVar('SERIAL_CONSOLES').split(';')[0]}"
-RK_CONSOLE_DEVICE ?= "${@d.getVar('SERIAL_CONSOLES').split(';')[1].split()[0]}"
WICVARS:append = " \
- RK_CONSOLE_BAUD \
- RK_CONSOLE_DEVICE \
SPL_BINARY \
UBOOT_SUFFIX \
"
diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index 8dc4d20f2f54..5d7701ef8a2e 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -28,7 +28,6 @@ part uboot_env --offset 4064 --fixed-size 32K --fstype=none
part reserved2 --offset 4096 --fixed-size 4096K --fstype=none
part loader2 --offset 8192 --fixed-size 4096K --fstype=none --source rawcopy --sourceparams="file=u-boot.${UBOOT_SUFFIX}"
part atf --offset 12288 --fixed-size 4096K --fstype=none
-part /boot --offset 16384 --size 114688K --fstype=vfat --active --source bootimg-partition --label boot --use-uuid --sourceparams="loader=u-boot"
-part / --fstype=ext4 --source rootfs --label root --use-uuid
+part / --offset 16384 --fstype=ext4 --active --source rootfs --label root
-bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 init=/sbin/init"
+bootloader --ptable gpt
--
2.43.0.76.g1a87c842ece3
next prev parent reply other threads:[~2024-02-12 20:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-12 20:23 [meta-rockchip][PATCH 1/4] rockchip.wks: specify fstype Trevor Woerner
2024-02-12 20:23 ` [meta-rockchip][PATCH 2/4] rockchip.wks: add all Rockchip partitions Trevor Woerner
2024-02-15 17:06 ` [yocto] " Quentin Schulz
2024-02-15 19:20 ` Trevor Woerner
2024-02-16 8:59 ` Quentin Schulz
2024-02-12 20:23 ` Trevor Woerner [this message]
2024-02-15 17:45 ` [yocto] [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition Quentin Schulz
2024-02-16 8:25 ` Trevor Woerner
2024-02-16 9:31 ` Quentin Schulz
2024-02-18 17:28 ` Trevor Woerner
2024-02-21 18:31 ` Quentin Schulz
2024-02-21 19:18 ` Trevor Woerner
2024-02-22 9:37 ` Quentin Schulz
2024-02-12 20:23 ` [meta-rockchip][PATCH 4/4] wks file cleanup Trevor Woerner
2024-02-15 17:47 ` [yocto] " Quentin Schulz
2024-02-15 16:49 ` [yocto] [meta-rockchip][PATCH 1/4] rockchip.wks: specify fstype Quentin Schulz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240212202342.37778-3-twoerner@gmail.com \
--to=twoerner@gmail.com \
--cc=yocto@lists.yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.