> On 1 Nov 2025, at 7:54 PM, Marek Vasut <[email protected]> wrote:
>
> On 11/1/25 8:45 AM, Beiyan Yun wrote:
>
> Hi,
>
>>>>> Can you not use the plain FW_LOADER to load the firmware from either
>>>>> storage, UBI or Block ? Is FS_LOADER even needed ?
>>>> Thanks for the suggestion, and yes you can, but that API is script-only—it
>>>> expects the board to stage the blob and just copies from the address
>>>> exposed via *_addr/_size. The current users of this driver expect the old
>>>> pattern: the bootloader mounts a filesystem (MMC before, now possibly
>>>> UBI/USB/etc.), reads the firmware, and applies it. Keeping an fs-loader
>>>> node in the DT is effectively the same contract as the legacy MMC setup,
>>>> just generalized.
>>>
>>> Can you maybe write a script which implements the old loader behavior in a
>>> compatible manner ?
>>>
>>>> The fs_loader driver gives us several things the script path doesn’t: a
>>>> standard way to describe the storage via "/chosen/firmware-loader"
>>>
>>> Try this:
>>>
>>> "fdt addr $fdtcontroladdr ; fdt print /chosen"
>>>
>>> And then look at the "fdt" command and what it can do regarding reading
>>> content of DT properties into variables.
>>>
>>>> , runtime overrides through "storage_interface/fw_dev_part/fw_ubi_*, and
>>>> no requirement for a board-specific script. So FS_LOADER isn’t
>>>> redundant—it’s the part that replaces the hard-coded MMC flow with a
>>>> configurable backend, while the script helper stays available for boards
>>>> that want extra logic.
>>> Maybe a more generic script can be a replacement for the older hard-coded
>>> approach ?
>> Fair enough, I’ll remove fsloader for now.
>> I still believe it would be valuable someday: if reading from nvmem cell is
>> implemented, the same DT could be used for both U-Boot and Linux.
>
> See example above, you can read anything from the U-Boot control DT both in
> U-Boot shell and in U-Boot env scripts, using 'fdt' command .
>
To make sure I understand the preferred architecture: are you suggesting that
FW_LOADER is the preferred method, and that all the logic for finding,
mounting, and reading from storage should be handled by board-specific scripts
that parse the DT using fdt?
My main objective with FS_LOADER was to provide a "zero-script" default for
most common use case. While scripting is powerful, it seems beneficial to have
a C-based driver that can natively read from a filesystem described by a
standard DT binding, rather than requiring every board to script the same
"find-and-mount" logic.
Am I overlooking al drawback to that C-based approach, or perhaps missing some
prior discussion on this?
Thanks,
Yun
> --
> Best regards,
> Marek Vasut
