Problem launching a custom USB HaLow board on patched OpenWRT 24.5.10

Software
1

Hello!

We are currently integrating WiFi HaLow to our IOT gateway. The module is mm8108-mf15457

We do not have SPI or SDIO on the PCIe slot, so we have designed our own PCIe board with USB as a host interface.

OS:

$ cat /etc/os-release

NAME=“OpenWrt”

VERSION=“24.10.5”

ID=“openwrt”

ID_LIKE=“lede openwrt”

PRETTY_NAME=“OpenWrt 24.10.5”

VERSION_ID=“24.10.5”

HOME_URL=“https://openwrt.org/”

BUG_URL=“https://bugs.openwrt.org/”

SUPPORT_URL=“https://forum.openwrt.org/”

BUILD_ID=“r29087-d9c5716d1d”

OPENWRT_BOARD=“mediatek/mt7622”

OPENWRT_ARCH=“aarch64_cortex-a53”

OPENWRT_TAINTS=“no-all”

OPENWRT_DEVICE_MANUFACTURER=“OpenWrt”

OPENWRT_DEVICE_MANUFACTURER_URL=“https://openwrt.org/”

OPENWRT_DEVICE_PRODUCT=“Generic”

OPENWRT_DEVICE_REVISION=“v0”

OPENWRT_RELEASE=“OpenWrt 24.10.5 r29087-d9c5716d1d”

OPENWRT_BUILD_DATE=“1766005702”

It is a stock OpenWRT 24.10.5 patched from the Morse Micro OpenWRT fork on the top of the same branch

The system is built with the following additional configuration options:

CONFIG_DRIVER_11AH_SUPPORT=y

CONFIG_PACKAGE_netifd-morse=y

CONFIG_PACKAGE_hostapd_s1g=y

CONFIG_PACKAGE_morsecli=y

CONFIG_PACKAGE_morse-regdb=y

CONFIG_MORSE_REGDB_COUNTRY_CODE_FILTER=“SG”

CONFIG_PACKAGE_kmod-mm81x=y

CONFIG_PACKAGE_mm81x-firmware=y

The device enumerates successfully:

$ lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 001 Device 002: ID 325b:8100 Morse Micro MM81xx Wi-Fi HaLow 802.11ah Transceiver

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

However, during the startup I have the following issue:

[ 31.128154] Morse Micro mm81x driver registration. Version MM81X_VERSION

[ 31.183371] mm81x_usb 1-1:1.0: Loaded firmware from morsemicro/mm8108b2-rl.bin, size 456924, crc32 0xe4799c8d

[ 31.202184] mm81x_usb 1-1:1.0: Loaded BCF from morsemicro/bcf_boardtype_0807.bin, size 2081, crc32 0xa80ae47b

[ 32.534568] mm81x_usb 1-1:1.0: failed to flash firmware: -22

[ 32.540435] mm81x_usb 1-1:1.0: failed to init firmware: -22

[ 32.546070] mm81x_usb 1-1:1.0: Failed to init firmware: -22

[ 32.551663] mm81x_usb 1-1:1.0: Failed to restart chip: -22

[ 32.569623] Call trace:

[ 32.572062] dump_backtrace+0x9c/0xd8

[ 32.575727] show_stack+0x14/0x1c

[ 32.579036] dump_stack_lvl+0x44/0x58

[ 32.582694] dump_stack+0x14/0x1c

[ 32.586003] mm81x_core_destroy+0x2528/0x252c [mm81x]

[ 32.591064] wiphy_apply_custom_regulatory+0x3a4/0x1360 [cfg80211]

[ 32.597264] wiphy_regulatory_register+0x74/0x8c [cfg80211]

[ 32.602843] wiphy_register+0x54c/0x6f4 [cfg80211]

[ 32.607642] ieee80211_register_hw+0x858/0xb38 [mac80211]

[ 32.613070] mm81x_mac_register+0x1f4/0x29c [mm81x]

[ 32.617952] mmrc_set_fixed_rate+0x10d0/0x140c [mm81x]

[ 32.623092] usb_match_id+0x258/0x3fc [usbcore]

[ 32.627740] really_probe+0x140/0x2a8

[ 32.631398] __driver_probe_device+0x74/0x120

[ 32.635747] driver_probe_device+0x3c/0xd4

[ 32.639836] __driver_attach+0x88/0x150

[ 32.643665] bus_for_each_dev+0x60/0xa0

[ 32.647494] driver_attach+0x20/0x28

[ 32.651063] bus_add_driver+0xdc/0x1fc

[ 32.654804] driver_register+0x58/0x114

[ 32.658634] usb_register_driver+0x78/0x160 [usbcore]

[ 32.663724] mm81x_usb_init+0x28/0xfa0 [mm81x]

[ 32.668171] init_module+0x28/0x60 [mm81x]

[ 32.672269] do_one_initcall+0x68/0x1e8

[ 32.676099] do_init_module+0x54/0x1d0

[ 32.679842] load_module+0x18d8/0x196c

[ 32.683584] __do_sys_init_module+0x210/0x258

[ 32.687933] __arm64_sys_init_module+0x18/0x20

[ 32.692369] invoke_syscall.constprop.0+0x4c/0xe0

[ 32.697067] do_el0_svc+0x3c/0xbc

[ 32.700375] el0_svc+0x18/0x4c

[ 32.703424] el0t_64_sync_handler+0x118/0x124

[ 32.707774] el0t_64_sync+0x150/0x154

[ 32.711766] usbcore: registered new interface driver mm81x_usb

Is there anything that could cause this issue?

Will appreciate any help.

2

Hi @Peter_B

It appears you’ve pulled in our upstream driver, the one which merged into the kernel at 7.3.
Unfortunately, this driver only supports US frequencies, as that is all the kernel knows about. We have some work scoped to extend the supported regions for this driver, but it relies on more than just kernel changes.

Are you setting the region to SG? This could cause the error you are seeing.

For other region support, I’d recommend looking at the packages in GitHub - MorseMicro/morse-feed · GitHub to include our out of tree driver.

1 Like
3

Thank you for the lead!
You mean the driver, not the firmware, right?

How come the driver for kernel 7.3 is in the diff for owrt 24.5.10 which is on kernel 6.6? Or am i missing something?

4

In our OpenWrt fork we’ve backported the upstream driver to 6.6 to allow users to try it

1 Like
5

I see, thanks!
The feed is pinned by the commit hash. How do i know in which commit there is the correct in-tree driver?

Update:
I have realized that we are using the driver that came with the patch. The feed only contains kmod-morse, which is mm61xx driver.

6

Could you suggest which feed commit hash matches the mm/v24.10.5 ?

7

If i set the region later in the /etc/config/wireless:
idrc@egw_ee18760bcc44:~$ sudo uci set wireless.radio4.country='US'
idrc@egw_ee18760bcc44:~$ sudo uci commit wireless
idrc@egw_ee18760bcc44:~$ sudo wifi reload
[ 1211.683523] mm81x_usb 1-1:1.0: Loaded firmware from morsemicro/mm8108b2-rl.bin, size 456924, crc32 0xe4799c8d
[ 1211.694519] mm81x_usb 1-1:1.0: Loaded BCF from morsemicro/bcf_boardtype_0807.bin, size 2081, crc32 0xa80ae47b
[ 1212.853904] mm81x_usb 1-1:1.0: FW version mismatch, some features might not be supported: (Driver) 56.24.0, (Chip) 56.3.0

8

Just for clarity, are you intending to use the upstream driver? If you are, you don’t want morsecli/morse-regdb/netifd-morse or the country filter. I can tell you’re using the upstream driver because it says mm8x_usb.

As Arien mentioned, we would recommend using the normal driver for now. If you just remove kmod-mm8x and mm8x-firmware from your build and add morse-fw-8108 and kmod-morse, the upstream one should go away and things should work (I hope!).

1 Like
9

Unrelatedly, where did you get CONFIG_MORSE_REGDB_COUNTRY_CODE_FILTER=“SG” from? This does nothing in the current release of the software, AFAIK (this option has been removed).

10

So how to specify country if we use upstream driver?
And are there plans to keep it for kernel 6.6? (because currently only US is supported)

11

I see, that’s good to know. Will remove it

12

I’m happy to support you using the upstream driver, but I’m worried we’re getting side-tracked. Perhaps we should split the upstream driver questions out into a separate thread, @ajudge ?

Or you can clarify if the normal driver is not an option for you for some reason.

13

I confirmed that the patch uses upstream driver and it’s backport.
I want to switch to normal driver, yes.
Could you please suggest the morse-openwrt commit hash and corresponding morse-feed hash that I could use?

14

Check out:

The appropriate hash is the tip of the default branch (currently 3.2-dev). When configuring, select the morse-fw-8108 and kmod-morse packages and netifd-morse. These are available in Morse Micro/Essentials if you’re using make menuconfig. This will bring in everything you need.

feeds.conf.default will link to the appropriate feed hashes.

15

3.2-dev is on the top of OpwnWRT 24.10.5, right?

16

Yes, 3.2-dev has our changes on top of 24.10.5. But you don’t need to check out 24.10.5, just check out 3.2-dev.

(we should release a new version on top of 24.10.8 soon-ish)

1 Like
17

I’m late to the party, but the FW version mismatch error when OpenWrt loads the upstream driver was a known issue for this release. It shouldn’t impact functionality.

But as @james.haggerty has mentioned, this is not the driver you want right now as it has many features removed to allow us to get into upstream more smoothly :slight_smile:

Regarding the branch names. Treat mm/v24.10.5 as our “development” trunk that our versions branch off, and therefore as unstable. 3.2-dev (and better yet, the release tags themselves), will provide a much more stable base for you. The tags have the added benefit of specifying the commit hash in the feeds.conf.default file

18

Thanks a lot guys, it’s really helpful.
I will move to 3.2 (release, with pinned feeds) and see if i can make it work.
Will be back with an update