Just download https://github.com/kvalo/ath10k-firmware/blob/master/QCA9984/hw1.0/firmware-5.bin_10.4-3.2-00072
And replace /lib/firmware/ath10k/qca9984/hw1.0/firmware-5.bin manually
@chunkeey - https://github.com/LEDE-RT-AC58U/LEDE_RT-AC58U/blob/master/target/linux/ipq806x/image/Makefile#L298
Parallel builds should be disabled at the image building stage. This (.NOTPARALLEL:) fixes problem (2) for me. All previous stages can use parallel jobs.
As for (1) - it looks like some dependency is missing in lede trunk packages.
So it is enough to just replace the firmware blob? Nothing else needs to change? If so, I'll probably test that and see if it makes wifi useable also in master.
Thats enough to change radio firmware itself to test
Well, there's also the custom board-2.bin. From what I know, the R7800 currently uses the board-2.bin that came with the ath10k-firmware. However, these calibration values will only work if the vendor sticked with the reference design. If Netgear switched to a different PA/LNA Chip or went with a different RF Layout; The device will still sort of work, but poorly.
For example, the RT-AC58U had this very problem. The board-2.bin provided by the ath10k-firmware repository did totally destroy the 5GHz performance (it was like 6Mbps in the same room). However, the same board-2.bin values work fine for the FB4040 (Both the RT-AC58U and the FB4040 have the same bmi-id - so the bmi-id alone is useless).
There's a fix in ath.git that may have smth to do with rx ring buffer crashes
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=f35a7f91f66af528b3ee1921de16bea31d347ab0
We're testing it ATM
edit: oh and btw, I've tested board bins from OEM gpl, it made close to no difference
Can you give some more details - why we need two stage lede installation on Asus RT-AC58U? Can a one stage image be created?
dullish from 4pda.ru created a trx that contains sysupgrade.tar and installs it. But this is not a good aproach IMHO.
BTW. As reported by some users on Russian forum going back from lede to stock is not that easy.
(1) if asus trx firmware is flashed using uart cable - kernel starts to boot and never finishes.
(2) recovery mode (with the help of reset button) does not work. TFTP daemon is started but does not receive firmware.
(3) one can flash some junk in lede with sysupgrade -f - after it (1) and (2) work.
(1)-(3) is not my own experience.... I am waiting for "an expert" to solder pins to router to use uart cable. I am not good in soldering.
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 
: (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! 
No issues with opkg. Luci is included. Syspgrade files are used for upgrading.