PCI trouble on mvebu (Turris Omnia)

[Toke Høiland-Jørgensen]

"™֟☻̭҇ Ѽ ҉ ®" <vtolkm at googlemail.com> writes:

> 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

Why would that be weird? The driver is requesting firmware with a path
prefix, so the firmware location has to match... Doesn't matter if it's
in the filesystem or builtin.

> ----
>
> 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

Well you'd need to fix that :)

>    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

Based on that error message, you'd need to do something like:

mkdir -p /srv/fw/ath10k/QCA988X/hw2.0
mv /srv/fw/{board.bin,firmware-5.bin} /srv/fw/ath10k/QCA988X/hw2.0

> '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.

Yes, obviously it's reading the firmware blobs at build time from the
location on the build box, then embedding them in the kernel image,
which is then served over tftp to the Omnia. It's not loading anything
from the build box after that (how would that work?)

-Toke