Query on RISC-V booting ABI

Query on RISC-V booting ABI

[Ivan Velickovic]

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.

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?

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

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.



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.

Re: Query on RISC-V booting ABI

[Ivan Velickovic]

I should note that (from what I can see) this ABI that I’m referring to is just a convention by OpenSBI and others
and is not specified by RISC-V itself so U-Boot isn’t obligated to follow it or anything, I was more-so just wondering
if U-Boot maintainers were interested in having this behaviour be consistent across the different boot methods.

For context, my motivation for this kind of behaviour is that for my OS I need to know the hart ID. The hardware
register for the hart ID is mhartid which is M-mode only. OpenSBI does not emulate this CSR and there is no
SBI call to get the value of mhartid.

It is possible for me to format my image so that bootm works instead but I would prefer to stick with binary/ELF.

Thanks,
Ivan

On 21 Nov 2025, at 13:00, Ivan Velickovic <i.velickovic@unsw.edu.au> 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.

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?

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

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.




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.

Re: Query on RISC-V booting ABI

[Yao Zi]

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/

Re: Query on RISC-V booting ABI

[Ivan Velickovic]

Hi Yao

Thank you for your response.

Thank you for pointing me to those patches, I will target the Linux image format from now on then.

Thanks
Ivan

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.