On 1/22/26 11:43, Nikita Shubin wrote:
> EXTERNAL EMAIL: Do not click any links or open any attachments unless you
> trust the sender and know the content is safe.
>
> 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.
>
I know this is what we have now; but I really mean
PBL (M-Mode) -> u-boot SPL (M-Mode) -> u-boot proper (M-Mode) ->
opensbi (M-Mode) -> linux (S-Mode)
For this, need to support u-boot proper in M-mode. This way it is more
valuable for development. Point is, opebSBI need DTB used by Linux,
it makes modification for this DTB. With S-mode u-boot, one can load only
linux kernel and initrd, opensbi and FDT loaded before.
I want to be able to load all components, that's why I want M-mode u-boot.
Anyway, this is a different discussion
>>
>> 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.
firmware-options looks fine, good idea.
>
>> 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.
>
Agree. Then, I will prepare patch doing this
>> ramdisk = "initrd";
>>
>> fdt = "fdt-1";
>>
>> loadables = "linux", "initrd";
>>
>> };
>>
>>
>> Comments?
>>
>> Thanks, Vladimir
