Timo Schroeder reported:
"The TP-Link Archer VR2600v is stuck in a boot loop on written
snapshot image. It's able to boot using the snapshot uimage
though, but there ath10k firmware can't be found.
21.02.2 release version doesn't have either problem."
The VR2600v has a 512 byte header at the beginning of the
firmware that needs to be accounted for.
Fixes: f6a01d7f5c3d ("ipq806x: convert TP-Link Archer VR2600v to denx,uimage")
Reported-by: Timo Schroeder <der.timosch@gmail.com>
References: <https://github.com/openwrt/openwrt/issues/9467>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
This device still had the legacy flash partitioning.
This is a problem, because neither the nvmem-cells
for mac-address and calibration. Nor the denx,uimage
mtd-splitter compatible would be picked up.
The patch also changes the node-names of the flash
and partition nodes to hopefully meet all the
current FDT trends.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
The recent device-tree modification that added pre-cal
nvmem-cells pushed the device's kernel+dtb over the
allotted 3072k KERNEL_SIZE.
> WARNING: Image file tplink_vr2600v-uImage is too big: 3147214 > 3145728
There was a previous kernel partition size upgrade:
commit 0c967d92b3d9 ("ipq806x: increase kernel partition size for the TP-Link Archer VR2600v")
It has been seemingly upgraded from a 2048k KERNEL_SIZE in the past.
The commit talks about using the MTD_SPLIT_TPLINK_FW. But looking at
the image make recipe, there is no code that adds a TPLINK header.
So instead the board will use "denx,umimage". This requires
MTD_SPLIT_UIMAGE_FW, but this is present thanks to some NEC devices.
(Maybe the MTD_CONFIG_ARGS can be removed as well? But it could be
there because of the padding at the beginning. This needs testing.)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
converts extraction entries from 11-ath10k-caldata into
nvmem-cells in the individual board's device-tree file.
The patch also moves previously existing referenced
nvmem-cells data nodes which were placed at the end
back into the partitions node. As well as removing
some duplicated properties from qcom-ipq8065-xr500.dts's
art (the included nighthawk.dtsi defines those already).
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Commit d284e6ef0f06 ("treewide: convert mtd-mac-address-increment* to
generic implementation") renamed "mtd-mac-address-increment" property
to "mac-address-increment". Convert remaining usages that have been
added after that.
Fixes: f44e933458b1 ("ipq806x: provide WiFI mac-addresses from dts")
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
Use nvmem framework for supported mac-address stored
in nvmem cells and drop mac patch function for hotplug
script for supported devices.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
[rebase, move to correct node for d7800, include xr500]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
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>
Rework patch 681-NET-add-mtd-mac-address-support to implement
only the function to read the mac-address from mtd.
Generalize mtd-mac-address-increment function so it can be applied
to any source of of_get_mac_address.
Rename any mtd-mac-address-increment to mac-address-increment.
Rename any mtd-mac-address-increment-byte to mac-address-increment-byte.
This should make simplify the conversion of target to nvmem implementation.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
wakeup-source is required for gpio keys to fix error
genirq: irq_chip msmgpio did not update eff. affinity mask
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
The target uses 5.4 as default kernel since 04/2020.
Kernel 4.19 support is not really maintained anymore, and there has
been a lot of changes between 4.19 and 5.4 on this target. Despite,
new devices are typically added for 5.4 only anyway.
Thus, make maintaining of old stuff and reviewing of new stuff
easier by removing support for kernel 4.19.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Remove the wifi5g LED from the the d7800, r7500 and r7800. Albeit this
GPIO is mentioned in the GPL tarball, it doesn't do anything. The
2.4/5 GHz LEDs are connected to the wifi chips and not be controlled
from the the userspace.
Use the LEDs names/colours as they are used in the board manuals. Merge
redundant LED configurations. Use the phy[0|1]tpt trigger for the
wireless LEDs. Remove the workarounds for the not controllable wireless
LEDs.
Fix spi compatible strings and remove superfluous spi-max-frequency
parameters.
If there are two power leds, use one for indicating normal operation and
one for failsafe/upgrade. Keep the on/off state of the main power led
during boot.
Use the usb pinmux settings from the nbg6817 gpl sources.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Set the pinmux to the values found in the GPL tarballs of the boards.
Remove pinmux which are is not used (like nand pinmux for spi
flash boards).
This allows to use the wan orange led of the C2600 which had a wrong
pinmux before. Might fix buttons or leds of other boards as well.
Fix the LED color and the ledswitch key code of the C2600. Rename the
ledgnr to ledswitch.
Add support for indication the boot state using LEDs to the D7800,
NBG6817, R7500 and R7500v2.
Change GPIO active to readable values in D7800, EA8500, R7500,
R7500v2 and R7800.
Change gpioexport to gpio pinmux.
Add proper "drive strenght" to i2c4_pins and use it for RPM on
C2600, D7800, EA8500, R7500, R7500v2.
Remove pcie pinmux from D7800.
Move pinctrl to correct place in NBG6817 and R7800.
Signed-off-by: Henryk Heisig <hyniu@o2.pl>
This router is similar to the C2600. Ethernet on WAN + LAN, switch,
sysupgrade, LEDs, buttons and WiFi on 2G + 5G do work. The xDSL modem
and the POTS/DECT interface are not supported yet.
It is not possible to flash LEDE via the TP-Link webinterface. The
image need to be signed. The first 0x200 bytes of the image is the
TP-Link header including the signature. The signature is not validated
by the bootloader. The LEDE image is zeroed in this area.
To install LEDE it is necessary to solder a four pin header to JP2.
Connect a serial interface to this header and interrupt the autostart
of kernel. Transfer the sysupgrade image via TFTP and write it to the
serial flash at 0x320000.
Signed-off-by: Sebastian Quilitz <zeraphim@x-pantion.de>
