Openwrt 23.05 | fgh100m | MM6108

Software Linux
21

Hi @james.haggerty ,
After loading bcf_fgh100mjaamd.bin the SSID is now broadcasting. But other wont work showing error

[10950.944877] morse_io: Device node ‘/dev/morse_io’ created successfully
[10950.952182] morse_spi spi1.0: Loaded firmware from morse/mm6108.bin, size 430512, crc32 0xb25c264b
[10950.961420] morse_spi spi1.0: Loaded BCF from morse/bcf_fgh100mjaamd.bin, size 858, crc32 0xb0da770a
[10951.515558] morse_spi spi1.0: Country code AU not found in BCF
[10952.065336] morse_spi spi1.0: Country code AU not found in BCF
[10952.617360] morse_spi spi1.0: Country code AU not found in BCF
[10952.623248] morse_spi spi1.0: morse_firmware_init failed: -1
[10952.629015] morse_spi_probe failed. The driver has not been loaded!
[10952.635274] morse_spi: probe of spi1.0 failed with error -1

We are using our product globally, and my question is, how do I find the proper BCF file?

22

If you’re using the FGH100MJAAMD, which is a Japanese module from Quectel, you are using the correct BCF. This is why it’s failing to load in AU. Make sure that this is the module you have, particularly since it’s different from the previous BCF file you tried to load.

23

Hi @james.haggerty ,
Thanks for the update. After changing the correct bcf file, the SSID is broadcasting.

But I found the other issues in STA mode.

root@OpenWrt:/# [ 7338.111867] br-lan: port 5(wlan0) entered blocking state
[ 7338.117184] br-lan: port 5(wlan0) entered disabled state
[ 7338.122708] device wlan0 entered promiscuous mode
[ 7340.298609] br-lan: port 5(wlan0) entered disabled state
[ 7340.304186] device wlan0 left promiscuous mode
[ 7340.308710] br-lan: port 5(wlan0) entered disabled state
[ 7340.363439] br-lan: port 5(wlan0) entered blocking state
[ 7340.368795] br-lan: port 5(wlan0) entered disabled state
[ 7340.374286] device wlan0 entered promiscuous mode
[ 7340.379569] wlan0: authenticate with 0c:bf:74:1f:fb:e5
[ 7340.568565] wlan0: send auth to 0c:bf:74:1f:fb:e5 (try 1/3)
[ 7340.585369] wlan0: authenticate with 0c:bf:74:1f:fb:e5
[ 7340.590534] wlan0: send auth to 0c:bf:74:1f:fb:e5 (try 1/3)
[ 7340.645289] wlan0: authenticated
[ 7340.657810] wlan0: associate with 0c:bf:74:1f:fb:e5 (try 1/3)
[ 7340.674748] wlan0: RX AssocResp from 0c:bf:74:1f:fb:e5 (capab=0x11 status=0 aid=1)
[ 7340.690499] wlan0: associated
[ 7341.068112] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 7341.074588] br-lan: port 5(wlan0) entered blocking state
[ 7341.079921] br-lan: port 5(wlan0) entered forwarding state
[ 7341.357786] invalid GPIO -2
[ 7341.360590] invalid GPIO -2
[ 7342.308009] invalid GPIO -2
[ 7342.310810] invalid GPIO -2
[ 7342.584480] invalid GPIO -2
[ 7342.587283] invalid GPIO -2
[ 7342.590085] invalid GPIO -2
[ 7343.187887] invalid GPIO -2
[ 7343.190683] invalid GPIO -2
[ 7343.403409] invalid GPIO -2
[ 7343.406213] invalid GPIO -2
[ 7343.409013] invalid GPIO -2
[ 7358.328001] invalid GPIO -2
[ 7358.330798] invalid GPIO -2
[ 7358.348647] invalid GPIO -2
[ 7358.351445] invalid GPIO -2
[ 7384.778759] invalid GPIO -2
[ 7384.781562] invalid GPIO -2
[ 7385.172416] invalid GPIO -2
[ 7385.175219] invalid GPIO -2
[ 7385.178024] invalid GPIO -2
[ 7385.217826] invalid GPIO -2
[ 7385.220617] invalid GPIO -2
[ 7385.377055] invalid GPIO -2
[ 7385.379870] invalid GPIO -2
[ 7385.382654] invalid GPIO -2
[ 7385.467383] invalid GPIO -2
[ 7385.470187] invalid GPIO -2
[ 7385.683116] invalid GPIO -2
[ 7385.685918] invalid GPIO -2
[ 7385.688718] invalid GPIO -2
[ 7385.898689] invalid GPIO -2
[ 7385.901479] invalid GPIO -2
[ 7386.092655] invalid GPIO -2
[ 7386.095455] invalid GPIO -2
[ 7386.098257] invalid GPIO -2
[ 7386.217780] invalid GPIO -2

The invalid GPIO-2 is flooding in STA mode, but in AP mode, it was coming 5 times. Herewith, i attached a snippet of our DTS.

&spi2 {
    pinctrl-names = “default”;
    pinctrl-0 = <&spi2_flash_pins>;
    status = “okay”;
    mm6108: mm6108@0  {
            compatible = "morse,mm610x-spi";
            reg = <0>;
            spi-max-frequency = <50000000>;
            spi-irq-gpios = <&pio 30 0>;
            reset-gpios = <&pio 8 0>;
            power-gpios = <0>;
            status = "okay";
    };
};
24

Why is your power-gpios undefined?

25

Hi @james.haggerty ,
I added it for debugging; I tried without it, and it also showed an error. Also, for your reference, when I did the Wi-Fi restart, I figured these logs

[ 124.919675] morse_spi spi1.0: Morse SPI device removed
[ 124.924822] Failed to acquire reset gpio. Skipping reset.
[ 125.003683] kmodloader: loading kernel modules from /etc/modules.d/morse*
[ 125.015697] morse micro driver registration. Version 0-rel_1_14_1_2024_Dec_05

I am not sure from where the error is triggered.

26

You must define the power-gpios to the host processor pins connected to wake and busy pins of the module respectively.

The second error regarding the reset-gpios is the driver claiming that it can’t access the gpio. Either the property you have set is invalid, or another peripheral has laid claim to it and is preventing our driver from using it.

Do you have a schematic snippet you can share for the connections between the module and the host processor?

27

Defining power GPIO is necessary, because we heard from our Chinese vendor that only reset and IRQ are necessary.

Can you define what all the gpios we need to include in the DTS?

Also, in AP mode, there were 5 iterations of “invalid gpio error”, but in STA mode, it was flooding. Can you provide any solution for that?

i will try to get the schematics for that from our vendor.

28

Also, in AP mode, there were 5 iterations of “invalid gpio error”, but in STA mode, it was flooding. Can you provide any solution for that?

AP mode will disable powersave by default, so the power-gpios will be largely unused (except initially).
Client mode will have power save enabled by default, and will frequently try to toggle the lines.

The Linux driver is written such that reset-gpios, and power-gpios (wake, busy respectively) are required to be defined.

If using SPI you will also need the spi-irq-gpios.

29

@ajudge

Thank you for your response. We will forward this information to our vendor and get back to you.