This patch will match the clock-latency-ns values in the device tree
for those found inside the OEM device tree and kernel source code and
unlock 896Mhz CPU operating points.
(cherry picked from commit a8a01ea334)
This version fixes two vulnerabilities:
- SM2 Decryption Buffer Overflow (CVE-2021-3711)
Severity: High
- Read buffer overruns processing ASN.1 strings (CVE-2021-3712)
Severity: Medium
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 7119fd32d3)
Backport a patch from upstream U-Boot to fix the compile with host GCC 10.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 8d143784cb)
Backport a patch from upstream U-Boot to fix the compile with host GCC 10.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit a1034afba8)
The bootloader will look for a configuration section named ap.dk01.1-c2
in the FIT image. If this doesn't exist, the device won't boot.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
(cherry picked from commit a43da1be43)
A missing quote in target/linux/ath79/patches-5.x/920-mikrotik-rb4xx.patch
produces:
...
scripts/kconfig/conf --syncconfig Kconfig
drivers/mfd/Kconfig:2016:warning: multi-line strings not supported
...
This patch adds missing closing quote, fixing the above warning.
Signed-off-by: Paul Blazejowski <paulb@blazebox.homeip.net>
(cherry picked from commit f7374bce00)
On the NanoPI R4S it takes an average of 3..5 seconds for the network devices
to appear in '/proc/interrupts'.
Wait up to 10 seconds to ensure that the distribution of the interrupts
really happens.
Signed-off-by: Ronny Kotzschmar <ro.ok@me.com>
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
(cherry picked from commit fd65ce6f32)
Installing headers and static libraries to the target system seems
to be not required for most use cases, so let's factor them
out into a dedicated -dev package.
This cuts down to disk usage to around 50% of the original
package to ~ 2MB - not that disk space is an issue normally,
but when using inside an initramfs only project, it counts.
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
This board is a fork of NanoPi R2S, with the native NIC changed.
Hardware
--------
RockChip RK3328 ARM64 (4 cores)
1GB DDR4 RAM
2x 1000 Base-T
3 LEDs (LAN / WAN / SYS)
1 Button (Reset)
Micro-SD slot
USB 2.0 Port
Installation
------------
Uncompress the OpenWrt sysupgrade and write it to a micro SD card using
dd.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
NR_CPUS limits the number of CPUs supported to 8. This makes total sense
on hardware-restircted platforms, but not on x86_64, where CPUs with
more than 8 cores can be easily acquired and with less physical limitaions.
see also: https://forum.openwrt.org/t/x86-64-8-cpu-limitation-on-vanilla-release/100946
Signed-off-by: Edgar Su <sjs333@outlook.com>
(cherry picked from commit df554e6fca)
When having two keys that start with the same characters and the second
key just has one character more nand_tffs_read and tffs_read return the
wrong value for the longer key. This is due to the usage of strncmp in
combination with the length of the shorter key which is usually first in
the list before the longer key and when strncmp matches, the search is
stopped. The problem only occurs when the length of the two keys is
different, not if just the last character is different. The fix is to
use strcmp and as such it will only return the value if the key (name)
and the key to look for (namefilter) have the same value and length. A
sample case returning wrong values is when keys macwlan and macwlan2 are
defined and querying macwlan2 returns the value for macwlan.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
(cherry picked from commit 12564c5b86)
Based on the discussion on the mailing list [1], the patch which was
reverted, it reverts only one patch without the subsequent ones.
This leads to the SoC scaling issue not using a CPU parent clock, but
it uses DDR clock. This is done for all variants, and it's wrong because
commits (hacks) that were using the DDR clock are no longer in the mainline kernel.
If someone has stability issues on 1.2 GHz, it should not affect all
routers (1 GHz, 800 MHz) and it should be rather consulted with guys, who are trying to
improve the situation in the kernel and not making the situation worse.
There are two solutions in cases of instability:
a) disable cpufreq
b) underclock it up to 1 GHz
This reverts commit 080a0b74e3.
[1] https://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035702.html
CC: Pali Rohár <pali@kernel.org>
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
(cherry picked from commit 7b868fe04a)
