[Buildroot] [PATCH v3 0/4] rock5b improvements

[Buildroot] [PATCH v3 0/4] rock5b improvements

[Niklas Cassel via buildroot]

From: Niklas Cassel <cassel@kernel.org>

This series depends on:
https://lore.kernel.org/buildroot/20241013103341.78501-1-bernd@kuhls.net/
which adds support for linux 6.11.x.


Hello all,

The first patch updates linux to 6.11.3.

The second patch updates uboot to 2024.10.

The third patch uses a more correct partition-type-uuid.

The fourth patch defines a uboot-env on the SD card,
so that setenv and saveenv commands can be used.


Kind regards,
Niklas


Changes since v2:
-Bump linux to an even newer version (6.11.3).
-Bump uboot to an even newer version (2024.10).


Niklas Cassel (4):
  configs/rock5b: update to linux 6.11.3
  configs/rock5b: update to uboot 2024.10
  configs/rock5b: use the arm64 rootfs partition-type-uuid
  configs/rock5b: enable uboot-env on the SD card

 board/radxa/rock5b/genimage.cfg             |  8 +++++++-
 board/radxa/rock5b/patches/linux/linux.hash |  4 ++--
 board/radxa/rock5b/patches/uboot/uboot.hash |  2 +-
 board/radxa/rock5b/u-boot.fragment          |  5 +++++
 configs/rock5b_defconfig                    | 10 +++++++---
 5 files changed, 22 insertions(+), 7 deletions(-)
 create mode 100644 board/radxa/rock5b/u-boot.fragment

-- 
2.47.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 1/4] configs/rock5b: update to linux 6.11.3

[Niklas Cassel via buildroot]

From: Niklas Cassel <cassel@kernel.org>

A bunch of new hardware has been enabled for rock5b in linux 6.11,
most notably USB3 host controller support, GPU support, cpufreq
support, and PCIe endpoint mode support.

Add the dependency on host python3 that is new since linux 6.10.

Also add the missing dependency on openssl (which has been needed for
a long time, since we are using arm64 defconfig, but only shows up as
an error if the host system doesn't have extract-cert installed.)

Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 board/radxa/rock5b/patches/linux/linux.hash | 4 ++--
 configs/rock5b_defconfig                    | 6 ++++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/board/radxa/rock5b/patches/linux/linux.hash b/board/radxa/rock5b/patches/linux/linux.hash
index ba90c84f54..005667b1f1 100644
--- a/board/radxa/rock5b/patches/linux/linux.hash
+++ b/board/radxa/rock5b/patches/linux/linux.hash
@@ -1,2 +1,2 @@
-# Locally calculated
-sha256  f68d9f5ffc0a24f850699b86c8aea8b8687de7384158d5ed3bede37de098d60c  linux-6.7.4.tar.xz
+# From https://www.kernel.org/pub/linux/kernel/v6.x/sha256sums.asc
+sha256  057263d0afc17d5253794afd3d239ba4da4aa734b22fa36c1665f41b95449b73  linux-6.11.3.tar.xz
diff --git a/configs/rock5b_defconfig b/configs/rock5b_defconfig
index 4d5e7ca583..bc7b73d652 100644
--- a/configs/rock5b_defconfig
+++ b/configs/rock5b_defconfig
@@ -1,6 +1,6 @@
 BR2_aarch64=y
 BR2_cortex_a76_a55=y
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_7=y
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_11=y
 BR2_GLOBAL_PATCH_DIR="board/radxa/rock5b/patches"
 BR2_DOWNLOAD_FORCE_CHECK_HASHES=y
 BR2_TARGET_GENERIC_HOSTNAME="rock5b"
@@ -12,13 +12,15 @@ BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh"
 BR2_ROOTFS_POST_SCRIPT_ARGS="-c board/radxa/rock5b/genimage.cfg"
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.7.4"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.11.3"
 BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
 BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/radxa/rock5b/linux.fragment"
 BR2_LINUX_KERNEL_DTS_SUPPORT=y
 BR2_LINUX_KERNEL_INTREE_DTS_NAME="rockchip/rk3588-rock-5b"
 BR2_LINUX_KERNEL_DTB_OVERLAY_SUPPORT=y
 BR2_LINUX_KERNEL_INSTALL_TARGET=y
+BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
+BR2_LINUX_KERNEL_NEEDS_HOST_PYTHON3=y
 BR2_PACKAGE_LINUX_FIRMWARE=y
 BR2_PACKAGE_LINUX_FIRMWARE_RTL_8169=y
 BR2_PACKAGE_ROCKCHIP_RKBIN=y
-- 
2.47.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 1/4] configs/rock5b: update to linux 6.11.3

[Thomas Petazzoni via buildroot]

On Wed, 16 Oct 2024 15:24:40 +0200
Niklas Cassel via buildroot <buildroot@buildroot.org> wrote:

> From: Niklas Cassel <cassel@kernel.org>
> 
> A bunch of new hardware has been enabled for rock5b in linux 6.11,
> most notably USB3 host controller support, GPU support, cpufreq
> support, and PCIe endpoint mode support.
> 
> Add the dependency on host python3 that is new since linux 6.10.
> 
> Also add the missing dependency on openssl (which has been needed for
> a long time, since we are using arm64 defconfig, but only shows up as
> an error if the host system doesn't have extract-cert installed.)
> 
> Signed-off-by: Niklas Cassel <cassel@kernel.org>
> ---
>  board/radxa/rock5b/patches/linux/linux.hash | 4 ++--
>  configs/rock5b_defconfig                    | 6 ++++--
>  2 files changed, 6 insertions(+), 4 deletions(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 1/4] configs/rock5b: update to linux 6.11.3

[Niklas Cassel via buildroot]

On Tue, Oct 22, 2024 at 10:46:31PM +0200, Thomas Petazzoni wrote:
> On Wed, 16 Oct 2024 15:24:40 +0200
> Niklas Cassel via buildroot <buildroot@buildroot.org> wrote:
> 
> > From: Niklas Cassel <cassel@kernel.org>
> > 
> > A bunch of new hardware has been enabled for rock5b in linux 6.11,
> > most notably USB3 host controller support, GPU support, cpufreq
> > support, and PCIe endpoint mode support.
> > 
> > Add the dependency on host python3 that is new since linux 6.10.
> > 
> > Also add the missing dependency on openssl (which has been needed for
> > a long time, since we are using arm64 defconfig, but only shows up as
> > an error if the host system doesn't have extract-cert installed.)
> > 
> > Signed-off-by: Niklas Cassel <cassel@kernel.org>
> > ---
> >  board/radxa/rock5b/patches/linux/linux.hash | 4 ++--
> >  configs/rock5b_defconfig                    | 6 ++++--
> >  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> Applied to master, thanks.

Hello Thomas,

It appears that you missed the cover letter for this series, which stated:
"""
This series depends on:
https://lore.kernel.org/buildroot/20241013103341.78501-1-bernd@kuhls.net/
which adds support for linux 6.11.x.
"""

I do not see this dependency on master yet.

So I think you need to also apply the series that adds support for linux 6.11.

I don't see a reason why it hasn't been merged yet.
Bernd's first patch series that added support for 6.11 was sent in September
(2024-09-17), the series that I link to above is his V2 (even though he didn't
mark it as V2) which he sent in October (2024-10-13).


Kind regards,
Niklas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 1/4] configs/rock5b: update to linux 6.11.3

[Niklas Cassel via buildroot]

On Tue, Oct 22, 2024 at 11:08:12PM +0200, Niklas Cassel wrote:
> On Tue, Oct 22, 2024 at 10:46:31PM +0200, Thomas Petazzoni wrote:
> > On Wed, 16 Oct 2024 15:24:40 +0200
> > Niklas Cassel via buildroot <buildroot@buildroot.org> wrote:
> > 
> > > From: Niklas Cassel <cassel@kernel.org>
> > > 
> > > A bunch of new hardware has been enabled for rock5b in linux 6.11,
> > > most notably USB3 host controller support, GPU support, cpufreq
> > > support, and PCIe endpoint mode support.
> > > 
> > > Add the dependency on host python3 that is new since linux 6.10.
> > > 
> > > Also add the missing dependency on openssl (which has been needed for
> > > a long time, since we are using arm64 defconfig, but only shows up as
> > > an error if the host system doesn't have extract-cert installed.)
> > > 
> > > Signed-off-by: Niklas Cassel <cassel@kernel.org>
> > > ---
> > >  board/radxa/rock5b/patches/linux/linux.hash | 4 ++--
> > >  configs/rock5b_defconfig                    | 6 ++++--
> > >  2 files changed, 6 insertions(+), 4 deletions(-)
> > 
> > Applied to master, thanks.
> 
> Hello Thomas,
> 
> It appears that you missed the cover letter for this series, which stated:
> """
> This series depends on:
> https://lore.kernel.org/buildroot/20241013103341.78501-1-bernd@kuhls.net/
> which adds support for linux 6.11.x.
> """
> 
> I do not see this dependency on master yet.
> 
> So I think you need to also apply the series that adds support for linux 6.11.
> 
> I don't see a reason why it hasn't been merged yet.
> Bernd's first patch series that added support for 6.11 was sent in September
> (2024-09-17), the series that I link to above is his V2 (even though he didn't
> mark it as V2) which he sent in October (2024-10-13).

And now just a few minutes later I see that you picked up the linux 6.11
series :)


Kind regards,
Niklas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 1/4] configs/rock5b: update to linux 6.11.3

[Thomas Petazzoni via buildroot]

Hello Niklas,

On Tue, 22 Oct 2024 21:08:14 +0000
Niklas Cassel <Niklas.Cassel@wdc.com> wrote:

> It appears that you missed the cover letter for this series, which stated:
> """
> This series depends on:
> https://lore.kernel.org/buildroot/20241013103341.78501-1-bernd@kuhls.net/
> which adds support for linux 6.11.x.
> """

Gah, indeed, I had missed that. In fact, I very often miss the cover
letters, as they are not well visible in patchwork. I see the commit
logs of the patches themselves of course, but not really the cover
letter. I should pay more attention to this.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 1/4] configs/rock5b: update to linux 6.11.3

[Kilian Zinnecker via buildroot]

Hey Niklas,

> A bunch of new hardware has been enabled for rock5b in linux 6.11,
> most notably USB3 host controller support, GPU support, cpufreq
> support, and PCIe endpoint mode support.
> 
> Add the dependency on host python3 that is new since linux 6.10.
> 
> Also add the missing dependency on openssl (which has been needed for
> a long time, since we are using arm64 defconfig, but only shows up as
> an error if the host system doesn't have extract-cert installed.)

Thanks for updating to 6.11

Best regards,
Kilian
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 2/4] configs/rock5b: update to uboot 2024.10

[Niklas Cassel via buildroot]

From: Niklas Cassel <cassel@kernel.org>

Newer uboot versions contain commit ebb0ad4eef0a ("arch: arm:
mach-rockchip: Kconfig: Enable BOOTSTD_FULL for RK3399 and RK3588"),
which enables BOOTSTD_FULL for RK3588, making it easier to figure
out issues with the bootflow, if any.

Also add the GnuTLS dependency which is needed for uboot 2024.10.

Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 board/radxa/rock5b/patches/uboot/uboot.hash | 2 +-
 configs/rock5b_defconfig                    | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/board/radxa/rock5b/patches/uboot/uboot.hash b/board/radxa/rock5b/patches/uboot/uboot.hash
index bc999536af..904fa56c02 100644
--- a/board/radxa/rock5b/patches/uboot/uboot.hash
+++ b/board/radxa/rock5b/patches/uboot/uboot.hash
@@ -1,2 +1,2 @@
 # Locally calculated
-sha256  b99611f1ed237bf3541bdc8434b68c96a6e05967061f992443cb30aabebef5b3  u-boot-2024.01.tar.bz2
+sha256  b28daf4ac17e43156363078bf510297584137f6df50fced9b12df34f61a92fb0  u-boot-2024.10.tar.bz2
diff --git a/configs/rock5b_defconfig b/configs/rock5b_defconfig
index bc7b73d652..d75ad585fb 100644
--- a/configs/rock5b_defconfig
+++ b/configs/rock5b_defconfig
@@ -32,11 +32,12 @@ BR2_TARGET_ROOTFS_EXT2_SIZE="250M"
 BR2_TARGET_UBOOT=y
 BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
 BR2_TARGET_UBOOT_CUSTOM_VERSION=y
-BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2024.01"
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2024.10"
 BR2_TARGET_UBOOT_BOARD_DEFCONFIG="rock5b-rk3588"
 BR2_TARGET_UBOOT_NEEDS_PYLIBFDT=y
 BR2_TARGET_UBOOT_NEEDS_PYELFTOOLS=y
 BR2_TARGET_UBOOT_NEEDS_OPENSSL=y
+BR2_TARGET_UBOOT_NEEDS_GNUTLS=y
 BR2_TARGET_UBOOT_NEEDS_ROCKCHIP_RKBIN=y
 BR2_PACKAGE_HOST_DOSFSTOOLS=y
 BR2_PACKAGE_HOST_DTC=y
-- 
2.47.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 2/4] configs/rock5b: update to uboot 2024.10

[Thomas Petazzoni via buildroot]

On Wed, 16 Oct 2024 15:24:41 +0200
Niklas Cassel via buildroot <buildroot@buildroot.org> wrote:

> From: Niklas Cassel <cassel@kernel.org>
> 
> Newer uboot versions contain commit ebb0ad4eef0a ("arch: arm:
> mach-rockchip: Kconfig: Enable BOOTSTD_FULL for RK3399 and RK3588"),
> which enables BOOTSTD_FULL for RK3588, making it easier to figure
> out issues with the bootflow, if any.
> 
> Also add the GnuTLS dependency which is needed for uboot 2024.10.
> 
> Signed-off-by: Niklas Cassel <cassel@kernel.org>
> ---
>  board/radxa/rock5b/patches/uboot/uboot.hash | 2 +-
>  configs/rock5b_defconfig                    | 3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 3/4] configs/rock5b: use the arm64 rootfs partition-type-uuid

[Niklas Cassel via buildroot]

From: Niklas Cassel <cassel@kernel.org>

Use the arm64 rootfs partition-type-uuid instead of the generic "Linux
filesystem" partition-type-uuid.

This is strictly more correct. No functional change introduced.

Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 board/radxa/rock5b/genimage.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/radxa/rock5b/genimage.cfg b/board/radxa/rock5b/genimage.cfg
index 43bb65bdd9..8c56251135 100644
--- a/board/radxa/rock5b/genimage.cfg
+++ b/board/radxa/rock5b/genimage.cfg
@@ -12,7 +12,7 @@ image sdcard.img {
 	}
 
 	partition rootfs {
-		partition-type-uuid = L
+		partition-type-uuid = root-arm64
 		image = "rootfs.ext2"
 	}
 }
-- 
2.47.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 3/4] configs/rock5b: use the arm64 rootfs partition-type-uuid

[Thomas Petazzoni via buildroot]

Hello Niklas,

On Wed, 16 Oct 2024 15:24:42 +0200
Niklas Cassel via buildroot <buildroot@buildroot.org> wrote:

> diff --git a/board/radxa/rock5b/genimage.cfg b/board/radxa/rock5b/genimage.cfg
> index 43bb65bdd9..8c56251135 100644
> --- a/board/radxa/rock5b/genimage.cfg
> +++ b/board/radxa/rock5b/genimage.cfg
> @@ -12,7 +12,7 @@ image sdcard.img {
>  	}
>  
>  	partition rootfs {
> -		partition-type-uuid = L
> +		partition-type-uuid = root-arm64

In principle, this looks fine, but this "breaks" the pattern that we
have document in the Buildroot manual at
https://buildroot.org/downloads/manual/manual.html#writing-genimage-cfg:

   For GPT partitions, the partition-type-uuid value must be U for the
   EFI System Partition (expanded to
   c12a7328-f81f-11d2-ba4b-00a0c93ec93b by genimage), F for a FAT
   partition (expanded to ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 by
   genimage) or L for the root filesystem or other filesystems
   (expanded to 0fc63daf-8483-4772-8e79-3d69d8477de4 by genimage). Even
   though L is the default value of genimage, we prefer to have it
   explicitly specified in our genimage.cfg files. Finally, these
   shortcuts should be used without double quotes, e.g
   partition-type-uuid = U. If an explicit GUID is specified,
   lower-case letters should be used. 

That being said, we already have a few genimage.cfg files that use
b921b045-1df0-41c3-af44-4c6f280d3fae which is root-arm64:

board/aarch64-efi/genimage-efi.cfg:             partition-type-uuid = b921b045-1df0-41c3-af44-4c6f280d3fae
board/arm/fvp-ebbr/genimage.cfg:                partition-type-uuid = b921b045-1df0-41c3-af44-4c6f280d3fae
board/pine64/rockpro64/genimage.cfg:            partition-type-uuid = b921b045-1df0-41c3-af44-4c6f280d3fae
board/qemu/aarch64-ebbr/genimage.cfg:           partition-type-uuid = b921b045-1df0-41c3-af44-4c6f280d3fae
board/qemu/aarch64-sbsa/genimage.cfg:           partition-type-uuid = b921b045-1df0-41c3-af44-4c6f280d3fae

My point is that we want *consistency*. So either we use "L" for all
rootfs partitions. Or we use root-${ARCH} for all rootfs partitions.
But we don't use "L" for some, "root-${ARCH}" for some others, and a
complete UUID in the matching a known root-${ARCH} for yet some others.
I don't have a strong opinion either way between L or root-${ARCH}, all
I'm expecting is consistency, between the defconfigs, and with the
manual.

Do you want to tackle this? :-)

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 3/4] configs/rock5b: use the arm64 rootfs partition-type-uuid

[Niklas Cassel via buildroot]

On Tue, Oct 22, 2024 at 10:49:45PM +0200, Thomas Petazzoni wrote:
> Hello Niklas,
> 
> On Wed, 16 Oct 2024 15:24:42 +0200
> Niklas Cassel via buildroot <buildroot@buildroot.org> wrote:
> 
> > diff --git a/board/radxa/rock5b/genimage.cfg b/board/radxa/rock5b/genimage.cfg
> > index 43bb65bdd9..8c56251135 100644
> > --- a/board/radxa/rock5b/genimage.cfg
> > +++ b/board/radxa/rock5b/genimage.cfg
> > @@ -12,7 +12,7 @@ image sdcard.img {
> >  	}
> >  
> >  	partition rootfs {
> > -		partition-type-uuid = L
> > +		partition-type-uuid = root-arm64
> 
> In principle, this looks fine, but this "breaks" the pattern that we
> have document in the Buildroot manual at
> https://buildroot.org/downloads/manual/manual.html#writing-genimage-cfg:
> 
>    For GPT partitions, the partition-type-uuid value must be U for the
>    EFI System Partition (expanded to
>    c12a7328-f81f-11d2-ba4b-00a0c93ec93b by genimage), F for a FAT
>    partition (expanded to ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 by
>    genimage) or L for the root filesystem or other filesystems
>    (expanded to 0fc63daf-8483-4772-8e79-3d69d8477de4 by genimage). Even
>    though L is the default value of genimage, we prefer to have it
>    explicitly specified in our genimage.cfg files. Finally, these
>    shortcuts should be used without double quotes, e.g
>    partition-type-uuid = U. If an explicit GUID is specified,
>    lower-case letters should be used. 
> 
> That being said, we already have a few genimage.cfg files that use
> b921b045-1df0-41c3-af44-4c6f280d3fae which is root-arm64:
> 
> board/aarch64-efi/genimage-efi.cfg:             partition-type-uuid = b921b045-1df0-41c3-af44-4c6f280d3fae
> board/arm/fvp-ebbr/genimage.cfg:                partition-type-uuid = b921b045-1df0-41c3-af44-4c6f280d3fae
> board/pine64/rockpro64/genimage.cfg:            partition-type-uuid = b921b045-1df0-41c3-af44-4c6f280d3fae
> board/qemu/aarch64-ebbr/genimage.cfg:           partition-type-uuid = b921b045-1df0-41c3-af44-4c6f280d3fae
> board/qemu/aarch64-sbsa/genimage.cfg:           partition-type-uuid = b921b045-1df0-41c3-af44-4c6f280d3fae
> 
> My point is that we want *consistency*. So either we use "L" for all
> rootfs partitions. Or we use root-${ARCH} for all rootfs partitions.
> But we don't use "L" for some, "root-${ARCH}" for some others, and a
> complete UUID in the matching a known root-${ARCH} for yet some others.
> I don't have a strong opinion either way between L or root-${ARCH}, all
> I'm expecting is consistency, between the defconfigs, and with the
> manual.
> 
> Do you want to tackle this? :-)

I don't feel comfortable to change it for platforms that I don't have
access too.

The reason why I saw this was because u-boot has support for searching
for a suitable rootfs (if CONFIG_PARTITION_TYPE_GUID).

and then specifying the type using type=
in e.g. PARTS_DEFAULT.

However:
1) rock5b does not have the uboot CONFIG_PARTITION_TYPE_GUID Kconfig enabled.
2) rockchip is incorrectly specifying the arm64 partition type GUID:
https://github.com/u-boot/u-boot/blob/master/include/configs/rockchip-common.h#L19
using uuid= and not type=.

So currently a uboot built for rockchip will only automatically find the rootfs
partition if the rootfs partition (incorrectly) has set the partition UUID to
the arm64 partition type UUID.
Rock5b in buildroot does not rely on this automatic finding of rootfs anyway,
so all good.

However, there might be other uboot configurations in uboot that actually has
set the type= a specific partition type GUID in PARTS_DEFAULT, and I don't
want to risk breaking any platform.

As written in the commit log, the patch in $subject does not introduce any
functional change, so it is completely fine to ignore this patch.


Kind regards,
Niklas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 3/4] configs/rock5b: use the arm64 rootfs partition-type-uuid

[Thomas Petazzoni via buildroot]

Hello Niklas,

On Tue, 22 Oct 2024 21:50:51 +0000
Niklas Cassel <Niklas.Cassel@wdc.com> wrote:

> I don't feel comfortable to change it for platforms that I don't have
> access too.

Absolutely, but we can evolve what we can consider to be "the best
practice", documented in the manual.

> The reason why I saw this was because u-boot has support for searching
> for a suitable rootfs (if CONFIG_PARTITION_TYPE_GUID).
> 
> and then specifying the type using type=
> in e.g. PARTS_DEFAULT.

PARTS_DEFAULT is used to assign the "partitions" environment variable,
but I don't see anything that uses that except the fastboot
implementation. So I believe this PARTS_DEFAULT is only used in
conjunction with fastboot, which is irrelevant to our discussion.

> However:
> 1) rock5b does not have the uboot CONFIG_PARTITION_TYPE_GUID Kconfig enabled.
> 2) rockchip is incorrectly specifying the arm64 partition type GUID:
> https://github.com/u-boot/u-boot/blob/master/include/configs/rockchip-common.h#L19
> using uuid= and not type=.

Again, this is only used for fastboot I believe, so not relevant.

> So currently a uboot built for rockchip will only automatically find the rootfs
> partition if the rootfs partition (incorrectly) has set the partition UUID to
> the arm64 partition type UUID.

I don't think so, at least based on the evidence that you provide.

> Rock5b in buildroot does not rely on this automatic finding of rootfs anyway,
> so all good.
> 
> However, there might be other uboot configurations in uboot that actually has
> set the type= a specific partition type GUID in PARTS_DEFAULT, and I don't
> want to risk breaking any platform.

See above.

I must say I'm a bit confused by your reasoning, which I have a hard
time following. Could you walk me more step by step? Either I'm missing
something (very possible), or you're missing something (also possible,
considering how crazy the U-Boot environment and boot flow is...).

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 3/4] configs/rock5b: use the arm64 rootfs partition-type-uuid

[Niklas Cassel via buildroot]

Hello Thomas,

On Wed, Oct 23, 2024 at 06:19:18PM +0200, Thomas Petazzoni wrote:
> Hello Niklas,
> 
> On Tue, 22 Oct 2024 21:50:51 +0000
> Niklas Cassel <Niklas.Cassel@wdc.com> wrote:
> 
> > I don't feel comfortable to change it for platforms that I don't have
> > access too.
> 
> Absolutely, but we can evolve what we can consider to be "the best
> practice", documented in the manual.
> 
> > The reason why I saw this was because u-boot has support for searching
> > for a suitable rootfs (if CONFIG_PARTITION_TYPE_GUID).
> > 
> > and then specifying the type using type=
> > in e.g. PARTS_DEFAULT.
> 
> PARTS_DEFAULT is used to assign the "partitions" environment variable,
> but I don't see anything that uses that except the fastboot
> implementation. So I believe this PARTS_DEFAULT is only used in
> conjunction with fastboot, which is irrelevant to our discussion.

I see.

There obviously is code in uboot to automatically detect and use the
uboot-environment based on the u-boot-env partition type GUID being detected.

I didn't know if any u-boot code actually used PARTS_DEFAULT, or the
root-arm64 partition type GUID, so it seemed better not to change the
partition type GUID for any board I do not have access to.

I could imagine some board supported by buildroot perhaps having a custom
uboot script/config/patch that somehow depends on the rootfs GPT partition
type GUID being what they currently have configured in their genimage.cfg.

I tried to do a 'git grep ",type="' in buildroot, but I couldn't find
anything interesting.

I did find some ',type=' matches (related to PARTS_DEFAULT) in u-boot:
https://github.com/u-boot/u-boot/blob/v2024.10/include/configs/starfive-visionfive2.h#L25
https://github.com/u-boot/u-boot/blob/v2024.10/include/configs/sifive-unleashed.h#L38

But perhaps PARTS_DEFAULT is only used by the fastboot support in u-boot,
like you said.


> I must say I'm a bit confused by your reasoning, which I have a hard
> time following. Could you walk me more step by step? Either I'm missing
> something (very possible), or you're missing something (also possible,
> considering how crazy the U-Boot environment and boot flow is...).

I think that it is most likely me who was missing something :)

It is most likely safe to change the GPT partition type GUID for boards
that use u-boot. (I have no idea about edk2 boards though...)

I've already spent way too much time on getting the u-boot environment
to work in a nice way. (I am happy for all the feedback that you gave,
because of that we finally have a nice solution that hopefully will be
emulated/copied by other boards.)

But I have to respectfully decline to clean up the inconsistency with
regards to root-arm64 vs b921b045-1df0-41c3-af44-4c6f280d3fae vs L.

I have too many things on my todo list already (including some important
non-trivial tasks that I wish I had finished already (if they only weren't
so non-trivial :P)).


Kind regards,
Niklas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 4/4] configs/rock5b: enable uboot-env on the SD card

[Niklas Cassel via buildroot]

From: Niklas Cassel <cassel@kernel.org>

Having the uboot environment defined on the SD card allows the user to
use the uboot setenv and saveenv commands to make persistent changes
(e.g. to change the boot order, or to set a server IP for PXE boot).

We need to mark the root partition as bootable, otherwise uboot will no
longer be able to boot the partition by default. (Most likely because
the root partition is now no longer the first partition on the device.)

Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 board/radxa/rock5b/genimage.cfg    | 6 ++++++
 board/radxa/rock5b/u-boot.fragment | 5 +++++
 configs/rock5b_defconfig           | 1 +
 3 files changed, 12 insertions(+)
 create mode 100644 board/radxa/rock5b/u-boot.fragment

diff --git a/board/radxa/rock5b/genimage.cfg b/board/radxa/rock5b/genimage.cfg
index 8c56251135..8ec7780c6c 100644
--- a/board/radxa/rock5b/genimage.cfg
+++ b/board/radxa/rock5b/genimage.cfg
@@ -11,8 +11,14 @@ image sdcard.img {
 		offset = 32K
 	}
 
+	partition uboot-env {
+		offset = 16M
+		size = 64K
+	}
+
 	partition rootfs {
 		partition-type-uuid = root-arm64
 		image = "rootfs.ext2"
+		bootable = true
 	}
 }
diff --git a/board/radxa/rock5b/u-boot.fragment b/board/radxa/rock5b/u-boot.fragment
new file mode 100644
index 0000000000..e332bc0c79
--- /dev/null
+++ b/board/radxa/rock5b/u-boot.fragment
@@ -0,0 +1,5 @@
+CONFIG_SYS_MMC_ENV_DEV=1
+CONFIG_ENV_SIZE=0x10000
+CONFIG_ENV_OFFSET=0x1000000
+# CONFIG_ENV_IS_NOWHERE is not set
+CONFIG_ENV_IS_IN_MMC=y
diff --git a/configs/rock5b_defconfig b/configs/rock5b_defconfig
index d75ad585fb..af748a5d25 100644
--- a/configs/rock5b_defconfig
+++ b/configs/rock5b_defconfig
@@ -34,6 +34,7 @@ BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
 BR2_TARGET_UBOOT_CUSTOM_VERSION=y
 BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2024.10"
 BR2_TARGET_UBOOT_BOARD_DEFCONFIG="rock5b-rk3588"
+BR2_TARGET_UBOOT_CONFIG_FRAGMENT_FILES="board/radxa/rock5b/u-boot.fragment"
 BR2_TARGET_UBOOT_NEEDS_PYLIBFDT=y
 BR2_TARGET_UBOOT_NEEDS_PYELFTOOLS=y
 BR2_TARGET_UBOOT_NEEDS_OPENSSL=y
-- 
2.47.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 4/4] configs/rock5b: enable uboot-env on the SD card

[Thomas Petazzoni via buildroot]

Hello Niklas,

On Wed, 16 Oct 2024 15:24:43 +0200
Niklas Cassel via buildroot <buildroot@buildroot.org> wrote:

> +	partition uboot-env {
> +		offset = 16M
> +		size = 64K
> +	}
> +
>  	partition rootfs {
>  		partition-type-uuid = root-arm64
>  		image = "rootfs.ext2"
> +		bootable = true
>  	}
>  }
> diff --git a/board/radxa/rock5b/u-boot.fragment b/board/radxa/rock5b/u-boot.fragment
> new file mode 100644
> index 0000000000..e332bc0c79
> --- /dev/null
> +++ b/board/radxa/rock5b/u-boot.fragment
> @@ -0,0 +1,5 @@
> +CONFIG_SYS_MMC_ENV_DEV=1
> +CONFIG_ENV_SIZE=0x10000
> +CONFIG_ENV_OFFSET=0x1000000

Hardcoding an offset isn't super nice. Could you try using
CONFIG_SYS_MMC_ENV_PART instead? It isn't clear to me how it interacts
CONFIG_ENV_OFFSET.

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 4/4] configs/rock5b: enable uboot-env on the SD card

[Niklas Cassel via buildroot]

Hello Thomas,

On Tue, Oct 22, 2024 at 10:50:40PM +0200, Thomas Petazzoni wrote:
> Hello Niklas,
> 
> On Wed, 16 Oct 2024 15:24:43 +0200
> Niklas Cassel via buildroot <buildroot@buildroot.org> wrote:
> 
> > +	partition uboot-env {
> > +		offset = 16M
> > +		size = 64K
> > +	}
> > +
> >  	partition rootfs {
> >  		partition-type-uuid = root-arm64
> >  		image = "rootfs.ext2"
> > +		bootable = true
> >  	}
> >  }
> > diff --git a/board/radxa/rock5b/u-boot.fragment b/board/radxa/rock5b/u-boot.fragment
> > new file mode 100644
> > index 0000000000..e332bc0c79
> > --- /dev/null
> > +++ b/board/radxa/rock5b/u-boot.fragment
> > @@ -0,0 +1,5 @@
> > +CONFIG_SYS_MMC_ENV_DEV=1
> > +CONFIG_ENV_SIZE=0x10000
> > +CONFIG_ENV_OFFSET=0x1000000
> 
> Hardcoding an offset isn't super nice. Could you try using
> CONFIG_SYS_MMC_ENV_PART instead? It isn't clear to me how it interacts
> CONFIG_ENV_OFFSET.

I can't use CONFIG_SYS_MMC_ENV_PART.

If you read the Kconfig help text:
"""
MMC hardware partition device number on the platform where the
environment is stored.  Note that this is not related to any software
defined partition table but instead if we are in the user area, which is
partition 0 or the first boot partition, which is 1 or some other defined
partition.
"""

So CONFIG_SYS_MMC_ENV_PART is about specifying a MMC specific hwpartition,
which is different from a GPT partition (which is usually stored in a MMC
"user area" hwpartition).

I sent a v4 of this patch that uses the uboot feature which automatically
loads the u-boot environment from a GPT partition which has the
"u-boot-env" GPT partition type GUID instead:
https://lore.kernel.org/buildroot/20241023182509.2808544-1-niklas.cassel@wdc.com/


Kind regards,
Niklas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 4/4] configs/rock5b: enable uboot-env on the SD card

[Thomas Petazzoni via buildroot]

On Wed, 23 Oct 2024 18:35:00 +0000
Niklas Cassel <Niklas.Cassel@wdc.com> wrote:

> I can't use CONFIG_SYS_MMC_ENV_PART.
> 
> If you read the Kconfig help text:
> """
> MMC hardware partition device number on the platform where the
> environment is stored.  Note that this is not related to any software
> defined partition table but instead if we are in the user area, which is
> partition 0 or the first boot partition, which is 1 or some other defined
> partition.
> """
> 
> So CONFIG_SYS_MMC_ENV_PART is about specifying a MMC specific hwpartition,
> which is different from a GPT partition (which is usually stored in a MMC
> "user area" hwpartition).

Ah, indeed!

> I sent a v4 of this patch that uses the uboot feature which automatically
> loads the u-boot environment from a GPT partition which has the
> "u-boot-env" GPT partition type GUID instead:
> https://lore.kernel.org/buildroot/20241023182509.2808544-1-niklas.cassel@wdc.com/

Looks nice, I'll apply this solution. We should use this more globally
in other defconfigs!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot