This device seems to have switch port 7 connected to the CPU:
vlan1ports=1 2 3 5 7*
vlan2ports=0 7u
it should be handled by eth1 and NVRAM seems to confirm that (no
et0macaddr entry, existing et1macaddr & et1phyaddr entries).
One of the remaining ports (4/8?) may be connected to the Quantenna SoC.
Original firmware boot log contains following messages:
(0x00,0x5d)Port 5 States Override: 0xfb
(0x00,0x5f)Port 7 States Override: 0xfb
(0x00,0x0e)Port 8 States Override: 0x0a
(why does it force port 5 state?!)
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45692
It has 3 Ethernet interfaces, each of them connected to separated switch
port. Default NVRAM uses switch port 8 as CPU which is connected to the
3rd interface (eth2).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45681
This chipset has at least 8 usable ports, e.g. Netgear R8000 has ports
5, 7 and 8 connected to Ethernet interfaces:
vlan1ports=0 1 2 3 5 7 8*
vlan2ports=4 8u
Port 6 seems to be always disabled.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 45676
Since the kernel/rootfs split handling was modified 2 years ago by r37283 (
https://dev.openwrt.org/changeset/37283 ) and by the subsequent checkins,
users have seen rather scary mtd errors in the log at every boot. The message
ends "-- forcing read-only", which looks a bit error-like. That error has
been mentioned in some forum threads, when users have noticed this message
instead of some actual error.
[ 2.940000] 0x000000070000-0x000000ff0000 : "firmware"
[ 2.970000] 2 netgear-fw partitions found on MTD device firmware
[ 2.970000] 0x000000070000-0x000000188440 : "kernel"
[ 2.980000] mtd: partition "kernel" must either start or end on erase
block boundary or be smaller than an erase block -- forcing read-only
[ 2.990000] 0x000000188440-0x000000ff0000 : "rootfs"
The patch removes the rather useless warning message.
signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
SVN-Revision: 45669
This change adds PCIe support to IPQ806x based platforms. The driver is
actually cherry-picked from the following LKML thread:
*https://lwn.net/Articles/643086/ (patches 110-111)
We also add here an additional fix to support multiple PCI controllers
on the same platform (patch 112), and to patch the ap148 & dbs149 DTS
files (patch 113).
Signed-off-by: Mathieu Olivari <mathieu@codeaurora.org>
SVN-Revision: 45663
This change enable zImage+appended dtb support in ipq806x kernel
options. The zImage will now be generated as part of the kernel
binaries. Platforms which do not have DT support enabled in U-boot
can now make use of it by generating zImage files and appending dtb
to it.
It is not used yet but it is done as a stepping stone for early IPQ806x
platforms, which did not include DT support in U-boot.
Signed-off-by: Mathieu Olivari <mathieu@codeaurora.org>
SVN-Revision: 45662
ARCH_QCOM is using the ARCH_MULTIPLATFORM option, as now recommended
on most ARM architectures. This automatically calculate ZRELADDR by
masking PHYS_OFFSET with 0xf8000000.
On IPQ806x though, the first ~20MB of RAM is reserved for the hardware.
In newer bootloader, when DT is used, this is not a problem, we just
reserve this memory in the device tree. But if the bootloader doesn't
have DT support, then ATAGS have to be used. In this case, the ARM
decompressor will position the kernel in this low mem, which will not be
in the RAM section mapped by the bootloader, which means the kernel will
freeze in the middle of the boot process trying to map the memory.
As a work around, this patch allows disabling AUTO_ZRELADDR when
ARCH_QCOM is selected. It makes the zImage usage possible on bootloaders
which don't support device-tree, which is the case on certain early
IPQ806x based designs.
Signed-off-by: Mathieu Olivari <mathieu@codeaurora.org>
SVN-Revision: 45661
This option has been added in kernel 3.17. It shows-up only when both
ARCH_QCOM and CRYPTO are enabled. So we'll disable these two by default
to avoid stalling the build when these conditions are met.
Signed-off-by: Mathieu Olivari <mathieu@codeaurora.org>
SVN-Revision: 45658
There are 2 images missing: TLWR2543 TLWR1043V2 which have special properties.
v2: set correct DEVICE_PROFILES for all images.
v2: migrate TP-LINK TL-WR710N v2 which was committed after v1.
v2: split very very long line `TARGET_DEVICES +=` into smaller parts
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
SVN-Revision: 45643
Users will now be provided with the inherent wifi toggle functionality
of /etc/rc.button/rfkill
Signed-off-by: Michael J. Bazzinotti <mbazzinotti@gmail.com>
SVN-Revision: 45635
Originally pressing a button would trigger a release state and vice-versa,
as observed from hotplug.d.
Signed-off-by: Michael J. Bazzinotti <mbazzinotti@gmail.com>
SVN-Revision: 45634
Most people report broken ethernet with upstream. Last year, user "franz.flasch"
authored a working mach-file. His patch is outdated so I modernized it. Original
patch and user commentary on page 1:
https://forum.openwrt.org/viewtopic.php?pid=260861#p260861
I have figured out what the critical differences are between the two that caused
upstream ethernet to break.
1) Both ath79_init_mac() functions calls must be invocated before any GMAC init
2) must init GMAC0 before GMAC1
That was enough to get upstream to function, but I wanted to enjoy my confidence
having tested franz's patch for a week sucessfully, so I put his whole
function in, which only features more differences in order of function calls.
An expert should consider these changes, which could pose potential bugs/issues:
1) No longer using the flag AR934X_ETH_CFG_SW_PHY_SWAP in the
ath79_setup_ar934x_eth_cfg() call.
2) Possible consequence of no longer explicitly setting ethernet duplex/speed.
Review: With this patch, my ethernet and wireless works.
Signed-off-by: Michael J. Bazzinotti <mbazzinotti@gmail.com>
SVN-Revision: 45633
It is common that the router provider be used rather than product name.
One can see this in target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
Signed-off-by: Michael J. Bazzinotti <mbazzinotti@gmail.com>
SVN-Revision: 45630
This also changes the MAC address to one of the adresses actually used by the
stock firmware on one of the ethernet interfaces.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 45599
INET_LRO deprecated and there are exactly two drivers using it, neither
being included in any of the targets enabling INET_LRO. At the same time
both drivers needing it select it.
So just disable it for everyone.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 45584
This was a remnant of an old version.
Reported-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 45583
I still need to test following patch before backporting:
bgmac: leave interrupts disabled as long as there is work to do
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45571
Linux 4.0 was released on 2014-04-12
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
SVN-Revision: 45559
This patch adds support for the XW version of the Rocket M series devices
manufactured by Ubiquiti, based on the Atheros AR9342 SoC.
Signed-off-by: Roger Pueyo Centelles <roger.pueyo@guifi.net>
SVN-Revision: 45553
There are some rare devices without NAND, like Netgear EX6200 or
TP-LINK Archer C8.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45545
This is needed as prepare_generic_squashfs generates more data (in our
case 0x40004 B) and it's complex for sysupgrade to extract UBI image out
of TRX.
Signed-off-by: Dan Haab <dhaab@luxul.com>
SVN-Revision: 45541
DB149 is a IPQ8064 based platform. This patch adds the init scripts to
detect it, configure the network accordingly, and generate a flashable
image for it.
Signed-off-by: Mathieu Olivari <mathieu@codeaurora.org>
SVN-Revision: 45537
DB149 is an IPQ806x based development platform. This patch adds the dts
files to support it.
Signed-off-by: Mathieu Olivari <mathieu@codeaurora.org>
SVN-Revision: 45536
Certain IPQ806x based platforms are making use of this PHY. So we'll
enable it so it gets detected as such.
Signed-off-by: Mathieu Olivari <mathieu@codeaurora.org>
SVN-Revision: 45535
-removed symbol because it should be handled by wpan.mk
-add missing FAKEHARD symbol (this symbol is removed in Kernel 4.0)
Signed-off-by: Dirk Neukirchen <dirkneukirchen@web.de>
SVN-Revision: 45530
It was reported that OM5P-AN needs not only a delay setting of 1 for RXD/RDV
but 2. These was found when testing with a NetGear GS752TP POE switch with a
cable length of 50ft and 250ft.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 45524
The ETH_RXDV_DELAY (17:16) and ETH_RXD_DELAY (15:14) are currently not cleared
by the function ath79_setup_ar934x_eth_cfg. Clearing these in the
ath79_setup_ar934x_eth_cfg may cause problems on some hardware because they
rely on the preset value by the bootloader.
Instead another function is introduced which also works on ETH_CFG on AR934x.
It can be used to safely clear and set ETH_RXDV_DELAY and ETH_RXD_DELAY on
machines which require special settings.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 45523
The commit r38948 ("ag71xx: add F1E specific feature bit definitions to AR934X
register file") introduced definitions for some bits in the RDV/RXD part of the
ETH_CFG register of AR934x. These are incomplete because ETH_RXDV_DELAY is
specified as 17:16 and ETH_RXD_DELAY is specified 15:14. The original commit
only specified the lower bits. The upper bits also have to be unset when the
lower bits should only be set.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 45522
The tx/rx delay bits in the ETH_XMII_CONTROL register have to be unset when the
enable_rgmii_rx_delay/enable_rgmii_tx_delay will be set in the AT803x PHY.
Othwise the throughput in gigabit mode is heavily reduced.
Signed-off-by: Sven Eckelmann <sven@open-mesh.org>
SVN-Revision: 45521
Profile definitions need to be checked and fixed before this patch can
be applied again.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45511
Refresh patches to remove the trailing whitespaces caused by an old
diffutils version on osx.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 45506
This should rather be done by passing appropriate platform_data/OF, but
should suffice for now.
Fixes e.g. GbE ports on BCM963268BU_P300.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 45505
At least the third rgmii port is available on 63169, so assume all are
available. Simplifies cpu vs. variant handling.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 45504
The new building code included the rootfs twice when building tplink initramfs images.
To make it more readable move initramfs into an own build step
Build/mktplinkfw-initramfs.
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
SVN-Revision: 45491
The new image size is verified by a running tplink device and checked
against mktplinkfw source code.
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
SVN-Revision: 45488
The mips74k subtarget of brcm47xx configures gcc to compile for mips32r2;
however, the generated kernel config for 3.14 and later kernels ends up
with CPU_MIPS32_R1 and CPU_MIPSR1 selected. The generated kernel config
for the 3.10 kernel (Barrier Breaker) properly selected CPU_MIPS32_R2 and
CPU_MIPSR2. Modify the default kernel config for mips74k to explicitly
select CPU_MIPS32_R2 and CPU_MIPSR2.
Signed-off-by: Nathan Hintz <nlhintz@hotmail.com>
Tested-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45469
Open-Mesh OM5P-AN use a AT8035 (F1E) behind one of the ethernet ports. This PHY
requires special flags to work correctly. Otherwise massive packet loss happens
with active POE or when switching the link speed from gigabit ethernet to fast
ethernet. The generic PHY doesn't have support to change these settings.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 45439
The OM5P-AN boards are suffering from ethernet packet loss when booting with
some active POE setups or when switching to Fast Ethernet when previously
booted with Gigabit ethernet attached.
The cause of the problem is that the AR8035 PHYs requires special register
settings to work reliably on these boards. Enable the RGMII TX, RX delays and
disable SmartEE functionality of the AR8035 PHYs. Also enable the RXD and RDV
delay in the ETH_CFG register to fix the issue.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 45438
it has been non-functional for years and caused numerous memleaks and
crashes for people that tried to enable it.
it has no maintained upstream source, and it does not look like it's
going to be fixed any time soon
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45423
It seems to have few ports connected to CPU (only for CPU sending data?)
as part of "SMP dual core 3 GMAC setup" feature.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45403
On BCM5301X there are two different cases to handle: CPU port 8 vs. any
other one. Support for CPU port 8 was already partially implemented but
it lacked setting some extra bit for 2G speed. It also will need to be
extended to implement "SMP dual core 3 GMAC setup". That's the reason
for handling it in separated code block.
This patch also adds overriding CPU port state for port other than 8. It
requires using recently defined GMII_PORT registers.
It was tested for regressions on BCM53011 revs 2 & 3. It was also
confirmed to fix switch on some internal Broadcom board.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 45402
In most cases it allows reverting back to the vendor firmware (as they
usually don't use UBI). If users wants to do that we can't do anything
anyway. Erease counters will be just lost. The only thing we do is warn:
"Flashing firmware without UBI for rootfs. All erase counters will be
lost."
It still requires forcing sysupgrade.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45392
We can now detect that provided firmware contains kernel and UBI image
partitions. Flashing it in a sane way (keeping erase counters) still
needs to be implemented.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45391
With previous version of patch info about need of erasing blocks was
stored once per boot. It was breaking in following scenario:
1) First boot after installation (erasing blocks after 0xdeadc0de)
2) Doing sysupgrade (with ubidetach & ubiformat)
3) Attaching UBI again (it caused all blocks to be erased)
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45387
It currently does not seem to make a difference anymore, except by
increasing compressed kernel image size
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45385
* properly enclose macro arguments in paranthesis on use
* remove trailing white space
* convert C99 // comments
* add missing blank lines after declaration
* remove braces from single statement blocks
* split lines > 80 chars (except for one)
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 45356
Having CONFIG_XZ_DEC_ARMTHUMB enabled breaks squashfs when ARM BCJ
filter was used to create the filesystem (and that's what we do on
all ARM targets). Thus unset CONFIG_XZ_DEC_ARMTHUMB to fix
squashfs on sunxi.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SVN-Revision: 45347
kmod-usb-phy-qcom-dwc3 is required to get USB working on ipq806x. It was
missed in previous commit so let's enable it automatically.
Signed-off-by: Mathieu Olivari <mathieu@codeaurora.org>
SVN-Revision: 45345
MicroWRT is an wireless router with 2 USB,1 ethernet port. It
has a 16M flash and 64M DDR2 RAM. You can use most interface, such as
i2c, SPI, i2s and PCIe. Besides that there are three expansion borad to
combine with the core board. The detailed information, please refer to
https://www.microduino.cc/wiki/index.php?title=Main_Page
This patch adds support for it.
Because there is only one port,so disabled VLAN and use eth0 as lan
port. and only a power LED control by power pin.
Signed-off-by: 盛凯 <shengkai81@gmail.com>
SVN-Revision: 45331
None of the LEDs are enabled by default on the Hornet-UB X2 board
(the 16/64MB version of the Hornet-UB), because it uses a different
board-name ("hornet-ub-x2"); but hornet-ub and hornet-ub-x2 boards
are equivalent WRT their LEDs.
SIgned-off-by: Joshua Judson Rosen <jrosen@harvestai.com>
SVN-Revision: 45328
