pppoe is not working on my 3800 after applying your PR, does it need extra configuration?
Thanks
While I can't speak for the wndr3800 in particular, there is nothing hardware specific about PPP(oE) (configuration identical as on ar71xx, just make sure to use the correct underlying ethernet/ switch interface) - and I did successfully test PPPoE on the tl-wdr4300.
curve ball from the side:
blogic's staging has now a new branch with a commit that bumps the old ar71xx into 4.14
https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=shortlog;h=refs/heads/staging
Seems that the ath79 transition will take too long, so ar71xx might be bumped to 4.14 in the meanwhile.
(the same branch also contains interesting stuff about bringing mac80211 and also ath10k firmware closer to mainline Linux)
Background to the actions is outlined in http://lists.infradead.org/pipermail/openwrt-adm/2018-August/000863.html
The reason is more likely to be "Further Roadmap", namely being able get rid of kernels <4.14 for the next release (ath79 should take over for quite a few boards by then, but the number of supported ar71xx devices is just too high for quick solutions to port them all in one go).
2 Likes
OK,I got it,thanks
I made a test build for 3700v2 and 3800. (but not yet for 3700 v1)
The build "ath79-kernel4.14-master-test" can be found in my WNDR3700 community build's download dir in dropbox.
- wifi works. (but phy0 and phy1 may get reversed)
- wifi does not work on the first boot after flash, but will work on later reboots
- MAC address handling is done at user-space, so the setting gets created at firstboot in /etc/config/network
Note that based on recent discussion in https://github.com/openwrt/openwrt/pull/1258#issuecomment-412066495 it sounds like WAN works only at 1000 Mbit/s and crashes at 100 Mbit/s.
Wow. Certainly didn't see that coming 
My network speed is 100M,that's why pppoe doesn't work 
@mkresin
What would be the correct way to organise the DTSI / DTS files for the WNDR3700/3800 family?
Currently ath79 has only 3800, but the other two can be easily defined. I have already built 3700v2, and 3700 should be easy, too.
The devices are otherwise identical, but they have different IDs and the flash+RAM memory sizes differ: 3700: 8+64, 3700v2: 16+64, 3800: 16+128
RAM size is not any more in DTS, so the only differences are the device names and flash structure. 3700v2 and 3800 even share the flash structure.
I don't think that partition structure can be partially re-utilised (and that might be confusing in any case), so partitions need to be defined separately for each device, right?
Does it sound ok, that
- there is wndr3700.dtsi, that is then referenced by wndr3700.dts, wndr3700v2.dts and wndr3800.dts
- the device DTS files only include the compatible and model definition, plus the &spi section for flash definition.
Sounds good
Thank's for your build, its work fine, but flow offloading is a little slower than fastpath.
PPPoE isnĀ“t that good utilized with fast path as with sfe... On non PPPoE connections itĀ“s almost the same performance.
But flow offloading isnĀ“t that hacky as sfe 
Sounds good to me. Distributing the partitions over multiple dts files makes it indeed hard to follow/read and for this reason is error prone on the long run.
We might not need to redefine the spi node for each dts file. Something like the following should be a good tradeoff between duplication and readability:
&spi {
status = "okay";
num-cs = <1>;
flash: flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <25000000>;
};
};
&flash {
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "u-boot";
reg = <0x000000 0x050000>;
read-only;
};
partition@1 {
label = "u-boot-env";
reg = <0x050000 0x020000>;
read-only;
};
partition@2 {
label = "firmware";
reg = <0x070000 0xf80000>;
};
art: partition@3 {
label = "art";
reg = <0xff0000 0x010000>;
read-only;
};
};
};
It would be also possible to define an empty partitions node and expend it later on. But not yet sure about the readability on the long run (in contrast to the spi node, it doesn't defines any [shared] parameters). I'll leave it up to you to decide what's the best here:
&spi {
status = "okay";
num-cs = <1>;
flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <25000000>;
partitions: partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
};
};
};
&partitions {
partition@0 {
label = "u-boot";
reg = <0x000000 0x050000>;
read-only;
};
partition@1 {
label = "u-boot-env";
reg = <0x050000 0x020000>;
read-only;
};
partition@2 {
label = "firmware";
reg = <0x070000 0xf80000>;
};
art: partition@3 {
label = "art";
reg = <0xff0000 0x010000>;
read-only;
};
};
I made a PR for supporting WNDR3700 and 3700v2.
https://github.com/openwrt/openwrt/pull/1270
No wifi things, yet. Just the basic support for the devices.
As 3700, 3700v2 and 3800 will share most the DTS, adding things later will be easy.
EDIT:
PR updated according to the advice/feedback received
1 Like
They are reversed because you initially copied my dts settings for DIR-825.
But on this device wlan0 is 2.4 and wlan1 is 5. So the devfn should be reversed I guess.
@lucize So the tplink tl-1043nd-v1 is fixed.
u-boot was unrelated. It just set the regs correctly.
You can build from
2 Likes
I removed branches now. Both DIR-825b1 and tp-link 1043nd v1 are workable from trunk now.
1 Like
I tested your build on a 3800, in a ppp "gigabit" environnement : speedtest.net gives me up to 720Mbps in download (vs 330Mbps with 18.06) with software offloading enable (400Mbps without).
I'll try in a dhcp environnement in the next days.
My changes introducing the WNDR3700 and v2 have been merged, so I have rebased the addition of wifi support.
https://github.com/openwrt/openwrt/pull/1284
I have also updated my test builds with wifi for WNDR3700, WNDR3700v2 and WNDR3800. Downloadable from my community build:
"ath79-kernel4.14-master-wifi-test-20180813"
1 Like
Thanks @hnyman. I just built master and will be testing the WNDR3700. I also saw TL-WR1043ND v2 support, but I'm a bit wary yet (no hero with TP-Link's recovery).