Message ID | 20240222170415.7061-1-twoerner@gmail.com |
---|---|
State | New |
Headers | show |
Series | [meta-rockchip,v4,1/5] rockchip.wks: specify offsets in sectors | expand |
On Thu 2024-02-22 @ 12:04:12 PM, Trevor Woerner via lists.yoctoproject.org wrote: > If the wks file doesn't specify, the assumption is that each partition > contains a vfat-formatted filesystem. Most of the partitions in the > Rockchip layout don't have filesystems. Implicitly setting the fstype to > vfat causes wic to format the partitions. It doesn't make sense to format > the rawcopy partitions as vfat just to immediately overwrite them with > binaries, and it wastes time formatting partitions that won't ever be used > as filesystems. > > Reviewed-by: Quentin Schulz <foss+yocto@0leil.net> > Signed-off-by: Trevor Woerner <twoerner@gmail.com> > --- > changes in v4: > - none > > changes in v3: > - tweak to accommodate offsets specified in sectors > > changes in v2: > - reword the commit message to add clarity > - add Quentin's tag > --- > wic/rockchip.wks | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) Applied to meta-rockchip, master branch.
On Thu 2024-02-22 @ 12:04:13 PM, 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 > > There are 2 partitions at the start that can not be specified in > rockchip.wks due to a limitation in wic which assumes all sizes (e.g. > --size or --fixed-size) are specified in units of 1024 bytes. Since these > partitions don't fall on 1024-byte boundaries, they can not be specified at > this time. > > Note: in the Rockchip layout, not all partitions are expected to show up > in the gpt partition table. While --no-table could be used to hide these > partitions from the partition table, as specified in the wiki, there's > no practical reason to do so. In fact, exposing these partitions in the > partition table makes it easier and safer for users to interact with them. > For example, a user dd'ing some data to a particular area would need to > ensure they're using the correct offset and size values when accessing the > raw disk directly. However being able to specify a partition ensures data > won't accidentally "spill" out into adjacent regions. > > Note: there is a mistake in the Rockchip table (which I've copied verbatim > here in this commit message but corrected in rockchip.wks). Going by the > values of the "Start Sector", the size of the "reserved1" partition is > listed as being 2x its actual size/number of sectors. > > Expected: > Partition Start Sector Number of Sectors Partition Size PartNum in GPT Requirements > MBR 0 00000000 1 00000001 512 0.5KB > Primary GPT 1 00000001 63 0000003F 32256 31.5KB > loader1 64 00000040 7104 00001bc0 4096000 2.5MB 1 preloader (miniloader or U-Boot SPL) > Vendor Storage 7168 00001c00 512 00000200 262144 256KB SN, MAC and etc. > Reserved Space 7680 00001e00 384 00000180 196608 192KB Not used > reserved1 8064 00001f80 128 00000080 65536 64KB legacy DRM key > U-Boot ENV 8128 00001fc0 64 00000040 32768 32KB > reserved2 8192 00002000 8192 00002000 4194304 4MB legacy parameter > loader2 16384 00004000 8192 00002000 4194304 4MB 2 U-Boot or UEFI > trust 24576 00006000 8192 00002000 4194304 4MB 3 trusted-os like ATF, OP-TEE > boot 32768 00008000 229376 00038000 117440512 112MB 4 kernel, dtb, extlinux.conf, ramdisk > rootfs 262144 00040000 - - - -MB 5 Linux system > > Prior to this patch: > # fdisk -l /dev/mmcblk1 > GPT PMBR size mismatch (1504727 != 30375935) will be corrected by write. > The backup GPT table is not on the end of the device. > Disk /dev/mmcblk1: 14.48 GiB, 15552479232 bytes, 30375936 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: gpt > Disk identifier: 00000000-0000-0000-0000-00004D9B9EF0 > > Device Start End Sectors Size Type > /dev/mmcblk1p1 64 8063 8000 3.9M Microsoft basic data > /dev/mmcblk1p2 8064 8191 128 64K Microsoft basic data > /dev/mmcblk1p3 8192 16383 8192 4M Microsoft basic data > /dev/mmcblk1p4 16384 24575 8192 4M Microsoft basic data > /dev/mmcblk1p5 24576 32767 8192 4M Microsoft basic data > /dev/mmcblk1p6 32768 330955 298188 145.6M Microsoft basic data > /dev/mmcblk1p7 330956 1504693 1173738 573.1M Linux filesystem > > New: > # fdisk -l /dev/mmcblk1 > GPT PMBR size mismatch (1504473 != 30375935) will be corrected by write. > The backup GPT table is not on the end of the device. > Disk /dev/mmcblk1: 14.48 GiB, 15552479232 bytes, 30375936 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: gpt > Disk identifier: 00000000-0000-0000-0000-00004D9B9EF0 > > Device Start End Sectors Size Type > /dev/mmcblk1p1 64 7167 7104 3.5M Linux filesystem > /dev/mmcblk1p2 7168 7679 512 256K Linux filesystem > /dev/mmcblk1p3 7680 8063 384 192K Linux filesystem > /dev/mmcblk1p4 8064 8127 64 32K Linux filesystem > /dev/mmcblk1p5 8128 8191 64 32K Linux filesystem > /dev/mmcblk1p6 8192 16383 8192 4M Linux filesystem > /dev/mmcblk1p7 16384 24575 8192 4M Linux filesystem > /dev/mmcblk1p8 24576 32767 8192 4M Linux filesystem > /dev/mmcblk1p9 32768 330955 298188 145.6M Microsoft basic data > /dev/mmcblk1p10 330956 1504439 1173484 573M Linux filesystem > > Reviewed-by: Quentin Schulz <foss+yocto@0leil.net> > Signed-off-by: Trevor Woerner <twoerner@gmail.com> > --- > changes in v4: > - remove all --no-table to include all partitions in the gpt table > > changes in v3: > - tweaked to accommodate offsets specified in sectors > - clarified that the first 2 partitions can not be added > - change name of vstorage to v_storage > - fixed typo (ATR -> ATF) > - added Quentin's tag > > changes in v2: > - expand the commit message to show past, expected, and new behaviour > - spell out that vstorage stands for "vendor storage" > --- > wic/rockchip.wks | 18 ++++++++++++------ > 1 file changed, 12 insertions(+), 6 deletions(-) Applied to meta-rockchip, master branch.
On Thu 2024-02-22 @ 12:04:14 PM, Trevor Woerner via lists.yoctoproject.org wrote: > In order to boot successfully, most Rockchip SoCs require a specific > partitioning scheme which was defined many years (and many SoCs) ago. That > partitioning scheme places the SPL and U-Boot at specific offsets at the > start of the boot block device: > > https://opensource.rock-chips.com/wiki_Partitions > > The Rockchip partitioning scheme goes on to also define the locations > of a number of additional partitions, including the "boot" and "root" > partitions. > > Since both the SPL and U-Boot have already been placed on the block device, > the "boot" partition only contains the extlinux config file and the > kernel+dtb/fitImage; it doesn't contain any bootloader artifacts (other > than the extlinux config). > > The location of the SPL partition is a hard dependency since the BOOTROM > etched inside the Rockchip SoCs is programmed to load and run a validated > binary it finds at this location. The locations of the "boot" and "root" > partitions are not so rigid since it is U-Boot which interacts with them. > U-Boot is very flexible with how it finds boot components, and in its > support for various devices, filesystems, sizes, etc. > > Both oe-core's U-Boot metadata and wic's bootimg-partition script contain > logic to generate the extlinux pieces required for a bootloader to boot > a Linux system. If both are enabled, the wic pieces silently clobber the > U-Boot pieces. However, the mechanisms contained in the U-Boot metadata are > much more flexible, from a user's point of view, than the mechanisms in > wic's bootimg-partition. > > If a user wishes to setup some sort of A/B redundant update mechanism, they > must have redundant root partitions (in order to update their filesystem > contents) but they also need to have redundant boot partitions if they > wish to update the kernel as part of their update mechanism. Pairing > redundant kernel partitions with redundant filesystem partitions becomes > unnecessarily complicated. Therefore it makes sense to combine the kernel > and the filesystem into the same partition so that both the kernel and > filesystem are updated, or rolled back, in lock-step as one unit. Specific > kernel versions and configurations often have dependencies on user-space > components and versions. > > The /boot location is not going away. This patch simply transfers > responsibility for its creation to the more flexible U-Boot mechanism > and includes the kernel as part of the same partition as the root > filesystem. Not only does it add flexibility, it also makes update schemes > more straightforward. Although having a separate /boot partition is a > "requirement" of the Rockchip partitioning scheme, it is not an actual > hard requirement when using a flexible, open-source bootloader (such as > U-Boot) instead of using Rockchip's proprietary miniloader, preloader, and > trust.img. > > Build-tested for all boards. > Run-tested on: > nanopi-m4-2gb, nanopi-m4b, nanopi-r2s, nanopi-r4s, roc-rk3328-cc, > rock-3a, rock-5a, rock-5b, rock-pi-4b, rock-pi-e, rock-pi-s, > rock64 > > Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> > Signed-off-by: Trevor Woerner <twoerner@gmail.com> > --- > changes in v4: > - updated for latest rockchip.wks > - remove offset for /boot partition (let wic calculate this) > > changes in v3: > - add back the comment explaining the need for NONFITDT > - change the inclusion of the u-boot-extlinux package from RRECOMMENDS > to RDEPENDS > - clarify the commit message to remove the un-true statement that sizes > are hard requirements > - add back the "--ptable gpt" line to rockchip.wks > > changes in v2: > - add UBOOT_EXTLINUX_FDT and tweak UBOOT_EXTLINUX_FDTDIR to modify their > behaviour based on whether or not KERNEL_IMAGETYPE is fitImage > - remove extraneous WKS_FILE_DEPENDS > - remove "--ptable gpt" from wks > - move newly added "earlycon" to UBOOT_EXTLINUX_CONSOLE > - re-word the commit message to better explain the behaviour of the > Rockchip BootROM > --- > conf/machine/include/rockchip-defaults.inc | 2 ++ > conf/machine/include/rockchip-extlinux.inc | 24 ++++++++++++++++++++++ > conf/machine/include/rockchip-wic.inc | 20 ++---------------- > wic/rockchip.wks | 12 +++++------ > 4 files changed, 33 insertions(+), 25 deletions(-) > create mode 100644 conf/machine/include/rockchip-extlinux.inc Applied to meta-rockchip, master branch.
On Thu 2024-02-22 @ 12:04:15 PM, Trevor Woerner via lists.yoctoproject.org wrote: > Cleanup the elements of the wic/rockchip.wks file so that they take up less > horizontal space. > > Reviewed-by: Quentin Schulz <foss+yocto@0leil.net> > Signed-off-by: Trevor Woerner <twoerner@gmail.com> > --- > changes in v4: > - updated for latest rockchip.wks > > changes in v3: > - tweaks to accommodate the existing changes > > changes in v2: > - add Quentin's tag > --- > wic/rockchip.wks | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) Applied to meta-rockchip, master branch.
diff --git a/wic/rockchip.wks b/wic/rockchip.wks index fac0b8f70112..804e84ceb316 100644 --- a/wic/rockchip.wks +++ b/wic/rockchip.wks @@ -5,8 +5,7 @@ # short-description: Create a disk image suitable for booting Rockchip from SD-card # long-description: Creates a disk image partitioned using GPT, suitable for Rockchip # Disk layout -# Note that the reference documentation refers to 512 byte disk sectors, but -# wic uses 1KB blocks. The following table uses 512 byte sectors: +# See: https://opensource.rock-chips.com/wiki_Partitions # # Partition Start Sector Number of Sectors # loader1 64 8000 (idbloader / U-Boot SPL) @@ -17,12 +16,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 loader1 --offset 64s --fixed-size 4000K --source rawcopy --sourceparams="file=${SPL_BINARY}" +part reserved1 --offset 8064s --fixed-size 64K +part reserved2 --offset 8192s --fixed-size 4096K +part loader2 --offset 16384s --fixed-size 4096K --source rawcopy --sourceparams="file=u-boot.${UBOOT_SUFFIX}" +part atf --offset 24576s --fixed-size 4096K +part /boot --offset 32768s --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 bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 init=/sbin/init"