Unusual reference to firmware in Yocto build

allsey87

Hello, I am getting the following error when I boot Linux

Wifi loading: brcmfmac mmc1:0001:1: Direct firmware load for ampak/brcm/brcmfmac43430-sdio.AAEON-UP-CHCR1.txt failed with error -2

I would like to know where the reference to this file comes from? I literally grep'd through the entire Yocto build directory for references to AAEON and CHCR1 and didn't find anything relevant. Does this string come from the ACPI tables/bios perhaps?

allsey87

Results from grep attached. The only references to CHCR1 I could find were from QEMU which I don't think is related...

allsey87

These are the additional files installed by the AMPAK firmware recipe, none of the files here are named "brcmfmac43430-sdio.AAEON-UP-CHCR1.txt" though...

BCM43430A1.hcd
BCM4345C0.hcd
brcmfmac-ampak.conf
brcmfmac43430-sdio.bin
brcmfmac43430-sdio.txt
brcmfmac43455-sdio.bin
brcmfmac43455-sdio.txt
firmware-ampak-ap6214a.service
firmware-ampak-ap6355.service

DCleri

Is the WiFi working correctly for you anyway?

We will look into it with our BIOS team as the system should just load the available brcmfmac43430-sdio.txt

allsey87

It works with the caveat that every couple of seconds the latency increases momentarily to around 2 secs. At the moment, I have a hack to work around this so that I can get a usable SSH connection. The hack is getting the board to ping the router every 200 ms, which is enough to make these increases in latency disappear. It is almost like the device is scanning for access points or something as soon as it is idle for more than a second.

allsey87

@DCleri did you hear back from your BIOS team?

DCleri

Hi @allsey87

Unfortunately our BIOS team is currently very busy and it might take longer.

Can you help me to check if, after renaming the following file from
brcmfmac43430-sdio.txt
to
brcmfmac43430-sdio.AAEON-UP-CHCR1.txt

(also a second attempt renaming also brcmfmac43430-sdio.bin to brcmfmac43430-sdio.AAEON-UP-CHCR1.bin)

you still have the dmesg error and latency increase?

allsey87

Hi @DCleri , here are the results from some testing.

Output of dmesg filtered by brcm before copying the firmware to the new target name:

brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
usbcore: registered new interface driver brcmfmac
brcmfmac mmc1:0001:1: Direct firmware load for ampak/brcm/brcmfmac43430-sdio.AAEON-UP-CHCR1.txt failed with error -2
brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Nov 25 2016 15:06:56 version 7.46.57.5.apsta.r4.o12 (Station/Softap) FWID 01-64fb9fe8 es6.c5.n4.a3

Following this, I duplicated and renamed the firmware and config provided by Yocto to match what the driver appeared to be looking for:

root@up-core:/lib/firmware/ampak/brcm# md5sum *
bcb42d82535d2cbb8f0543a643fc6c2c  brcmfmac43430-sdio.AAEON-UP-CHCR1.bin
6dd5cd745c34b02ec53428256334c533  brcmfmac43430-sdio.AAEON-UP-CHCR1.txt
bcb42d82535d2cbb8f0543a643fc6c2c  brcmfmac43430-sdio.bin
6dd5cd745c34b02ec53428256334c533  brcmfmac43430-sdio.txt
0324fe9ce34b6c6c44cc5fd77a669d39  brcmfmac43455-sdio.bin
05474c3669e27286aca96e9792a47580  brcmfmac43455-sdio.txt

The output from dmesg is now as follows:

brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
usbcore: registered new interface driver brcmfmac
brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Nov 25 2016 15:06:56 version 7.46.57.5.apsta.r4.o12 (Station/Softap) FWID 01-64fb9fe8 es6.c5.n4.a3

So the error about the txt file is now gone. It seems that the ping is a bit more stable than before, however, this is non-conclusive for the moment since I wasn't able to recreate the previous situation with the ping after removing the files with "AAEON-UP-CHCR1" in their names. I think it may be the case that those settings were downloaded during boot and were persistent even after removing the power. Perhaps the old behavior will reappear after the board has been powered down for a longer period of time and the wifi chip loses its previous configuration....

Still no idea where this string of characters "AAEON-UP-CHCR1" comes from... could it be from some EFI variables perhaps?

DCleri

Yes it could be and it is good to know what you have just found.

If you can confirm about the ping delays (if either is the same or not) that would be great, thanks.

allsey87

@DCleri here are the ping test results.

As a baseline
Laptop (wifi) -> Router

--- 192.168.1.1 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 19892ms
rtt min/avg/max/mdev = 0.777/7.964/28.102/6.361 ms

The wifi adapter in this laptop is (from lspci): Intel Corporation Wireless 8265 / 8275 (rev 78)

Laptop (lan) -> Router

--- 192.168.1.1 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 20069ms
rtt min/avg/max/mdev = 0.454/0.779/0.869/0.074 ms

Original scenario (no changes in /lib/firmware/ampak)
Laptop (lan) -> Router -> Up Core

--- 192.168.1.226 ping statistics ---
100 packets transmitted, 99 received, 1% packet loss, time 20080ms
rtt min/avg/max/mdev = 1.975/381.164/2218.146/597.959 ms, pipe 11

Copying brcmfmac43430-sdio.txt to brcmfmac43430-sdio.AAEON-UP-CHCR1.txt

--- 192.168.1.226 ping statistics ---
100 packets transmitted, 97 received, 3% packet loss, time 20073ms
rtt min/avg/max/mdev = 1.919/330.913/1805.716/536.514 ms, pipe 9

Distribution: 70% of the pings are good and form a peak around 10 ms mark, 30% of the pings are bad and form a second peak around the 800 ms mark.

Copying brcmfmac43430-sdio.bin to brcmfmac43430-sdio.AAEON-UP-CHCR1.bin

--- 192.168.1.226 ping statistics ---
100 packets transmitted, 98 received, 2% packet loss, time 20009ms
rtt min/avg/max/mdev = 1.994/207.891/1838.498/445.550 ms, pipe 9

Similar distribution as the previous scenario.

I also moved the Up Core and its antenna right on top of the router to try eliminate the effects of signal attenuation/interference etc. but I did not observe any deviations from the above results.

As I mentioned before, running ping -i0.2 ROUTER_IP &> /dev/null & keeps ping running quietly in the background and resolves all these issues. It seems that keeping the wifi busy stops the fluctuations in latency.

DCleri

Hi @allsey87

So the txt or bin files do not make any difference, but it is possibly some low power state while not using the board/connection.

Cherry Trail (the SoC used on UP Board and UP Core) works with pretty aggressive low power states, so it might not be the WiFi, but the system itself.

It would be worth checking if you are running a video or an application locally, while pinging the router from time to time, will have the same results or improve it.

We will also run further tests internally.