The MR1750 must unset some bits in ETH_CFG which were set by u-boot to work
correctly under OpenWrt. But the global function
ath79_setup_qca955x_eth_cfg will not unset all of them to increase the
backward compatiblity with older mach-* files. A private (simplified)
version for MR1750 can be used instead.
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
Backport of r49070
The MR900 must unset some bits in ETH_CFG which were set by u-boot to work
correctly under OpenWrt. But the global function
ath79_setup_qca955x_eth_cfg will not unset all of them to increase the
backward compatiblity with older mach-* files. A private (simplified)
version for MR900 can be used instead.
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
Backport of r49069
The delays of PHY/MAC on the MR1750 are done by u-boot and OpenWrt in
different ways. u-boot only modifies the ETH_CFG of the QCA955x based on
the link speed. But OpenWrt can only modify the PHY delays based on the
link speed.
This can lead to communication problems when u-boot initializes the ETH_CFG
for a specific link speed (e.g. 10BASE-T) but then OpenWrt the sets the PHY
delays to an incompatible value.
Instead reset the ETH_CFG delay bits of the QCA955x to a specific value and
only rely on the AT803x PHY settings.
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
Backport of r49031
The delays of PHY/MAC on the MR900 are done by u-boot and OpenWrt in
different ways. u-boot only modifies the ETH_CFG of the QCA955x based on
the link speed. But OpenWrt can only modify the PHY delays based on the
link speed.
This can lead to communication problems when u-boot initializes the ETH_CFG
for a specific link speed (e.g. 10BASE-T) but then OpenWrt the sets the PHY
delays to an incompatible value.
Instead reset the ETH_CFG delay bits of the QCA955x to a specific value and
only rely on the AT803x PHY settings.
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
Backport of r49030
Some OpenWrt based firmwares like Gluon expect that a sysupgrade image
exists when a device firmware can be updated via sysupgrade. This image
wasn't created until now because OpenMesh devices use the same image for
factory and sysupgrade flash. Copying the image from *factory.bin to
*sysupgrade.bin is therefore enough to make the sysupgrade functionality
visible.
Reported-by: Matthias Schiffer <mschiffer@universe-factory.net>
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
This reverts commit 0fd48fd7dab066db8a46e51775579c9ef507ca25.
We are facing some problem on rolling out the current 15.05-branch to
our devices because the image name changed.
The changed image name breaks compatibility for derived projects and
that's something which should only happen if there is a really good
reason (e.g. security fix).
Signed-off-by: Tim Niemeyer <tim@tn-x.org>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49231 3c298f89-4303-0410-b956-a3cf2f4a3e73
Backport of r47914 to CC.
Without this patch the TDW8970 is left without any status LED at all,
even during preinit and failsafe.
Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49230 3c298f89-4303-0410-b956-a3cf2f4a3e73
Backport of r47911, r47912, r47969 to CC.
All other required patches have already been backported in r48822.
Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49229 3c298f89-4303-0410-b956-a3cf2f4a3e73
This patch backports support for the TP-Link TL-WA901ND v4 to Chaos Calmer 15.05.1,
which was added into trunk recently [1].
Signed-off by Stijn Segers <francesco.borromini@inventati.org>
[1]: http://patchwork.ozlabs.org/patch/606780/
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49226 3c298f89-4303-0410-b956-a3cf2f4a3e73
This patch adds support for the TP-Link TL-WR740N v6 to OpenWrt Chaos Calmer. Hardware wise, it's very similar to the TL-WR841N v10. See the forum thread [1]. Credit goes to the user 'traveler' who did the legwork and tested builds.
Also thanks to Matthias Schiffer for clarifying the DEVICE_PROFILE settings.
Signed-off by: Stijn Segers <francesco.borromini@inventati.org>
[1]: https://forum.openwrt.org/viewtopic.php?pid=318704
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49225 3c298f89-4303-0410-b956-a3cf2f4a3e73
Archer C7 V2.0 units from December 2015 onwards ( serials starting 215C
) have changed flash chips to the gd25q128 chip, this is supported in
trunk but not presently in 15.05. I would like stable support for this
version so I've back ported the required fix from trunk and removed a
conflicting patch from bcm53xx I've tested the patch it and I'm able to
install a build of 15.05.1 on a new Archer C7 device with this patch.
Signed-off-by: John Marrett <johnf@zioncluster.ca>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49220 3c298f89-4303-0410-b956-a3cf2f4a3e73
It was already increased for NAND devices so do the same for the ones
with serial memory.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Backport of r49207
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49208 3c298f89-4303-0410-b956-a3cf2f4a3e73
Reconfiguring the UART when the FIFO is not empty may cause the boot to
hang. This hang is extremely suspectible to timing differences; recompiling
the kernel with the same configuration, but different UTS_VERSION
timestamps can yield images that hang more or less often. Sometimes images
are produced that hang reproducibly.
This patch should also make it into one of the next linux-stable releases,
but it's better to get this fixed as soon as possible.
Fixes#21773, #21857.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Backport of r49156
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49202 3c298f89-4303-0410-b956-a3cf2f4a3e73
the fullduplex on CS1 is broken. remove the fullduplex support and run on
plain half duplex on both CS lines.
Signed-off-by: John Crispin <blogic@openwrt.org>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49201 3c298f89-4303-0410-b956-a3cf2f4a3e73
there is a deadlock that triggers under heavy bus load. until the bug is
fxed, revert to an old version of the I2C driver that does not suffer
from this issue.
Signed-off-by: John Crispin <blogic@openwrt.org>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49200 3c298f89-4303-0410-b956-a3cf2f4a3e73
We need to fix Seama just like we fix TRX due to the rootfs mark.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Backport of r48522
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49170 3c298f89-4303-0410-b956-a3cf2f4a3e73
14e4:d612 was found in D-Link DIR-885L and Netgear R8500. It's most
likely a bridge used by all 14e4:4365 BCM4366 devices.
Without this fixup device wasn't treated as a bridge:
[ 2.849895] pci 0000:00:00.0: ignoring class 0x020000 (doesn't match header type 01)
and didn't get its resources assigned. This resulted in child devices
not being able to get any resources (due to the parrent missing them):
[ 3.375428] pci 0000:01:00.0: BAR 2: no space for [mem size 0x00400000 64bit]
[ 3.387949] pci 0000:01:00.0: BAR 2: failed to assign [mem size 0x00400000 64bit]
[ 3.725797] pci 0000:01:00.0: BAR 0: no space for [mem size 0x00008000 64bit]
[ 3.738314] pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00008000 64bit]
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49118 3c298f89-4303-0410-b956-a3cf2f4a3e73
