* [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
* 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 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 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
* [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
* 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 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 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
* [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 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 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
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.