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 .
--
Best regards,
Marek Vasut
