That's exactly what I was looking for. Thank you. On Monday I get my consol cable, so I'll start working on those steps at that time. I'm looking forward to it.
Just an update: I just had time to pull all the data from my router as shown in the article. Now I need to map GPIO ports, so I'll see if testing those at startup will work. I'm having the same issue as at https://forum.archive.openwrt.org/viewtopic.php?id=60299
If anyone else knows an easier way to test GPIOs while the router is running, let me know. Just wish there was a way to turn them all off so I could probe...
1 Like
Not sure what happened to the editing functionality on here, so I guess I'm stuck adding more and more comments...
Anyway, I mapped out most of the GPIO today, and it was very complicated. I still couldn't get the 2.4GHz, 5GHz, and WAN LEDs mapped because they just don't change for the GPIO values.
In case you'd like to know how I did it, see below, but here's my mapping so far. (I kept to the formatting from the original output of cat /sys/kernel/debug/gpio. The original only listed the 18 and 19 labels. Also some of the labels I added also needed the hi/lo setting changed from the output.)
gpio-5 ( |? ) out hi
gpio-7 ( |? ) out hi
gpio-8 ( |? ) out hi
gpio-9 ( |? ) out hi
gpio-11 ( |? ) out lo
gpio-13 ( |Module #2 ) out lo
gpio-14 ( |Module #1 ) out lo
gpio-15 ( |? ) out hi
gpio-16 ( |Power/Booting ) out lo
gpio-17 ( |Internet ) out lo
gpio-18 ( |Reset Button ) in hi
gpio-19 ( |pcie_rst ) out hi
Here's what I did to get this list using the console port (USB console wire needed) on the router:
- Run
find /lib/modules/$(uname -r) -type f -name '*.ko*'and pipe it to grep to find "led" and "gpio". - Find out about
leds-gpio.komodule which controls the LEDs. - Disable that module by running
rmmod leds-gpio.koso it allows the below commands to work and not say the device is busy. - Use
vito create shell scripts listed at https://openwrt.org/docs/guide-developer/add.new.device. - Maps the LEDs using the gpio-test.sh script.
Now if you'd like to test the Reset Button, use rmmod gpio-button-hotplug.ko and then running the gpio-dump.sh will show that GPIO 18 is free. I don't remember which kernel module I disabled to free GPIO 19, though.
Now here's where I'm currently stuck. Below is a list of things I've tried to get the GPIOs for the remaining 3 lights. (5GHz, 2.4GHz, WAN)
- Run
ifconfigto see a list of all interfaces. - Run
ifconfig ra0 downto disable 2.4GHz. - Run
ifconfig rai0 downto disable 5GHz. - Run ifconfig eth1 down to disable WAN.
- Now that all LEDs in this group are off, run the gpio-dump.sh file to see that nothing changes. Run the gpio-test.sh to try turning on and off those LEDs to no avail. Try editing the script to use chip 32 and chip 64, and see that none of those GPIOs are mapped to the LEDs.
If you have some ideas on mapping those last 3 lights, let me know. Mofi stock firmware is OpenWRT, so that should make things more convenient.
My next steps to try:
- See how I can use the leds-gpio.ko functionality to control the LEDs through that. Disabling that doesn't seem to disable those lights, hence the
ifconfigstuff, so this is probably indicating that it's not what changes those LEDs. - Open up the device and see if I can follow the track on each LED, back to the chip pin, and find a pinout for the MT7621 to find out which GPIO they map to.
EDIT:
I just noticed that the WLAN LED and the LED on the WLAN port blink at the same time, so maybe they use the same track on the board. I'm wondering if the two wifi LEDs are connected to the wifi chip pins, and not the CPU GPIO pins. That could explain a lot, and then I don't have to map those at all, but why would disabling the LED kmod free several other GPIOs? Perhaps it's for an LED inside the device? I'll have to test that tomorrow.
EDIT 2:
Yay! I figured out the last of the LEDs by opening up the MoFi and examining it. I've also learned what major chips are present on it, too, as well as its RAM and flash chip memories.
First the LEDs. I traced the tracks on the board for the 3 missing LEDs. The WAN LED is in serial with the LED on the RJ45 jack. So no GPIO. It's handled elsewhere as far as I can tell.
Next up are the 2 WiFi LEDs. Those don't map to the main processor directly. They instead go to each of the WiFi processor chips on the board. (See below for which ones are used.
Alright, so here's the list of chips on the board.
- GL3510 USB Controller
- Max3232 RS-232 Controller
- NT5CB256M16CP-DI - DDR3 4GB SD RAM chip
- 25Q256JVEQ - 32MB SPI FLASH
- MT7615N - There are two of these. One is configured to handle the 5GHz half, and the other is configured to handle 2.4GHz.
- MT7621AT main processor
- SKY85728-11 5GHz front end chips (Not sure that this is important info, but that's how I could tell that the two MT7615N chips were configured differently.)
Well now I should have all the info I need to create a board for OpenWRT. What I'm not sure of is if OpenWRT will be able to sniff out the USB an SD card ports or not. I'll have to try and see. I don't have the sim card driver boards in my MoFi since carriers just disable my service whenever I would use them on the 4500, but if there's an option to bake that into the firmware with make menuconfig then I'll do it.
Anyway, the build is tomorrow's project. For now I'll just log my findings in case it helps others.
Just a quick progress update:
I started work on the files for the MoFi 5500 board today. The bread and butter is /target/linux/ramips/dts/mt7621_mofinetwork_mofi5500-5gxelte.dts which I built from scratch from my research and copying data from other 7621 files.
To get the board to show in make menuconfig, I edited /target/linux/ramips/image/mt7621.mk and added a new entry for the MoFi 5500 in alphabetical order. Here's what I put in there. If this is missing something or is wrong in some way, let me know. I have yet to test it. Unless I have reason to edit more files or add more data to the DTS, then I'll just add the kmod packages to the make file tomorrow and that's it.
define Device/mofinetwork_mofi5500-5gxelte
IMAGE_SIZE := 27656k
DEVICE_VENDOR := MoFi Network
DEVICE_MODEL := MOFI5500-5GXeLTE
DEVICE_PACKAGES := kmod-mt7615-firmware kmod-usb3
SUPPORTED_DEVICES += mofi5500-5gxelte
endef
TARGET_DEVICES += mofinetwork_mofi5500-5gxelte
I'll grab a list of installed kmods from the current MoFi firmware tomorrow. Then I'll work out which ones are for the hardware on the device, and which should just be customized through make menuconfig.
So tomorrow is test day, and I'll do it as a ramfs so it doesn't write to flash right away. See what's working, what's busted, and what I need to do.
EDIT:
The IMAGE_SIZE came from the decimal size of the "firmware" partition, rounded to kilobytes.
The OpenWRT codebase and selections have gotten to the point of being overwhelming, especially since the docs are either outdated or non-existent.
As a software engineer of over 20 years, I'm saddened to see that such a major project has such poor documentation to the point of being unworkable for people new to the ecosystem. I was really hoping for some setting where I could spin up a default OpenWRT image, and just have to describe my hardware in a DTS file, and select a few extra packages. Instead I find volumes of libraries to install (useless without installing software that depends on them, and should just get selected in the background), lots of non-luci packages which might not have a Luci interface, and so on and so forth.
There are even multiple configuration systems, such as make config and make kernel_menuconfig which I can't for the life of me understand why there needs to be so many when we should just be focusing on a unified configuration interface. Do you have to use them all? Do you pick one? Without proper docs, I haven't a clue.
Why are we piecing out so many things at such a low level in make menuconfig instead of making it intuitive?
I'm throwing in the towel, as this is horrendously documented and designed. If I'm missing something, feel free to chime in here. Below is my DTS file which uses my above research, but as I can generate a 43MB file when the makefile says that the max is only a bit over 27MB, I'm unable to test it. I don't even know if I got anything right in the compilation. There's just no intuitive interface to generate a basic image to start testing features. Hopefully this research gets someone else interested in taking over the project. It's just not worth it to me to keep going...
Target device: Mofi 5500 5GXeLTE (No sim version, so I didn't add in cell modem data.)
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
#include "mt7621.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
/ {
compatible = "mofinetwork,mofi5500-5gxelte", "mediatek,mt7621-soc";
model = "MoFi Network MOFI5500-5GXeLTE";
aliases {
led-boot = &led_power;
led-failsafe = &led_power;
led-running = &led_power;
led-upgrade = &led_power;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
compatible = "mips,mips1004Kc";
reg = <0>;
};
cpu@1 {
device_type = "cpu";
compatible = "mips,mips1004Kc";
reg = <1>;
};
cpu@2 {
device_type = "cpu";
compatible = "mips,mips1004Kc";
reg = <2>;
};
cpu@3 {
device_type = "cpu";
compatible = "mips,mips1004Kc";
reg = <3>;
};
};
chosen {
bootargs = "console=ttyS0,115200";
};
leds {
compatible = "gpio-leds";
led_power: power {
label = "green:power";
gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
};
internet {
label = "green:internet";
gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
};
module_1 {
label = "blue:module_1";
gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
};
module_2 {
label = "blue:module_2";
gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
};
};
keys {
compatible = "gpio-keys-polled";
poll-interval = <10>;
reset {
label = "reset";
gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
linux,code = <KEY_RESTART>;
};
};
};
&switch0 {
ports {
port@0 {
status = "okay";
reg = <0>;
label = "lan1";
};
port@1 {
status = "okay";
reg = <1>;
label = "lan2";
};
port@2 {
status = "okay";
reg = <2>;
label = "lan3";
};
port@3 {
status = "okay";
reg = <3>;
label = "lan4";
};
};
};
&sdhci {
status = "okay";
};
&i2c {
status = "okay";
};
&pcie {
status = "okay";
};
&pcie0 {
wifi0: wifi@0,0 {
compatible = "pci14c3,7615";
reg = <0x0000 0 0 0 0>;
mediatek,mtd-eeprom = <&factory 0x0000>;
ieee80211-freq-limit = <2400000 2500000>;
};
};
&pcie1 {
wifi1: wifi@0,0 {
compatible = "pci14c3,7615";
reg = <0x0000 0 0 0 0>;
mediatek,mtd-eeprom = <&factory 0x8000>;
ieee80211-freq-limit = <5000000 6000000>;
};
};
&spi0 {
status = "okay";
flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <133000000>;
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "Bootloader";
reg = <0x0 0x30000>;
read-only;
};
partition@30000 {
label = "Config";
reg = <0x30000 0x10000>;
read-only;
};
factory: partition@40000 {
label = "factory";
reg = <0x40000 0x10000>;
read-only;
};
partition@50000 {
compatible = "denx,uimage";
label = "firmware";
reg = <0x50000 0x1ab0000>;
};
partition@1b00000 {
label = "stock_kernel";
reg = <0x1b00000 0x1ec68e>;
read-only;
};
partition@1cec68e {
label = "stock_rootfs";
reg = <0x1cec68e 0x18c3972>;
read-only;
};
partition@35B0000 {
label = "rootfsstock__data";
reg = <0x35B0000 0x2d0000>;
read-only;
};
partition@3880000 {
label = "Recovery";
reg = <0x3880000 0x500000>;
read-only;
};
};
};
};
Don't be part of the problem, become a part of the solution.
That part is trivial (and documented in the wiki), compared to the original development needed to get a working DTS, image generation, firstboot initialization and sysupgrade support. If you have to ask about the former, you certainly won't stand a snowball's chance in hell to get either of the later working.
2 Likes
I WOULD be part of the problem if I tried to document anything without understanding it. Just because I've explored a bit and made an attempt at creating an OpenWRT distro does NOT make me an expert, and I shouldn't be documenting things which could mislead others. This thread shows my research and what I've learned, but as I said, I don't even know if the DTS is right.
As for the second bit, the reason why I'm looking for docs on OpenWRT compilation is because I don't understand OpenWRT compilation. If I had a tutorial on that which is able to work with the current release, then I could follow along. Do you have a link?
You mentioned the following tasks. My notes follow.
- Make a working DTS - If I can get a release that'll fit, then I can test an initramfs version so as not to impact my installed software.
- Image generation -
make menuconfigis where I'm overwhelmed by options, and it's not intuitive. I can get a distro to compile, but it's too large. - Firstboot initialization - Not sure what this entails, but I think you mean writing boot scripts. I haven't gotten this far.
- Sysupgrade support - In theory, this should just be upload it to the existing OpenWRT upgrade screen, so there shouldn't need to be any development nor configuration here.
There are currently around 230 supported mt7621 based devices, pick any of them (bonus points if you pick one with comparable features) and build an image for it, 98% of that (apart from the crucial parts 1-4 that do need original development, and that is indeed a steep learning curve) will be the same you will need four your device - and -while the image itself is 'useless' to you- will show you what needs to be done.
--
how to set up your build environment and to build for supported devices is documented in the wiki, and repeatedly explained in the forum for other devices, including best practices and shortcuts.
I'm not sure what that would get me. From what I gather, all that would change is the target and subtarget stuff in make menuconfig. Do you mean I should see if they work and then just copy the DTS for that device? That's a good idea if that's the case.
I found this one which showed me the make defconfig, but it says it didn't change anything when I ran that. Maybe it doesn't delete selected options and I have the defaults and then some. Not sure.
In addition, a Google search showed me the Table of Hardware, but that's all I found. Nothing I saw gives me a list of devices with a configuration tutorial. Any ideas?
I'll just throw this into the discussion as example for a seed config for make defconfig (doesn't need to be done this way, but may help to understand what is going on):
CONFIG_TARGET_ramips=y
CONFIG_TARGET_ramips_mt7621=y
CONFIG_TARGET_ramips_mt7621_DEVICE_dlink_dap-x1860-a1=y
CONFIG_PACKAGE_luci-ssl=y
…or more verbosely:
- choose your target
- select your sub-target
- select your target device
(as yours isn't available yet, substitute one randomly, to get into the flow)
- select your target device
- select your sub-target
- keep it pretty and include luci-ssl
- for anything else, stick to the defaults
(later add whatever else -beyond the defaults- you want).
--
which is indeed all the manual configuration you need, to get a fully functional image for the referenced devices, if you do it like this by seeding it for the defconfig make target or start your endeavour via the menuconfig route.
1 Like
Thank you. I'll give it a go when I get a moment.
So I tried that today, and here's what I learned and what happened.
- Backup my original .config and create a new one with the following contents.
CONFIG_TARGET_ramips=y
CONFIG_TARGET_ramips_mt7621=y
CONFIG_TARGET_ramips_mt7621_DEVICE_mofinetwork_mofi5500-5gxelte=y
CONFIG_PACKAGE_luci-ssl=y
- Run
make clean - run
make - It built my new firmware using only about 7MB. To use the initramfs, I had to install the TFTP server using
sudo apt-get install tftpd-hpa. By default, it creates a directory to use at/srv/tftp. I chose to use it and copied my initramfs bin file to that under the nameram.binfor simplicity. - Using my console cable to talk to the router using
screen /dev/ttyUSB0 115200, I logged in and told it toreboot. - Upon rebooting, I hit
1to get it to write the initramfs file to memory using TFTP. It asked me for the device IP (its own IP) and the server IP (my computer's IP). This is where it got difficult. - I plugged in my ethernet cable between my laptop and router so that it could talk to each other via IP, then disabled wifi on my laptop and enabled the wired connection. I configured the wired connection to use a static IP of
192.168.10.100and gave it the gateway IP of192.168.10.1. (Same details I gave the router when telling it to boot from TFTP.) It then automatically downloaded the initramfs and booted up. - Now for the testing. I learned that my labels were backwards on my DTS for the lan ports. They all populated and saw traffic stats with
ifconfig. I swapped the labels in DTS for later. - Then I tested if it could see the USB device I plugged into both USB ports. The console said I inserted it and removed it, which is the desired response. I didn't see any USB devices in /dev, though, so not sure what's up with that. I'll test that more later.
- I tested the SD Card by inserting one and removing it. The console didn't say anything. So maybe the defaults didn't include SD card drivers.
- The LEDs worked fine for power and WAN. Wifi wasn't running, and that's probably because I didn't configure it in LuCI, so those lights were rightfully off. Module lights were off, too, as I don't have any cell modules installed. I also have a MoFi 4500, so maybe I'll see if that module is compatible and test it later. The internet LED didn't blink, and I couldn't get a connection.
- I tested
ping google.comand it said it was an invalid name, so no connection.ping 192.168.1.1worked and said it was OpenWRT, so it knows it's IP. I testedwget https://192.168.1.1 --no check-certificateand it downloaded the index page for LuCI, so it is trying to serve LuCI. - I removed my static IP stuff and reset the wired connection, then tried opening
192.168.1.1in a browser. The router said it assigned me an IP in the /24 range, but I didn't get any response from the router, so no LuCI. I tried visiting Google, and it just endlessly loaded, too. Then I switched off the wired connection and turned back on wifi to connect to Starlink, and still no Google. My phone contacted Google just fine through Starlink, so I rebooted my computer and got a connection. No idea what was up with that, so hopefully it was a temporary issue. - Rebooting my router set everything back to the way it was before the initramfs, so everything works now internet-wise.
So my big issues to troubleshoot tomorrow are:
- Get the firmware loaded, and make it so I can visit LuCI in a browser. I need to see what's there and if everything looks normal, and see what's up with the internet connection issue. I'll also need to see if I can enable WiFi and get that to connect me. If not, then the DTS is probably wrong or the defaults don't include WiFi.
- Try compiling in something for the SD card reader to get it recognized.
If you see anything obvious as to why the internet connect didn't work or why my router said I connected via lan and had traffic on all 4 ports that I plugged into, but couldn't use LuCi, then let me know. Oh, and thanks for the idea, slh.
2 Likes
definitely rooting for you. I have a MOFI5500 5500V1-EM9191 - which, is rather disappointing. in fact I have a replacement cell modem/router arriving today because the service reliability with the mofi just doesn't cut it.
feel free to ping me once you get a better handle on this (which it sounds like you are well on the way to doing) because I could be coaxed into allowing the use of mine for dev (maybe) I would definitely like to see actual support for this hardware vs discarding it like it is disposable.
1 Like
Thank you. I chose a bunch of LuCI features and recompiled it. It was just below the maximum allowed space on the flash, but I have a few megabytes more. I have yet to test it, though.
Also, I bought an EM7455, cabling, and antennas to test if it will try to use the Sim features. Mofi said the 5500 supports that, too, and it was only like $50 for all of that, so I'll be testing it as best as I can.
Once I have a flashable bin file, would you like to beta test it for me? It'll especially help validate if the module can connect to a provider.
Also, while the info is still fresh in my mind and the hard part is done once I finish the 5500, I'm planning to do the same for my 4500 and release that for practice. Then we'll have both modern Mofi systems. No guarantees, though.
I would be happy to test it when/if it comes to that. relatively low risk seeing as it will be spare for me. I am surprised Mofi spoke more than one line and one time to you. every time I have submitted a ticket - it's a one line response (usually asking for information) and then they never respond again - if they respond in the first place. also yes, the firmware they list is one-for-all of a type so all variants of the 5500 series uses the same thing which seems a little off to me but what do I know.
They barely talk to me. I asked for their DTS as a "pot of red meat", but they didn't reply. I didn't actually think they'd send it, but it was worth a shot.
My info on their cards came from https://www.reddit.com/r/Rural_Internet/comments/1048w81/mofi55005gxelte_internal_guts/
The reason I decided to make my own distro for the 5500 is because they're very lax with security.
See https://www.zdnet.com/article/backdoors-left-unpatched-in-mofi-routers/
UPDATES:
I've gained access to LuCI now and poked around. I got A LOT working now.
- USB drives work fine.
- SD Cards don't yet get recognized. I'm still figuring out why. I installed the kmod-mmc which is supposed to make them work. Not sure what's going on.
- The LEDs all work fine across the board.
- WiFi connectivity works now, and it's upgraded to allow for WPA3, and fall back to WPA2 as one of the options on both 5GHz and 2.4GHz radios.
- I installed mwan3, so it has failover and load balancing capabilities, as well as multiwan options. I'm also able to scan for and connect to other networks. It's VASTLY more complicated than the stock MoFi firmware, but it's all possible to configure through LuCI. I'll need to learn how to do it, though.
- The most important drawback right now is that WAN does not work in any way. If I connect to a wifi network using the router as the client, it doesn't give me internet access. Connecting a live internet connection to the ethernet jack doesn't work either. I can't get a ping response from Google through the router. No idea what's going on at all. Any ideas will be very helpful. I'm using initramfs in case it matters. I've also make nftables default to fully open to see if that helped, and it didn't.
- I am now recompiling the firmware with watchcat as a way to reset any failing wan connections or the router. I'm not 100% sure how it works, but if someone has issues with connections dropping, then this will at least try to get it up and running again.
- There's a "Modems" page, but it's blank. Perhaps once I install my module on Saturday then it'll show me something.
So right now, the issues are WAN, SD Card Reader, and test a few things. (Module, watchcat, learn to use mwan3 and verify that it functions normally.)
Oh, and because mwan3 isn't ported to NFTables, there's a warning (dev said it's safe to ignore) that complains about iptables rules being used in conjunction with NFT. (Meaning we're running two firewalls.)
WAN now works correctly. I didn't know I had to add it to DTS. I added the following in the ports list and now wired WAN connects just fine.
port@4 {
status = "okay";
reg = <4>;
label = "wan";
};
Watchcat seems like it'll work fine, too, for those who want to use it. (Just restarts the router or interface if it goes down.)
I forgot to check the SD Card reader this go round, so I have to do that yet. I've installed the Argon theme to make it look nice.
So aside from testing the SD Card reader and getting it working, I also need to flash it directly to the router instead of in memory. Then I can test things more thoroughly, and learn mwan3.
Oh, and the cables I have don't work with the connectors on the cell modem, so I'll need to wait for the new ones to arrive. Then I can test the connectivity on that. I'll test them with the stock firmware first to make sure that the device functions normally, though.
You need to add pretty much all hardware to DTS for the drivers to find the hardware.
Note the due to GPL licensing, their OpenWrt sources should be open-source (except their private add-ons). They should provide you a compilable source code, if requested. (but GPL violations are common for small vendors 
)
Note that if you can get in to SSH console while running the OEM firmware, you could see the live DTS contents (without labels) in /proc/device-tree
root@router5:~# ls /proc/device-tree/
#address-cells cpus model soc
#size-cells firmware name soc_version_major
aliases flash_type opp-table soc_version_minor
boot_version interrupt-parent pmu thermal-zones
chosen keys psci timer
clocks leds reserved-memory tz_version
compatible machid rpm_version
cpu_type memory smp2p-wcss
root@router5:~# ls /proc/device-tree/reserved-memory/
#address-cells nss@40000000 tzapp@4a400000
#size-cells q6_etr_dump@50f00000 uboot@4a600000
m3_dump@51000000 ranges wcnss@4b000000
memory@4ac00000 sbl@4aa00000
name smem@4ab00000
root@router5:~# ls /proc/device-tree/reserved-memory/wcnss@4b000000/
name no-map phandle reg
root@router5:~# hexdump -C /proc/device-tree/reserved-memory/wcnss@4b000000/reg
00000000 00 00 00 00 4b 00 00 00 00 00 00 00 05 f0 00 00 |....K...........|
00000010
That would help you figuring out the SD card things, reserved memory areas etc. and you could verify if you have set things similarly.
2 Likes
Thank you. I'll give that a shot to see if things match up. Maybe I'll figure out the SD card slot issues that way and resolve any possible cell module issues that may come up.
@hynman Do you know what ^@ is a reference to in there? I tried looking it up on Google, but it won't search for symbols. I believe it's a reference to the model name, but where does it pull from? Do I just use ^@ in DTS, or do I need to expand it? (I'd prefer to expand it to help others know what it means more easily.)
EDIT:
^@ looks more like a delimiter. I found that `/proc/device-tree/compatible contains this text:
mofinetwork,mofi5500^@mediatek,mt7621-rfb-nor^@mediatek,mt7621-soc^@
In my DTS, I expanded my above "compatible" flag to become:
compatible = "mofinetwork,mofi5500-5gxelte", "mediatek,mt7621-rfb-nor", "mediatek,mt7621-soc";
I can't find the module anywhere on LuCI using the stock firmware, and I think that's because the eBay seller shipped me the EM7565 instead of an EM7455. The MoFi 5500 stock firmware doesn't work with the EM7565, so I ordered the correct one on Amazon. As I'm probably going to have to locate a driver for that card (hopefully already written) then I'll see if I can support the new guy, too. No idea what this will take, but maybe it's just LuCI which they made hide menus if a certain card type doesn't show so they have less tech support requests.
I'll still want to test that with a known good so I know that the hardware should work properly. It arrives on Tuesday.
EDIT:
I have some great news! I was able to extract the DTS file from MoFi's firmware. I'm trying to compile the custom firmware with that and then I'll test it out.
The bad news is that I just spent the last few hours going over the source code for custom components MoFi made for the router, and it looks like the functionality for the modules is almost entirely custom... I personally don't plan to use the modules and only bought them to test my work, but I;m not sure if I can make them work without a huge amount of work I won't be willing to do to build all the parts of the system.
If you're reading this and plan to use the custom firmware and want to keep the cell module functionality, then assuming I don't manage to already make that work when I finish building this firmware, then you'll want to follow the instructions below. It's illegal for me to just willy nilly copy their code and package it up in my release, but the DTS file is just a descriptor for the hardware, and has to be written the same way to get the router working with OpenWRT completely. I don't think it's illegal for me to use that.
Anyway, here's what I did so you can replicate it as needed.
- Download the latest MoFi firmware.
- Install binwalk. (Ex.
sudo apt-get install binwalk) - Install extract-dtb with
pip install extract-dtb, and install dtc withsudo apt-get install dtc. - Now, put the mofi firmware in a directory where you'd like to extract it. In a terminal, cd to that directory.
- Now run this command to extract the firmware.
binwalk -Me ./mofi-firmware.bin - You now should have a directory with lots of stuff in it. The important bits that I've found are
/squashfs-root/which contains all of the operating system files from the firmware, including MoFi's proprietary code. (I won't put any of that in my releases.) You also have a file named40in the root directory. (At least mine was named that.) The extractor couldn't name it, but using Bless Hex Editor, I examined it and it was compiled DTS code! Very useful. - Now we extract the DTS (Device Tree Source) from the compiled DTB (Device Tree Binary) file. Before we can do that, though, we need to use a tool to truncate the file enough for
dtcto recognize it. We extract the compiled dtb from that blob file by doingextract-dtb /my-file. ("my-file" is the file named40I mentioned earlier. If yours is under a different name, use the correct name.) - Now we can decompile the DTB file. To do that use
dtc -I dtb -O dts -o mofi.dts mofi.dtb. You should now have a "mofi.dts" file with a bunch of data on the router.
My newly compiled firmware is ready for testing. I'll do that tomorrow. I also found a firmware config file (for make menuconfig) located in /squashfs-root/proc/firmware.config which will help me to find out which generally-available packages they've added to their firmware. It'll make things easier to replicate!