Re: Query on RISC-V booting ABI

[Yao Zi <ziyao@disroot.org>]

On Fri, Nov 21, 2025 at 02:00:46AM +0000, Ivan Velickovic wrote:
> Hello everyone,
> 
> My understanding of the general RISC-V bootflow ABI is that each boot stage provides the hart ID and DTB
> in a0 and a1 respectively. From [1] I can see that U-Boot also adheres to that.

I think the ABI is only defined for Linux. OpenSBI follows a similar
convention, but provides a raw binary with no image header, and requires
an extra fw_dynamic_info parameter if dynamic image is used.

> For my use-case, I am typically booting my OS/application with U-Boot via the `go` or `bootelf` commands.
> I believe that currently these methods do not adhere to this ABI, and I’m wondering if someone could clarify
> whether that is a mistake or intentional?

There's some previous discussion about passing hart ID/DTB, too with
bootelf[3], but I think the patch is stalled. Here's the v2[4] but I've
never seen v3.

Personally speaking, I think it's a better idea to pack your customized
kernel into a Linux-style image, in which way existing facilities could
be re-used, and ABI stability is guaranteed, too.

> I can see that for `bootm` for Linux images for example, the ABI is preserved [2].

Yes, and similar convention also preserved in common/spl/spl_opensbi.c
which loads OpenSBI. But for "go" and "bootelf", you couldn't tell what
ABI the image really follows, so preserving the de-facto ABI may benefit
in some situation, but I personally won't consider the current
implementation buggy.

> Thank you,
> Ivan
> 
> [1]: https://docs.u-boot.org/en/latest/arch/riscv.html
> [2]: https://github.com/u-boot/u-boot/blob/2bc0715b558fa1ac5c88b11e250740b16a905837/arch/riscv/lib/bootm.c#L100.

Regards,
Yao Zi

> This email and any files transmitted with it may contain confidential information. If you believe you have received this email or any of its contents in error, please notify me immediately by return email and destroy this email. Do not use, disseminate, forward, print or copy any contents of an email received in error.
> 

[3]: https://lore.kernel.org/u-boot/ME0P300MB13096732AF44AC5409B9D0D49F96A@ME0P300MB1309.AUSP300.PROD.OUTLOOK.COM/
[4]: https://lore.kernel.org/u-boot/SY7P282MB5675687EA430C83D458678F89F77A@SY7P282MB5675.AUSP282.PROD.OUTLOOK.COM/