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
On newer Mikrotik boards, the radio calibration data
is stored differently and uses LZO compression instead
of RLE.
Update the RouterBOOT helper code to support the new
format.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 45297
First of all this patch was affecting other devices, not just Netgear
WNR834B. E.g. Linksys WRT300N v1 also has boardtype 0x0472.
This was breaking PCI on WRT300N, ssb couldn't detect core working in
hostmode (due to mips_busprobe32 failing).
Secondly this patch should not be needed for years now. From the analyze
of #8861 it seems it was needed just to make devices at slots other than
0 discoverable. Setting cardbus to 0 was simply making ssb allow access
to PCI config for devices other than bridge.
With the upstream commit a6c8462 (ssb: fix cardbus slot in hostmode) we
allow accessing device at slot 1 which should be enough for CardBus.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45293
SCHED_AUTOGROUP was turned on by default which forces the use of
CGROUPS, conflicting with the options we offer from menuconfig, remove
that.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
SVN-Revision: 45275
