* [meta-rockchip][PATCH 1/4] rockchip.wks: specify fstype
@ 2024-02-12 20:23 Trevor Woerner
2024-02-12 20:23 ` [meta-rockchip][PATCH 2/4] rockchip.wks: add all Rockchip partitions Trevor Woerner
` (3 more replies)
0 siblings, 4 replies; 16+ messages in thread
From: Trevor Woerner @ 2024-02-12 20:23 UTC (permalink / raw)
To: yocto
If the wks file doesn't specify, the fstype is assumed to be vfat. Most of
the partitions in the Rockchip layout don't have filesystems. Implicitly
setting the fstype to vfat causes wic to format the partitions. Also,
it doesn't make sense to format the rawcopy partitions as vfat, just to
immediately overwrite them with binaries.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
wic/rockchip.wks | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index fac0b8f70112..b14ec0d1690a 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -17,12 +17,12 @@
# boot 32768 229376
# root 262144 - (suggested)
-part loader1 --offset 32 --fixed-size 4000K --source rawcopy --sourceparams="file=${SPL_BINARY}"
-part reserved1 --offset 4032 --fixed-size 64K
-part reserved2 --offset 4096 --fixed-size 4096K
-part loader2 --offset 8192 --fixed-size 4096K --source rawcopy --sourceparams="file=u-boot.${UBOOT_SUFFIX}"
-part atf --offset 12288 --fixed-size 4096K
-part /boot --offset 16384 --size 114688K --active --source bootimg-partition --fstype=vfat --label boot --use-uuid --sourceparams="loader=u-boot"
-part / --source rootfs --fstype=ext4 --label root --use-uuid
+part loader1 --offset 32 --fixed-size 4000K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}"
+part reserved1 --offset 4032 --fixed-size 64K --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
bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 init=/sbin/init"
--
2.43.0.76.g1a87c842ece3
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [meta-rockchip][PATCH 2/4] rockchip.wks: add all Rockchip partitions
2024-02-12 20:23 [meta-rockchip][PATCH 1/4] rockchip.wks: specify fstype Trevor Woerner
@ 2024-02-12 20:23 ` Trevor Woerner
2024-02-15 17:06 ` [yocto] " Quentin Schulz
2024-02-12 20:23 ` [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition Trevor Woerner
` (2 subsequent siblings)
3 siblings, 1 reply; 16+ messages in thread
From: Trevor Woerner @ 2024-02-12 20:23 UTC (permalink / raw)
To: yocto
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
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
wic/rockchip.wks | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index b14ec0d1690a..8dc4d20f2f54 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -9,16 +9,22 @@
# wic uses 1KB blocks. The following table uses 512 byte sectors:
#
# Partition Start Sector Number of Sectors
-# loader1 64 8000 (idbloader / U-Boot SPL)
-# reserved1 8064 128
-# reserved2 8192 8192
+# loader1 64 7104 (idbloader / U-Boot SPL)
+# vstorage 7168 512 (serial number, MAC address, etc)
+# reserved 7680 384 (not used)
+# reserved1 8064 64 (legacy DRM key)
+# uboot_env 8128 64 (U-Boot environment)
+# reserved2 8192 8192 (legacy parameters, ATAGS, etc)
# loader2 16384 8192 (U-Boot proper)
-# atf 24576 8192
+# atf 24576 8192 (trusted OS e.g. ATR, OP-TEE, etc)
# boot 32768 229376
# root 262144 - (suggested)
-part loader1 --offset 32 --fixed-size 4000K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}"
-part reserved1 --offset 4032 --fixed-size 64K --fstype=none
+part loader1 --offset 32 --fixed-size 3552K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}"
+part vstorage --offset 3584 --fixed-size 256K --fstype=none
+part reserved --offset 3840 --fixed-size 192K --fstype=none
+part reserved1 --offset 4032 --fixed-size 32K --fstype=none
+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
--
2.43.0.76.g1a87c842ece3
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition
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-12 20:23 ` Trevor Woerner
2024-02-15 17:45 ` [yocto] " Quentin Schulz
2024-02-12 20:23 ` [meta-rockchip][PATCH 4/4] wks file cleanup Trevor Woerner
2024-02-15 16:49 ` [yocto] [meta-rockchip][PATCH 1/4] rockchip.wks: specify fstype Quentin Schulz
3 siblings, 1 reply; 16+ messages in thread
From: Trevor Woerner @ 2024-02-12 20:23 UTC (permalink / raw)
To: yocto
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
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [meta-rockchip][PATCH 4/4] wks file cleanup
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-12 20:23 ` [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition Trevor Woerner
@ 2024-02-12 20:23 ` 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
3 siblings, 1 reply; 16+ messages in thread
From: Trevor Woerner @ 2024-02-12 20:23 UTC (permalink / raw)
To: yocto
Cleanup the elements of the wic/rockchip.wks file so they take up less
horizontal space.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
wic/rockchip.wks | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index 5d7701ef8a2e..e76439dd52c3 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -20,14 +20,14 @@
# boot 32768 229376
# root 262144 - (suggested)
-part loader1 --offset 32 --fixed-size 3552K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}"
+part loader1 --offset 32 --fixed-size 3552K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}"
part vstorage --offset 3584 --fixed-size 256K --fstype=none
part reserved --offset 3840 --fixed-size 192K --fstype=none
part reserved1 --offset 4032 --fixed-size 32K --fstype=none
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 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 / --offset 16384 --fstype=ext4 --active --source rootfs --label root
+part / --offset 16384 --active --label root --fstype=ext4 --source rootfs
bootloader --ptable gpt
--
2.43.0.76.g1a87c842ece3
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [yocto] [meta-rockchip][PATCH 1/4] rockchip.wks: specify fstype
2024-02-12 20:23 [meta-rockchip][PATCH 1/4] rockchip.wks: specify fstype Trevor Woerner
` (2 preceding siblings ...)
2024-02-12 20:23 ` [meta-rockchip][PATCH 4/4] wks file cleanup Trevor Woerner
@ 2024-02-15 16:49 ` Quentin Schulz
3 siblings, 0 replies; 16+ messages in thread
From: Quentin Schulz @ 2024-02-15 16:49 UTC (permalink / raw)
To: yocto, twoerner
Hi Trevor,
On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:
> If the wks file doesn't specify, the fstype is assumed to be vfat. Most of
> the partitions in the Rockchip layout don't have filesystems. Implicitly
> setting the fstype to vfat causes wic to format the partitions. Also,
> it doesn't make sense to format the rawcopy partitions as vfat, just to
> immediately overwrite them with binaries.
>
> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Makes sense,
Reviewed-by: Quentin Schulz <foss+yocto@0leil.net>
Thanks,
Quentin
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [yocto] [meta-rockchip][PATCH 2/4] rockchip.wks: add all Rockchip partitions
2024-02-12 20:23 ` [meta-rockchip][PATCH 2/4] rockchip.wks: add all Rockchip partitions Trevor Woerner
@ 2024-02-15 17:06 ` Quentin Schulz
2024-02-15 19:20 ` Trevor Woerner
0 siblings, 1 reply; 16+ messages in thread
From: Quentin Schulz @ 2024-02-15 17:06 UTC (permalink / raw)
To: yocto, twoerner
Hi Trevor,
On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:
> 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
>
> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> ---
> wic/rockchip.wks | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/wic/rockchip.wks b/wic/rockchip.wks
> index b14ec0d1690a..8dc4d20f2f54 100644
> --- a/wic/rockchip.wks
> +++ b/wic/rockchip.wks
> @@ -9,16 +9,22 @@
> # wic uses 1KB blocks. The following table uses 512 byte sectors:
> #
> # Partition Start Sector Number of Sectors
> -# loader1 64 8000 (idbloader / U-Boot SPL)
> -# reserved1 8064 128
> -# reserved2 8192 8192
> +# loader1 64 7104 (idbloader / U-Boot SPL)
> +# vstorage 7168 512 (serial number, MAC address, etc)
> +# reserved 7680 384 (not used)
> +# reserved1 8064 64 (legacy DRM key)
> +# uboot_env 8128 64 (U-Boot environment)
> +# reserved2 8192 8192 (legacy parameters, ATAGS, etc)
> # loader2 16384 8192 (U-Boot proper)
> -# atf 24576 8192
> +# atf 24576 8192 (trusted OS e.g. ATR, OP-TEE, etc)
> # boot 32768 229376
> # root 262144 - (suggested)
>
> -part loader1 --offset 32 --fixed-size 4000K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}"
> -part reserved1 --offset 4032 --fixed-size 64K --fstype=none
> +part loader1 --offset 32 --fixed-size 3552K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}"
> +part vstorage --offset 3584 --fixed-size 256K --fstype=none
> +part reserved --offset 3840 --fixed-size 192K --fstype=none
> +part reserved1 --offset 4032 --fixed-size 32K --fstype=none
> +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
>
This is... quite dangerous. I assume people access raw partitions via
their index number, and now they would be changed, making it harder to
do partial updates. It depends how one sees this file, but could be seen
as immutable for existing partitions to avoid backward compatibility issues.
I was wondering whether there is support for partition labels or
something like that for raw partitions, but doesn't seem like it. Which
is quite odd, wouldn't that kind of information be stored in the
partition table for example?
Also, maybe use sectors for offsets and fixed-sizes since you document
them this way? S is the suffix for it.
Random thought, but we could probably also get the env from U-Boot
recipe (or any other recipe that generates one) (if one is generated)
and install it into uboot_env partition?
Cheers,
Quentin
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [yocto] [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition
2024-02-12 20:23 ` [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition Trevor Woerner
@ 2024-02-15 17:45 ` Quentin Schulz
2024-02-16 8:25 ` Trevor Woerner
0 siblings, 1 reply; 16+ messages in thread
From: Quentin Schulz @ 2024-02-15 17:45 UTC (permalink / raw)
To: yocto, twoerner
Hi Trevor,
On 2/12/24 21:23, 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 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
What matters is the location of TPL+SPL, U-Boot proper can be
programmatically be put anywhere (not where TPL+SPL is of course :) ).
The SPL actually stores in itself where to look for U-Boot proper in the
storage media (and different storage media may have different locations,
we have this for Puma RK3399 which has a differnet location for U-Boot
proper on SPI-NOR and on eMMC/SD card). We do this on Puma RK3399 and
Ringneck PX30 for example (but we're not using this wks file so this
isn't really relevant). Also, IIRC, the BootROM tries a few locations
for the TPL+SPL in the boot storage medium (e.g. every 32KB offsets for
the first 2/3/4).
Also, "blindly" is a bit of a stretch, the BootROM checks for a magic
header value and then another magic string (e.g. RK33 for RK3399 and
PX30). RK3568 and RK3588 have a different header layout also (headerv1
vs headerv2). There's also secure boot that is possible, doing a bunch
of extra checks directly from the BootROM, etc. :)
> 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.
>
And now users would have to update a potentially multi-gigabyte image
only to update their kernel or dtb :)
> 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.
This means the boot partition is going away :) which is confirmed by the
change in wic/rockchip.wks.
I think you meant to say the boot directory is not going away, or rather
the content of the boot partition is not going away?
> 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.
>
The upgrade path from current state to the new one is not
straightforward though? The boot partition would disappear IF the
partition table is reflashed (which is rarely done I guess?) Otherwise
it would still exist, with the old and never-to-be-updated-again kernel
binaries in the /boot partition (which does very much still exist unless
you reflash the partition table AND flash on the / partition with the
update mechanism). This also means that a rollback is impossible.
> 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 ?= ""
This should probably be checking for IMAGETYPE!=fitImage and then
install at the very least the first entry in KERNEL_DEVICETREE? The same
way it was done in IMAGE_BOOT_FILES before?
> +UBOOT_EXTLINUX_CONSOLE ?= "console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8"
> +UBOOT_EXTLINUX_KERNEL_ARGS ?= "rootwait rw rootfstype=ext4 earlycon"
earlycon seems to be new here. and also should probably be part of the
console entry rather, no?
Maybe also abstract the ext4 type here into a variable and use that
variable as fstype in the wks?
> +UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"
FWIW, I don't think /boot is required. bootstd/bootmeth in U-Boot
(upstream at the very least) will check for / and then /boot prefix for
the paths in extlinux.conf. Not providing /boot means if someone still
wants to use a separate boot partition, they wouldn't have to update
this variable. But since it's overridable, this is basically up to your
preference.
> +UBOOT_EXTLINUX_LABELS ?= "default"
> +UBOOT_EXTLINUX_MENU_DESCRIPTION:default ?= "${MACHINE}"
> +
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "u-boot-extlinux"
Is the image actually bootable if we do NOT have u-boot-extlinux
installed? I'm challenging the RRECOMMENDS basically. And wondering
whether MACHINE_ESSENTIAL_EXTRA_* is always included (it seems like
RDEPENDS one is part of packagegroup-core-boot which is virtually
installed in all images).
This is actually quite nice, I was wondering also if there was a way to
create as many entries as there are Device Trees supported for the
machine (and maybe even device tree overlays? but this one's difficult
because we need knowledge of which device tree overlay can apply on top
of which device tree(s) :) ). But I don't think we can have anonymous
python in conf file? Or maybe we should do this in u-boot bbappend?
> 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 \
> "
Does the WKS file still really depend on virtual/kernel or is it rather
a misplaced dependency now?
The backward compatibility issues omitted, this is quite nice :)
Cheers,
Quentin
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [yocto] [meta-rockchip][PATCH 4/4] wks file cleanup
2024-02-12 20:23 ` [meta-rockchip][PATCH 4/4] wks file cleanup Trevor Woerner
@ 2024-02-15 17:47 ` Quentin Schulz
0 siblings, 0 replies; 16+ messages in thread
From: Quentin Schulz @ 2024-02-15 17:47 UTC (permalink / raw)
To: yocto, twoerner
Hi Trevor,
On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:
> Cleanup the elements of the wic/rockchip.wks file so they take up less
> horizontal space.
>
> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Reviewed-by: Quentin Schulz <foss+yocto@0leil.net>
Cheers,
Quentin
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [yocto] [meta-rockchip][PATCH 2/4] rockchip.wks: add all Rockchip partitions
2024-02-15 17:06 ` [yocto] " Quentin Schulz
@ 2024-02-15 19:20 ` Trevor Woerner
2024-02-16 8:59 ` Quentin Schulz
0 siblings, 1 reply; 16+ messages in thread
From: Trevor Woerner @ 2024-02-15 19:20 UTC (permalink / raw)
To: Quentin Schulz; +Cc: yocto
On Thu 2024-02-15 @ 06:06:42 PM, Quentin Schulz wrote:
> Hi Trevor,
>
> On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:
> > 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
> >
> > Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> > ---
> > wic/rockchip.wks | 18 ++++++++++++------
> > 1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/wic/rockchip.wks b/wic/rockchip.wks
> > index b14ec0d1690a..8dc4d20f2f54 100644
> > --- a/wic/rockchip.wks
> > +++ b/wic/rockchip.wks
> > @@ -9,16 +9,22 @@
> > # wic uses 1KB blocks. The following table uses 512 byte sectors:
> > #
> > # Partition Start Sector Number of Sectors
> > -# loader1 64 8000 (idbloader / U-Boot SPL)
> > -# reserved1 8064 128
> > -# reserved2 8192 8192
> > +# loader1 64 7104 (idbloader / U-Boot SPL)
> > +# vstorage 7168 512 (serial number, MAC address, etc)
> > +# reserved 7680 384 (not used)
> > +# reserved1 8064 64 (legacy DRM key)
> > +# uboot_env 8128 64 (U-Boot environment)
> > +# reserved2 8192 8192 (legacy parameters, ATAGS, etc)
> > # loader2 16384 8192 (U-Boot proper)
> > -# atf 24576 8192
> > +# atf 24576 8192 (trusted OS e.g. ATR, OP-TEE, etc)
> > # boot 32768 229376
> > # root 262144 - (suggested)
> > -part loader1 --offset 32 --fixed-size 4000K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}"
> > -part reserved1 --offset 4032 --fixed-size 64K --fstype=none
> > +part loader1 --offset 32 --fixed-size 3552K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}"
> > +part vstorage --offset 3584 --fixed-size 256K --fstype=none
> > +part reserved --offset 3840 --fixed-size 192K --fstype=none
> > +part reserved1 --offset 4032 --fixed-size 32K --fstype=none
> > +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
> >
>
> This is... quite dangerous. I assume people access raw partitions via their
> index number, and now they would be changed, making it harder to do partial
> updates. It depends how one sees this file, but could be seen as immutable
> for existing partitions to avoid backward compatibility issues.
I don't think that's a huge problem, but I could be wrong. People will see
their builds fail, investigate, update, and move on?
But I think I saw something in wic about not adding a partition to the table,
or not giving it a number? So it might be possible to define these partitions
and not change the numbers? I could look into it a bit more.
> I was wondering whether there is support for partition labels or something
> like that for raw partitions, but doesn't seem like it. Which is quite odd,
> wouldn't that kind of information be stored in the partition table for
> example?
Yes, I noticed some things that should probably be there and aren't, such as
the label thing you point out. Also not formatting raw partitions; or not
requiring an explicit fstype on raw partitions to keep from formatting them.
> Also, maybe use sectors for offsets and fixed-sizes since you document them
> this way? S is the suffix for it.
>
> Random thought, but we could probably also get the env from U-Boot recipe
> (or any other recipe that generates one) (if one is generated) and install
> it into uboot_env partition?
That's exactly where I'm going with this. I already have a spreadsheet
listing all the rockchip devices, and their U-Boot environment configurations
(location, size, etc) to see which ones come with environment configurations,
and to make sure they're all the correct location and size for those that do
(they are). I also already have Yocto pieces generating and placing
the U-Boot environment in the U-Boot environment partition (via wic) but
haven't submitted the patches yet (as well as generating a correct
/etc/fw_env.config file. My next step is to add in env support in U-Boot for
those missing it.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [yocto] [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition
2024-02-15 17:45 ` [yocto] " Quentin Schulz
@ 2024-02-16 8:25 ` Trevor Woerner
2024-02-16 9:31 ` Quentin Schulz
0 siblings, 1 reply; 16+ messages in thread
From: Trevor Woerner @ 2024-02-16 8:25 UTC (permalink / raw)
To: Quentin Schulz; +Cc: yocto
On Thu 2024-02-15 @ 06:45:59 PM, Quentin Schulz wrote:
> Hi Trevor,
>
> On 2/12/24 21:23, 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 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
>
> What matters is the location of TPL+SPL, U-Boot proper can be
> programmatically be put anywhere (not where TPL+SPL is of course :) ). The
> SPL actually stores in itself where to look for U-Boot proper in the storage
> media (and different storage media may have different locations, we have
> this for Puma RK3399 which has a differnet location for U-Boot proper on
> SPI-NOR and on eMMC/SD card). We do this on Puma RK3399 and Ringneck PX30
> for example (but we're not using this wks file so this isn't really
> relevant). Also, IIRC, the BootROM tries a few locations for the TPL+SPL in
> the boot storage medium (e.g. every 32KB offsets for the first 2/3/4).
>
> Also, "blindly" is a bit of a stretch, the BootROM checks for a magic header
> value and then another magic string (e.g. RK33 for RK3399 and PX30). RK3568
> and RK3588 have a different header layout also (headerv1 vs headerv2).
> There's also secure boot that is possible, doing a bunch of extra checks
> directly from the BootROM, etc. :)
Good points. I've updated the commit message accordingly.
> > 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.
> >
>
> And now users would have to update a potentially multi-gigabyte image only
> to update their kernel or dtb :)
>
> > 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.
>
> This means the boot partition is going away :) which is confirmed by the
> change in wic/rockchip.wks.
>
> I think you meant to say the boot directory is not going away, or rather the
> content of the boot partition is not going away?
Yes.
> > 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.
> >
>
> The upgrade path from current state to the new one is not straightforward
> though? The boot partition would disappear IF the partition table is
> reflashed (which is rarely done I guess?) Otherwise it would still exist,
> with the old and never-to-be-updated-again kernel binaries in the /boot
> partition (which does very much still exist unless you reflash the partition
> table AND flash on the / partition with the update mechanism). This also
> means that a rollback is impossible.
>
> > 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 ?= ""
>
> This should probably be checking for IMAGETYPE!=fitImage and then install at
> the very least the first entry in KERNEL_DEVICETREE? The same way it was
> done in IMAGE_BOOT_FILES before?
Good catch!
> > +UBOOT_EXTLINUX_CONSOLE ?= "console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8"
> > +UBOOT_EXTLINUX_KERNEL_ARGS ?= "rootwait rw rootfstype=ext4 earlycon"
>
> earlycon seems to be new here. and also should probably be part of the
> console entry rather, no?
Sounds good.
> Maybe also abstract the ext4 type here into a variable and use that variable
> as fstype in the wks?
I'll do that as a separate, future patch.
> > +UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"
>
> FWIW, I don't think /boot is required. bootstd/bootmeth in U-Boot (upstream
> at the very least) will check for / and then /boot prefix for the paths in
> extlinux.conf. Not providing /boot means if someone still wants to use a
> separate boot partition, they wouldn't have to update this variable. But
> since it's overridable, this is basically up to your preference.
This is a good example of working ahead. The next thing I have queued up is
a meta-rauc-rockchip example that works generically on all (most?) rockchip
boards. As part of the U-Boot script I need to make the A/B logic work, it
needs the "/boot" in there otherwise it doesn't work; therefore it's best to
set it up properly now.
> > +UBOOT_EXTLINUX_LABELS ?= "default"
> > +UBOOT_EXTLINUX_MENU_DESCRIPTION:default ?= "${MACHINE}"
> > +
> > +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "u-boot-extlinux"
>
> Is the image actually bootable if we do NOT have u-boot-extlinux installed?
> I'm challenging the RRECOMMENDS basically. And wondering whether
> MACHINE_ESSENTIAL_EXTRA_* is always included (it seems like RDEPENDS one is
> part of packagegroup-core-boot which is virtually installed in all images).
I can double-check, but I'm pretty sure that line was added explicitly after
testing and noticing that it was needed. If we remove the extlinux artifacts
from the image, what boot method is U-Boot supposed to use?
> This is actually quite nice, I was wondering also if there was a way to
> create as many entries as there are Device Trees supported for the machine
> (and maybe even device tree overlays? but this one's difficult because we
> need knowledge of which device tree overlay can apply on top of which device
> tree(s) :) ). But I don't think we can have anonymous python in conf file?
> Or maybe we should do this in u-boot bbappend?
Yes. The bbclass has logic to generate as many entries as user-supplied labels
in UBOOT_EXTLINUX_LABELS:
https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/uboot-extlinux-config.bbclass#n114
I actually hint at the mechanism my providing the superfluous ":default"
entry.
> > 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 \
> > "
>
> Does the WKS file still really depend on virtual/kernel or is it rather a
> misplaced dependency now?
Great catch! Also, since all the partitions now have explicit fstypes, and the
fact we no longer have a vfat-formatted /boot partition, the mtools-native and
dosfstools-native dependencies can also be removed.
It will probably get rejected, but I think I'm going to create a patch for wic
that assumes unspecified partitions are "none" instead of "vfat". I wonder how
many BSP layers are copy&past'ing the mtools and dosfstools dependencies that
aren't using vfat-based partitions and wondering why?
> The backward compatibility issues omitted, this is quite nice :)
>
> Cheers,
> Quentin
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [yocto] [meta-rockchip][PATCH 2/4] rockchip.wks: add all Rockchip partitions
2024-02-15 19:20 ` Trevor Woerner
@ 2024-02-16 8:59 ` Quentin Schulz
0 siblings, 0 replies; 16+ messages in thread
From: Quentin Schulz @ 2024-02-16 8:59 UTC (permalink / raw)
To: Trevor Woerner; +Cc: yocto
Hi Trevor,
On 2/15/24 20:20, Trevor Woerner wrote:
> On Thu 2024-02-15 @ 06:06:42 PM, Quentin Schulz wrote:
>> Hi Trevor,
>>
>> On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:
>>> 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
>>>
>>> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
>>> ---
>>> wic/rockchip.wks | 18 ++++++++++++------
>>> 1 file changed, 12 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/wic/rockchip.wks b/wic/rockchip.wks
>>> index b14ec0d1690a..8dc4d20f2f54 100644
>>> --- a/wic/rockchip.wks
>>> +++ b/wic/rockchip.wks
>>> @@ -9,16 +9,22 @@
>>> # wic uses 1KB blocks. The following table uses 512 byte sectors:
>>> #
>>> # Partition Start Sector Number of Sectors
>>> -# loader1 64 8000 (idbloader / U-Boot SPL)
>>> -# reserved1 8064 128
>>> -# reserved2 8192 8192
>>> +# loader1 64 7104 (idbloader / U-Boot SPL)
>>> +# vstorage 7168 512 (serial number, MAC address, etc)
>>> +# reserved 7680 384 (not used)
>>> +# reserved1 8064 64 (legacy DRM key)
>>> +# uboot_env 8128 64 (U-Boot environment)
>>> +# reserved2 8192 8192 (legacy parameters, ATAGS, etc)
>>> # loader2 16384 8192 (U-Boot proper)
>>> -# atf 24576 8192
>>> +# atf 24576 8192 (trusted OS e.g. ATR, OP-TEE, etc)
>>> # boot 32768 229376
>>> # root 262144 - (suggested)
>>> -part loader1 --offset 32 --fixed-size 4000K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}"
>>> -part reserved1 --offset 4032 --fixed-size 64K --fstype=none
>>> +part loader1 --offset 32 --fixed-size 3552K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}"
>>> +part vstorage --offset 3584 --fixed-size 256K --fstype=none
>>> +part reserved --offset 3840 --fixed-size 192K --fstype=none
>>> +part reserved1 --offset 4032 --fixed-size 32K --fstype=none
>>> +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
>>>
>>
>> This is... quite dangerous. I assume people access raw partitions via their
>> index number, and now they would be changed, making it harder to do partial
>> updates. It depends how one sees this file, but could be seen as immutable
>> for existing partitions to avoid backward compatibility issues.
>
> I don't think that's a huge problem, but I could be wrong. People will see
> their builds fail, investigate, update, and move on?
>
Why would the builds fail? This is a runtime issue IMO. E.g. they flash
idbloader.img to mmcblkXp0 and u-boot.itb to mmcblkXp3 but now they
would need to flash the latter to mmcblkXp6. And if they have a device
that was flashed with the old partition table and another device with
the new partition table, they need some kind of userspace logic to
figure out which is which? They could also be flashing at an offset on
mmcblkX itself, but then this change wouldn't impact them in any way.
> But I think I saw something in wic about not adding a partition to the table,
> or not giving it a number? So it might be possible to define these partitions
> and not change the numbers? I could look into it a bit more.
>
That makes sense, but then.. what would the change in this commit
actually bring to the table? I guess as documentation?
[...]
>> Random thought, but we could probably also get the env from U-Boot recipe
>> (or any other recipe that generates one) (if one is generated) and install
>> it into uboot_env partition?
>
> That's exactly where I'm going with this. I already have a spreadsheet
> listing all the rockchip devices, and their U-Boot environment configurations
> (location, size, etc) to see which ones come with environment configurations,
> and to make sure they're all the correct location and size for those that do
> (they are). I also already have Yocto pieces generating and placing
> the U-Boot environment in the U-Boot environment partition (via wic) but
> haven't submitted the patches yet (as well as generating a correct
> /etc/fw_env.config file. My next step is to add in env support in U-Boot for
> those missing it.
Cool.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [yocto] [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition
2024-02-16 8:25 ` Trevor Woerner
@ 2024-02-16 9:31 ` Quentin Schulz
2024-02-18 17:28 ` Trevor Woerner
0 siblings, 1 reply; 16+ messages in thread
From: Quentin Schulz @ 2024-02-16 9:31 UTC (permalink / raw)
To: Trevor Woerner; +Cc: yocto
On 2/16/24 09:25, Trevor Woerner wrote:
> On Thu 2024-02-15 @ 06:45:59 PM, Quentin Schulz wrote:
>> Hi Trevor,
>>
>> On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:
[...]
>>> +UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"
>>
>> FWIW, I don't think /boot is required. bootstd/bootmeth in U-Boot (upstream
>> at the very least) will check for / and then /boot prefix for the paths in
>> extlinux.conf. Not providing /boot means if someone still wants to use a
>> separate boot partition, they wouldn't have to update this variable. But
>> since it's overridable, this is basically up to your preference.
>
> This is a good example of working ahead. The next thing I have queued up is
> a meta-rauc-rockchip example that works generically on all (most?) rockchip
> boards. As part of the U-Boot script I need to make the A/B logic work, it
> needs the "/boot" in there otherwise it doesn't work; therefore it's best to
> set it up properly now.
>
Mmmm I'm interested to see why it fails without the /boot thing? Let's
see when we get patches :)
>>> +UBOOT_EXTLINUX_LABELS ?= "default"
>>> +UBOOT_EXTLINUX_MENU_DESCRIPTION:default ?= "${MACHINE}"
>>> +
>>> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "u-boot-extlinux"
>>
>> Is the image actually bootable if we do NOT have u-boot-extlinux installed?
>> I'm challenging the RRECOMMENDS basically. And wondering whether
>> MACHINE_ESSENTIAL_EXTRA_* is always included (it seems like RDEPENDS one is
>> part of packagegroup-core-boot which is virtually installed in all images).
>
> I can double-check, but I'm pretty sure that line was added explicitly after
> testing and noticing that it was needed. If we remove the extlinux artifacts
> from the image, what boot method is U-Boot supposed to use?
>
I'm not saying it is not needed, I'm thinking _RRECOMMENDS is too weak
and it should be _RDEPENDS instead?
I'm not sure the wic image (or rather the rootfs) is proper basically if
u-boot-extlinux is not installed.
As for what U-Boot does if it doesn't find an extlinux.conf, it depends
on what U-Boot is configured to do. If I rememebr correctly, most (all)
Rockchip boards now use bootflow by default.
You can check the content of the bootcmd environment variable, that's
what's started when the user does nothing to interrupt the boot.
For me on Jaguar RK3588:
"""
> printenv bootcmd
bootcmd=bootflow scan -lb
"""
remove the -b flag so it doesn't boot and you should have something
reasonable.
For me:
"""
=> bootflow scan -lae
Scanning for bootflows in all bootdevs
Seq Method State Uclass Part Name Filename
--- ----------- ------ -------- ---- ------------------------
----------------
Scanning global bootmeth 'efi_mgr':
0 efi_mgr ready (none) 0 <NULL>
Scanning bootdev 'mmc@fe2e0000.bootdev':
1 extlinux media mmc 0 mmc@fe2e0000.bootdev.whol
** No partition found, err=-2: No such file or directory
2 script media mmc 0 mmc@fe2e0000.bootdev.whol
** No partition found, err=-2: No such file or directory
3 efi media mmc 0 mmc@fe2e0000.bootdev.whol
** No partition found, err=-2: No such file or directory
4 pxe base mmc 0 mmc@fe2e0000.bootdev.whol
** No media/partition found, err=-524: Unknown error
5 extlinux media mmc 1 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
6 script media mmc 1 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
7 efi media mmc 1 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
8 pxe base mmc 1 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
9 extlinux media mmc 2 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
a script media mmc 2 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
b efi media mmc 2 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
c pxe base mmc 2 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
d extlinux media mmc 3 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
e script media mmc 3 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
f efi media mmc 3 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
10 pxe base mmc 3 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
11 extlinux media mmc 4 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
12 script media mmc 4 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
13 efi media mmc 4 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
14 pxe base mmc 4 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
15 extlinux media mmc 5 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
16 script media mmc 5 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
17 efi media mmc 5 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
18 pxe base mmc 5 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
19 extlinux ready mmc 6 mmc@fe2e0000.bootdev.part
/extlinux/extlinux.conf
1a script fs mmc 6 mmc@fe2e0000.bootdev.part
/boot/boot.scr
** File not found, err=-2: No such file or directory
1b efi fs mmc 6 mmc@fe2e0000.bootdev.part
efi/boot/bootaa64.efi
** File not found, err=-2: No such file or directory
1c pxe base mmc 6 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
1d extlinux media mmc 7 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
1e script media mmc 7 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
1f efi media mmc 7 mmc@fe2e0000.bootdev.part
** No partition found, err=-22: Invalid argument
20 pxe base mmc 7 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
21 extlinux media mmc 8 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
22 script media mmc 8 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
23 efi media mmc 8 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
24 pxe base mmc 8 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
25 extlinux media mmc 9 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
26 script media mmc 9 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
27 efi media mmc 9 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
28 pxe base mmc 9 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
29 extlinux media mmc a mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
2a script media mmc a mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
2b efi media mmc a mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
2c pxe base mmc a mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
2d extlinux media mmc b mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
2e script media mmc b mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
2f efi media mmc b mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
30 pxe base mmc b mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
31 extlinux media mmc c mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
32 script media mmc c mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
33 efi media mmc c mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
34 pxe base mmc c mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
35 extlinux media mmc d mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
36 script media mmc d mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
37 efi media mmc d mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
38 pxe base mmc d mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
39 extlinux media mmc e mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
3a script media mmc e mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
3b efi media mmc e mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
3c pxe base mmc e mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
3d extlinux media mmc f mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
3e script media mmc f mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
3f efi media mmc f mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
40 pxe base mmc f mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
41 extlinux media mmc 10 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
42 script media mmc 10 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
43 efi media mmc 10 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
44 pxe base mmc 10 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
45 extlinux media mmc 11 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
46 script media mmc 11 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
47 efi media mmc 11 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
48 pxe base mmc 11 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
49 extlinux media mmc 12 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
4a script media mmc 12 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
4b efi media mmc 12 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
4c pxe base mmc 12 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
4d extlinux media mmc 13 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
4e script media mmc 13 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
4f efi media mmc 13 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
50 pxe base mmc 13 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
51 extlinux media mmc 14 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
52 script media mmc 14 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
53 efi media mmc 14 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
54 pxe base mmc 14 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
55 extlinux media mmc 15 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
56 script media mmc 15 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
57 efi media mmc 15 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
58 pxe base mmc 15 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
59 extlinux media mmc 16 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
5a script media mmc 16 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
5b efi media mmc 16 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
5c pxe base mmc 16 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
5d extlinux media mmc 17 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
5e script media mmc 17 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
5f efi media mmc 17 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
60 pxe base mmc 17 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
61 extlinux media mmc 18 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
62 script media mmc 18 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
63 efi media mmc 18 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
64 pxe base mmc 18 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
65 extlinux media mmc 19 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
66 script media mmc 19 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
67 efi media mmc 19 mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
68 pxe base mmc 19 mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
69 extlinux media mmc 1a mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
6a script media mmc 1a mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
6b efi media mmc 1a mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
6c pxe base mmc 1a mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
6d extlinux media mmc 1b mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
6e script media mmc 1b mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
6f efi media mmc 1b mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
70 pxe base mmc 1b mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
71 extlinux media mmc 1c mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
72 script media mmc 1c mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
73 efi media mmc 1c mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
74 pxe base mmc 1c mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
75 extlinux media mmc 1d mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
76 script media mmc 1d mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
77 efi media mmc 1d mmc@fe2e0000.bootdev.part
** No partition found, err=-2: No such file or directory
78 pxe base mmc 1d mmc@fe2e0000.bootdev.part
** No media/partition found, err=-524: Unknown error
Scanning bootdev 'mmc@fe2c0000.bootdev':
Card did not respond to voltage select! : -110
Unknown uclass 'nvme' in label
scanning bus for devices...
Bus usb@fc800000: USB EHCI 1.00
Bus usb@fc840000: USB OHCI 1.0
Bus usb@fc880000: USB EHCI 1.00
Bus usb@fc8c0000: USB OHCI 1.0
scanning bus usb@fc800000 for devices... 1 USB Device(s) found
scanning bus usb@fc840000 for devices... 1 USB Device(s) found
scanning bus usb@fc880000 for devices... 1 USB Device(s) found
scanning bus usb@fc8c0000 for devices... 1 USB Device(s) found
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17
Retry time exceeded; starting again
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17
Retry time exceeded; starting again
No more bootdevs
--- ----------- ------ -------- ---- ------------------------
----------------
(121 bootflows, 2 valid)
"""
The media tested seems to be located in boot_targets, which defaults for
that board to:
"""
> printenv boot_targets
boot_targets=mmc0 mmc1 nvme scsi usb pxe dhcp spi
"""
So it tries to boot from mmc0 (eMMC usually), mmc1 (SD card usually),
nvme, scsi, usb, pxe (glorified TFTP?), dhcp, spi.
So if nothing works/exists before scsi, then it'll try to boot from
that, then USB, then from the network and finally maybe from spi but
that is very likely to fail as well since SPI flashes are typically very
small and wouldn't be able to contain even the kernel Image?
>> This is actually quite nice, I was wondering also if there was a way to
>> create as many entries as there are Device Trees supported for the machine
>> (and maybe even device tree overlays? but this one's difficult because we
>> need knowledge of which device tree overlay can apply on top of which device
>> tree(s) :) ). But I don't think we can have anonymous python in conf file?
>> Or maybe we should do this in u-boot bbappend?
>
> Yes. The bbclass has logic to generate as many entries as user-supplied labels
> in UBOOT_EXTLINUX_LABELS:
>
> https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/uboot-extlinux-config.bbclass#n114
>
> I actually hint at the mechanism my providing the superfluous ":default"
> entry.
>
I'm actually more discussing how to *feed* this to this part of the
code. Right now, this is manual because we need to define labels and for
each variable a label override.
I was wondering if we could have something that automatically creates
labels for the non fitimage usecase, based on the KERNEL_DEVICETREE
variable.
in pseudo code:
UBOOT_EXTLINUX_LABELS ?= ""
python __anonymous() {
UBOOT_EXTLINUX_DEFAULT_LABEL = first(KERNEL_DEVICETREE)
for devicetree in KERNEL_DEVICETREE:
UBOOT_EXTLINUX_LABELS += basename(devicetree)
UBOOT_EXTLINUX_FDT:basename(devicetree) = devicetree
}
>>> 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 \
>>> "
>>
>> Does the WKS file still really depend on virtual/kernel or is it rather a
>> misplaced dependency now?
>
> Great catch! Also, since all the partitions now have explicit fstypes, and the
> fact we no longer have a vfat-formatted /boot partition, the mtools-native and
> dosfstools-native dependencies can also be removed.
>
> It will probably get rejected, but I think I'm going to create a patch for wic
> that assumes unspecified partitions are "none" instead of "vfat". I wonder how
> many BSP layers are copy&past'ing the mtools and dosfstools dependencies that
> aren't using vfat-based partitions and wondering why?
>
And a nice catch from you there too :)
Cheers,
Quentin
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [yocto] [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition
2024-02-16 9:31 ` Quentin Schulz
@ 2024-02-18 17:28 ` Trevor Woerner
2024-02-21 18:31 ` Quentin Schulz
0 siblings, 1 reply; 16+ messages in thread
From: Trevor Woerner @ 2024-02-18 17:28 UTC (permalink / raw)
To: Quentin Schulz; +Cc: yocto
On Fri 2024-02-16 @ 10:31:36 AM, Quentin Schulz wrote:
>
>
> On 2/16/24 09:25, Trevor Woerner wrote:
> > On Thu 2024-02-15 @ 06:45:59 PM, Quentin Schulz wrote:
> > > Hi Trevor,
> > >
> > > On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:
> [...]
> > > > +UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"
> > >
> > > FWIW, I don't think /boot is required. bootstd/bootmeth in U-Boot (upstream
> > > at the very least) will check for / and then /boot prefix for the paths in
> > > extlinux.conf. Not providing /boot means if someone still wants to use a
> > > separate boot partition, they wouldn't have to update this variable. But
> > > since it's overridable, this is basically up to your preference.
> >
> > This is a good example of working ahead. The next thing I have queued up is
> > a meta-rauc-rockchip example that works generically on all (most?) rockchip
> > boards. As part of the U-Boot script I need to make the A/B logic work, it
> > needs the "/boot" in there otherwise it doesn't work; therefore it's best to
> > set it up properly now.
> >
>
> Mmmm I'm interested to see why it fails without the /boot thing? Let's see
> when we get patches :)
I'm working on getting rauc working with meta-rockchip generically so it works
with all the MACHINES in meta-rockchip. The patch won't be part of
meta-rockchip, but rather be part of a meta-rauc-community/meta-rauc-rockchip
I hope to submit upstream at some point.
Basically rauc works with U-Boot via a boot script. To make that script more
flexible I'm borrowing a variable form meta-rockchip in the rauc U-Boot script
to actually do the booting of the kernel/fitImage/etc. So while U-Boot might
be smart enough to check a bunch of places looking for the thing to boot, the
rauc boot script isn't quite so smart. It's my script to write, and I could
add such logic, but that would just inflate the script for questionable gain.
> > > > +UBOOT_EXTLINUX_LABELS ?= "default"
> > > > +UBOOT_EXTLINUX_MENU_DESCRIPTION:default ?= "${MACHINE}"
> > > > +
> > > > +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "u-boot-extlinux"
> > >
> > > Is the image actually bootable if we do NOT have u-boot-extlinux installed?
> > > I'm challenging the RRECOMMENDS basically. And wondering whether
> > > MACHINE_ESSENTIAL_EXTRA_* is always included (it seems like RDEPENDS one is
> > > part of packagegroup-core-boot which is virtually installed in all images).
> >
> > I can double-check, but I'm pretty sure that line was added explicitly after
> > testing and noticing that it was needed. If we remove the extlinux artifacts
> > from the image, what boot method is U-Boot supposed to use?
> >
>
> I'm not saying it is not needed, I'm thinking _RRECOMMENDS is too weak and
> it should be _RDEPENDS instead?
>
> I'm not sure the wic image (or rather the rootfs) is proper basically if
> u-boot-extlinux is not installed.
>
> As for what U-Boot does if it doesn't find an extlinux.conf, it depends on
> what U-Boot is configured to do. If I rememebr correctly, most (all)
> Rockchip boards now use bootflow by default.
>
> You can check the content of the bootcmd environment variable, that's what's
> started when the user does nothing to interrupt the boot.
>
> For me on Jaguar RK3588:
> """
> > printenv bootcmd
> bootcmd=bootflow scan -lb
> """
>
> remove the -b flag so it doesn't boot and you should have something
> reasonable.
>
> For me:
> """
> => bootflow scan -lae
> Scanning for bootflows in all bootdevs
> Seq Method State Uclass Part Name Filename
> --- ----------- ------ -------- ---- ------------------------
> ----------------
> Scanning global bootmeth 'efi_mgr':
> 0 efi_mgr ready (none) 0 <NULL>
> Scanning bootdev 'mmc@fe2e0000.bootdev':
> 1 extlinux media mmc 0 mmc@fe2e0000.bootdev.whol
> ** No partition found, err=-2: No such file or directory
> 2 script media mmc 0 mmc@fe2e0000.bootdev.whol
> ** No partition found, err=-2: No such file or directory
> 3 efi media mmc 0 mmc@fe2e0000.bootdev.whol
> ** No partition found, err=-2: No such file or directory
> 4 pxe base mmc 0 mmc@fe2e0000.bootdev.whol
> ** No media/partition found, err=-524: Unknown error
> 5 extlinux media mmc 1 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> 6 script media mmc 1 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> 7 efi media mmc 1 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> 8 pxe base mmc 1 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 9 extlinux media mmc 2 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> a script media mmc 2 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> b efi media mmc 2 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> c pxe base mmc 2 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> d extlinux media mmc 3 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> e script media mmc 3 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> f efi media mmc 3 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> 10 pxe base mmc 3 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 11 extlinux media mmc 4 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> 12 script media mmc 4 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> 13 efi media mmc 4 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> 14 pxe base mmc 4 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 15 extlinux media mmc 5 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> 16 script media mmc 5 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> 17 efi media mmc 5 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> 18 pxe base mmc 5 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 19 extlinux ready mmc 6 mmc@fe2e0000.bootdev.part
> /extlinux/extlinux.conf
> 1a script fs mmc 6 mmc@fe2e0000.bootdev.part
> /boot/boot.scr
> ** File not found, err=-2: No such file or directory
> 1b efi fs mmc 6 mmc@fe2e0000.bootdev.part
> efi/boot/bootaa64.efi
> ** File not found, err=-2: No such file or directory
> 1c pxe base mmc 6 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 1d extlinux media mmc 7 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> 1e script media mmc 7 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> 1f efi media mmc 7 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-22: Invalid argument
> 20 pxe base mmc 7 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 21 extlinux media mmc 8 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 22 script media mmc 8 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 23 efi media mmc 8 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 24 pxe base mmc 8 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 25 extlinux media mmc 9 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 26 script media mmc 9 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 27 efi media mmc 9 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 28 pxe base mmc 9 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 29 extlinux media mmc a mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 2a script media mmc a mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 2b efi media mmc a mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 2c pxe base mmc a mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 2d extlinux media mmc b mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 2e script media mmc b mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 2f efi media mmc b mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 30 pxe base mmc b mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 31 extlinux media mmc c mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 32 script media mmc c mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 33 efi media mmc c mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 34 pxe base mmc c mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 35 extlinux media mmc d mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 36 script media mmc d mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 37 efi media mmc d mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 38 pxe base mmc d mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 39 extlinux media mmc e mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 3a script media mmc e mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 3b efi media mmc e mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 3c pxe base mmc e mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 3d extlinux media mmc f mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 3e script media mmc f mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 3f efi media mmc f mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 40 pxe base mmc f mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 41 extlinux media mmc 10 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 42 script media mmc 10 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 43 efi media mmc 10 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 44 pxe base mmc 10 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 45 extlinux media mmc 11 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 46 script media mmc 11 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 47 efi media mmc 11 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 48 pxe base mmc 11 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 49 extlinux media mmc 12 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 4a script media mmc 12 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 4b efi media mmc 12 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 4c pxe base mmc 12 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 4d extlinux media mmc 13 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 4e script media mmc 13 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 4f efi media mmc 13 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 50 pxe base mmc 13 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 51 extlinux media mmc 14 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 52 script media mmc 14 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 53 efi media mmc 14 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 54 pxe base mmc 14 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 55 extlinux media mmc 15 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 56 script media mmc 15 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 57 efi media mmc 15 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 58 pxe base mmc 15 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 59 extlinux media mmc 16 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 5a script media mmc 16 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 5b efi media mmc 16 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 5c pxe base mmc 16 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 5d extlinux media mmc 17 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 5e script media mmc 17 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 5f efi media mmc 17 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 60 pxe base mmc 17 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 61 extlinux media mmc 18 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 62 script media mmc 18 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 63 efi media mmc 18 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 64 pxe base mmc 18 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 65 extlinux media mmc 19 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 66 script media mmc 19 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 67 efi media mmc 19 mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 68 pxe base mmc 19 mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 69 extlinux media mmc 1a mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 6a script media mmc 1a mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 6b efi media mmc 1a mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 6c pxe base mmc 1a mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 6d extlinux media mmc 1b mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 6e script media mmc 1b mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 6f efi media mmc 1b mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 70 pxe base mmc 1b mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 71 extlinux media mmc 1c mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 72 script media mmc 1c mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 73 efi media mmc 1c mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 74 pxe base mmc 1c mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> 75 extlinux media mmc 1d mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 76 script media mmc 1d mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 77 efi media mmc 1d mmc@fe2e0000.bootdev.part
> ** No partition found, err=-2: No such file or directory
> 78 pxe base mmc 1d mmc@fe2e0000.bootdev.part
> ** No media/partition found, err=-524: Unknown error
> Scanning bootdev 'mmc@fe2c0000.bootdev':
> Card did not respond to voltage select! : -110
> Unknown uclass 'nvme' in label
> scanning bus for devices...
> Bus usb@fc800000: USB EHCI 1.00
> Bus usb@fc840000: USB OHCI 1.0
> Bus usb@fc880000: USB EHCI 1.00
> Bus usb@fc8c0000: USB OHCI 1.0
> scanning bus usb@fc800000 for devices... 1 USB Device(s) found
> scanning bus usb@fc840000 for devices... 1 USB Device(s) found
> scanning bus usb@fc880000 for devices... 1 USB Device(s) found
> scanning bus usb@fc8c0000 for devices... 1 USB Device(s) found
> BOOTP broadcast 1
> BOOTP broadcast 2
> BOOTP broadcast 3
> BOOTP broadcast 4
> BOOTP broadcast 5
> BOOTP broadcast 6
> BOOTP broadcast 7
> BOOTP broadcast 8
> BOOTP broadcast 9
> BOOTP broadcast 10
> BOOTP broadcast 11
> BOOTP broadcast 12
> BOOTP broadcast 13
> BOOTP broadcast 14
> BOOTP broadcast 15
> BOOTP broadcast 16
> BOOTP broadcast 17
>
> Retry time exceeded; starting again
> BOOTP broadcast 1
> BOOTP broadcast 2
> BOOTP broadcast 3
> BOOTP broadcast 4
> BOOTP broadcast 5
> BOOTP broadcast 6
> BOOTP broadcast 7
> BOOTP broadcast 8
> BOOTP broadcast 9
> BOOTP broadcast 10
> BOOTP broadcast 11
> BOOTP broadcast 12
> BOOTP broadcast 13
> BOOTP broadcast 14
> BOOTP broadcast 15
> BOOTP broadcast 16
> BOOTP broadcast 17
>
> Retry time exceeded; starting again
> No more bootdevs
> --- ----------- ------ -------- ---- ------------------------
> ----------------
> (121 bootflows, 2 valid)
> """
>
> The media tested seems to be located in boot_targets, which defaults for
> that board to:
>
> """
> > printenv boot_targets
> boot_targets=mmc0 mmc1 nvme scsi usb pxe dhcp spi
> """
>
> So it tries to boot from mmc0 (eMMC usually), mmc1 (SD card usually), nvme,
> scsi, usb, pxe (glorified TFTP?), dhcp, spi.
>
> So if nothing works/exists before scsi, then it'll try to boot from that,
> then USB, then from the network and finally maybe from spi but that is very
> likely to fail as well since SPI flashes are typically very small and
> wouldn't be able to contain even the kernel Image?
>
> > > This is actually quite nice, I was wondering also if there was a way to
> > > create as many entries as there are Device Trees supported for the machine
> > > (and maybe even device tree overlays? but this one's difficult because we
> > > need knowledge of which device tree overlay can apply on top of which device
> > > tree(s) :) ). But I don't think we can have anonymous python in conf file?
> > > Or maybe we should do this in u-boot bbappend?
> >
> > Yes. The bbclass has logic to generate as many entries as user-supplied labels
> > in UBOOT_EXTLINUX_LABELS:
> >
> > https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/uboot-extlinux-config.bbclass#n114
> >
> > I actually hint at the mechanism my providing the superfluous ":default"
> > entry.
> >
>
> I'm actually more discussing how to *feed* this to this part of the code.
> Right now, this is manual because we need to define labels and for each
> variable a label override.
>
> I was wondering if we could have something that automatically creates labels
> for the non fitimage usecase, based on the KERNEL_DEVICETREE variable.
>
> in pseudo code:
>
> UBOOT_EXTLINUX_LABELS ?= ""
>
> python __anonymous() {
> UBOOT_EXTLINUX_DEFAULT_LABEL = first(KERNEL_DEVICETREE)
> for devicetree in KERNEL_DEVICETREE:
> UBOOT_EXTLINUX_LABELS += basename(devicetree)
> UBOOT_EXTLINUX_FDT:basename(devicetree) = devicetree
I made all the EXTLINUX variables ?= so users could override them as they see
fit. If a user wants to add more boot targets then I figure they can generate
the entries manually in their own overrides/configurations to suit their needs
for the time-being. Maybe eventually we could have something clever and
automated (based on KERNEL_DEVICETREE) but that's a future task. In that case
the user would only need to specify a set of device trees and the BSP would
handle it automatically.
However boot targets might not all be based, or all be wanted, from different
device trees. If the user wanted to have a, for example. Xen target, that
would be an entirely separate thing.
More things to think about. In any case, the proposed changes allow the user
to do what the want, even if it means a bit more work on their part for the
time-being.
And that's why I'm happy to be switching over to the EXTLINUX handling
provided by the U-Boot metadata in oecore rather than using the EXTLINUX
pieces from wic. The oecore pieces are much more flexible. The wic support
doesn't allow anywhere near as much flexibility and certainly doesn't provide
a way to define multiple targets.
> }
>
> > > > 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 \
> > > > "
> > >
> > > Does the WKS file still really depend on virtual/kernel or is it rather a
> > > misplaced dependency now?
> >
> > Great catch! Also, since all the partitions now have explicit fstypes, and the
> > fact we no longer have a vfat-formatted /boot partition, the mtools-native and
> > dosfstools-native dependencies can also be removed.
> >
> > It will probably get rejected, but I think I'm going to create a patch for wic
> > that assumes unspecified partitions are "none" instead of "vfat". I wonder how
> > many BSP layers are copy&past'ing the mtools and dosfstools dependencies that
> > aren't using vfat-based partitions and wondering why?
> >
>
> And a nice catch from you there too :)
>
> Cheers,
> Quentin
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [yocto] [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition
2024-02-18 17:28 ` Trevor Woerner
@ 2024-02-21 18:31 ` Quentin Schulz
2024-02-21 19:18 ` Trevor Woerner
0 siblings, 1 reply; 16+ messages in thread
From: Quentin Schulz @ 2024-02-21 18:31 UTC (permalink / raw)
To: Trevor Woerner; +Cc: yocto
Hi Trevor,
On 2/18/24 18:28, Trevor Woerner wrote:
> On Fri 2024-02-16 @ 10:31:36 AM, Quentin Schulz wrote:
>>
>>
>> On 2/16/24 09:25, Trevor Woerner wrote:
>>> On Thu 2024-02-15 @ 06:45:59 PM, Quentin Schulz wrote:
>>>> Hi Trevor,
>>>>
>>>> On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:
>> [...]
>>>>> +UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"
>>>>
>>>> FWIW, I don't think /boot is required. bootstd/bootmeth in U-Boot (upstream
>>>> at the very least) will check for / and then /boot prefix for the paths in
>>>> extlinux.conf. Not providing /boot means if someone still wants to use a
>>>> separate boot partition, they wouldn't have to update this variable. But
>>>> since it's overridable, this is basically up to your preference.
>>>
>>> This is a good example of working ahead. The next thing I have queued up is
>>> a meta-rauc-rockchip example that works generically on all (most?) rockchip
>>> boards. As part of the U-Boot script I need to make the A/B logic work, it
>>> needs the "/boot" in there otherwise it doesn't work; therefore it's best to
>>> set it up properly now.
>>>
>>
>> Mmmm I'm interested to see why it fails without the /boot thing? Let's see
>> when we get patches :)
>
> I'm working on getting rauc working with meta-rockchip generically so it works
> with all the MACHINES in meta-rockchip. The patch won't be part of
> meta-rockchip, but rather be part of a meta-rauc-community/meta-rauc-rockchip
> I hope to submit upstream at some point.
>
> Basically rauc works with U-Boot via a boot script. To make that script more
> flexible I'm borrowing a variable form meta-rockchip in the rauc U-Boot script
> to actually do the booting of the kernel/fitImage/etc. So while U-Boot might
> be smart enough to check a bunch of places looking for the thing to boot, the
> rauc boot script isn't quite so smart. It's my script to write, and I could
> add such logic, but that would just inflate the script for questionable gain.
>
This seems like you're not using extlinux.conf when using rauc but using
one of the variables used to build the extlinux.conf to do some
magic/logic in rauc?
In any case, not a blocker.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [yocto] [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition
2024-02-21 18:31 ` Quentin Schulz
@ 2024-02-21 19:18 ` Trevor Woerner
2024-02-22 9:37 ` Quentin Schulz
0 siblings, 1 reply; 16+ messages in thread
From: Trevor Woerner @ 2024-02-21 19:18 UTC (permalink / raw)
To: Quentin Schulz; +Cc: yocto
On Wed 2024-02-21 @ 07:31:17 PM, Quentin Schulz wrote:
> Hi Trevor,
>
> On 2/18/24 18:28, Trevor Woerner wrote:
> > On Fri 2024-02-16 @ 10:31:36 AM, Quentin Schulz wrote:
> > >
> > >
> > > On 2/16/24 09:25, Trevor Woerner wrote:
> > > > On Thu 2024-02-15 @ 06:45:59 PM, Quentin Schulz wrote:
> > > > > Hi Trevor,
> > > > >
> > > > > On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:
> > > [...]
> > > > > > +UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"
> > > > >
> > > > > FWIW, I don't think /boot is required. bootstd/bootmeth in U-Boot (upstream
> > > > > at the very least) will check for / and then /boot prefix for the paths in
> > > > > extlinux.conf. Not providing /boot means if someone still wants to use a
> > > > > separate boot partition, they wouldn't have to update this variable. But
> > > > > since it's overridable, this is basically up to your preference.
> > > >
> > > > This is a good example of working ahead. The next thing I have queued up is
> > > > a meta-rauc-rockchip example that works generically on all (most?) rockchip
> > > > boards. As part of the U-Boot script I need to make the A/B logic work, it
> > > > needs the "/boot" in there otherwise it doesn't work; therefore it's best to
> > > > set it up properly now.
> > > >
> > >
> > > Mmmm I'm interested to see why it fails without the /boot thing? Let's see
> > > when we get patches :)
> >
> > I'm working on getting rauc working with meta-rockchip generically so it works
> > with all the MACHINES in meta-rockchip. The patch won't be part of
> > meta-rockchip, but rather be part of a meta-rauc-community/meta-rauc-rockchip
> > I hope to submit upstream at some point.
> >
> > Basically rauc works with U-Boot via a boot script. To make that script more
> > flexible I'm borrowing a variable form meta-rockchip in the rauc U-Boot script
> > to actually do the booting of the kernel/fitImage/etc. So while U-Boot might
> > be smart enough to check a bunch of places looking for the thing to boot, the
> > rauc boot script isn't quite so smart. It's my script to write, and I could
> > add such logic, but that would just inflate the script for questionable gain.
> >
>
> This seems like you're not using extlinux.conf when using rauc but using one
> of the variables used to build the extlinux.conf to do some magic/logic in
> rauc?
I'm using sed to search and replace a tag in a U-Boot script template with
UBOOT_EXTLINUX_KERNEL_IMAGE which my U-Boot bbappend then turns into a U-Boot
script that handles the rauc A/B logic.
Specifically once it figures out whether to use A or B,
UBOOT_EXTLINUX_KERNEL_IMAGE is what is booted.
So keeping the initial "/boot/" part of UBOOT_EXTLINUX_KERNEL_IMAGE is useful
to me so the U-Boot script can find what it needs to boot in the filesystem
image. I could strip that prefix from the variable and include it as part of
the script template, but the current way provides the most flexibility. In
theory the fitImage could be located anywhere in the filesystem and the U-Boot
script would be able to find, load, and run it.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [yocto] [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition
2024-02-21 19:18 ` Trevor Woerner
@ 2024-02-22 9:37 ` Quentin Schulz
0 siblings, 0 replies; 16+ messages in thread
From: Quentin Schulz @ 2024-02-22 9:37 UTC (permalink / raw)
To: Trevor Woerner; +Cc: yocto
Hi Trevor,
On 2/21/24 20:18, Trevor Woerner wrote:
> On Wed 2024-02-21 @ 07:31:17 PM, Quentin Schulz wrote:
>> Hi Trevor,
>>
>> On 2/18/24 18:28, Trevor Woerner wrote:
>>> On Fri 2024-02-16 @ 10:31:36 AM, Quentin Schulz wrote:
>>>>
>>>>
>>>> On 2/16/24 09:25, Trevor Woerner wrote:
>>>>> On Thu 2024-02-15 @ 06:45:59 PM, Quentin Schulz wrote:
>>>>>> Hi Trevor,
>>>>>>
>>>>>> On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:
>>>> [...]
>>>>>>> +UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"
>>>>>>
>>>>>> FWIW, I don't think /boot is required. bootstd/bootmeth in U-Boot (upstream
>>>>>> at the very least) will check for / and then /boot prefix for the paths in
>>>>>> extlinux.conf. Not providing /boot means if someone still wants to use a
>>>>>> separate boot partition, they wouldn't have to update this variable. But
>>>>>> since it's overridable, this is basically up to your preference.
>>>>>
>>>>> This is a good example of working ahead. The next thing I have queued up is
>>>>> a meta-rauc-rockchip example that works generically on all (most?) rockchip
>>>>> boards. As part of the U-Boot script I need to make the A/B logic work, it
>>>>> needs the "/boot" in there otherwise it doesn't work; therefore it's best to
>>>>> set it up properly now.
>>>>>
>>>>
>>>> Mmmm I'm interested to see why it fails without the /boot thing? Let's see
>>>> when we get patches :)
>>>
>>> I'm working on getting rauc working with meta-rockchip generically so it works
>>> with all the MACHINES in meta-rockchip. The patch won't be part of
>>> meta-rockchip, but rather be part of a meta-rauc-community/meta-rauc-rockchip
>>> I hope to submit upstream at some point.
>>>
>>> Basically rauc works with U-Boot via a boot script. To make that script more
>>> flexible I'm borrowing a variable form meta-rockchip in the rauc U-Boot script
>>> to actually do the booting of the kernel/fitImage/etc. So while U-Boot might
>>> be smart enough to check a bunch of places looking for the thing to boot, the
>>> rauc boot script isn't quite so smart. It's my script to write, and I could
>>> add such logic, but that would just inflate the script for questionable gain.
>>>
>>
>> This seems like you're not using extlinux.conf when using rauc but using one
>> of the variables used to build the extlinux.conf to do some magic/logic in
>> rauc?
>
> I'm using sed to search and replace a tag in a U-Boot script template with
> UBOOT_EXTLINUX_KERNEL_IMAGE which my U-Boot bbappend then turns into a U-Boot
> script that handles the rauc A/B logic.
>
> Specifically once it figures out whether to use A or B,
> UBOOT_EXTLINUX_KERNEL_IMAGE is what is booted.
>
> So keeping the initial "/boot/" part of UBOOT_EXTLINUX_KERNEL_IMAGE is useful
> to me so the U-Boot script can find what it needs to boot in the filesystem
> image. I could strip that prefix from the variable and include it as part of
> the script template, but the current way provides the most flexibility. In
> theory the fitImage could be located anywhere in the filesystem and the U-Boot
> script would be able to find, load, and run it.
Would be nice if you had some code somewhere we could use as a base for
discussion :)
FWIW, upstream U-Boot seems to have some interest using VBL/VBE for A/B
mechanism, this seems to be pushed by Google? So maybe something to look
there in the future.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2024-02-22 9:37 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 ` [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition Trevor Woerner
2024-02-15 17:45 ` [yocto] " 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
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.