On 6/29/25 6:10 PM, Lucien.Jheng wrote:
Hi,
I'm sorry for my abysmally slow response.
+config PHY_AIROHA_FW_IN_MMC
+ bool "Airoha firmware in MMC partition"
+ help
+ Airoha PHYs use firmware which can be loaded automatically
+ from storage directly attached to the PHY, and then loaded
+ via MDIO commands by the boot loader. The firmware is loaded
+ from a file specified by the PHY_AIROHA_FW_PART,
+ PHY_AIROHA_FW_DM_FILEPATH and PHY_AIROHA_FW_DSP_FILEPATH options.
I ran into the same firmware loading problem recently. I took a
different approach, have a look at [1] and specifically function
rcar_gen4_pcie_load_firmware() . This invokes U-Boot shell script ,
which has to be defined by the user, and which loads the firmware by
whatever means necessary, from whatever storage or location . I think
that might be the generic approach to U-Boot firmware loading . If the
user needs to change the firmware loading location, they do not need
to rebuild the U-Boot itself, they simply update their environment and
the matching script. What do you think ?
[1] https://patchwork.ozlabs.org/project/uboot/
patch/[email protected]/
Hi Marek
I've looked at the `rcar_gen4_pcie_load_firmware` API. As you mentioned,
it allows users to set the storage and location from the U-Boot shell,
meaning they don't need to recompile U-Boot.
Yes, that's the goal there.
However, I recently checked out `FS_LOADER` and realized it's
essentially the same approach as how I'm currently placing firmware on
eMMC, just with a unified API(request_firmware_into_buf).
I'm wondering if there's a future possibility to integrate U-Boot shell
scripts into `FS_LOADER`?
I think it would be ideal to have one unified firmware loading code, so
the answer to the "if" part of the question is "yes".
I have yet to think about the "how" part. If you want to give it a try,
please do.
Also, given that the Kernel has a built-in firmware mechanism where
files are compiled directly into the Kernel image, I'm curious if U-Boot
might adopt a similar approach in the future. I'm also considering if
`binman_sym` could be a viable alternative.
I'm not a lawyer. My understanding of this firmware bundling is, that
this is a legal minefield which is better avoided, and also causes
redistribution problems with prebuilt U-boot binaries. You end up
bundling together GPL code (U-Boot) and non-GPL code (firmware blobs),
and the final license of the result is unclear to me.
+CC Vagrant, since they have insight into this from Debian side.
For the short term, though, I'll go ahead and submit the EN8811H
firmware loading method using the `rcar_gen4_pcie_load_firmware`
approach. I'll then explore potential improvements later.
Please wait a bit for input from the others. Also keep in mind, that
rcar_gen4_pcie_load_firmware() is non-generic interface specific to that
one driver, you would have to implement something similar in this driver
, with different variable names .
