You mean it compiles…i guess your current code does not work because the function sets options needed for initialization
Right way is to fix different declaration between h and c file
Select code while editing and press <> button
How openwrt kernel knows where the rootfs is? I cant change uboot bootargs env, i specify kernel command line in kernel_menuconfig, overraiding uboot commandline. My commandline is
earlyprintk console=ttyS2,115200n8 block2mtd.block2mtd=/dev/mmcblk1,65536,SD,5 mtdparts=SD:512k(mbr)ro,512k(uboot)ro,512k(config)ro,512k(factory)ro,128M(firmware) rootfstype=squashfs,jffs2
Also, i leave checked in kernel_menuconfig openwrt-specified mtd parsers. And they normally works, parse ‘firmware’ to ‘kernel’, ‘rootfs’ and ‘rootfs_data’ mtd partitions. But kernel still not mount rootfs, without any errors or attempts. I lurk about openwrt kernel boot process, about openwrt mtd parsers, and about generic kernel boot process, and not understand what im doing wrong. Where in kernel_menuconfig option for make console output more messages for debugging?
Hello, I’m trying not to spend ages figuring out how to make OpenWrt trunk work fine with bpi-r2. There are people that managed to make it work (https://www.openmptcprouter.com/). This project works with with an ext4 rootfs and there are working images with 5.4 kernel too (https://www.openmptcprouter.com/release/develop/5.4/bpi-r2/targets/mediatek/mt7623/). You just need to play a little with the config as it is a project to use bpi-r2 to merge 2 or more upstream internet connection (ex. fibre optic and LTE): you need to revert the LAN port to act as WAN and the WAN Switch to act as LAN as in a normal router. The problem is the mt7615e driver included in <5.4 linux kernel that is still not working as expected. The TX Power is stuck to 6dBm and there is no way to increase it.(https://patchwork.kernel.org/patch/11358235/).
But i need manually selected packages. Like an ISCSI targe, or torrent client, or i2p daemon, etc. Theats why i spend time to build my own firmware. Befor bpi-r2 i use miwifi3g router and make openwrt firmwares without any trubles.
Reading comments and patch code it looks like that txpower reporting is broken in a first place (mphy->txpower_cur is no longer updated when txpower is set in mt7615_mcu_set_txpower_sku() leaving value in mphy->txpower_cur stale and non-representative of the real txpower level.
I know that most probably you hadn’t but have to ask just in case: have you had a chance to check real transmit power using some kind of a professional WiFi analyzer gear? Without measuring of a real mwatts emitted from the antennas it is impossible to tell if the problem is in broken power reporting or broken txpower setup.
have you tried applying the Patch you’ve linked?
Hello Alexey, I have no such material.at home, I use regular devices to test the signal. I bought some good Antenna (8dBi), I have auxiliary power. The wifi signal drops dead 4-5 meters away from the router. I have associated the poor signal to the transmission power but maybe I’m wrong; as you say, there are other factors: but I’m not expert enough to diagnose.
1 Like
I have tried the patch on your 4.19 and 5.4 kernel versions. But it report for a conflict (while applying the patch) and I’m not expert enough to look into the code and find a solution. If you think you can do something I will try to reproduce the error and post some logs here in the forum
No need to worry about not being and expert - most of us here are not 
.
You wrote that signal drops dead in like 4-5 meters away from the router. May I ask you to elaborate a bit on the test setup you have?
I guess you had been using R2 running some OpenWRT-derived OS build as a userspace, mt7651e as a WiFi Access Point and your custom-built kernel as - you guessed it - kernel 
. Then you’ve been using some other device as a WiFi client connecting to the R2 AP. Am I right?
If so - it would be interesting to get more details on:
- What was the client device and what software was it using?
- What configuration settings were used on R2 AP side, i.e. WiFi standard, band, channel, channel width, e.t.c.
- Were there any kernel/wifi driver combinations you had tested which were not experiencing wifi signal drops to nothing at 4-5 meters distance?
- What about trying to test with another client device - in my experience there were situations when my Android-based phone was working perfectly while iPad was loosing signal all the time, with the fix found by trial and error being moving to another channel and disabling HT-40.
I understand you have a lot of question, there are a lot of variables in my reported problem. Let’s start with the HW: I have bpi-r2 and mt7615 (PCIe) from sinovip (recent purchases). + 4 8dBi antennaes Client Devices are Xiaomi Android low cost, iPhone 7 and Samsung Tablet
I managed to have mt7615 driver loaded and operational in the following OS config:
-
Debian + 5.4.22 from frank-w (https://github.com/frank-w/BPI-R2-4.14/releases/tag/CI-BUILD-20200225_203315-c075525e6)
-
Openwrt 19.07.2 stock bin + kmod.mt7615e. Just a few tests as it is a non persistent OS and it is very painful
-
OpenMPTCPRouter.com 0.55 beta 2 with 5.4.22 kernel + kmod mt7615e
For all tests I have used mt7615 in AP mode with Hostapd
The tests with config 1 (Debian) I have no track of the parameter matrix, but I have tested all combinations of N and AC mode at different frequencies. All working fine but with a very poor range.
The tests with config 3 (openmptcp router) are still on-going. if you have some suggestion on how to test and which config, I’m available to contribute (I’m using netgear wi-fi analyzer to measure the signal levels)… The tx power is stuck to 6dBm but all modes (N and AC) are working at all allowed frequencies: range is still poor (radius of 4-5 meters before disconnection).
@adiz, thanks for detailed info on this, looks good and reasonable.
Just to make sure: from where does this number come from? Netgear wi-fi analyzer running on XIaomi device? Or from OpenMPTCP/OpenWRT web gui or command line?
What is strange is the fact that range is the same level bad on all allowed frequencies. My expectations would be that 2.4GHz band should provide a better coverage when transmitting at some defined power level compared to 5GHz.
Nevertheless you confirm that the range/coverage is poor for you which means that there are issues with driver 
. Unfortunately I’m not able to help you with this by doing my own tests as I don’t have bpi-mt7615e board and chances are low that I will get one soon - at the moment they only do offer EMS shipment to my country which costs the same as a wifi module itself and I’m refusing to pay that much for shipment at the same time I get stuff from other AliExpress sellers shipped at a fraction of EMS cost.
As a general suggestion on debugging this one I’d say that you’d need to find at least one software combination that works fine and provides you with a good wifi coverage. My approach would be to use some well established userland like debian 10 or 11 and couple it with self-built kernels based on @frank-w kernel repo. Giving https://backports.wiki.kernel.org/index.php/Releases a try is also a good idea. Main goal here would be to find a working baseline and then it would be possible to use git bisect or similar technique to determine the change where txpower gone wrong.
Hello Alexei,
I’ve spent quite a lot of time to follow SINOVIP engineers fix (following a request for support I sent to them, related to the txpower issue). It was a dead end, the new patch they sent me was not really compatible with the OpenWrt driver. As you say it is hard to establish the right branches for this driver. It is worth to note that the binary mod generated by any combination of software versions is very large. I think that the open source driver is very far to be mature.
In fact you are right, I have no mean to know at which power the card is operating. My assumption is based on the capability info I retrive from iw phy command. For the mt7615, it is listing all allowed frequencies and for each of them the operating power is 6dBm. Also my empyrical device test shows very poor range, so I have linked the 2 things (but maybe there are other things that are not good in the firmware, the driver, the system power supply or in the card itself)
I will do as you suggest, go back to a more reliable OS with Franck repositories for kernel compilation.
Andrea
1 Like
For mtd issue i guess we need CONFIG_MTD_ROOTFS_ROOT_DEV to get it working. And partition needs to be named rootfs (case sensitive). For ubi i found a patch
I also encountered the same problem. I tried to add a factory partition and write the calibration data on other devices to the factory partition. I specified to read the factory data in the DTS file. The txpower I saw was normal, and the Mac was not invalid. Therefore, I think that the failure to read EEPROM or eFuse caused mt7615 The PCI card didn’t work properly. I tested kernel4.14 and 5.4.
Have you solved this problem?
Are you sure driver is loaded correctly? Do you have the other firmware files loaded? Please provide bootlog.
My log is the same as the basic information provided above:
===================
[ 51.140713] mt7615e 0000:01:00.0: enabling device (0140 -> 0142)
[ 51.148163] mt7615e 0000:01:00.0: Invalid MAC address, using random address 6a:a9:c0:69:04:f0
[ 51.252805] mt7615e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20180518100604a
[ 51.480407] mt7615e 0000:01:00.0: N9 Firmware Version: 2.0, Build Time: 20200131181812
[ 51.517454] mt7615e 0000:01:00.0: CR4 Firmware Version: reserved, Build Time: 20190121161307
================================
Yes, I’m sure. When I add the following code “MTD EEPROM = < & factory 0x0000 >” in DTS and import other device factory data, it works normally.
I tried to remove “MediaTek, and MTD EEPROM = < & factory 0x0000 >” still failed to read the calibration data
How do I specify to read parity data on u7615n?
Eeprom is not same as calibrationdata. Imho calibrationdata is only read in openwrt kernel from rf-partition (if using mtd).