ah we may have our answer then
root@pi5-halow:~# grep -r mm610x /sys/firmware/devicetree/base/
root@pi5-halow:~# lsmod | grep spi
spidev 49152 0
spi_bcm2835 49152 0
spi_dw_mmio 49152 0
spi_dw 49152 1 spi_dw_mmio
what step could I have jacked up?
Good that the SPI driver is there. Looks like the device tree overlay isn’t being applied.
What does ls /boot/firmware/overlays/wm6108-spi.dtbo show?
(/boot/overlays should be a symbolic link /boot/firmware/overlays)
There is a tool that you can use to load device tree overlays at runtime. You could try that for testing. I don’t recall if it is included by default in Raspberry Pi OS, if it is it might be worth giving it a try.
sudo dtoverlay wm6108-spi
you can also list loaded overlays
sudo dtoverlay -l
These might also help point at what is going wrong.
root@pi5-halow:/boot/firmware/overlays# dtoverlay -v wm6108-spi
DTOVERLAY[debug]: using platform 'bcm2712'
DTOVERLAY[debug]: overlay map loaded
run_cmd: which dtoverlay-pre >/dev/null 2>&1 && dtoverlay-pre
DTOVERLAY[debug]: loading file '/boot/firmware/overlays/wm6108-spi.dtbo'
DTOVERLAY[debug]: wrote 2138 bytes to '/tmp/.dtoverlays/0_wm6108-spi.dtbo'
DTOVERLAY[debug]: wrote 2138 bytes to '/sys/kernel/config/device-tree/overlays/0_wm6108-spi/dtbo'
* Failed to apply overlay '0_wm6108-spi' (kernel)
run_cmd: which dtoverlay-post >/dev/null 2>&1 && dtoverlay-post
root@pi5-halow:/boot/firmware/overlays# dtoverlay -l
No overlays loaded
dmesg
[32155.186628] OF: resolver: node label 'morse_trst' not found in live devicetree symbols table
[32155.186635] OF: resolver: overlay phandle fixup failed: -22
I do notice this warning when using dtc. Also the list of compatibles at the top of the .dts file doesn’t include bcm2712 for the rpi5. not sure if either of those findings are significant.
wm6108-spi.dts:16.42-25.27: Warning (unique_unit_address): /fragment@0/__overlay__/mm6108@0: duplicate unit-address (also used in node /fragment@0/__overlay__/spidev@0)
The issue is the following reference in pinctrl-0 - &morse_trst
Just remove the &morse_trst from the pinctrl for the spi node and rebuild the dtbo. I will also have to remove from the guide, as I’ve accidentally left it in there - my fault, sorry 
.
It’s not relevant for the SeeedStudio hat, but rather an artefact from the mmech06 board (the hat used in our EKH01 kits) that I was using during the guide.
You could also add brcm,bcm2712 to the list of compatibles if you like.
Will fix and test shortly!
we’ve done it! I see the one error in dmesg but maybe that’s expected. how’s it looking to you?
iw_phy.txt (12.0 KB)
dmesg.txt (46.6 KB)
ifconfig_a.txt (1.6 KB)
It seems the interface has come up correctly and is functioning. The error seen (-19=ENODEV) seems a bit odd, but it looks like the hardware restart called immediately after has resolved that.
All in all, looks good so far! Well done.
@ajudge thank you again for all the assistance. I was able to spin up another pi5 without hiccup. I attached all steps below that worked for me. Hope this helps some others. I did all of the steps as root so no need for sudo.
# Dependencies
apt install fakeroot build-essential libncurses-dev xz-utils libssl-dev flex libelf-dev bison git device-tree-compiler bc -y
git clone --branch stable_20250428 https://github.com/raspberrypi/linux
cd linux
git remote add morse https://github.com/MorseMicro/rpi-linux.git
git fetch morse
git cherry-pick b37a3f6bb..morse/mm/rpi-6.12.21/1.16.x
# Working hashes after fixing conflicts
sha256sum include/net/mac80211.h
d9e4ea0bbaa84c4cd106302c8b166cc05dac7f598da398cfa83abe06f3fcb3fa include/net/mac80211.h
sha256sum net/mac80211/debugfs.c
c7a3ef4ca4bf2a8ee97ec2e6bf55ca94d992e5cc3412af913e6cec38fd012671 net/mac80211/debugfs.c
sha256sum net/mac80211/mesh_hwmp.c
19fba1e89b7ce1a1c1aec4c72b59e90e9a7a1741236a62770f7a4c61094a8d09 net/mac80211/mesh_hwmp.c
cd ~
git clone https://github.com/MorseMicro/morse_driver.git
cd morse_driver
git submodule update --init --recursive
cd ~
git clone https://github.com/MorseMicro/morse-firmware.git --branch 1.16
cd ~/linux
make bcm2712_defconfig
sed -r -i 's/CONFIG_LOCALVERSION=\"(.*)\"/CONFIG_LOCALVERSION=\"\1-morse\"/g' .config
make -j6 Image.gz modules dtbs
make -j6 modules_install
cp arch/arm64/boot/Image.gz /boot/firmware/kernel_2712-morse.img
cd ~/morse_driver
make KERNEL_SRC=~/linux/ CONFIG_WLAN_VENDOR_MORSE=m CONFIG_MORSE_SPI=y CONFIG_MORSE_USER_ACCESS=y CONFIG_MORSE_VENDOR_COMMAND=y
make KERNEL_SRC=~/linux modules_install
cd ~/morse-firmware
make install
cd ~
cat << EOF >> wm6108-spi.dts
/dts-v1/;
/plugin/;
/ {
compatible = "brcm,bcm2835", "brcm,bcm2836", "brcm,bcm2708", "brcm,bcm2709", "brcm,bcm2711", "brcm,bcm2712";
fragment@0 {
target = <&spi0>;
frag0: __overlay__ {
pinctrl-0 = <&rp1_spi0_gpio9 &rp1_spi0_cs_gpio7 &morse_wake &morse_busy &morse_irq &morse_reset>;
cs-gpios = <&gpio 8 1>;
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
mm6108: mm6108@0 {
compatible = "morse,mm610x-spi";
reg = <0>;
reset-gpios = <&gpio 17 0>;
power-gpios = <&gpio 23 0>,
<&gpio 24 0>;
spi-irq-gpios = <&gpio 25 0>;
spi-max-frequency = <50000000>;
status = "okay";
};
spidev@0 {
reg = <0>;
status = "disabled";
};
spidev@1 {
reg = <1>;
status = "disabled";
};
};
};
fragment@1 {
target = <&rp1_spi0_cs_gpio7>;
frag1: __overlay__ {
function = "gpio";
pins = "gpio8";
bias-pull-up;
};
};
fragment@2 {
target = <&gpio>;
frag2: __overlay__ {
morse_wake: morse_wake {
function = "gpio";
pins = "gpio23";
output-high;
bias-disable;
};
morse_busy: morse_busy {
function = "gpio";
pins = "gpio24";
input;
bias-pull-down;
};
morse_irq: morse_irq {
function = "gpio";
pins = "gpio5";
bias-pull-up;
input;
};
morse_reset: morse_reset {
function = "gpio";
pins = "gpio17";
output-high;
bias-disable;
};
};
};
fragment@3 {
target = <&rp1_spi0_gpio9>;
frag3: __overlay__ {
bias-disable;
};
};
};
EOF
dtc -I dts -O dtb wm6108-spi.dts -o wm6108-spi.dtbo
cp wm6108-spi.dtbo /boot/overlays/
echo "dtoverlay=wm6108-spi" | sudo tee -a /boot/firmware/config.txt
echo "dtparam=spi=on" | sudo tee -a /boot/firmware/config.txt
echo "kernel=kernel_2712-morse.img" | sudo tee -a /boot/firmware/config.txt
echo "options morse bcf=bcf_fgh100mhaamd.bin" | sudo tee -a /etc/modprobe.d/morse.conf
reboot
You’re welcome. Very glad you got there in the end.
There’s a couple of minor errors in the build thread on my side with the SeeedStudio device tree file - unfortunately I didn’t have one on hand to test. I’ll fix that up as soon as possible.
Nooooo
root@pi5-halow-client:~# ip link set wlan1 down
root@pi5-halow-client:~# iw dev wlan1 set type mp
root@pi5-halow-client:~# ip link set wlan1 up
RTNETLINK answers: Operation not permitted
how can I get this driver for US?
[ 207.261464] morse_spi spi0.0: Regulatory domain US is not consistent with loaded country code AU
It shouldn’t be required, but you can set a country code to the driver on driver insertion.
If you’re using the modprobe.d files just add the parameter in, eg
morse bcf=bcf_fgh100mhaamd country=US
If you’re inserting manually then run modprobe morse bcf=bcf_fgh100mhaamd country=US
The driver should be taking hints from the kernel about the region making the above not strictly required. Curious to know what happens if you manually run iw reg set US before bringing the interface up.
it worked by adding the country=US to modprobe.d file. I did try the iw reg set US but that didn’t fix things. seems okay now. working on meshing 2 nodes.
Cool! Keen to see how far you get with standard Raspberry Pi OS for meshing.
You may find yourself needing to use wpa_supplicant_s1g instead of the standard wpa_supplicant for various fixes and improvements. If you do need to use wpa_supplicant_s1g, this will also require our morse_cli utility for some dependent vendor specific commands.
Instructions for compiling these can be found in our Linux Porting Guide - pages 9-11 .
I’ll post some updates after I work through it. I had a good setup script for 2.4 GHz meshing. Not sure what I’ll have to modify yet.
Okay I’m sorry to say but I am stuck again. I followed the appnote to compile hostapd_s1g and wpa_supplicant_s1g, along with morse_cli. I am using the example configs from the appnote with the only exception being I changed country_code in the hostapd.conf to be US.
hostapd_s1g output.
root@pi5-halow:~# hostapd_s1g hostapd.conf
s1g mapped ht channel 163
Automatically configuring VHT due to 160MHz chan selection
Full Channel Information
Operating Frequency: 924000 kHz
Operating BW: 8 MHz
Primary BW: 2 MHz
Primary Channel Index: 0
wlan1: interface state UNINITIALIZED->COUNTRY_UPDATE
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
wlan1: interface state COUNTRY_UPDATE->ENABLED
wlan1: AP-ENABLED
But when I try to launch wpa_supplicant_s1g
root@pi5-halow:~# wpa_supplicant_s1g -D nl80211 -i wlan1 -c wpa_supplicant.conf
Successfully initialized wpa_supplicant
nl80211: kernel reports: Match already configured
nl80211: Could not configure driver mode
nl80211: deinit ifname=wlan1 disabled_11b_rates=0
wlan1: Failed to initialize driver interface
wlan1: CTRL-EVENT-DSCP-POLICY clear_all
I tried a couple commands with morse_cli but they all seem to fail. Maybe that’s expected because I’m not using your hardware.
root@pi5-halow:~# morse_cli hw_version
NL80211, code -95: Error callback called
NL80211, code -10: Failed to rcvmsgs
Command 'morse_cli hw_version' failed with error code -10
root@pi5-halow:~# morse_cli stats
NL80211, code -95: Error callback called
NL80211, code -10: Failed to rcvmsgs
NL80211, code -95: Error callback called
NL80211, code -10: Failed to rcvmsgs
Command 'morse_cli stats' failed with error code -10
EDIT: Ah, am I supposed to run hostapd on one device, and wpa_supplicant on another? 
they seem to be competing with each other.
EDIT: Progress!!
pi5-halow: hostapd
root@pi5-halow:~# hostapd_s1g ./hostapd.conf
s1g mapped ht channel 163
Automatically configuring VHT due to 160MHz chan selection
Full Channel Information
Operating Frequency: 924000 kHz
Operating BW: 8 MHz
Primary BW: 2 MHz
Primary Channel Index: 0
wlan1: interface state UNINITIALIZED->COUNTRY_UPDATE
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
RAW Settings: disable 4096 26900 1 disable 0 0 0 0
wlan1: interface state COUNTRY_UPDATE->ENABLED
wlan1: AP-ENABLED
wlan1: STA 3c:22:7f:71:d9:e7 IEEE 802.11: associated (aid 1)
wlan1: AP-STA-CONNECTED 3c:22:7f:71:d9:e7
wlan1: STA 3c:22:7f:71:d9:e7 RADIUS: starting accounting session CD4545396FFC24CB
wlan1: STA 3c:22:7f:71:d9:e7 WPA: pairwise key handshake completed (RSN)
wlan1: EAPOL-4WAY-HS-COMPLETED 3c:22:7f:71:d9:e7
pi5-halow-client: wpa_supplicant
root@pi5-halow-client:~# wpa_supplicant_s1g -D nl80211 -i wlan1 -c ./wpa_supplicant.conf
Successfully initialized wpa_supplicant
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
nl80211: kernel reports: Match already configured
morse: disable long sleep on ifname wlan1
wlan1: SME: Trying to authenticate with 3c:22:7f:37:4d:57 (SSID='MorseMicro' chan=37)
wlan1: SME: Trying to authenticate with 3c:22:7f:37:4d:57 (SSID='MorseMicro' chan=37)
wlan1: PMKSA-CACHE-ADDED 3c:22:7f:37:4d:57 0
wlan1: Trying to associate with 3c:22:7f:37:4d:57 (SSID='MorseMicro' chan=-1)
wlan1: Associated with 3c:22:7f:37:4d:57
wlan1: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlan1: WPA: Key negotiation completed with 3c:22:7f:37:4d:57 [PTK=CCMP GTK=CCMP]
wlan1: CTRL-EVENT-CONNECTED - Connection to 3c:22:7f:37:4d:57 completed [id=0 id_str=]
Am able to pass data between nodes! Also confirmed meshing doesn’t seem to work when I add mode=5 to my wpa_supplicant.conf. Any current work arounds for 802.11s with these seeedstudio cards and your firmware/drivers?
What else is super weird is I cannot ping from server to client (hostapd to wpa_supplicant) unless im already pinging client to server. hopefully that makes sense. pings report host unreachable unless im actively trying to ping the other direction. Same issue occurs with iperf3. I did have a successful iperf3 test with the server as the hostapd system, and the client as the wpa_supplicant system
root@pi5-halow-client:~# iperf3 -c 10.0.0.1
Connecting to host 10.0.0.1, port 5201
[ 5] local 10.0.0.2 port 37360 connected to 10.0.0.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 2.19 MBytes 18.4 Mbits/sec 0 119 KBytes
[ 5] 1.00-2.00 sec 2.49 MBytes 20.9 Mbits/sec 0 223 KBytes
[ 5] 2.00-3.00 sec 2.80 MBytes 23.5 Mbits/sec 0 313 KBytes
[ 5] 3.00-4.00 sec 2.24 MBytes 18.8 Mbits/sec 0 393 KBytes
[ 5] 4.00-5.00 sec 2.42 MBytes 20.3 Mbits/sec 0 414 KBytes
[ 5] 5.00-6.00 sec 2.42 MBytes 20.3 Mbits/sec 0 414 KBytes
[ 5] 6.00-7.00 sec 1.62 MBytes 13.6 Mbits/sec 0 414 KBytes
[ 5] 7.00-8.00 sec 2.42 MBytes 20.3 Mbits/sec 0 414 KBytes
[ 5] 8.00-9.00 sec 1.62 MBytes 13.5 Mbits/sec 0 421 KBytes
[ 5] 9.00-10.00 sec 2.61 MBytes 21.9 Mbits/sec 0 445 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 22.8 MBytes 19.1 Mbits/sec 0 sender
[ 5] 0.00-10.13 sec 20.9 MBytes 17.3 Mbits/sec receiver
iperf Done.
Also I’d love to use 915 MHz
@ajudge figured I’d check in after harassing you consistently last week. Anything I posted make sense?
Hey @castironclay, sorry i managed to miss this.
I’ll need to take a closer look at my own setup and confirm configuration for you. I won’t be able to do that until next week unfortunately. So I’ll have to give some handwavey guidance for now.
There shouldn’t be any magic needed (except the kernel patches) to get meshing to work. It is a fair amount of configuration once you start needing to consider routing protocols - which is why we generally recommend OpenWrt at this point. It is possible the kernel hasn’t been compiled with mesh support (CONFIG_MAC80211_MESH=y).
The inability to iperf until you send a ping from the client sounds like the routing table might be unable to establish the mac for the client. This could possibly happen if there is no broadcast address set on the interface so ARPs are failing, or otherwise a firewall is getting in the way. I’d be interested to see the output of ip -a on the device when the iperf doesn’t function.
Thank you @ajudge I will look in to those and report back.