1. Add support for Marvell CN9130 SoC
2. Add support for CP115,and create an armada-cp11x.dtsi file which will be used to instantiate both CP110 and CP115
3. Add support for AP807/AP807-quad,AP807 is a major component of CN9130 SoC series
4. Drop PCIe I/O ranges from CP11x file and externalize PCIe macros from CP11x file
Signed-off-by: Ian Chang <ianchang@ieiworld.com>
It's been brewing on my cortexa9 subtarget (Turris Omnia) for months.
Perfectly stable.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
[modify subject to match previous updates]
Signed-off-by: Paul Spooren <mail@aparcar.org>
CONFIG_RCU_{NEED_SEGCBLIST,STALL_COMMON} are set basically everywhere. Move them
to the generic kconfigs. And resort the generic kconfigs while at it.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
While an image layout based on MBR and 'bootfs' partition may be easy
to understand for users who are very used to the IBM PC and always have
the option to access the SD card outside of the device (and hence don't
really depend on other recovery methods or dual-boot), in my opinion
it's a dead end for many desirable features on embedded systems,
especially when managed remotely (and hence without an easy option to
access the SD card using another device in case things go wrong, for
example).
Let me explain:
* using a MSDOS/VFAT filesystem to store kernel(s) is problematic, as a
single corruption of the bootfs can render the system into a state
that it no longer boots at all. This makes dual-boot useless, or at
least very tedious to setup with then 2 independent boot partitions
to avoid the single point of failure on a "hot" block (the FAT index
of the boot partition, written every time a file is changed in
bootfs). And well: most targets even store the bootloader environment
in a file in that very same FAT filesystem, hence it cannot be used
to script a reliable dual-boot method (as loading the environment
itself will already fail if the filesystem is corrupted).
* loading the kernel uImage from bootfs and using rootfs inside an
additional partition means the bootloader can only validate the
kernel -- if rootfs is broken or corrupted, this can lead to a reboot
loop, which is often a quite costly thing to happen in terms of
hardware lifetime.
* imitating MBR-boot behavior with a FAT-formatted bootfs partition
(like IBM PC in the 80s and 90s) is just one of many choices on
embedded targets. There are much better options with modern U-Boot
(which is what we use and build from source for all targets booting
off SD cards), see examples in mediatek/mt7622 and mediatek/mt7623.
Hence rename the 'sdcard' feature to 'legacy-sdcard', and prefix
functions with 'legacy_sdcard_' instead of 'sdcard_'.
Tested-by: Stijn Tintel <stijn@linux-ipv6.be>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This patch is backported from linux-arm-kernel [1] to improve situation, when
it was reported that 1.2 GHz variant is unstable with DFS.
It waits to be accepted upstream, however, it waits for Marvell people to respond.
[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210630225601.6372-1-kabel@kernel.org/
Fixes: 7b868fe04a ("Revert "mvebu: 5.4 fix DVFS caused random boot crashes"")
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
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
Fixes: d379476817 ("mvebu: armada-37xx: add patch to forbid cpufreq for 1.2 GHz")
CC: Pali Rohár <pali@kernel.org>
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
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>
Follow the recommendations stated in the Turris Omnia DTS for eth2:
"In case SFP module is present, U-Boot has to enable the sfp node above,
remove phy-handle property, and add managed = "in-band-status" property."
The boot script is written in a way, that it works for all U-Boot
versions deployed by the vendor so far (2015.10-rc2, 2019.07).
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Kernel 5.4 receives a reduced set, just to make the SFP cage work.
While we are at it, move the patches accepted upstream to the 0xx series.
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Kernel 5.10 receives the complete set of improvements from 5.11/5.12.
While we are at it, move the patches accepted upstream to the 0xx series.
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Now that we have a generic sdcard upgrade method, which was copied from
the mvebu platform method, we can switch mvebu to the generic method.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
This patch has been carried since introduction throughout every kernel
major bump and no one has tested if the later kernels improved the
situation. The Armada 3720 SoC can only process GbE interrupts on Core 0
and this is already limited in all stable kernels, so ditch this
workaround for 64 bit SoCs.
Ref: https://git.kernel.org/torvalds/c/cf9bf871280d
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Define nvmem-cells and convert mtd-mac-address to nvmem implementation.
The conversion is done with an automated script.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
This patch has been added with initial support for ESPRESSObin board and
mistakenly it affects all boards with this SoC. Drop this patch since
the aliases are now in upstream dts for ESPRESSObin. If any boards are
relying on this, please add the respective alias to that board dts.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Many people appear to use an unneeded "+" prefix for the increment
when calculating a MAC address with macaddr_add. Since this is not
required and used inconsistently [*], just remove it.
[*] As a funny side-fact, copy-pasting has led to almost all
hotplug.d files using the "+", while nearly all of the
02_network files are not using it.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The CLK125 output pin at the ethernet PHY is connected via capacitor to
GND and nowhere else. Disable it. Also tune the LED masks.
The MPP56 and MPP60 pins at the SoC are conected to the μPD720202 USB3.0
chip:
- MPP56: wired to PCIe CLKREQ# (out)
- MPP60: wired to PCIe RESET# (in)
Configure the pcie pinmux for these pins.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
Some targets select HZ=100, others HZ=250. There's no reason to select a higher
timer frequency (and 100 Hz are available in every architecture), so change all
targets to 100 Hz.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
For the targets which enable ubifs, these symbols are already part of the
generic kconfigs. Drop them from the target kconfigs.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
The GL.iNet GL-MV1000 is booting from eMMC and the images for it are in
theory sysupgrade compatible. But the platform upgrade scripts were not
adjusted to select the mmcblock device as upgrade target. This resulted in
a failed sysupgrade because the mtd device (NOR flash) was instead tried to
be modified by the sysupgrade script.
Fixes: 050c24f05c ("mvebu: add support for GL.iNet GL-MV1000")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The crypto engine in Armada 370 SoCs is currently broken. It can be
checked installing the required packages for testing openssl with hw
acceleration:
opkg install openssl-util
opkg install kmod-cryptodev
opkg install libopenssl-devcrypto
After configuring /etc/ssl/openssl.cnf to let openssl use the crypto
engine for digest operations, and performing some checksums..
md5sum 10M-file.bin
openssl md5 10M-file.bin
...we can see they don't match.
There might be an alignment or size constraint issue caused by the
idle-sram area.
Use the whole crypto sram and disable the idle-sram area to fix it. Also
disable the idle support by adding the broken-idle property to prevent
accessing the disabled idle-sram.
We don't care about disabling the idle support since it is already broken
in Armada 370 causing a huge performance loss because it disables
permanently the L2 cache. This was reported in the Openwrt forum and
elsewhere by Debian users with different board models.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
Ran update_kernel.sh in a fresh clone without any existing toolchains.
Removed upstreamed:
mvebu/patches-5.4/319-ARM-dts-turris-omnia-configure-LED-2--INTn-pin-as-interrupt-pin.patch
Build system : x86_64
Build-tested : ipq806x/R7800
Run-tested : ipq806x/R7800
No dmesg regressions, everything functional
Signed-off-by: John Audia <graysky@archlinux.us>
