Porting guide ar71xx to ath79?


#1

Hey there,

as the topic says, does anybody work currently on an 4.14 config and patches for ar71xx platform?

I want to switch from shortcut-fe (fast-classifier) to the new ipt-offload kernel (4.14) modules and i dont know what the steps are for creating a good config for my ar71xx routers.
Also i see there are a lot of patches for 4.4 and 4.9 versions...

I'm not a big openwrt dev, but i know something about building linux kernel and rootfs for embedded machines and also about build a custom openwrt image from source...

Is there a guide how to create config and patches for a new kernel version?

I have two tp link wdr3600 with pepe2k's bootloader, so i'm ready for testing dev builds with 4.14 kernel.


Upgrading Firmware Too Big and 18.06 using 4/32 Devices
Build for WNDR3700v1/v2 / WNDR3800
Flashed tp-link 1043nd v1 with trunk (ath79) and can't connect
Mikrotik 450G NAND changed
Help required to fix bug: porting from legacy to generic build form (WNR2000v3, 4/32 device)
Build for WNDR3700v1/v2 / WNDR3800
Ath79 target status
Ath79 target status
#2

ar71xx may soon be abandonware if I read the tea leaves right

http://lists.infradead.org/pipermail/lede-dev/2018-February/011312.html

I would like to see ar71xx and ramips stay on v4.9, regardless of there being patches for v4.14. I would also like to see ar71xx never being bumped to v4.14

So, the core devs are thinking that the old ar71xx is rotting away. (Yes, it is quite a mess)

Likely the newer ar71xx devices should be converted to ath79 target and to have DTS definitions instead of C-language mach files providing the low-level hardware settings.


#3

Just to clarify this, that doesn't mean hardware support would be dropped for ar71xx devices - all of those can be covered by the upcoming ath79 targets. The difference between ar71xx and ath79 is the pending switch to devcie tree instead of mach files, which moves ath79 device closer to mainline (mach files are not accepted there) and at the same time helps with flash and RAM requirements (all mach, for all devices, files are built into the kernel, with device tree, only the single FDT matching your device gets appended to the kernel).

Switching such a large target as ar71xx over to device tree is a huge endeavour, both in terms of porting the basic driver support and even more when it comes to adapting each and every of the myriad of ar71xx devices, this needs a bit of a cut.


#4

Why keep Ramips on 4.9? It already has 4.14 support that is working well. It only requires switching to the 4.14 kernel by updating the makefile.


#5

Please don't quote that to me.
That was just a quote from the mailing list, like I provided the link.


#6

I know it wasn't you, sorry if my message implied that way. Was just thinking out loud :slight_smile:


#7

Thank you all for your helpful replies.

I forgot about the problem with mach files...

I think no one will create dts files and compatible drivers for my wdr3600 and i can live with 4.9 kernel too.


#8

Where would a perhaps naive but enthusiastic individual find out what is involved in contributing to this, especially for an aging, but reasonably popular target like the Archer C7?


#9

googling?
ar71xx dts

reveals some interesting links...

But it will be low-level hardware stuff. Figuring out how to connect the drivers in the current kernel to the hardware via correct definitions in th DTS files.


#10

Hmm... :slight_smile:

WDR3600 is DB120 and there exists a predefined machine within ath79_defconfig on 4.14 kernel...

It could be possible to create a dts with the one from reference board...

Edit: There is no dts for db120 and also no dtsi for ar9344.


#11

Looks like blogic has just refreshed his ath79 staging branch based on kernel 4.14:
https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=shortlog;h=refs/heads/ath79

It seems to e.g. have DTS file WNDR3800 that I have. (but e.g. the network config is still missing for that router, so the branch is largely just a skeleton at the moment.)


#13

Please refrain from such deragatory analogies. If you disagree with the direction of the development, feel free to discuss on the mailing lists and provide compelling arguments (and more importantly invest actual effort) on why developers should voluntarely start working on upgrading to 4.14 while losing support for a large number of devices.


#14

With total respect towards the developers, my suggestion is flow offload, which would be available for these older and much weaker SoCs with kernel 4.14, and they would profit a lot from it. If this is possible by backporting instead of upgrading the kernel, that would be fine as well, but a lot of devices would benefit from that feature.


#15

That would be beautiful if this great feature would be backported...


#16

I am totally agree with you


#17

Yes, this would be great if backported. If the challenge is access to hardware, happy to supply a C7v2 or v4 to a dev (US based) willing to get this going.


#18

As the first kernel selected for Super Long Term Support (SLTS), the Civil Infrastructure Platform will provide [kernel 4.4] support until at least 2026, possibly until 2036.

https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance


#19

I have a big ol' stack of ar71xx devices I'd like to see rolled to the ath79 side. I'm willing to put in the effort. Is there a guide or some examples of other devices that have been successfully switched?


#20

see https://github.com/p-wassi/lede-source/commits/ath79_devicetree
and
https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=shortlog;h=refs/heads/ath79


#21

That looks like a fantastic starting point. Thanks!