On 9/30/25 4:49 PM, Mark Kettenis wrote:
Hi,
Maybe try request_firmware_into_buf_via_script() instead ?
That might make this more flexible /wrt firmware location and user
preferences.
I'm not sure about that. For one thing, I thought there was a push to
move away from scripts.
There was ? This script based firmware loader interface is in fact new,
it allows users to provide the firmware whichever way they see fit. If
the firmware loader should be locked down, that is up to the user.
At least that was a major driver for
replacing distroboot with bootstd. Granted, the motivation for that
was secure/trusted/verified boot, which is something I personally
don't care all that much about.
Writing a script that implements the logic of asahi_esp_devpart() is
also not trivial. Especially because there are no actual working
examples of such a script in U-Boot. At least I can't find any
definitions of the "mt7987_i2p5ge_load_pmb_firmware",
"mt7987_i2p5ge_load_dspbit_firmware" or
"mt7988_i2p5ge_load_pmb_firmware" scripts that are used by
drivers/net/phy/mediatek/mtk-2p5ge.c. And that is currently the only
driver that uses request_firmware_into_buf_via_script().
R-Car Gen4 PCIe is being switched over to that interface too.
The script looks something like this:
renesas_rcar_gen4_load_firmware 'env set
renesas_rcar_gen4_load_firmware_addr 0x54000000 && load mmc 0:1
${renesas_rcar_gen4_load_firmware_addr} lib/firmware/rcar_gen4_pcie.bin
&& env set renesas_rcar_gen4_load_firmware_size ${filesize}'
I'd prefer to keep using request_firmware_into_buf() until there is an
actual use case that requires more flexibility. For now I'm not aware
of any hardware besides the Apple M2 and M2 Pro machines that have an
ASMedia PCI XHCI controller that requires loading firmware.
My use case for the PCIe controller was loading the firmware from
another location (tftp) during development.
