Looking at /lib/upgrade/linksys.sh this is called to find the flash target:

linksys_get_target_firmware() {
        cur_boot_part=`/usr/sbin/fw_printenv -n boot_part`
        target_firmware=""
        if [ "$cur_boot_part" = "1" ]
        then
                # current primary boot - update alt boot
                target_firmware="kernel2"
                fw_setenv boot_part 2
                fw_setenv bootcmd "run altnandboot"
        elif [ "$cur_boot_part" = "2" ]
        then
                # current alt boot - update primary boot
                target_firmware="kernel1"
                fw_setenv boot_part 1
                fw_setenv bootcmd "run nandboot"
        fi

        echo "$target_firmware"
}

So if you booted from primary, then the next sysupgrade will flash to secondary and vice versa.  The currently booted system will be left intact, but the bootloader is set up to boot to the other one.  This can become a problem if the flash fails, because the bootloader is then set up to boot the failed installation. Easy to fix if you have serial console: Just press a key and type e.g. "run nandboot" to boot the other, working, installation.

But IMHO it would be much better if sysupgrade somehow could delay changing the bootloader variables until *after* a successful flash.

Right now OpenWrt isn't doing anything with the actual "auto recovery" process, by which I mean it doesn't update the other variables that I think are necessary for that to work properly. I believe the factory firmware updates badcount, boot_part_ready and probably more variables that the "auto_recovery" process then uses to determine if it should boot from the other partition instead. As far as I know Linksys never released the WRT1900AC's u-boot source, so I can't tell what it actually is doing.

leitec wrote:

Right now OpenWrt isn't doing anything with the actual "auto recovery" process, by which I mean it doesn't update the other variables that I think are necessary for that to work properly. I believe the factory firmware updates badcount, boot_part_ready and probably more variables that the "auto_recovery" process then uses to determine if it should boot from the other partition instead. As far as I know Linksys never released the WRT1900AC's u-boot source, so I can't tell what it actually is doing.

Anyone got a contact with LinkSys that can put some pressure on them to release the u-boot source? It would be nice if we could back-port some of the more recent changes to support flashing from a usb drive (for example).

jklap wrote:

leitec wrote:

Right now OpenWrt isn't doing anything with the actual "auto recovery" process, by which I mean it doesn't update the other variables that I think are necessary for that to work properly. I believe the factory firmware updates badcount, boot_part_ready and probably more variables that the "auto_recovery" process then uses to determine if it should boot from the other partition instead. As far as I know Linksys never released the WRT1900AC's u-boot source, so I can't tell what it actually is doing.

Anyone got a contact with LinkSys that can put some pressure on them to release the u-boot source? It would be nice if we could back-port some of the more recent changes to support flashing from a usb drive (for example).

Is this the source code you are looking for?
https://github.com/Chadster766/McWRT/wi … r-recovery

So it seems that when I tried to flash "Kaloz's" build it made my router bricked or something? All it shows is an index screen and it wont load an interface... Is there anything I can do to get out of that?

oshrizak wrote:

So it seems that when I tried to flash "Kaloz's" build it made my router bricked or something? All it shows is an index screen and it wont load an interface... Is there anything I can do to get out of that?

its not bricked. You need to install "luci" via ssh or via telnet.

opkg update
opkg install luci

oshrizak wrote:

alirz wrote:

its not bricked. You need to install "luci" via ssh or via telnet.

opkg update
opkg install luci

How do i do so? sorry im pretty new to openwrt..

Try to clear your browser's cache and reconnect. It shouldn't show index. Either it will load LuCI or 'the page cannot be opened/displayed' message.

@nitroshift
@leitec

Is it really enough to set empty LINUX_VERSION-4.0 = in

/trunk/include/kernel-version.mk

and KERNEL_PATCHVER:=4.0

in /trunk/target/Linux/mvebu/Makefile

to compile the newest kernel version 4.0 or do we need to wait until @Kaloz pushes it to the trunk?

I did the above mentioned and it shows:

Model Linksys WRT1900AC
Firmware Version OpenWrt Chaos Calmer r45447 / LuCI (git-15.102.66001-622cfc6) 
Kernel Version 4.0.0
Local Time Wed Apr 15 18:06:24 2015
Uptime 6h 49m 38s
Load Average 0.00, 0.01, 0.05

P.S. Edited. It's not easy to write messages when driving.

taykiin06 wrote:

Good evening all, having been lurking around a bit trying to take all this information in as I just picked up a 1900ac about a month ago. Currently on CC r45277 and was wanting to sysupgrade but now notice two different build types: 

- openwrt-mvebu-armada-xp-db-squashfs-sysupgrade.tar
- openwrt-mvebu-armada-xp-gp-squashfs-sysupgrade.tar

Can someone explain the differences please and how often most everyone upgrades (ie each time a build is released, a few months etc...)? I'm still learning and got frustrated with the amount of research I was doing just to find an answer about the different sysupgrade options. I've upgraded a few times now, but this is the first time I've seen two different ones. TIA!

The right ones are

- openwrt-mvebu-armada-xp-linksys-mamba-squashfs-factory.img
- openwrt-mvebu-armada-xp-linksys-mamba-squashfs-sysupgrade.tar

Upgrade when you think it is relevant or interesting for you to try and investigate. This is a development project.

If you decide to upgrade please do it via Linksys stock firmware using

- openwrt-mvebu-armada-xp-linksys-mamba-squashfs-factory.img

This is due to some changes made after the build r45400.

nitroshift wrote:

Kaloz wrote:

Warning: changes in trunk will likely require flashing to factory and back, so hold tight.

I can confirm that this *IS* needed.

nitroshift

Anyone got a contact with LinkSys that can put some pressure on them to release the u-boot source? It would be nice if we could back-port some of the more recent changes to support flashing from a usb drive (for example).

Gentlemen,
When are we going to see a public build?

I have been holding off since the McWRT 1.08 way back.

Reverted back to stock currently and contemplating on the newest build from Kaloz...

Thank you!
-JM

leitec wrote:

Right now OpenWrt isn't doing anything with the actual "auto recovery" process, by which I mean it doesn't update the other variables that I think are necessary for that to work properly. I believe the factory firmware updates badcount, boot_part_ready and probably more variables that the "auto_recovery" process then uses to determine if it should boot from the other partition instead. As far as I know Linksys never released the WRT1900AC's u-boot source, so I can't tell what it actually is doing.

Anyone got a contact with LinkSys that can put some pressure on them to release the u-boot source? It would be nice if we could back-port some of the more recent changes to support flashing from a usb drive (for example).

jklap wrote:

Anyone got a contact with LinkSys that can put some pressure on them to release the u-boot source? It would be nice if we could back-port some of the more recent changes to support flashing from a usb drive (for example).

Is u-boot gpl? If it is then shouldn't we "kindly" ask them for the source? Shouldn't they have released the source already?

gufus wrote:

gufus wrote:

Ah

Ya... 4000+ messages in this thread. I don't read every thing

Heh, the thread I mentioned was on a different site entirely.  Found it once I got home, it was on a discussion list for the Linux ARM kernel, thread starts here:

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

So what this did was simply adding another record with boot count(?)=0. Which matches the pattern I see at the start of /dev/mtd2, when I only booted stock firmware.  The boot count there is 1,0,1,0,1,0 etc.

This should be pretty easy to replicate, assuming that the magic number is fixed? And that the assumption that the last number is simply a sum of the first two holds.

I get these errors in my syslog every once in a while, build (45222), searching I didn't find anything.  Is the rx status from another device, or from the router itself?

Tue Apr 14 23:37:35 2015 kern.err kernel: [   51.648696] mvneta f1070000.ethernet eth0: bad rx status 0f850000 (max frame length error), size=1536
Tue Apr 14 23:37:35 2015 kern.err kernel: [   52.157976] mvneta f1070000.ethernet eth0: bad rx status 0f850000 (max frame length error), size=1536

Speaking of syslog, I tried to setup openwrt using a remote syslogd server, and the settings for logd and logreader looked right, but the syslog server never got the messages/logged messages, does this work?  There are some syslog packages, do I need them?

I have syslog working with the stock system (no extra logging sw)
Setting  System->Logging
External system log server 192.168.200.25
External log server port 514
Output log level debug
cron log level normal

I have syslog working with the stock system (no extra logging sw)
....
Hope this helps abit.

Edit: I forgot to add before that the Linksys EA4500 does have published u-boot source, including both Linksys and Marvell's changes. Linksys also uses the dual firmware thing there so you might get some mileage out of reading that source code.

That said, last time I talked to Kaloz about this (months ago) he wasn't too keen on spending time trying to work in a system that isn't all that great at preventing bricking. Getting actual source for u-boot would mean we'd have the ability to chainload a custom u-boot, where you could add real recovery and do away with the dual firmware thing altogether. Such is done on some other targets (kirkwood, for example).

Other boards with u-boot have real recovery mechanisms, like a TFTP or web server you can connect to and upload a working image, rather than banking on the possibility that the second image is working.