On Mon, May 26, 2025 at 8:26 PM Tom Rini <tr...@konsulko.com> wrote:
>
> On Mon, May 26, 2025 at 10:17:54AM +0100, Conor Dooley wrote:
> > On Mon, May 26, 2025 at 09:02:46AM +0530, Mayuresh Chitale wrote:
> > > On Thu, May 22, 2025 at 10:11 PM Yao Zi <zi...@disroot.org> wrote:
> > > >
> > > > 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:
> >
> > > > > 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-mchit...@ventanamicro.com>
> > > > > (raw)
> > > > > | In-Reply-To: <20250404144859.112313-1-mchit...@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 <mchit...@ventanamicro.com>
> > > > > | Reviewed-by: Maxim Moskalets <maximmo...@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.
> > > >
> > > Are you suggesting something like this :
> > >
> > > { IH_ARCH_RISCV, "riscv", "RISC-V",},
> > > { IH_ARCH_RISCV32, "riscv32", "RISC-V 32 Bit",},
> > > { IH_ARCH_RISCV64, "riscv64", "RISC-V 64 Bit",},
> > >
> > > I tried to implement it like on ARM64. However the problem is that
> > > while on ARM64 it switches to aarch32 if it encounters an IH_ARCH_ARM
> > > kernel image, there is no equivalent mechanism for Risc-V yet.
> >
> > But we don't even want that, since the current behaviour on a 64-bit
> > system is not to do anything 32-bit related, right? My 64-bit images
> > created with my system mkimage use IH_ARCH_RISCV.
> >
> > > Another
> > > option could be to disable this check in the bootm flow for now until
> > > a similar mechanism is implemented on Risc-V.
> >
> > Why not just allow IH_ARCH_RISCV to retain the current "dumb" behaviour
> > permanently, and only implement the strict checking when the explicit
> > width types are detected?
>
> This seems most reasonable to me for the current situation.
Ok. In that case, I think the patch set needs to be reverted.
>
> --
> Tom
