[GIT PULL] u-boot-riscv/master

[Yao Zi]

On Thu, May 22, 2025 at 12:28:18PM +0100, Conor Dooley wrote:
> On Wed, May 21, 2025 at 12:39:50PM -0600, Tom Rini wrote:
> > On Wed, 21 May 2025 17:50:03 +0800, Leo Liang wrote:
> > 
> > > The following changes since commit a3e09b24ffd4429909604f1b28455b44306edbaa:
> > > 
> > >   Merge tag 'mmc-2025-05-20' of https://source.denx.de/u-boot/custodians/u-boot-mmc (2025-05-20 08:35:31 -0600)
> > > 
> > > are available in the Git repository at:
> > > 
> > >   https://source.denx.de/u-boot/custodians/u-boot-riscv.git
> > > 
> > > [...]
> > 
> > Merged into u-boot/master, thanks!
> 
> This PR seems to have made my CI blow up, and I'm not entirely sure if
> that's something intentional or not. I've not yet bisected, but since
> the error is "Image arch not compatible with host arch", I can only
> imagine the patch in question is:
> | Subject: [PATCH v2 1/3] riscv: image: Add new image type for RV64
> | Date: Fri,  4 Apr 2025 14:48:55 +0000	[thread overview]
> | Message-ID: <20250404144859.112313-2-mchitale at ventanamicro.com> (raw)
> | In-Reply-To: <20250404144859.112313-1-mchitale at ventanamicro.com>
> | 
> | Similar to ARM and X86, introduce a new image type which allows u-boot
> | to distinguish between images built for 32-bit vs 64-bit Risc-V CPUs.
> | 
> | Signed-off-by: Mayuresh Chitale <mchitale at ventanamicro.com>
> | Reviewed-by: Maxim Moskalets <maximmosk4 at gmail.com>
> | ---
> |  boot/image.c    | 3 ++-
> |  include/image.h | 3 ++-
> |  2 files changed, 4 insertions(+), 2 deletions(-)
> | 
> | diff --git a/boot/image.c b/boot/image.c
> | index 139c5bd035a..45299a7dc33 100644
> | --- a/boot/image.c
> | +++ b/boot/image.c
> | @@ -92,7 +92,8 @@ static const table_entry_t uimage_arch[] = {
> |  	{	IH_ARCH_ARC,		"arc",		"ARC",		},
> |  	{	IH_ARCH_X86_64,		"x86_64",	"AMD x86_64",	},
> |  	{	IH_ARCH_XTENSA,		"xtensa",	"Xtensa",	},
> | -	{	IH_ARCH_RISCV,		"riscv",	"RISC-V",	},
> | +	{	IH_ARCH_RISCV,		"riscv",	"RISC-V 32 Bit",},
> | +	{	IH_ARCH_RISCV64,	"riscv64",	"RISC-V 64 Bit",},
> |  	{	-1,			"",		"",		},
> |  };
> |  
> | diff --git a/include/image.h b/include/image.h
> | index 07912606f33..411bfcd0877 100644
> | --- a/include/image.h
> | +++ b/include/image.h
> | @@ -138,7 +138,8 @@ enum {
> |  	IH_ARCH_ARC,			/* Synopsys DesignWare ARC */
> |  	IH_ARCH_X86_64,			/* AMD x86_64, Intel and Via */
> |  	IH_ARCH_XTENSA,			/* Xtensa	*/
> | -	IH_ARCH_RISCV,			/* RISC-V */
> | +	IH_ARCH_RISCV,			/* RISC-V 32 bit*/
> | +	IH_ARCH_RISCV64,		/* RISC-V 64 bit*/
> |  
> |  	IH_ARCH_COUNT,
> |  };
> | -- 
> | 2.43.0
> | 
> since it is changing the existing "riscv" image type to be the 32-bit
> image and requiring the new entry for 64-bit. My CI job uses the system
> mkimage to create the image that U-Boot is loading, so it doesn't know
> about the new define etc. Maybe it's not considered a problem if a new
> U-Boot cannot boot an old image, but the comment above the enum reads:
> |/*
> | * CPU Architecture Codes (supported by Linux)
> | *
> | * The following are exposed to uImage header.
> | * New IDs *MUST* be appended at the end of the list and *NEVER*
> | * inserted for backward compatibility.
> | */
> The overwhelming majority of existing supported boards in U-Boot are
> 64-bit platforms, and the 64-bit platforms are the ones that have been
> supported for longer, so my thought would be that the compatibility of
> 64-bit platforms should be prioritised over 32-bit? Or even add explicit
> 32-bit and 64-bit entries and the existing one is a catch-all for
> compatibility reasons?

I've mentioned entries with bitwidth explicitly specified in my previous
reply (and there hasn't been any response).

> I'll consider IH_ARCH_RISCV32 a better idea, instead of implying 32bit
> when no suffix attached. We (and the Linux kernel) mix 32-bit and 64-bit
> variants of RISC-V together, thus it's hard to tell the exact bitwidth
> of "IH_ARCH_RISCV" without inspecting the code around. To me, it sounds
> more like "RISC-V, but no bitwidth specified".
>
> It will be nice if we could avoid this kind of ambiguity.

(referring my own reply[1])

I'll second explicit 32-bit and 64-bit entries, and keeping
IH_ARCH_RISCV for compatibility consideration.

> 
> Hopefully my lack of bisection isn't causing me to blame something
> incorrect, but I'll go try to replicate now :)

Regards,
Yao Zi

[1]: https://lore.kernel.org/u-boot/Z_CjTyXaVrpUOPnJ@pie.lan/