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.

@northbound I flash LEDE-to-LEDE using the sysupgrade.bin file.  I believe sera has posted he thinks there may be an issue sysupgrading (or luci) using the .img file, but I don't personally have any info there.  I've used the .img once, when converting from stock.

@InkblotAdmirer
Nyet. She be borked, and borked good. I have never seen this on my v1. What @kirkbr reported a while back; one flash but both partitions fracked and unable to do a 3 cycle back. Same build as you, but I did not do a tools/clean; may be that is it. Going to pull it and hook up the serial.

Edit: As a data point I used factory on that flash.

(Last edited by Villeneuve on 16 Aug 2016, 04:38)

InkblotAdmirer wrote:

@northbound I flash LEDE-to-LEDE using the sysupgrade.bin file.  I believe sera has posted he thinks there may be an issue sysupgrading (or luci) using the .img file, but I don't personally have any info there.  I've used the .img once, when converting from stock.

Will try again with the sysupgrade after I have flashed a working image to the other nand.
I have been going from lede>lede  Without a problem until this issue.

@InkblotAdmirer
Results are the same. I guess I am stuck on r1302 until this issue is resolved.
But thanks for your time.

@northbound
Not sure what to say, I've flashed it on both an ACV1 and ACSV1.

Since the issues appear to be networking related, I'll mention a few recent changes I've made.  I updated busybox to 1.25.0 (unstable so not necessarily recommended) but that broke openvpn's ability to add routes through ip.  Not sure if I broke that or if it's an issue with busybox (the update was not hard but definitely not trivial), but I just moved to the full ip package.

So my recent major departures from LEDE source are busybox 1.25.0 and the full ip package instead of the busybox implementation.  I'm out for the night now, good luck.

-------------------------------------------------------------------------------------------------
                ##----- WRT AC Series Wiki Master ToDo List -----##
-------------------------------------------------------------------------------------------------

Still Needing to be Done

  • Numbers 2 & 3

    • Will be combined, as a script exists within this thread to backup all partitions and create a tarball for storing away (see this post by @sera)

  1. Add information, per @sera's request, regarding this

  2. [See bullet above] Add mtd backup instructions, specifically for mtd3

  3. [See bullet above] ]Add process to restore settings back to mtd1 [u_env]

  4. [DONE]  Consolidate bootloader recovery and bootloader environment under a Bootloader [Troubleshooting] heading 4

    • [In Progress]  Add bootloader recovery for Armada 385

    • Specify that 'kwboot' does not write anything too flash, but is strictly in RAM until flashed to NAND.

      • This has been axed due to input from @nitroshift

  5. [DONE]  Add Bootloader section to the main section of the wiki as well

    • Add USB to Serial Flash section

    • Add the nandboot cli commands [run nandboot ; run altnandboot]

  6. @sera Please let me know if these are still needing to be added:

    • [re: WiFi] refer to this section under introduction in case of wireless issues and add some stuff to try here

    • [re: WiFi] add steps if one encounters a bug: search tracker first and meaning full bug report after (refer to external documents)

      • This has been axed due to input from @sera

  7. [DONE]  Add sysupgrade section with appropriate commands

  8. Add links to vlan wikis/posts

    • The subject of vlans has come up from several users over the months, and while it doesn't make sense to add vlan instructions in the wiki [vlans aren't device specific], I also know the OpenWrt wiki site isn't the easiest to navigate if you're not familiar with it.

  9. @sera had a great suggestion about adding a brief description for CC, DD, & LEDE... anyone who has ideas, please post them, as I've been unable to come up with a decent description for any of the three.

  10. Add when and where to run the commands for the Corrupt Bootloader Environment

  11. Articulate what each command in Step 6 under Serial Flash does

  12. Add annotation that luci-ssl is not required for https and should not be installed, as well as providing a link to a pre-built openssl.cnf containing all required commands at bottom of config (starting at line 507)

    • Simply put, PolarSSL isn't worth the repeated headaches, combined with the fact px5g, nor easy-rsa, does not create secure enough certs

  13. Add annotation that engine cryptodev needs to be added to OpenVPN client config in order to utilize marvell cesa hardware acceleration

    • This has been axed due to great input from @InkblotAdmirer

  14. Add warning that flashing a factory.img using sysupgrade or luci is broken on caiman, cobra and shelby  (discovered a few days ago by @sera)

  15. Require clarification from @nitroshift regarding kwboot command and the accompanying file for Armada 385 (please see this post for details).  This ties in with #4

  16. Add "Where to Go Next" section after "Flashing Firmware" section, of which will contain helpful links, such as the main UCI System wiki

    • I will eventually be reformatting that wiki page as well, incorporating many of the DokuWiki formatting I've applied to the WRT1X00AC/S series wiki.  I take the position that it benefits all when wiki pages make full utilization out of DokuWiki as it it breaks up the monotony of plain text after plain text.  Breaking up information into clearly defined, aesthetically pleasing format makes it easier on all users to disseminate the information they need, all the while keeping the reader engaged in the content.

      • This shouldn't be taken, and is not meant as, a slight against, or critique of, contributing members to wiki pages, as many most likely don't have time to fully read through the DokuWiki plugin pages (it took me several hours of reading, with an additional several hours of applying the different coding to become quite familiar with the different plugins and how they can be utilized).  Many may also not be aware of what DokuWiki is, as I know I wasn't until over a year after creating my first wiki page.

(Last edited by JW0914 on 5 Sep 2017, 15:48)

Villeneuve wrote:

@InkblotAdmirer
Nyet. She be borked, and borked good. I have never seen this on my v1. What @kirkbr reported a while back; one flash but both partitions fracked and unable to do a 3 cycle back. Same build as you, but I did not do a tools/clean; may be that is it. Going to pull it and hook up the serial.

Edit: As a data point I used factory on that flash.

In my case, it wasn't a single flash that broke both.  I booted one tried to flash, borked one.  Booted the other tried flash again and borked the other.

@JW0914

kwboot tool doesn't write anything to the flash.

nitroshift

JW0914 wrote:

@mmcneil Please post logs/log output within code brackets.  It makes the output far easier to read and shrinks the post

Oops.. Sorry about that.  I know how annoying that can be ;-)

InkblotAdmirer wrote:

@northbound I flash LEDE-to-LEDE using the sysupgrade.bin file.  I believe sera has posted he thinks there may be an issue sysupgrading (or luci) using the .img file, but I don't personally have any info there.  I've used the .img once, when converting from stock.

Sysupgrade fails to detect ubi images within factory.img. It checks for the file magic at an offset of 3M, which only works for mamba, for the others it shoudl check at 6M.

When it detects an ubi imgage it erases the partition before reflashing as is required. There is a hack to mitigate the issue which is to pad the image with some magic markers and patch the kernel to look for them and if encountered to erase the reminder before attempting to attach to it.

Not that easy to hit but as it doesn't always work I call it broken. Anyway, the recommendation to always use sysupgrade.tar if possible is true regardless (wear-leveling).

@JW0914

You left flash_pri_image which only works 50% of time, replace with update_both_images to make the instruction always correct.

As to point 1), it's not a warning, it's about adding the new models (v2), they are missing.

I had a free half hour so did some work on the wiki... I removed all references to "Trunk", utilizing "Development Branch" or "Development Build" in lieu of.  I also went through and updated all Trunk interwiki links to point to the renamed headings.

  • Glanced over @kaloz's github to grab the updated information for updating the build instructions in the wiki, however I'm not sure where to grab the PKG_SOURCE_VERSION for PKG_VERSION 10.3.0.18-20160804 (firmware 7.2.9.26)


nitroshift wrote:

@JW0914

kwboot tool doesn't write anything to the flash.

I'll remove that then.  I added it due to this post by @leitec


Also, could you clarify a few things about the Armada 385 recovery process please:

Is u-boot-spl.kwb the UART file? 

  • If so, is the u-boot-nand.kwb from the Armada XP utilized, or is 1 file all that's needed to rebuild the bootloader of Armada 385s?


kwboot -b /tftpboot/db-88f6820-gp/u-boot-2013.01-2014_T3.0p10-a38x_spi-uart.bin -p -q 5 -s 5 -t /dev/ttyUSB0

Is the above command utilized in lieu of

./kwboot –a –t /dev/ttyUSB0 –b u-boot-uart.kwb

  • Additionally, what do the following switches mean:

    • -p

    • -q

    • -s  (seconds ?)

(Last edited by JW0914 on 20 Aug 2016, 23:21)

sera wrote:

@JW0914

You left flash_pri_image which only works 50% of time, replace with update_both_images to make the instruction always correct.

As to point 1), it's not a warning, it's about adding the new models (v2), they are missing.

I've changed the flash command from primary to both, however it's not possible for the command to flash primary or alternate partitions to fail (I believe this would require u-boot to be corrupted across not just one, but all wrt devices).

  • I'm assuming you've had issues with it from your reply, and, more likely than not, the device was set to boot from the alternate partition [mtd7], of which would result in the device not booting to the partition that was just flashed with the primary flash command, thus giving the appearance of an issue.

    • In u-boot, the primary flash command always flashes the primary partition [mtd5], with the alternate flash command always flashing the alternate partition [mtd7]


I've modified #1, as I was using the wording from your post (I hadn't read the post you linked to in that reply yet)

(Last edited by JW0914 on 16 Aug 2016, 15:43)

@JW0914

a) The command flash_pri_image will succeed. The user may or may not able to boot after reset. (Here you need the thousand words as to how it can fail)
b) The command update_both_images will succeed. The user can boot for sure.

We don't want to run a command successfully but getting the device back into shape. This recipes target audience are those who have to clue what each of those lines mean. It just has to work.

I have a hard time to try to make it more clear what I mean, if someone else may skim in.

@sera That makes sense

If you have time in the next week or so, would you be willing to type up a brief synopsis of different ways it can fail and how to troubleshoot?  If you can give me one or two sentences per, I can do the additional legwork to flesh it out with details, then add it under either the main bootloader section that I added, or under the troubleshooting bootloader section



@All  Can the 1200 v2 and 1900ACS v2 user flash v1 firmware and simply install/build with the updated wifi driver?

(Last edited by JW0914 on 16 Aug 2016, 17:08)

@InkblotAdmirer
Restored both partitions to working r1297, did a make tools/clean and built a clean tree with the same source code. Flashed the sysupgrade image from luci, keeping settings, borked. Other than the changes you noted in your build, mine is on kernel 4.4.17 and minus the revert-i2c-delay patch from testing done earlier. Guess I'll leave unit connected to serial until this is resolved.

@sera
After the above test I flashed to the owrt 4.7 image to test comment regarding non-functioning CESA. On the mamba it does not appear to be working OOTB, at least with the build I made. My understanding was this should now be in kernel 4.7 and nothing special required?

Edit:
@kirkgbr
Noticed your last post after I had already got the serial connected and fixed things up, so too late to do some kind of forensic unfortunately.
The naming convention changed somewhere along the way. now called:
lede-mvebu-linksys-wrt1900ac-squashfs-sysupgrade.bin

Edit2:
My misunderstanding. When I flashed to the owrt 4.7 image, from r1297 and onto the previous bad flash partition, I used the factory.img.

(Last edited by Villeneuve on 16 Aug 2016, 18:02)

Villeneuve wrote:

@InkblotAdmirer
Restored both partitions to working r1297, did a make tools/clean and built a clean tree with the same source code. Flashed the sysupgrade image from luci, keeping settings, borked. Other than the changes you noted in your build, mine is on kernel 4.4.17 and minus the revert-i2c-delay patch from testing done earlier. Guess I'll leave unit connected to serial until this is resolved.

Curious if you used the sysupgrade.tar image?

EDIT:  Sorry and nevermind then, thought you were using sera's 4.7 stuff.

(Last edited by kirkgbr on 16 Aug 2016, 17:53)

@Villeneuve
I'm using 4.4.17 as well but I have NOT removed the revert-i2c patch.  I also recall Kaloz indicating that was required for mamba devices to boot.  I know some testing was done but you might want to try adding it back.

Villeneuve wrote:

@sera
After the above test I flashed to the owrt 4.7 image to test comment regarding non-functioning CESA. On the mamba it does not appear to be working OOTB, at least with the build I made. My understanding was this should now be in kernel 4.7 and nothing special required?

The cesa driver was added in 4.1 but was unusable out of the box up to 4.7. How to make it work is known for a while. Now that it is in 4.7 it will likely be backported, maybe back to 4.1. So in a month or two the kernel part is covered for all anyway.

The other thing is openssl that needs to be built after kmod-cryptodev which is a bit of a mess to enforce with current dependencies. Some builds are fine some are not. I want to leave support optional, just didn't had the time to look into it yet, worst case just hard depend on it.

I have a few new things in store for the next series
- musl changes mentioned a few posts earlier
- full base feed support
- usable 4.8, the regression now has a fix
- cherry picked dropbear update
and more, will see to get this cesa stuff sorted as well.

I'm trying to build Openwrt Daily Driver r49395, using the 4.4.16 kernel.  I keep getting compilation errors due to the patches in target/linux/generic/patches-4.4/ not applying/failing.  I'm assuming that the patches are for a lower revision of the linux kernel and may not be needed, or already upstreamed, into the 4.4.16 kernel. Am I missing something?

Thanks

JW0914 wrote:
nitroshift wrote:

@JW0914

kwboot tool doesn't write anything to the flash.

I'll remove that then.  I added it due to this post by @leitic


Also, could you clarify a few things about the Armada 385 recovery process please:

Is u-boot-spl.kwb the UART file? 

  • If so, is the u-boot-nand.kwb from the Armada XP utilized, or is 1 file all that's needed to rebuild the bootloader of Armada 385s?


kwboot -b /tftpboot/db-88f6820-gp/u-boot-2013.01-2014_T3.0p10-a38x_spi-uart.bin -p -q 5 -s 5 -t /dev/ttyUSB0

Is the above command utilized in lieu of

./kwboot –a –t /dev/ttyUSB0 –b u-boot-uart.kwb

  • Additionally, what do the following switches mean:

    • -p

    • -q

    • -s  (seconds ?)

Please look me up on #openwrt channel on freenode iRC server for explanations. There's no need to clutter this (already hefty) thread.

nitroshift

PS. By the way: it's @leitEc wink

(Last edited by nitroshift on 17 Aug 2016, 11:18)

@nitroshift Will do later today =] 

lol that's the second time I've misspelled someone's user name (first was mrfrezee, which I spelled mrfreeze)

after being offline for work for nearly 6 months, I decided to use my holidays to flash a new version of openwrt (v1). As I also decided to not read the past 100 pages of this thread please forgive me if my questions already have been answered before.
I read the complete wiki-entries for WRT1900AC, chose the appropriate version of davidc502's builds, successfully compared all checksums and upgraded without keeping config-files.
As I started reconfiguring my v1 I realized different curiosities/issues:
- https://abload.de/thumb/statusudpba.png : status tells me, kernel is 4.1.23, wiki states kernel would be 4.4.14. Possibility 1: the wrong (perhaps harmful) versions have been uploaded. Possiblity 2: the entry concerning kernel-version stated in the wiki is wrong. Possibility 3: The entry concerning kernel-version stated in the gui is wrong ...?
- https://abload.de/thumb/wifiuoq7m.png: No matter whatever I do (enabled/disabled SSIDs, /etc/init.d/network restart, reboot) - I cannot fully configure a single SSID, they won't come up. Is there any trick to do that?
- LED configuration: It seems there are only 3 LEDs preconfigured (WAN, USB2, USB3). I vaguely remember that in a previous version I had to change only one entry to get the LED configuration perfectly working but now there seem to be several entries missing. Would somebody please provide a copy of his/her /etc/config/system concerning the LEDs?

@ssdnvv Please verify if the link below is the firmware you downloaded. 

http://davidc502sis.dynamic-dns.net/mvebu/Kernel4.4.7/4.4WNandPatchMamba/openwrt-mvebu-armada-xp-linksys-mamba-squashfs-factory.img
  • David's builds should all be on at least 4.4.14.

    • Kernel 4.1.23 is the default kernel version for 4.1, however 4.4.14 is the default for 4.4.

  • I'm not able to view your images, and I suspect, due to the size, something went wonky since that would be the approximate size for a thumbnail (9kb & 10kb).


Please see WiFi in the wiki for the inability to configure the radios

LED configuration is user specific, with the ability to add or delete, options under System -> LED Configuration. 

  • Those 3 LED options are the default and you can add others via the ADD button on the bottom of the LED Configuration page.

(Last edited by JW0914 on 17 Aug 2016, 17:23)

Re. the current netifd stall.

Sorry, posts 12876 to 12875 are missing from our archive.