All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Niklas Cassel <Niklas.Cassel@wdc.com>
Cc: Niklas Cassel via buildroot <buildroot@buildroot.org>,
	Niklas Cassel <cassel@kernel.org>,
	Damien Le Moal <dlemoal@kernel.org>,
	Kilian Zinnecker <kilian.zinnecker@mail.de>
Subject: Re: [Buildroot] [PATCH v3 3/4] configs/rock5b: use the arm64 rootfs partition-type-uuid
Date: Wed, 23 Oct 2024 18:19:18 +0200	[thread overview]
Message-ID: <20241023181918.13ba7a70@windsurf> (raw)
In-Reply-To: <ZxgeOudkPEBVJBkz@ryzen>

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

  reply	other threads:[~2024-10-23 16:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-16 13:24 [Buildroot] [PATCH v3 0/4] rock5b improvements Niklas Cassel via buildroot
2024-10-16 13:24 ` [Buildroot] [PATCH v3 1/4] configs/rock5b: update to linux 6.11.3 Niklas Cassel via buildroot
2024-10-22 20:46   ` Thomas Petazzoni via buildroot
2024-10-22 21:08     ` Niklas Cassel via buildroot
2024-10-22 21:10       ` Niklas Cassel via buildroot
2024-10-22 21:14       ` Thomas Petazzoni via buildroot
2024-10-23 18:31   ` Kilian Zinnecker via buildroot
2024-10-16 13:24 ` [Buildroot] [PATCH v3 2/4] configs/rock5b: update to uboot 2024.10 Niklas Cassel via buildroot
2024-10-22 20:46   ` Thomas Petazzoni via buildroot
2024-10-16 13:24 ` [Buildroot] [PATCH v3 3/4] configs/rock5b: use the arm64 rootfs partition-type-uuid Niklas Cassel via buildroot
2024-10-22 20:49   ` Thomas Petazzoni via buildroot
2024-10-22 21:50     ` Niklas Cassel via buildroot
2024-10-23 16:19       ` Thomas Petazzoni via buildroot [this message]
2024-10-23 20:07         ` Niklas Cassel via buildroot
2024-10-16 13:24 ` [Buildroot] [PATCH v3 4/4] configs/rock5b: enable uboot-env on the SD card Niklas Cassel via buildroot
2024-10-22 20:50   ` Thomas Petazzoni via buildroot
2024-10-23 18:35     ` Niklas Cassel via buildroot
2024-10-23 19:13       ` Thomas Petazzoni via buildroot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241023181918.13ba7a70@windsurf \
    --to=buildroot@buildroot.org \
    --cc=Niklas.Cassel@wdc.com \
    --cc=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=kilian.zinnecker@mail.de \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.