[PATCH v2 1/3] apple: Set up file system firmware loader

[Marek Vasut]

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.