How to build IPQ4018 firmware

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!

More to follow...

It was after lede installation.

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?

Here is a log - sending asus stock firmware when lede is installed - kernel panic.
This time tftp sending was successful
https://pastebin.com/6RMGH11f

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 :expressionless: : (see rt-ac58u.h, ipq40xx_cdp.h and drivers/mtd/flash_wrapper.c etc...)

#define CFG_FACTORY_SIZE                0x10000
#define CFG_NVRAM_SIZE                  0x20000
#define ORIGINAL_HLOS_OFFSET            0x190000

#define CONFIG_SYS_FLASH_BASE   0xC0000000      /* define fake flash address. */
#define CFG_NVRAM_ADDR          (CONFIG_SYS_FLASH_BASE)
#define CFG_FACTORY_ADDR        (CONFIG_SYS_FLASH_BASE + CFG_NVRAM_SIZE)
#define CFG_KERN_ADDR           (CONFIG_SYS_FLASH_BASE + (CFG_NVRAM_SIZE + CFG_FACTORY_SIZE))
#define CFG_KERN2_ADDR          (CONFIG_SYS_FLASH_BASE + (CFG_NVRAM_SIZE + CFG_FACTORY_SIZE + CFG_UBI_FIRMWARE_SIZE))

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.)

Here is a log (restore asus firmware after kernel panic before). Serial cable is used
https://pastebin.com/aSahrtjS

In rescue mode it is a server

## Enter Rescue Mode ##
preferred nic: eth0
eth0 PHY0 up Speed :100 Full duplex
eth0 PHY1 Down Speed :10 Half duplex
eth0 PHY2 Down Speed :10 Half duplex
eth0 PHY3 Down Speed :10 Half duplex
eth0 PHY4 up Speed :1000 Full duplex
switch prereq:0
tftpd start

Our IP address is:(192.168.1.1)
Wait for TFTP request...
tftpd open 

I think there is some misundestending with the Russian tester.

AFAIU - U-Boot creates missing volumes, but does not fix size (or id). From the /flash_wrapper.c

v = get_vol_by_name(ubi, p->name);
              if (v) {
.....
.....
                      continue;
              }

              show++;
....
rcode = do_ubi(NULL, 0, ARRAY_SIZE(ubi_create_vol), ubi_create_vol);

I have written my vision of lede and stock firmwares, flash layout, U-Boot. It is rather long and in Russian - http://forums.zyxmon.org/viewtopic.php?f=6&t=5576

I don't want to make a mistake installing the test builds @zyxmon is kindly providing --

Is stock-to-lede.trx installed first or can the newest ...flash-factory.trx file be used for initial flash from Asus stock?

Do the builds contain Luci? I ask because of an OPKG issue was mentioned.

THANK ALL FOR YOUR HARD WORK! :smile:

No issues with opkg. Luci is included. Syspgrade files are used for upgrading.

How about the initial flash from Asus stock? Because the stock-to-lede.trx file exists, I'm afraid to use a newer ...flash-factory.trx as I said.

Then for update, am I correct that I take the newest ...sysupgrade.tar and flash it from SSH or Telnet?

THANKS

Factory.trx can be used for 2 steps flashing. Stock-to-lede combines both steps and needs double time to wait.

1 Like

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

Hi sorry to ask something stupid.

Is that something related to the ath10k? any problem with that?
Thu Sep 7 12:28:39 2017 kern.warn kernel: [ 1978.708775] ath10k_ahb a800000.wifi: Invalid mcs 15 peer stats
Thu Sep 7 12:28:39 2017 kern.warn kernel: [ 1978.709092] ath10k_ahb a800000.wifi: Invalid mcs 15 peer stats
Thu Sep 7 12:28:40 2017 kern.warn kernel: [ 1979.325021] ath10k_ahb a800000.wifi: Invalid mcs 15 peer stats
Thu Sep 7 12:30:05 2017 kern.warn kernel: [ 2064.432803] ath10k_ahb a000000.wifi: Invalid mcs 15 peer stats

Many thanks!

1 Like

I had two weeks vacation and was far away from my home. I have just returned. I hope I'll release an update in few days.

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". :roll_eyes: (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?

It's part of the install procedure. See Step 3.3:

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.