Well, let's try to answer this first. Since some of the "details" are right here:
(1) Was this before or after a install? And at which stage? LEDE sysupgrade implementation does delete the existing rootfs and kernel partitions in order to replace them. This has the side-effect that the linux1 (=fit-kernel) partition shrinks. The original image will not fit in it anymore. It would be great if the sysupgrade code could be modified to keep the original size. However, you would loose a 44 MiB of usable flash storage space. (From what I remember ASUS' original flash layout allocates ~50MiB for the combined fit+rootfs images in linux1 and the backup in linux2.)
(2) I know about it already. And I have added a note in the (original - well very early?) git commit:
"U-Boot Note: The ethernet driver isn't always reliable and can sometime time out... Don't worry, just retry."
This is because, I too have a switch (SMC EZSwitch 8508T - I think it's a vitesse based chip - it has a big heatsink that I don't want to remove) that isn't co-operating. It constantly switches between 100/1000 FDX/HDX. However, it works as expected with a Netgear GS105 and a ALLNet 8894WMP. So the best option is to try it on different HW. Note: The SMC switch only has problems with the u-boot driver. It's working fine with the ASUS Stock firmware or LEDE.
As for (3): I know that the sysupgrade.tar will fail to upgrade, if it tries to update from the alpha/4.8/4.9-ipq40xx-target branch to the current ipq806x. Was this the case, or was it between one of the releases on the russian board? I can't say much more without the details but sysupgrade -f actually is dangerous!
In some (for some nics) ethernet is up, but there are no pings. In the case there is ping - but tftp send timeouts with no messages in serial console.
What is the correct procedure to restore asus firmware from lede - do you have any suggestions. Without serial cable? With the cable. Can sysupgrade -f purge the bootloader in mtd0 or uboot?
As I said, ASUS' added code to their u-boot in order to implement the redundant system partition copy-over feature. This is implemented in the do_bootm() in common/cmd_bootm.c:
...
if (bootm_start(cmdtp, flag, argc, argv)) {
#if defined(ASUS_PRODUCT) && defined(CONFIG_DUAL_TRX)
char buf2[30];
char *new_argv[2]={NULL, buf2};
sprintf(buf2, "0x%X#config@1", CFG_KERN2_ADDR);
if (bootm_start(cmdtp, flag, 2, new_argv))
return 1;
/* copy linux2 to linux1 */
printf("Copy firmware from %x to %x, length %x\n", CFG_KERN2_ADDR, CFG_KERN_ADDR, images.fit_total_len);
ra_flash_erase_write(images.os.start, CFG_KERN_ADDR, images.fit_total_len, 0);
#else
return 1;
#endif
}
#if defined(ASUS_PRODUCT) && defined(CONFIG_DUAL_TRX)
else {
/* check linux2 & copy linux1 to linux2 if neccessary */
ulong img_len;
img_len=asus_get_fitimg_size(CFG_KERN2_ADDR);
if ((!img_len) || (img_len != images.fit_total_len)) {
printf("Copy firmware from %x to %x, length %x\n", CFG_KERN_ADDR, CFG_KERN2_ADDR, images.fit_total_len);
ra_flash_erase_write(images.os.start, CFG_KERN2_ADDR, images.fit_total_len, 0);
}
}
#endif
What's really great about this code is that CFG_KERN2_ADDR and CFG_KERN_ADDR are a bunch of "fixed" offsets in the ubi-partition : (see rt-ac58u.h, ipq40xx_cdp.h and drivers/mtd/flash_wrapper.c etc...)
4all
This log fragment illustrates it. sysupgrade -f was the reason
RT-AC58U bootloader version: 1.0.0.3
MAC Address: 70:4D:7B:11:xx:xx
Read 0x40 bytes from volume [linux] offset 0x0 to 84000000
No valid 1st firmware found at 0x0009b000
ERROR: can't get kernel image!
Read 0x40 bytes from volume [linux2] offset 0x0 to 84000000
FIT/FDT format image found at 0x84000000, size 0x001f920c
Read 0x1f924c bytes from volume [linux2] offset 0x0 to 84000000
## Booting kernel from FIT Image at 84000000 ...
Using 'config@1' configuration
Trying 'kernel@1' kernel subimage
Description: ARM OpenWrt Linux-4.9.44
Type: Kernel Image
Compression: lzma compressed
Data Start: 0x840000e4
Data Size: 2034189 Bytes = 1.9 MiB
Architecture: ARM
OS: Linux
Load Address: 0x80208000
Entry Point: 0x80208000
Hash algo: crc32
Hash value: 43c0f0e0
Hash algo: sha1
Hash value: b8ea15b840eb932ec2d04ec307cf57476fc308a1
## Flattened Device Tree from FIT Image at 84000000
Using 'config@1' configuration
Trying 'fdt@1' FDT blob subimage
Description: ARM OpenWrt RT-AC58U device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x841f0c28
Data Size: 33533 Bytes = 32.7 KiB
Architecture: ARM
Hash algo: crc32
Hash value: b476afd2
Hash algo: sha1
Hash value: cc22d7af564762622cf31674b82c8f57b98e8dd8
Booting using the fdt blob at 0x841f0c28
Copy firmware from c30ae000 to c009b000, length 1f924c
0x1f924c bytes written to volume linux
Uncompressing Kernel Image ... OK
Loading Device Tree to 86ed4000, end 86edf2fc ... OK
Using machid 0x8010100 from environment
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.9.44 (papa@jessie) (gcc version 5.4.0 (LEDE GCC 5.4.0 r27-1c8f7e0) ) #0 SMP Sat Aug 19 14:53:24 2017
... tftp sends timeouts? That sounds like the person is trying to use the tftp-(client) to upload a firmware to it.
Can you verify that? If so, point the user to the git commit. He(or she) has to setup another PC on the network
to be a tftp SERVER. The router is the client.
Something like:
Get a cable and boot the initramfs image. Once you have a prompt/shell: fix the ubi layout.: delete linux partition and recreate it with the correct size. Once this is done, u-boot's " 2: Load System code then write to Flash via TFTP." option will work again.
EDIT:
The bootloader partition is set to read-only in the device-tree definition. So even if sysupgrade is running wild, it will not be able to touch it normally. you have to try really hard to overwrite it. (it's possible though to remove the read-only flag by loading a kernel module: see Writable u-boot partition (Ralink MT7268 Soc) - #4 by drbrains for example.)
Are there still builds being made for these? Haven't seen an update in niz.zyxmon.org/test/ page in almost 2 weeks and it hasn't been added to the builts in the IPQ806x folder. THANKS
Yes, this is a known bug that has been fixed a while back:
So yeah, Qualcomm Atheros never tested their wave-2 11ac products with any 2x2:2 11n clients on their "upstreamed linux driver". (Their other QSDK driver is fine however).
Apart from the noisy warnings this is mostly harmless.
I back home from vocation. The latest firmware for asus rt-ac58u will be always here - http://lede-ac58u.zyxmon.org/firmware/
Core lede repo is replaced with http://lede-ac58u.zyxmon.org/packages/ that has 200+ kmod packages and --force-depends is not needed. More kmod packages will be added on requests.
@chunkeey - I have not found where jffs2 ubi volume from factory firmware is deleted. It is a liitle bit special. It is defined with the size bigger, that is left on flash (uboot code)
#define CFG_UBI_APP_NR_LEB 219 /* 124KB x 219 = 27.37MB. This volume size cannot reach requested size due to UBI's overhead. */
It is really created with b5 (181) lebs, not 219. Can you give me the key how jffs2 volume is deleted when lede is installed?
3. Connect to the intermediate/temporary LEDE installation
[...]
3 delete the "jffs2" ubi partition to make room for your new root partition
# ubirmvol /dev/ubi0 --name=jffs2
It could that dullish put this into his install script.