[quote="Spots, post:95, topic:316"]
I tried to install it through putty with the command sysupgrade -n -F. This results in a bootloop.[/quote]
Sure. In most devices you can't install the OEM image via sysupgrade. That holds true to R7800, too. (The few devices where you can do that (like wrt1900ac series), are exceptions,)
[quote="Spots, post:95, topic:316"]
I could fix the bootloop by flashing LEDE over TFTP, but the stock one breaks at 75% everytime.
[/quote]Sounds strange as the the whole TFTP functionality is in the OEM bootloader (u-boot) that is not modified by LEDE or Openwrt. LEDE (or Openwrt) firmware has no role in the TFTP recovery flash. So, OEM firmware images should be compatible with OEM TFTP flash routine...
Yes. The changes are pretty much about tweaking some LEDs, config settings etc. to match R7800 better. Full diffs are available in the download directory as patch files, just like I say on the first message of this thread:
Hi,your build Firmware for R7800 is very good,but when I command line 'opkg install iptables-mod-tproxy',install fail,do you know what is happen,how can I fix it to install?Thank you!
Like I already answered to your private message, you can't install kernel-related packages into private builds. There is a strict kernel options checksum check in order to prevent installing modules compiled with different kernel options, and possibly bricking the device.
@hnyman, I have noticed that you are using f_codel/simple.qos for your build and not cake. I am seeing latency issues with cake, but f_codel is even a bit worse. And I am not using your build, but might try.
Yes. I generally leave all packages to their default settings, except that I correct a few hardware-specific things like e.g. the default interface for SQM.
SQM has HTB+fq_codel / simple as its default, so I leave it for that. Each user can then configure himself which qdisc he wants to use. Both HTB+fq_codel and cake are currently included by default in SQM, so it is only about toggling a config parameter in /etc/config/sqm
I give advice about that in the first message of this thread:
The main reason for the weak "simple" performance with HTB+fq_codel seems actually to be HTB, not fq_codel itself. It is also possible to use "simplest_tbf" that avoids HTB by using TBF but still normally uses fq_codel. That simplest_tbf performed much better than simple (at least with kernel 4.4).
Thx, I will take a closer look at those links. In the meantime, your build includes irqbalance and I cannot find it in the standard LEDE to install. Am I doing it wrong?
If I install your build, will I be able to install other packages like samba, etc? I read that it I not possible with custom builds and went with the plain vanilla 17.01.1.
Well, maybe I should backport the package to the official 17.01 branch so that the 17.01 release buildbot could build it. Generally new stuff is not backported to already existing stable branches, but I have been compiling it myself for 17.01 for several months now, without problems.
If you install my firmware, you should be able to install most normal apps. But in general you can't install new kernel modules. (I haven't tested samba, but I do not see any kernel dependencies in its Makefile so I guess you could install it.)
EDIT2:
I backported the irqbalance package to the 17.01 packages feed repo. Buildbot should build it in a day. Then it should be available with opkg also in 17.01.
No, I have not needed it myself, so I have not included it, yet. But I have several times considered adding it to the default build.
Note that my build includes kmod-tun, which is the only kernel dependency for OpenVPN, so it should be possible to install OpenVPN (the openvpn-openssl variant).
Thanks for the information regarding the VPN client. When I unbox my newly arrived R7800 tomorrow I'll see what I can do. Not that bright though at things like that.
I was a little surprised to read that it doesn't contain the OpenVPN client as the router, being a dual core 1.7Ghz powered device, is going to be very capable of doing so and chosen by those who see its value in being used in that way.
There is no major reason to include it by default, as those who want it can easily install by themselves with opkg.
If I would try to include all possible "interesting" packages in my build, the size would grow quite much. LEDE has well over 1000 packages, so picking even the top 5% of packages would be over 50 packages.
But I try to include the necessary kernel modules in the build, so that most insteresting packages can be installed afterwards easily. kmod-tun is there mostly for possible openvpn needs (or aiccu, or other tunnel softwares).
But yeah, openvpn is a major app and something that might get included at some point.
@hnyman, I just pulled irqbalance, but I have not noticed any difference as per below. Do I need to do anything to activate it?
EDIT: Yes, I do have to run it and I am seeing it works. Do I still need to also move eth0/1 to CPU1 as per some suggestions in the other R7800 thread?
EDIT2: Does not look like I need to worry about eth0/1: irqbalance seems to be doing its job now. Thx for porting it.
[quote="fantom-x, post:115, topic:316"]
Any change your collectd-mod-cpufreq plug-in can be back-ported also?
[/quote]Thanks for raising this question. You found a bug
The plugin should actually be available in the 17.01 branch. I build it for my own build from the normal github source repo without modification for both 17.01 aand master. However, for some reason it seems to be missing from the release download repo. It can be found e.g. in mvebu and x64 downloads for 17.01. Interesting.
I notice that it is also missing for master snapshots for ipq806x (arm_cortex-a15_neon-vfpv4). Very interesting.
@jow
Could this possible be due to the two-phase buildbot thing? collectd-mod-cpufreq is enabled only for x64, mvebu and ipq806x targets.
I realised a few days ago that arm_cortex-a15_neon-vfpv4 (used by ipq806x) apparently uses armvirt SDK in buildbot phase2 instead of ipq806x SDK. That is probably the reason why the plugin is not compiled for arm_cortex-a15_neon-vfpv4, as the SDK thinks that it is armvirt, not ipq806x.
This two-step buildbot build process can apparently cause sneaky errors