[meta-rockchip,v4,1/5] rockchip.wks: specify offsets in sectors

In WIC, size arguments can be optionally specified using one of a variety
of suffixes (e.g. K, M, G, etc.) thanks to sizetype(). One such suffix being
"s/S" for handling sector sizes which are assumed to be 512 bytes, rather than
the other size suffixes which are multiples of 1024 bytes.

Using the s/S sizetype allows the definition to match the documentation.
Unfortunately we can not use the s/S suffix for --fixed-size.

Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
changes in v4:
- add Quentin's tag

changes in v3:
- new
---
 wic/rockchip.wks | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

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.