How to build IPQ4018 firmware

Hi all

Does this works with rbr50/rbs50? I have and orbi kit that I could use to test: can you help me doing so?

@chunkeey - there are conflicts in 4 files in your repo after the last merge with lede trunk.

I have made a fork (combined chunkeey & lede trunk) here

Firmwares do work on rt-ac58u. There are still two problems

  1. trx image is not always built correctly. (itb is ok and can be used with uart console)
  2. make always fails, but running it second time gives correct sysupgrade firmware.

I hope I'll fix (1). It would be difficat to fix (2).
sysupgrade's are temporary uploaded here - http://ziniz.zyxmon.org/test/

1 Like

Hey, great! that's the spirit! :+1:

But I'm not sure about the conflicts you mentioned. What I think that has happend is, that you simply use "git pull" from https://github.com/chunkeey/LEDE-IPQ40XX/tree/staging into your own branch? Is this correct?

If so, please watch out, that this is a staging repository. So, the patches there get rebased every so often and if you had pulled an older version of a patch into your "master" repository, this can easily cause the clashes you are getting now.

As for 1) 2). See my previous comment:

So, unless someone comes up with a new way to make a factory image that is compatible with the way ipq806x is setup. There's no point in wasting any time/effort for this. Because this will not get merged into LEDE the way it is.

Not exactly. But now I see the issue. Thanks. I have not noticed the staging branch. Now I'll merge it in "my repo". I do not think there is much difference with yours in fact.

@chunkeey - just FYI. There are about two dozens users using lede on asus rt-ac58u based on your repo.
More info (Russian) here - http://4pda.ru/forum/index.php?showtopic=790326&st=300#entry62828141

No serious problems were found so far....

1 Like

Thanks for letting me know. I do appreciate it, that you are trying to provide images for the router. If you are looking for a few more international users, you could make a thread in the Community Builds, Projects & Packages section about the RT-AC58U/RT-ACRH13.

As for the other forum. I read to some of the messages (via translate). I saw a comments about the longevity of the components and stuff. From my experience, the 128MiB SPINAND could be the first thing to fail. In a way, ASUS accounted for this, by having a redundant kernel+rootfs partition (linux1 and linux2). But sadly, the rootfs_data (which stores config) does not have a spare area. So, only time will tell.

As for current issues: the Qualcomm' provided ath10k-firmware: firmware-5.bin_10.4-3.4-00082 isn't as stable/robust as the older firmware-5.bin_10.4-3.2.1-00053. It looks like this is more of a problem for the QCA9984 with a IPQ806X (R7800 and friends) but so far, nobody tested that. Instead they are blaming it on the RX ring memory reduction patches. :smirk:

Because those patches stink :mask: :slight_smile:
I've tested all firmware branches including 1st release, there has been no difference or whatsoever in capped 2.4ghz wireless performance, probably caused by the same issue

I own MediaTek MT7621AT router with 128MiB NAND Flash (SLC NAND - Spansion) for about two years (this is a special ZyXEL model for Russia) now. No problems up to now and never heard about nand problems on this model. Uboot code can be fitted on a single nand block and is dublicated AFAIK.
Thanks for the info about ath10k-firmware. I'll switch back to it (it is used in lede trunk). I do not use 2.4Ghz wifi.

1 Like

Well:

"You might be interested to test reverting the ath10k buffer reduction that was done in March in master. That might help with performance issues.

The background is that the ath10k buffer size reduction was introduced a bit sneakily into ipq806x with a commit improving support for QCA4019. (The commit title talks about QCA4019 but does not mention that ath10k buffers get reduced for all chips):
https://git.lede-project.org/?p=source.git;a=commit;h=cc189c0b7fa015978b04bb663a75b1da726376b56

I tried to initiate discussion about that action later, but that got no traction as there was no real proof that the buffer reduction caused harm in a significant way. If there would be proof, the action might hopefully be retracted."

"I couldn't wait, so I tested it just now. Bad news though, performance on wifi is still abysmal."

Thing is, this wasn't the first time. It comes up again and again, if 2.4G acts up on the R7800.
As for the IPQ4019, In my observations, the firmware-5.bin_10.4-3.4-00082 isn't as stable/robust as the older firmware-5.bin_10.4-3.2.1-00053. So maybe the same is true for the QCA9984, you could ask people that have a problem with the 2.4GHz stability to try the older firmware. But YMMV.

No matter what, for me it's a fact that on the R7800 wifi is unusable in master, which is annoying. A patch to revert to the older driver (and firmware blob) would actually have been nice. But it is perhaps a lot of work?

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?