PCI trouble on mvebu (Turris Omnia)

™֟☻̭҇ Ѽ ҉ ® vtolkm at googlemail.com
Tue Oct 27 18:01:00 EDT 2020


On 27/10/2020 22:31, Toke Høiland-Jørgensen wrote:
>>> To follow up on this, everything seems to work just fine (ath10k init at
>>> boot + regulatory db load) if I simply set:
>>>
>>> CONFIG_EXTRA_FIRMWARE="ath10k/QCA988X/hw2.0/board.bin ath10k/QCA988X/hw2.0/firmware-5.bin regulatory.db regulatory.db.p7s"
>>>
>>> -Toke
>>>
>> That works on my node only for the regulatory files but not the ath10
>> firmware with kconfig:
>>
>>    Symbol: EXTRA_FIRMWARE_DIR [=/srv/fw]
>>    Type  : string
>>    Defined at drivers/base/firmware_loader/Kconfig:63
>>      Prompt: Firmware blobs root directory
>>      Depends on: FW_LOADER [=y] && EXTRA_FIRMWARE [=regulatory.db
>> regulatory.db.p7s board.bin firmware-5.bin]!=
>>      Location:
>>       -> Device Drivers
>>         -> Generic Driver Options
>>           -> Firmware loader
>>             -> Firmware loading facility (FW_LOADER [=y])
>>               -> Build named firmware blobs into the kernel binary
>> (EXTRA_FIRMWARE [=regulatory.db regulatory.db.p7s board.bin
>> firmware-5.bin])
> I think that's because you're missing the path prefix
> (ath10k/QCA988X/hw2.0/) from board.bin and firmware-5.bin?
> request_firmware() uses the full path...
>
> -Toke

Well, that would be weird/strange having to specify the path prefix for 
build-in firmware,considering:

  CONFIG_FW_LOADER:

  This enables the firmware loading facility in the kernel. The kernel
  will first look for built-in firmware, if it has any. Next, it will
  look for the requested firmware in a series of filesystem paths:

        o firmware_class path module parameter or kernel boot param
        o /lib/firmware/updates/UTS_RELEASE
        o /lib/firmware/updates
        o /lib/firmware/UTS_RELEASE
        o /lib/firmware

----

Nevertheless, I tried with same path prefix as per your kconfig but the 
compilation fails, which I am not surprised since the ath10 blobs are 
not located at that path

   UPD     drivers/base/firmware_loader/builtin/regulatory.db.gen.S
   UPD drivers/base/firmware_loader/builtin/regulatory.db.p7s.gen.S
make[4]: *** No rule to make target 
'/srv/fw/ath10k/QCA988X/hw2.0/board.bin', needed by 
'drivers/base/firmware_loader/builtin/ath10k/QCA988X/hw2.0/board.bin.gen.o'. 
Stop.
make[4]: *** Waiting for unfinished jobs....
   UPD 
drivers/base/firmware_loader/builtin/ath10k/QCA988X/hw2.0/board.bin.gen.S
make[3]: *** [scripts/Makefile.build:500: 
drivers/base/firmware_loader/builtin] Error 2
make[2]: *** [scripts/Makefile.build:500: drivers/base/firmware_loader] 
Error 2
make[1]: *** [scripts/Makefile.build:500: drivers/base] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1799: drivers] Error 2
make: *** Waiting for unfinished jobs....

I suspect that since you are booting the kernel directly from my build 
box over tftp it accesses the ath10 firmware blobs on the build box.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x729CFF47A416598B.asc
Type: application/pgp-keys
Size: 3119 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20201027/e430caec/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20201027/e430caec/attachment.sig>


More information about the linux-arm-kernel mailing list