Oh right, thanks. Guess i pulled the ethernet cable when i removed my serial console

I know that CESA is important to some of you guys... 

I am more concerned about the new version of .17 (latency and the bad Rx rates on 5 GHz)

Either way, I think just based on the rate that the guys at LEDE are piling up the changes, we are going to be happy very soon..

r339 just finished building...  time for the sysupgrade test

Cheers

@InkblotAdmirer: i've tweaked openssl to use the cryptodev engine now on my WRT1900AC-V2.
CESA is also correctly registered. My current puzzle is that testing openssl with AES256 will crash and reboot the router.
Did you solve that issue already on your V2? do i need that coherency patch for that? (to me it is unclear what that thing does, so havent applied it yet)

(Last edited by JohnnySL on 22 May 2016, 00:46)

i'm actually running R341 at the moment, with the latest changes that are not pushed into main trunk yet.
it has loads more backported network fixes. BM doesn't work on my V2 yet though.

you luck guy with the newest toys

sysupgrade to LEDE r339 was painless... 

Latency is gone (it comes back a bit under load but nothing like before)

Rx still blows (a third of what is should be based on stock firmware and Tx)
Tx is on par if not slightly better than stock.

Some more tweaking the mwlwifi driver and we have a winner (over 2 years after I got my fist unit)

Cheers

hmm...  not all is well

opkg list-installed is killing one proc at 100 %

LUCI is not available (bad gateway - process did not produce any response)

all else is working...

despite the high proc usage the latency is still less than half of what I had before (bouncing between 7 and 14 ms)

Cheers

@davidc502
Do you by chance have a changelog I can link to? 

If you don't, it's not a big deal.  Whenever you make a new build, and only if you have the time, could you please make one?  Thanks =]

The coherency patch I included is from the folks at free-electrons to fix the freeze when the crypto engine is highly loaded (like with AES256).

I also have the buffer manager ported to the ACS, it's not hard (but it's different than the V1).  I can share them (out of town this week so it may take me a bit).  Guarantee they'll need to be reworked, I piled all the device tree buffer manager and crypto patches into the same patches but they show how it's done.

EDIT:  device tree changes for BM on 385.  I don't have access to great documentation so I had to make some guesses as to how to implement this.  Someone who knows what they're doing should fix it

These contain the crypto MBUS_ID sections as well, so they need to be reworked to be applied on top of changes already made of course.

--- a/arch/arm/boot/dts/armada-385-db-ap.dts
+++ b/arch/arm/boot/dts/armada-385-db-ap.dts
@@ -61,7 +61,8 @@
         ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
               MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
               MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
-              MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+              MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000
+              MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
 
         internal-regs {
             spi1: spi@10680 {
@@ -138,6 +139,9 @@
                 status = "okay";
                 phy = <&phy2>;
                 phy-mode = "sgmii";
+                buffer-manager = <&bm>;
+                bm,pool-long = <2>;
+                bm,pool-short = <3>;
             };
 
             ethernet@34000 {
@@ -157,6 +161,13 @@
                 status = "okay";
                 phy = <&phy0>;
                 phy-mode = "rgmii-id";
+                buffer-manager = <&bm>;
+                bm,pool-long = <0>;
+                bm,pool-short = <1>;
+            };
+
+            bm@c8000 {
+                status = "okay";
             };
 
             nfc: flash@d0000 {
@@ -193,6 +204,10 @@
             };
         };
 
+        bm-bppi {
+            status = "okay";
+        };
+
         pcie-controller {
             status = "okay";

--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -58,8 +58,9 @@
     soc {
         ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
               MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
-              MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
-              MBUS_ID(0x09, 0x05) 0 0xf1110000 0x10000>;
+              MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
+              MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000
+              MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
 
         internal-regs {
 
@@ -93,6 +94,9 @@
             ethernet@70000 {
                 status = "okay";
                 phy-mode = "rgmii-id";
+                buffer-manager = <&bm>;
+                bm,pool-long = <0>;
+                bm,pool-short = <1>;
                 fixed-link {
                     speed = <1000>;
                     full-duplex;
@@ -102,12 +106,20 @@
             ethernet@34000 {
                 status = "okay";
                 phy-mode = "sgmii";
+                buffer-manager = <&bm>;
+                bm,pool-long = <2>;
+                bm,pool-short = <3>;
                 fixed-link {
                     speed = <1000>;
                     full-duplex;
                 };
             };
 
+
+            bm@c8000 {
+                status = "okay";
+             };
+
             mdio {
                 status = "okay";
             };
@@ -198,6 +210,10 @@
             };
         };
 
+        bm-bppi {
+            status = "okay";
+        };
+
         pcie-controller {
             status = "okay";

--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -540,6 +540,14 @@
                 status = "disabled";
             };
 
+            bm: bm@c8000 {
+                compatible = "marvell,armada-380-neta-bm";
+                reg = <0xc8000 0xac>;
+                clocks = <&gateclk 13>;
+                internal-mem = <&bm_bppi>;
+                status = "disabled";
+            };
+
             sata@e0000 {
                 compatible = "marvell,armada-380-ahci";
                 reg = <0xe0000 0x2000>;
@@ -618,6 +626,17 @@
             #size-cells = <1>;
             ranges = <0 MBUS_ID(0x09, 0x15) 0 0x800>;
         };
+
+        bm_bppi: bm-bppi {
+            compatible = "mmio-sram";
+            reg = <MBUS_ID(0x0c, 0x04) 0 0x100000>;
+            ranges = <0 MBUS_ID(0x0c, 0x04) 0 0x100000>;
+            #address-cells = <1>;
+            #size-cells = <1>;
+            clocks = <&gateclk 13>;
+            no-memory-wc;
+            status = "disabled";
+        };
     };
 
     clocks {

(Last edited by InkblotAdmirer on 22 May 2016, 05:48)

@all

This is an OpenWRT forum, please keep it as such. Thank you!

nitroshift

@Inktblotadmirer: thanks! will try your fix for CESA. The BM patches to the DTSI i have, but it still fails allocating memory on my V2 Will try to debug that later.

edit: EUREKA! i've got CESA working stable now:

openssl speed -evp aes256
Doing aes-256-cbc for 3s on 16 size blocks: 192448 aes-256-cbc's in 0.07s
Doing aes-256-cbc for 3s on 64 size blocks: 190344 aes-256-cbc's in 0.04s
Doing aes-256-cbc for 3s on 256 size blocks: 172258 aes-256-cbc's in 0.04s
Doing aes-256-cbc for 3s on 1024 size blocks: 126216 aes-256-cbc's in 0.04s
Doing aes-256-cbc for 3s on 8192 size blocks: 29311 aes-256-cbc's in 0.01s

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc      43988.11k   304550.40k  1102451.20k  3231129.60k 24011571.20k

lol, infinite amount of aes128 8k  blocks?:

openssl speed -evp aes128
Doing aes-128-cbc for 3s on 16 size blocks: 195366 aes-128-cbc's in 0.11s
Doing aes-128-cbc for 3s on 64 size blocks: 191646 aes-128-cbc's in 0.10s
Doing aes-128-cbc for 3s on 256 size blocks: 177495 aes-128-cbc's in 0.06s
Doing aes-128-cbc for 3s on 1024 size blocks: 134139 aes-128-cbc's in 0.07s
Doing aes-128-cbc for 3s on 8192 size blocks: 31848 aes-128-cbc's in 0.00s

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc      28416.87k   122653.44k   757312.00k  1962261.94k         infk

(Last edited by JohnnySL on 22 May 2016, 09:33)

am not seeing any of those issues. maybe wipe your settings and start fresh? (i did)

I'm gonna take my repo offline, i want to test LEDE. Will be back in a few after rebuilding my conf.

Cheers

Edit: Will take it offline at 1:30PM GMT

(Last edited by mrfrezee on 22 May 2016, 13:44)

@JW0914

Some more points:

Hardware table
--------------
* make Code Name it's own column and remove from Comment column.

switch layout
-------------
* table mapping 0-6 to their respective meaning instead of trees that still don't cover full mapping.

firmware
--------
* What the heck is oobo? http://www.urbandictionary.com/define.php?term=oobo -> proper English.
* fills -> frills

wireless driver
---------------
* add motivation for this section, use one or two sentences from dlang, he said it quite well.
* brief description of link to source and link to prebuilt binaries.
* The source isn't a sub-item of prebuilt binaries, if at all it's the other way around.

Bootlog
-------
* add taken from mamba, no need to lists others though

Bugs
----
* maybe merge with firmware respectively wireless section. Though having an own section can be argued for as well.

Revert to Default Settings
--------------------------
* /sbin/firstboot unless you know a good reason not to.
* luci?

tftp
----
"Rename applicable image [*.img] to the OEM default name:" - OEM default name isn't an existing well defined construct.
* replace with as expected by bootloader, expected by default by the device, some other proper English construct.
* applicable isn't ideal either, might create more questions than giving answers.
* putty is not only for windows but all the others as well (for the sake of simplicity, ignore that other software exists), the the linked profile and instructions are windows specific, make that clear.
* tftp server instructions are windows only, make that clear.
* 5. At the 3 second interrupt boot delay, press any key. Possibly not obvious, how about adding it to the console output further down?

Essentially, usually every 1 to 2 weeks a new clone of trunk is downloaded. Any new committed wifi drivers are included, and two patches applied (BM and NAND). I keep a .config of many of the packages people want and make sure I upload those as well.

I'll usually test 2 days before uploading to make sure there are no huge bugs that are going to affect the system. Otherwise I won't upload, and will wait for a fix.

Please elaborate

LOL That is a very good question.  Typo fixed  (should have been OOBE [Out Of Box Experience])

Planned on doing that day, as I ran out of time making changes last night

I meant to ask about that, thanks =]

Should I perhaps include the individual link for each under their respective sections, as well as maintaining the Bug Reports section under Troubleshooting?

Each was originally under Introduction, however I moved them to Troubleshooting to coalesce all troubleshooting subjects into a cohesive Troubleshooting section (instead of having disparate troubleshooting references throughout the wiki).

Good catch, will do

Great points =] will do

(Last edited by JW0914 on 22 May 2016, 15:06)

1st row cell values: 0 1 2 3 4 5 6
2nd row cell values: lan 1, lan 2, lan 3, lan 4, lan cpu port, wan, wan cpu port
In lack of a better suggestion row headers: switch port, port
sort and transpose as necessary.
result: compact and straight forward.

I'd say either or.

I'd personally prefer to leave it under troubleshooting, however if you and others believe it would make more sense under the respective sections of Firmware and Wireless Driver, I have no issue with that.

I guess once the mwlwifi section is gone so should the corresponding bug link, that's why I brought it up.

Hi
im trying to get cake into my build. (using stable branch)
It worked but my tc is missing some options. (autorate_ingress for example)

I followed this guide:
https://web.archive.org/web/20160328150 … /wiki/Cake

Then i found this patch:
https://gist.github.com/hnyman/b35bf1e2501ad7dd08d4

When i use this patch do i still have to include tc-adv in my build?

//Edit Okay...

So need for tc-adv.
But the patch is for iproute2 v4.4. but stable branch is using v4.0?
Can it still be used?

@davidc502
Do your builds include cake?

(Last edited by shm0 on 22 May 2016, 17:07)

did a bare bones build (no packages) and after sysupgrade installed them manually

everything works now, latency is perfect even under load, and the Rx rates are better as well (about 2/3 of Tx which in turn are also slightly better than on my prior attempt - r339)

Model Linksys WRT1900AC
Firmware Version LEDE Designated Driver r343 / LuCI Master (git-16.135.27427-6415c04) 
Kernel Version 4.4.11
Local Time Sun May 22 12:06:50 2016
Uptime 0h 8m 56s
Load Average 0.23, 0.11, 0.06

Cheers

Are the radios flipped on the 1200AC vs 1900ACv1? 

On My 1900AC:
Marvell 88W8864 802.11bgn (radio0)
Marvell 88W8864 802.11nac (radio1)

On My 1200AC:
Marvell 88W8864 802.11nac (radio0)
Generic 802.11 Wireless Controller (radio1)

As can be seen above, it does not seem to be recognizing my 2.4 radio - the radio is not working.

I just installed davidc502 on it all else seems to work properly.  I did try a reflash.
Do I have bad hardware?

I include cake in my own trunk build, both old Openwrt trunk and the LEDE trunk using that patch. If you check my build sources (from the community builds section), you will notice that I use a modified cake package Makefile that depends just on "tc" with that patch, so there is no need for "tc-adv" dependency.

The patch may work with the old stable (and stale) CC15.05 branch, but you might need to modify it slightly for it to apply cleanly as the iproute2 4.0 differs from 4.4.

But wrt1900ac family seems to be under active fixing in the LEDE trunk, so I doubt if spending too much time on the stale CC15.05 build is worthwhile. I guess you would be better off with trunk.

@hnyman
Thanks for your answer.
I just did a quick compile.
Stable + your patch.
Build with out problems but havent flashed yet.

When i go for LEDE. Do i still need nand patch and so on?

Thank you.

As of about 3 hours ago you should be able to drop CESA, BM, NAND, any manual modifications to config files, and pick up a new unit on the mvneta device. At least I did so, and all seems to be good.

Yeah i've been testing the builds for the V2, and the latest build has been flawless for me until now.