[GIT PULL] u-boot-riscv/master
Leo Liang
ycliang at andestech.com
Thu May 22 17:36:47 CEST 2025
On Thu, May 22, 2025 at 08:45:59AM -0600, Tom Rini 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:
> > >
> > > > 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?
> >
> > Hopefully my lack of bisection isn't causing me to blame something
> > incorrect, but I'll go try to replicate now :)
>
> Ugh. No, this is a problem that needs to be fixed and I'm sorry I missed
> it during reviews. We need to keep the list compatible.
Hi Conor, Tom,
I am so sorry! I did not catch the compatibility issue as well.
How do you think we should proceed from here?
Maybe revert the whole patchset first?
And then send a fix up patch after?
Best regards,
Leo
>
> --
> Tom
More information about the U-Boot
mailing list