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/me0p300mb13096732af44ac5409b9d0d49f...@me0p300mb1309.ausp300.prod.outlook.com/ [4]: https://lore.kernel.org/u-boot/sy7p282mb5675687ea430c83d458678f89f...@sy7p282mb5675.ausp282.prod.outlook.com/
