Hello Vladimir!
Thank you for sharing this!
On Wed, 2026-01-21 at 17:21 +0200, Vladimir Kondratiev wrote:
> Hi all,
>
> After commit aa0eda17cf98 ("spl: opensbi: convert scratch options to
> config") it is possible
> to specify options for the opensbi, as in struct fw_dynamic_info
> "options", in config file.
> It is better than hard coded value but still, it is fixed at the
> compile time.
>
> Can we have this options set at image load time? This would help to
> enable, for example,
> opensbi debug prints at the runtime. I see an option to do so in FIT
> image, by adding
> property like "opensbi_options" to the opensbi image node or to the
> configuration node.
>
> While bootloader usually flashed on some raw partition and it is not
> that easy to
> recompile and re-flash it for every run, OS FIT image can be stored
> on the partition
> formatted with some filesystem so changing FIT image is easy. Also,
> if it is only
> matter of changing .its file and re-run "mkimage", whole process of
> changing opensbi
> options became easy.
Generally, I like the idea. However, there are some issues we need to
consider... See below.
>
> I see even more value in this for u-boot proper, if we teach it to
> run in M-mode, so
> for developer boot sequence can be
>
> PBL -> u-boot SPL -> u-boot -> opensbi -> linux
Not this, but:
PBL (M-Mode) -> u-boot SPL (M-Mode) -> OpenSBI (M-Mode) -> u-boot
Proper (S-Mode) -> linux (S-Mode)
OpenSBI is earlier in chain than U-boot Proper, so additional options
can be passed only via U-Boot SPL.
>
> where u-boot will enable network and load FIT image from TFTP; then
> changing opensbi flags
> will be matter of seconds
>
> Examples, proposed modification marked with "==>":
>
> for opensbi image node:
>
> opensbi {
>
> description = "OpenSBI fw_dynamic Firmware";
>
> data = /incbin/("fw_dynamic.bin");
>
> type = "firmware";
>
> arch = "riscv";
>
> os = "opensbi";
> ==> opensbi_options =
> <2>; // SBI_SCRATCH_DEBUG_PRINTS
"opensbi-options" looks more like Device Tree to me. Also if we refer
type as "firmware" may be naming it "firmware-options" is more
convenient.
> compression = "none";
>
> load = <0x8 0x00100000>;
>
> entry = <0x8 0x00100000>;
>
> };
>
>
> for configuration node:
>
> config-1 {
>
> description = "config-description";
>
> kernel = "linux";
>
> firmware = "opensbi";
>
> ==> opensbi_options = <2>; // SBI_SCRATCH_DEBUG_PRINTS
Same here "firmware-options".
If you are using it in three places what is supposed priority ?
Recently similar issue was solved by Alexander Sverdlin for linux
bootargs btw:
https://patchew.org/linux/[email protected]/
So order can be SPL_OPENSBI_SCRATCH_OPTIONS -> opensbi node -> config
node.
> ramdisk = "initrd";
>
> fdt = "fdt-1";
>
> loadables = "linux", "initrd";
>
> };
>
>
> Comments?
>
> Thanks, Vladimir
