hi everyone
Currently, I am using the mm6108-ekh03 eva kit, and I have found some options in the administration panel that allow users to customise or completely change the firmware of the kit. I have searched the user guide completely, but I didn’t find any guidelines about how to perform this action.
I have two questions:
Can you clarify what options you’re looking at here? A screenshot may help.
If you’re referring to the the ThinLMAC firmware option, then it’s designed only for APs with higher station counts (e.g. over 50), and we would not recommend using it on the EKH03. This is because it moves work from the MM6108 to the host processor, and the EKH03 processor doesn’t have much spare capacity.
There is no option for you to build/compile your own firmware, if that’s what you’re referring to.
I am a developer currently working with the MM6108-EKH03 and EKH01 Evaluation Kits. My goal is to customize and develop a new version of the OpenWrt firmware for the MM6108 chip.
For safe development, I need to utilize Network Boot (TFTP/NFS) to load and test the new kernel and root filesystem directly into RAM, which is crucial to prevent bricking the kit. This process requires access to the U-Boot/Serial Console (UART) right at the boot stage.
I noticed the following statement in the User Guide:
“For serial console access, connect a USB to serial adapter to one of the USB-A ports before booting the device (operates at 115,200 bps 8N1).”
However, I have some critical questions regarding the exact connection method, as I cannot clearly locate a traditional 4-pin UART header on the board.
Physical UART Access:
CNx or Jxx) on the PCB?USB Port Utilization (As per Guide):
What exactly is the recommended “USB to serial adapter”? Does this refer to a USB-to-RJ45 serial console cable (like those used for Cisco devices), or a standard USB-to-TTL adapter that connects to a USB-A port?
Does the USB-C or USB-A port on the EKH03 incorporate an onboard Serial-to-USB bridge? This would allow console access using only a standard USB data cable.
Network Boot Instructions:
setenv bootcmd 'tftp ...', saveenv).And besides all of my asked question what is your suggested way for developing and customizing OpenWrt firmware in your Evaluation kits?
My specific recommendations if you want to get started are:
No UART is required (and RPI4s don’t have uboot). You can also plug a display in via HDMI to see what happens in early boot if necessary. Hope that helps!
I really appreciate your quick and detailed response.
Yes, I meant the OS (OpenWrt) from the beginning, not the firmware on the radio chip.
If I want to perform my development on the EKH01, I don’t see any UART pins on the device’s outer body.
Do I need to open the enclosure to access them?
Will the UART pins be visible on the board itself, or does the EKH03 not include UART pins at all?
As I mentioned above, I don’t believe you need a UART for the EKH01, at least to get started. They’re an RPI4; they have HDMI out and you can reflash the SDcard if you break something.
If you desperately want a UART for early boot before the USB serial can be brought up, refer to RPI4 documentation. You will need to identify the UART pins you want to use on the GPIO header, and need to change both boot/config.txt and boot/cmdline.txt; our board is not currently configured to output via any of the RPI4s UARTs. I would strongly recommend not bothering with this unless you have a specific use case. We do not rely on wiring up these UARTs for our internal development.
With the EKH03, the pins are on the board as indicated, marked RX/TX/GND. They’re next to the LED. Just remove the cover by pressing on the two sides and pulling up.
But I think what would really help here is if you gave some indication of what kind of modifications you wanted to make to the EKH01/EKH03 OS images. Then we can advise on the simplest approach.
sorry in last message i meant EKH03
I need this kit for iot application, and for my Specific usage i need some light operating system Running on the kit, for example I don’t need this much tools and options in administration panel and I want to remove or replace some of them so i can hava a powerful kit with light os. This was an example of what i am planing to do.
It seems like the easiest option would be for you to take our existing OpenWrt build and remove all the ‘luci’ packages from the boards config (this is the HTTP admin interface) as well as the optional packages (e.g. camera support etc.).
Checkout GitHub - MorseMicro/openwrt , then:
Then run the morse_setup.sh script again to correctly populate your .config file, and check that it has no luci packages, then build your image using make -j8 or similar.
You can also use make menuconfig to adjust what appears on the OS image.
If you do this, there is a limited risk of a bad flash that won’t boot. However, if this does happen, you will need to us the UART pins on the board to get into uboot and flash from there (using tftp or similar).
I am very thankful for your practical and useful help.
I have another question:
In developing os for EKH03 or EKH01, which method do you use for trial and error? For example, I have made some configuration in os development. Will I need to flash the os in the board every time I want to see my development results? You told me in your last messages that you don’t use network booting. I wonder what method you use?
It depends what kind of change you make. If it’s a userspace change, you can usually just build that particular program, or if it doesn’t require compilation (like js/bash/ucode) we have a simple script to scp the file across to the development device.
If you have made changes to the kernel, I would just flash the device again. On the EKH01 it’s probably possible to use kexec, but I haven’t tried this; on the EKH03 it’s not setup to do this easily.
Hi,
I have another question about the OpenWrt source code from GitHub.
I’m planning to make some changes in the driver partition (the Morse driver). The source seems to be located at
feeds/morse/morse_driver/
after running the feeds update.
The issue is that these driver source files only appear in the build directory (inside build_dir/…) after the build process starts, because they are downloaded and unpacked from the feed.
So my question is:
How can I properly apply my own changes or patches to this driver in a clean and permanent way that survives make clean or make dirclean and is automatically applied during every build?
When you customize or modify a driver that comes from a feed on GitHub (like morse_driver), do you usually:
create patch files?
fork the feed repo?
use some custom patch directory?
or is there a better/recommended method in OpenWrt to handle this?
Thanks a lot for any advice!(my software is ekh03 )
Hi @m.aminezzatimofarah ,
Which approach you take will probably depend on how many modifications you intend to make.
OpenWrt describes how they expect users to work with patches here. This will create patch files for your changes inside the feed repository, which you can commit to your own fork. Then, you would fork the OpenWrt base tree itself for the purpose of modifying the feeds.conf.default file to point to your forked feed.
Alternatively you could fork all three of the morse_driver, morse-feed, and openwrt repositories - make your modifications in your morse_driver fork, point the Makefile in morse-feed to your morse_driver fork, and then point OpenWrt to your feed!
thank you very much from you help. it actually solved my problem.
can you tell me in morse_driver folder (basically in driver files) how drivers can handle txpower and channel? for example if i want to add my special power and channel controlling algorithm how can i do that? which function in which files should i use? and there is and special architecture for handling power and channel in drivers?
The maximum transmit power is set by the BCF. For various regulatory reasons we only let approved module vendors access the tooling to create/modify these files as they can be set incorrectly in such a way that regulatory limitations are exceeded - and therefore the radios could transmit illegally.
If all you need to do is adjust transmit power at levels below this maximum, on a Linux system that is typically handled by a netlink command. A call with iw can set it as
iw dev <devname> set txpower <auto|fixed|limit> [<tx power in mBm>]
Thank you very much. I know how to handle channel and power (of course, in regulated value) using iw and uci commands in a Linux system. But in the available and allowed range of configuration, I was planning to make and create a special program to handle channel and power in a specific algorithm that I want, which I am planning to use for educational purposes in evaluating the wifi halow functionality. So I would be very thankful if you could give me information about the channel and the power controlling flow in OpenWRT (the version which is published on Morsemicro’s GitHub page officially) that can help if i am allowed to add my program in OS, not user-space based configuration.