So should I go with Attitude-Adjustment

Wait, are you talking about the Barrier Breaker that Belkin released a while ago? I see that 'mvebu' wasn't copied to the BB release svn repo (rightfully so) so what I said before applies more to what was then "Barrier Breaker" trunk.

The wiki entry has some information about the different unofficial firmware releases: http://wiki.openwrt.org/toh/linksys/wrt1900ac

I know "McWRT" is based on the Belkin AA release.

(Last edited by leitec on 24 Feb 2015, 01:26)

I just need a repository to compile image for wrt1900ac

https://dev.openwrt.org/wiki/GetSource

"trunk (main development tree)"

(Last edited by leitec on 24 Feb 2015, 02:27)

I backup everything except the sp0.0 partition into  a single file and then copy the file over to my workstation. It probably takes almost three minutes to run the backup script and only a few seconds to copy the data over to my  computer.

I use a method that is on an inspirational (not religious) you-tube video about how to backup a WNDR3700 to the cloud. It took me awhile to get everything to work but it is not that hard to do. All the work is done by BB's dd which is capable of appending data from each mount point listed in the script. To restore the backup  the command mtd is needed so one approach would to use a snapshot image restore to get things started and then use winscp to copy your backup to the /tmp directory of the router and finally run a script from there to install your backup image. I use putty and winscp to make life a bit easier. Also installing nano  editor will be helpful unless you are a vi freak.

First, connect to the WRT1900ac with putty. The command cat /proc/mtd will give you all the information you need to create/edit your dd batch file. My latest working batch file is below. The last line is commented out because dd barfs if is back in. I don't think I need I2C support so eventually sp0.0 will be gone anyway. My backup is just over 38MB.

#!/bin/sh
cd /tmp
rm *.bin
dd if=/dev/mtd0 of=/tmp/openwrt-wrt1900ac-trunk-r44486.bin
dd if=/dev/mtd1 of=/tmp/openwrt-wrt1900ac-trunk-r44486.bin
dd if=/dev/mtd2 of=/tmp/openwrt-wrt1900ac-trunk-r44486.bin
dd if=/dev/mtd3 of=/tmp/openwrt-wrt1900ac-trunk-r44486.bin
dd if=/dev/mtd4 of=/tmp/openwrt-wrt1900ac-trunk-r44486.bin
dd if=/dev/mtd5 of=/tmp/openwrt-wrt1900ac-trunk-r44486.bin
dd if=/dev/mtd6 of=/tmp/openwrt-wrt1900ac-trunk-r44486.bin
dd if=/dev/mtd7 of=/tmp/openwrt-wrt1900ac-trunk-r44486.bin
dd if=/dev/mtd8 of=/tmp/openwrt-wrt1900ac-trunk-r44486.bin
#dd if=/dev/mtd9 of=/tmp/openwrt-wrt1900ac-trunk-r44486.bin

Put the text above into a shell file in the /tmp directory. The batch file can be named anything you want but the first line must be exactly as above. If you generate the file under Linux it should only need to have the chmod +x <filename> command to be able to use it as a shell file. To run the file go to the tmp directory and type ./<filename>. If it doesn't run your not alone but the fix is easy. Run nano <filename> amd look for ^M's at the end of each line. They must be deleted  before Linux will run the file.

The restore (which I haven't done yet) is achieved by copying your backup file to the /tmp directory with winscp and then running the restore command from the /tmp directory.

mtd -r write /tmp/<filename.bin> firmware.

It might be best to double check that 'firmware' is the correct target name. Also case matters and I have adopted lower case as much as I can to reduce my abundant typos.

Charlie

I am able to build a imgaebased on the guidelines at https://github.com/wrt1900ac/opensource
I got the following files generated in bin/mvebu folder:
4669440 Feb 23 20:19 bin/mvebu/openwrt-mvebu-armada-xp-mamba-jffs2-128k-sysupgrade.tar
4597760 Feb 23 20:19 bin/mvebu/openwrt-mvebu-armada-xp-mamba-jffs2-64k-sysupgrade.tar
5898240 Feb 23 20:19 bin/mvebu/openwrt-mvebu-armada-xp-mamba-squashfs-factory.img
3880960 Feb 23 20:19 bin/mvebu/openwrt-mvebu-armada-xp-mamba-squashfs-sysupgrade.tar
3276800 Feb 23 20:19 bin/mvebu/openwrt-mvebu-root.jffs2-128k
3145728 Feb 23 20:19 bin/mvebu/openwrt-mvebu-root.jffs2-64k
2490368 Feb 23 20:19 bin/mvebu/openwrt-mvebu-root.squashfs
1513404 Feb 23 20:19 bin/mvebu/openwrt-mvebu-uImage-armada-xp-mamba

Is this good enough to go ahead with imaging the router.

@leitec

I am running 3.19 and the speeds I claim are obtained while running an image based on it....

nitroshift

Just noticed kernel 4.0 rc1 came up and early support was introduced in trunk by @rmilecki. Will try to build an image with it later today (if it builds at all) and give it a go tonight. As usual, I will come back with the results.

nitroshift

(Last edited by nitroshift on 24 Feb 2015, 07:23)

@nasa007

You can flash openwrt-mvebu-armada-xp-mamba-squashfs-factory.img from the existing firmware.

nitroshift

First bug in latest trunk supporting kernel 4.0: there is no mirror string defined to download the kernel. File /trunk/scripts/download.pl must be manually edited to add line

https://www.kernel.org/pub/linux/kernel/v4.x/testing/

under section #push @mirrors.

Also, file /trunk/include/netfilter.mk must be manually edited to add line

$(eval $(if $(NF_KMOD),$(call nf_add,IPT_NAT,CONFIG_NF_NAT_REDIRECT, $(P_XT)nf_nat_redirect, ge 4.0.),))

under #nat --> #kernel only section.

More additions to come as I progress compiling.

nitroshift

(Last edited by nitroshift on 24 Feb 2015, 12:43)

Yeah, I know, I just wanted to point out the differences.

There are a few commits to arch/arm/mach-mvebu since 3.19 that may improve things, so I look forward to your results with 4.0.

@leitec

It dies out with

/trunk/build_dir/target-arm_cortex-a9+vfpv3_uClibc-0.9.33.2_eabi/linux-mvebu/compat-wireless-2014-11-04/net/wireless/util.c:711:2: error: implicit declaration of function 'vlan_tx_tag_present' [-Werror=implicit-function-declaration]
  if (vlan_tx_tag_present(skb)) {

and

/trunk/build_dir/target-arm_cortex-a9+vfpv3_uClibc-0.9.33.2_eabi/linux-mvebu/compat-wireless-2014-11-04/net/wireless/util.c:712:3: error: implicit declaration of function 'vlan_tx_tag_get' [-Werror=implicit-function-declaration]
   vlan_priority = (vlan_tx_tag_get(skb) & VLAN_PRIO_MASK)

Any hints?

nitroshift

(Last edited by nitroshift on 24 Feb 2015, 14:21)

Probably this: https://git.kernel.org/cgit/linux/kerne … 2976d62cc0

A lot of the generic patches didn't apply cleanly when I tried to build, and even after modifying them there are some things that aren't compiling. Rafal said it was not complete, so I'll hold off until it is.

@leitec

True, most patches failed to compile but as they weren't related to our platform I just deleted them I'm going through the patches from the link you gave me above but probably will finish tomorrow as right now I am getting ready to go home from work.

nitroshift

Looks pretty straight forward though i don't understand the target "firmware" part. Has anyone else tried this?
Would this work for all the various builds out there i.e AA, BB, CC ?

So the idea is to flash your router with the FW first and then restore the backed up partitions. Keeping in mind that you restore the backup that was made on the same FW you are restoring it on.

(Last edited by alirz on 24 Feb 2015, 15:38)

It turns out that 'firmware' is a wrt3600 partition name so it is no good for the WRT1900AC. Any of the named partitions backed up would be the set. Today I want to find out which partitions are important to restore and create a batch file for this to be easier. I have made a number of backups in the past and have never had to restore anything yet so there  may be write protection issues to address.

Charlie

OK, with the latest few commits plus the swconfig bit from http://patchwork.ozlabs.org/patch/443021/ I was able to compile a working 4.0 image. I copied the mvebu-specific 3.19 config (missing a few symbols) and patches (a lot don't apply; may already be commited upstream)

I re-ran the iperf3 benchmarks. I'm seeing about 35 mbit/sec improvement (regularly) in one direction (client->server, "upload") and about 100 mbit/sec in the other (server->client, iperf3 -R, "download"). What I'm not sure is if that's a result of mvebu-specific improvements (although I'd guess it's that, since there are a few) or general improvements.

edit: I'm not sure why there is such a difference between the two directions. Each test machine can saturate the gigabit link.

3.19:

[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-30.00  sec  1.36 GBytes   389 Mbits/sec                  sender
[  5]   0.00-30.00  sec  1.36 GBytes   389 Mbits/sec                  receiver

[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-30.00  sec  2.53 GBytes   725 Mbits/sec   94             sender
[  5]   0.00-30.00  sec  2.53 GBytes   725 Mbits/sec                  receiver

4.0-rc1:

[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-30.00  sec  1.48 GBytes   424 Mbits/sec                  sender
[  5]   0.00-30.00  sec  1.48 GBytes   424 Mbits/sec                  receiver

[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-30.00  sec  2.88 GBytes   825 Mbits/sec   45             sender
[  5]   0.00-30.00  sec  2.88 GBytes   825 Mbits/sec                  receiver

Those are from single 30 second runs of each test but the numbers are pretty consistent.

(Last edited by leitec on 24 Feb 2015, 21:08)

@leitec

Great! Could you please upload somewhere the 4.0 image to save me the trouble of compiling it? Thanks! Actually I only need the sysupgrade archive.

nitroshift

(Last edited by nitroshift on 24 Feb 2015, 20:56)

I compiled without WiFi enabled. That'll require a few more fixes (the stuff you ran across before). Is that of any use to you?

@leitec

I stopped compiling when it complained about not finding "armada-xp-mamba.dtb" file. That's on my work PC at the office. I'll fire up another build tomorrow with kernel 3.19 to get the .dtb file, copy it across to the corresponding location in 4.0 compiler and carry on. I thought you might have it compiled already with wifi on. No worries, I'll continue tomorrow and come back should I need any more help or if everything works out ok, I'll post back with any modifications needed to finish image build.

nitroshift

(Last edited by nitroshift on 24 Feb 2015, 21:17)

Just copy mvebu/patches-3.19 to mvebu/patches-4.0 and get rid of the ones that don't apply. I think that's all I had to do. That way, you'll also get the other arch- and board-specific things you need (dual firmware stuff, masking bootloader args, fan stuff)

$ ls patches-4.0
001-build_mamba_dts.patch
019-mtd-nand-pxa3xx-Fix-PIO-FIFO-draining.patch
050-leds_tlc59116_document_binding.patch
051-leds_tlc59116_add_driver.patch
100-find_active_root.patch
102-revert_i2c_delay.patch
202-gpio_mvebu_add_limited_pwm_support.patch
203-dt_bindings_extend_mvebu_gpio_documentation_with_pwm.patch
204-mvebu_xp_add_pwm_properties_to_dtsi_files.patch
205-arm_mvebu_enable_pwm_in_defconfig.patch
206-mvebu_wrt1900ac_use_pwm-fan_rather_than_gpio-fan.patch
$ 

That's enough to get you an image. No guarantees of anything else...

@leitec

Thanks for the advice. I was going the hard way around... By the way, out of the 3.19 patches I remember deleting 771 through to 779 or so as they failed to compile.

nitroshift

(Last edited by nitroshift on 24 Feb 2015, 21:39)

Feb. 24 factory img.
OpenWrt Chaos Calmer r44511 / LuCI (git-15.051.48491-4137afe)
Reboot fan run-up RPM has been throttled back.
No initial hiccups / hangs.

Is anyone having an issue mounting USB drives?   running on the latest Kaloz build.

Can you install any *.ipk packages without errors?