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 <[email protected]> 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.
