Unusual reference to firmware in Yocto build

allsey87
allsey87 New Member Posts: 33
edited July 2020 in UP Core Linux

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?

Tagged:

Comments

  • allsey87
    allsey87 New Member Posts: 33

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

  • allsey87
    allsey87 New Member Posts: 33

    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
    DCleri Administrator, AAEON Posts: 1,213 admin

    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
    allsey87 New Member Posts: 33

    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
    allsey87 New Member Posts: 33

    @DCleri did you hear back from your BIOS team?

  • DCleri
    DCleri Administrator, AAEON Posts: 1,213 admin

    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
    allsey87 New Member Posts: 33

    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
    DCleri Administrator, AAEON Posts: 1,213 admin

    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
    allsey87 New Member Posts: 33

    @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
    DCleri Administrator, AAEON Posts: 1,213 admin

    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.