OpenWrt Forum Archive

Topic: Update on Linksys WRT1900AC support

The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

cybrnook2002 wrote:
davidc502 wrote:
cybrnook2002 wrote:

@davidc502, how are you looking now at day 3?

Since it ran good after 2 days on 40mhz, I bumped it up to 80mhz... will let you know in a few days.

Thank you much sir! This is the same build you are hosting on your share (Thanks btw on that), in case I, or anyone else, wanted to try the new .17 driver?

EDIT: Also, are you pre-loading the BM patch in your build, or should we do this after the fact? :-)

Buffer Management Patches are put into the 4.4 directory and compiled with the image.

Thank you davidc502!

Just flashed your build (wrt1200ac), so far so good:
2.4 on channel 4 (currently at 108mbps link)
5.0 on channel 149 (Currently at 866.7 mbps link)
both using forced AES

I will let you know in a couple days (if I make it that far) what my speeds are like. So far, I am seeing no issues out of the box with a vanilla setup.


EDIT: I will say I am having the same issue I had on DD-WRT (Kong's with latest driver), that my printer is only printing half the page I send it, then just stops. Flashing back to factory firmware fixes this.

(Last edited by cybrnook2002 on 13 Apr 2016, 00:41)

I can report 80mhz setting 5Ghz has already dropped to 20mbps.

@Nihilanth

Any news? Kernel 4.4.7 went public yesterday, gonna fire a new build later on today.

nitroshift

davidc502 wrote:

I can report 80mhz setting 5Ghz has already dropped to 20mbps.

that was my observation as well David, on the latest build i had 5ghz set to 80mhz and it dropped to 20mbps instantly.
changing it to 40mhz brought the speed upto normal values.
my 2.4ghz has been performing great btw... i had the 20mbps issue with the older builds and with ddwrt only on 2.4ghz in the past. Its been abt 4 days and my 2.4 is running well and my 5ghz (set to 40mhz).

oddly though in the past i never had any issues with 5ghz.

(Last edited by jawad_hai on 13 Apr 2016, 08:03)

nitroshift wrote:

@Nihilanth

Any news? Kernel 4.4.7 went public yesterday, gonna fire a new build later on today.

nitroshift

Hey buddy. Got an uptime of 13 days and it seems that wifi speeds have been constant throughout - no noticeable speeds drops that I could observe.

Looking forward to you next build.

Nihilanth wrote:
nitroshift wrote:

@Nihilanth

Any news? Kernel 4.4.7 went public yesterday, gonna fire a new build later on today.

nitroshift

Hey buddy. Got an uptime of 13 days and it seems that wifi speeds have been constant throughout - no noticeable speeds drops that I could observe.

Looking forward to you next build.


Same here nitroshift.  I have been running the one you posted back here for 16 days uptime and no noticeable decline.

@anomeome @InkblotAdmirer

Did you guys found out how to generate the ko for marvell_cesa ? I tried to toggle the m flag on both mv_cesa and marvell_cesa but i keep failing to build the ko into the ipk (or i'm missing something)

openwrt@SRV001:~/devel/work2$ find ./staging_dir ./bin ./target -name "*cesa*"
./staging_dir/target-arm_cortex-a9+vfpv3_musl-1.1.14_eabi/pkginfo/kmod-crypto-marvell-cesa.provides
./staging_dir/target-arm_cortex-a9+vfpv3_musl-1.1.14_eabi/pkginfo/kmod-crypto-mv-cesa.provides
./staging_dir/target-arm_cortex-a9+vfpv3_musl-1.1.14_eabi/root-mvebu/stamp/.kmod-crypto-mv-cesa_installed
./staging_dir/target-arm_cortex-a9+vfpv3_musl-1.1.14_eabi/root-mvebu/stamp/.kmod-crypto-marvell-cesa_installed
./staging_dir/target-arm_cortex-a9+vfpv3_musl-1.1.14_eabi/root-mvebu/etc/modules.d/09-crypto-marvell-cesa
./staging_dir/target-arm_cortex-a9+vfpv3_musl-1.1.14_eabi/root-mvebu/etc/modules.d/09-crypto-mv-cesa
./staging_dir/target-arm_cortex-a9+vfpv3_musl-1.1.14_eabi/root-mvebu/lib/modules/4.4.6/mv_cesa.ko
./bin/mvebu/packages/kernel/kmod-crypto-mv-cesa_4.4.6-1_mvebu.ipk
./bin/mvebu/packages/kernel/kmod-crypto-marvell-cesa_4.4.6-1_mvebu.ipk
./target/linux/generic/files/crypto/ocf/kirkwood/cesa
./target/linux/generic/files/crypto/ocf/kirkwood/cesa_ocf_drv.c
./target/linux/generic/patches-3.18/252-mv_cesa_depends.patch
./target/linux/generic/patches-4.4/252-mv_cesa_depends.patch
./target/linux/generic/patches-4.1/252-mv_cesa_depends.patch

@nitroshift

How did you compile with kernel 4.4.7? I ask because a make clean still compiled with 4.4.6. Did you need a make distclean or changed something else?

@xhemp

Since the change to 4.4.7 hasn't been pushed upstream yet, I manually edited /include/kernel-version.mk

nitroshift

nitroshift wrote:

@xhemp

Since the change to 4.4.7 hasn't been pushed upstream yet, I manually edited /include/kernel-version.mk

nitroshift

Cool, thanks for that!

@mrfrezee

If you just update crypto.mk to include the new marvell-cesa driver and select it, it is in the kernel as a built-in.  I added CONFIG_CRYPTO_MARVELL_CESA=m in the mvebu config-4.4 file, and this then builds it as a loadable module and you get the ko.  For good measure you likely want to make sure that the line for the MV_CESA module "is not set".

I have gotten "acceleration" on both md5 and sha1... but I'm not convinced it's actually working.  marvell-cesa should be shown as the module in /proc/crypto (I believe) and I'm not seeing that.

The module can be built and auto-loaded, but I haven't figured out how to actually put it to use.  I'm not sure if module load order is important or if there are other dependencies missing (or incorrectly included such that they're overriding desired behavior).

Also, there may be a bug in the Makefile for cryptodev.  There is an "autoload" line that fires it up at "50" and an install line that includes an autoload at "80".  They both end up loading the same module so only the 50 will take effect.  Not sure which one is the one we want.

@nitroshift

Went back to basics: new clone @ 4.4.7 + nand patch

Fails to build at the 150-crypto-ccp-add-hash-state-import-and-export-support.patch

Did you have similar issues?  Will delete that patch and try without it....

Also, has anyone tried building with kernel 4.5.1 or even 4.6-rcx?

Cheers

@doITright

The builder tells you which hunks failed. Rework the named patch to omit those hunks and rebuild.

nitroshift

nitroshift wrote:

@doITright

The builder tells you which hunks failed. Rework the named patch to omit those hunks and rebuild.

nitroshift

Will do a deep dive into that patch once the current build (without it) completes.

Cheers

***EDIT: Removing the two chunks that were failing did the trick.

Linksys WRT1900AC
Firmware Version OpenWrt Designated Driver r49162 / LuCI Master (git-16.100.63971-9c77aea) 
Kernel Version 4.4.7
Local Time Wed Apr 13 14:10:46 2016
Uptime 0h 5m 52s

(Last edited by doITright on 13 Apr 2016, 19:11)

davidc502 wrote:

**NEW Build** David's Snapshot Builds W/LuCi - http://personalpages.tds.net/~davidc502 … 4.4.6.html.

I try it on a wrt 1900 acV2:

Setting the local network 192.168.0.1 => I cannot reconnect to the GUI with my PC (LAN card set in static or DHCP on the same adress base....) Oupsss
A reset will reset the network  => 192.168.1.1 and i can reconnect with the machine on the 192.168.1.x base...

Disco

(Last edited by disco67 on 13 Apr 2016, 17:14)

doITright wrote:

***EDIT: Removing the two chunks that were failing did the trick.

Yeah, the piece of code this patch was modifying at HUNK #2 got included in 4.4.7, so you don't need it anymore smile
Gonna fire up a full build with .7 sometime soon to have some packages.

mrfrezee wrote:
doITright wrote:

***EDIT: Removing the two chunks that were failing did the trick.

Yeah, the piece of code this patch was modifying at HUNK #2 got included in 4.4.7, so you don't need it anymore smile
Gonna fire up a full build with .7 sometime soon to have some packages.

So far so good but have not really done much to test it yet.... 

I only included the NAND patch and as such:

positive observation -> from the client side TX is much better
negative observation -> from the client side RX is slightly worse

Will run some proper iperfs later....

Cheers

@InkblotAdmirer, @mrfrezee
In doing a new build for 4.4.7 I took another look at the CESA device and here is where I am at. A little bit closer, but still not quite.

On page 174 of the first PDF on this page are listed what the CESA device supports. I ran make kernel_menuconfig and in Cryptographic API selected everything that the device supports as documented in the PDF, as well as the Hardware crypto devices near the bottom. I had to build in the foreground as there are some "NEW" defines, and "oldconfig" did not get the job done. Builds and packages the .ko file, and the module is in the /proc/crypto file.

I think there also needs to be an equivalent patch for this device as provided by:
target/linux/generic/patches-4.4/252-mv_cesa_depends.patch

Edit:
As noted CONFIG_CRYPTO_MARVELL_CESA has to be "=m" not "y" for the .ko to be generated.

Edit2:
My Kconfig does not have select CRYPTO_HASH2 in the MARVELL_CESA section.

(Last edited by anomeome on 14 Apr 2016, 03:16)

@anomeome

Guess what, I did an exact build to update a WRT1900ACV1 -- and the marvell-cesa module is loaded.  Exact build, and it is NOT loaded into /proc/crypto on the ACS.

Now to figure out why... all my debugging has been on the ACS and here it was likely configured correctly the whole time (at least for the V1).

And I don't think the patch you mentioned needs to be updated, that information is already in the Kconfig for the MARVELL_CESA driver.

anomeome wrote:

I had to build in the foreground as there are some "NEW" defines, and "oldconfig" did not get the job done. Builds and packages the .ko file, and the module is in the /proc/crypto file.

make kernel_menuconfig have this behavior. It crushes some defines who where put there by OpenWRT dev. When i'm doing a kernel_menuconfig, i'm just doing a diff between 4.4-config and the new generated one and pick the things i think i need. Always (well, kindof) working for me so far and i can create an unattended 4.4-config.

anomeome wrote:

Edit:
As noted CONFIG_CRYPTO_MARVELL_CESA has to be "=m" not "y" for the .ko to be generated.

I think that was my mistake on my first tries (public build r49161).

Re: crypto on WRT1900ACS.  I'm closer to understanding why it won't load.  Info in log:

marvell-cesa: probe of f1090000.crypto failed with error -22

I think this is code EINVAL, which is only in a few places in the driver.  I think this is the likely code:

    if (!res || resource_size(res) < cesa->sram_size)
        return -EINVAL;

It's trying to allocate SRAM in a call from the initialization routine.  This works on the WRT1900ACV1, not on the ACS.

Here's a thread showing some debug was required on a similar platform:

http://lists.infradead.org/pipermail/li … 05560.html

Not encouraging for the short term, but it looks to me like the dtb for this platform might have a bug?  I'll keep digging but I have an identical config for both platforms -- one works, the other doesn't.

EDIT:  found the problem.  Here is an excerpt from the mamba dts (missing from all cobra/caiman/shelby dts):

            crypto@90000 {
                compatible = "marvell,armada-375-crypto";
                reg = <0x90000 0x10000>;
                reg-names = "regs";
                interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
                         <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
                clocks = <&gateclk 30>, <&gateclk 31>,
                     <&gateclk 28>, <&gateclk 29>;
                clock-names = "cesa0", "cesa1",
                          "cesaz0", "cesaz1";
                marvell,crypto-srams = <&crypto_sram0>,
                               <&crypto_sram1>;
                marvell,crypto-sram-size = <0x800>;
            };

There's the missing property.  Hopefully I can track down the right information to populate from somewhere, and it looks like there may be some other missing stuff.  Fun fun!

(Last edited by InkblotAdmirer on 15 Apr 2016, 19:08)

@David
4 days uptime using your 4.4.6 r49114 and ive hit a 24mbps barrier on 2.4 Working fine on 5Gz.
the only errors in the kernel logs are:
[41582.870254] ieee80211 phy0: check ba result error 1
[41582.875243] ieee80211 phy0: ampdu start error code: -22

if i reboot the speeds will return to normal. it worked fine till today giving me full speed on both 2.4 & 5gh.