Support for Xiaomi Wifi R3P Pro?

@pellmen: no i haven't seen it... actually routers aren't my "thing"... but i just got impatient and jumped in :wink:

FWIW, I'm currently writing you over a 2.4G connection on my R3P using @nossiac's binary modules (for kernel .93 ... i know i know... not supposed to mix kernel versions.. i'll get around to that later). I'm not sure what a "comprehensive" test would be (apart from putting it up as my "production" router, and bring down the wrath of everyone at the school....) but it seems to be working pretty well if I can run a DSL speed test, do http/ssh connections and all...

No luck (so far) with 5G yet (but then... I've only being playing with this for the past 20 minutes).

In short: @nossiac's mt7615 binary modules appear to work with my R3P port (at least for 2.4G). I hope this will encourage potential testers...

(BTW: Yeay!!!)

2 Likes

Can you post the release of firmware with working wifi? Or just place the instructions how to make it work on beta 2 release? In this way I can attrack more people for testing. Until there is no wifi, nobody wants to install it((

@ilyas - can you try to roll back openwrt git to 3fe555c as it was last commit with 4.14.93 kernel supported by nossiac's binary module and rebuild image ?

I thought @nossiac supports more kernels((

As can you see there is different configurations of cpu+wifi chips and latest version of R3P configuration (7621+7615) is 4.14.93. OpenWrt git kernel is 4.14.100+

2 Likes

You got 2.4ghz working, is it stable so far...?

I hope you can get your head around the 5ghz..

Do you need my help testing or are you okay at the moment?

@souk: it's funny you asked if 2.4ghz is "stable" :wink: it just died when i was about to respond to your post. @followme_8: if i didn't botch anything in git, kernel 4.14.93 + my changes is compiling at the moment and will be up for public consumption soon...

5ghz seems strange (can connect, but it's not part of the "bridge" (br-lan) and I can't get it to add...)... as well as the whole interface issue... (there seems to be two 2.4ghz and two 5ghz configurations... maybe that too is operator error. will continue to play around). if anyone has experience configuring this stuff i'd appreciate any pointers.

as for "could you use help testing".. hell yeah! you can never get enough testing (plus, i'm likely to only test very basic functionality...)

Take a look at nossaic's git -> issues , we have dual 7615 , which means we need two configuration .dat files and two eeprom .bin files, one for each band
Here is the link

First of all, there's a new "release" out based on kernel 4.14.93 (same place as before). That's the last kernel @nossiac's modules are compiled for, so this should be more reliable. Go get it and share it with all your friends. I also created a new git "branch" in case someone wants to build it himself.

@nossiac's kernel modules (and associated stuff) are bundled. 2.4ghz is still OK but still the same problems with 5ghz (which I honestly haven't done much to track down).

@followme_8: yeah, I had read that post and I have the [1-2].dat and .eeprom files where @nossiac says they should be. Still no luck. It looks like it's trying to configure rai0 (the 2nd interface) as 2.4ghz as well.... rather bizarre.

But obviously your mileage may vary (and i'm by no means an expert in network and especially wireless configuration), so please don't be shy and try it out.

PS: @pellmen: what I did to "configure" (if it can be called that) is to grab eeprom.*.bin from the "Factory" partition:

dd if=/dev/mtd3 of=/lib/firmware/eeprom.1.bin bs=1k count=1
dd if=/dev/mtd3 of=/lib/firmware/eeprom.2.bin bs=1k count=1 skip=32
(you can then run 'hexdump' on them to make sure the first 4 bytes are '7615')

The bizarre thing is that stock xiaomi also eeprom files (3 of them to be exact) in /lib/wifi/*eeprom.bin but they aren't the same as the files in the "Factory" partition...

@nossiac already has some *.dat files in /etc/wireless/mt7615, which I just kept. (stock also has *.dat files in /etc/wireless/mt7615e[2|5|/*.dat but I didn't really investigate their differences) I also copied /lib/wifi/singlesku/SingleSKU.dat from stock to /etc/wireless/mt7615/mt7615-sku.dat but I'm not sure it made much of a difference.

[edit: obviously I was doing something wrong because it wasn't working.... please don't do what I've tried here. See the instructions on my github page.]

Maybe we'll try to take out of Pandora firmware eeprom.bin and *.dat files and just put it to the right dir's for openwrt? Maybe 5GHz will boot with Pandora's files.

@pellmen: possibly. who knows. i'm reading through @nossiac's bug report you referenced earlier... looks like at some point (a year ago) you had a openwrt working on the R3P... I wonder why you stopped?

another (possibly) important point: stock xiaomi has wl0 as 5ghz and wl1 as 2.4ghz... maybe that's the correct configuration. god knows.

@dissent1 was not interested in r3p, he made the firmwares for r3g. Me and another man asked him to help us with r3p and build firmware with @nossiac driver. We've discovered some problems, as you can see in @nossiac issues, and after trying the last instructions of @nossiac we gave up, because I don't understand a lot in openwrt and @dissent1 wasn't interested in supporting of firmware for r3p. We stopped only because of driver. I'm not too clever in this point to understand, why driver is going wrong. I want to go second degree to learn programming)) I already have a degree, but in developing wheeled and tracked vehicles))

Alright all:

I have 2.4ghz and 5ghz both working. Turns out there were some hidden gems there on @nossiac's bug list...

What I'm doing differently:

  1. I'm using the stock eeprom files as follows:
    (stock) /lib/wifi/mt7615e5.eeprom.bin -> (openwrt) /lib/firmware/mt7615.2.eeprom.bin
    (stock) /lib/wifi/mt7615e2.eeprom.bin -> (openwrt) /lib/firmware/mt7615.1.eeprom.bin
  2. I'm getting rid of most of /etc/wireless/mt7615 (i only keep mt7615.1.2G.dat and mt7615.1.5G.dat)
  3. (and possibly most importantly): edit (both) *.dat files (above) to change the line that reads
    E2pAccessMode=1
    and make it:
    E2pAccessMode=2

I've messed with a bunch of settings, so hopefully that's all that really matters. I now have a rather weak 5G signal (but at least it's there and I can connect to it), and the 2.4ghz seems quite nice (at least the bssid isn't garbage).

Test and let me know. And good luck.

BTW, there is an open bug on @nossiac's page regarding random kernel reboots when using these exact settings (which is how i discovered the settings actually)... your mileage may vary.

PS: I'm not sure if it was really necessary to use the stock firmware's eeprom files rather than the stuff on the Factory partition... but it's too late to test it out now. Maybe someone can try it and let me know.

@followme_8 i think you're mistaken... I think it's a single chip with DBDC mode (like k2p)... see: https://github.com/Nossiac/mtk-openwrt-feeds/issues/11

No, we realy have two chips. Here's photos of board and chips: https://drive.google.com/folderview?id=1X6HYCxcwsqPcxyYOym-ybGWmGmbNdYgv

@pellmen: haha... i stand corrected. i was too lazy to pull open the cover of the router last night... in that case, the configuration of wifi remains a mystery....

@ilyas, as I know there is one more device, that have mt7615 - bpi-r2 and there is a good support for it. @frank-w porting driver to 4.14 and 4.19 kernel: https://github.com/frank-w/BPI-R2-4.14
https://github.com/frank-w/BPI-R2-4.14/blob/4.14-main/README.md

And there is a try to create a new driver, as I think: https://github.com/frank-w/wireless-drivers-next/commits/mt7615-devel_new
http://forum.banana-pi.org/t/bpi-r64-kernel-development/7819

Here is one more repo with mt7615 patch:

Maybe that will be a little help


1 Like

@ilyas - try to swap .dat files between physical devices, the fact that we have two chip doesn't mean they are equal (e.g. external amplifiers )

@pellmen: thank you for all the suggestions and links... I honestly didn't know there was so much code already out there. The patch you linked to seems to be for kernel 3.10.14 which is pretty prehistoric.

The good news is that @nossiac's drivers work well :wink: