If xfer_mode is set to auto the vdsl_cpe_control daemon assumes that
ATM should be used for ADSL and PTM for VDSL.
xfer_mode and line_mode can be set to fixed value independantly from
each other.
The syntax for the tc_layer argument of vdsl_cpe_control is as follow:
-T<TcADSL>:<TcCfgUsADSL>:<TcCfgDsADSL>_<TcVDSL>:<TcCfgUsVDSL>:<TcCfgDsVDSL>
where TcADSL and TcVDSL can be: 1=ATM, 2=PTM/EFM, 4=Auto TC-Layer
and TcCfgUsADSL, TcCfgUsVDSL, TcCfgDsADSL, TcCfgDsVDSL can be:
1=64/65-octet encapsulation supported
2=64/65-octet encapsulation with pre-emption
3=64/65-octet encapsulation with short packets
Default: In case of no '-T' option is given, ADSL will be configured
in ATM and VDSL in PTM/EFM: -T1:0x1:0x1_2:0x1:0x1
The '-M' argument of dsl_cpe_control defines the initial DSL mode
(NextMode) for ADSL/VDSL multimode handling.
Possible Values: 0=API-default, 1=ADSL, 2=VDSL
Default: In case of no '-M' option is given, '0' (API-default) will
be selected.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This is needed to be able to load the ltq-atm/ltq-ptm driver
from a notify script during synchronization, because the line can
reach showtime state before the driver is fully loaded.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This makes it possible to simply add additional notification handlers
by putting new scripts in the /etc/hotplug.d/dsl directory.
the following Environment Variables are used:
(values marked with an * are only available when bonding support is
compiled in)
DSL_NOTIFICATION_TYPE with one of these values:
- DSL_STATUS
- DSL_INTERFACE_STATUS
- DSL_DATARATE_STATUS_US
- DSL_DATARATE_STATUS_DS
DSL_LINE_NUMBER=<0|1> *
If DSL_NOTIFICATION_TYPE == DSL_STATUS, these variables are set:
- DSL_XTU_STATUS=<ADSL|VDSL>
- DSL_TC_LAYER_STATUS=<ATM|EFM>
- DSL_EFM_TC_CONFIG_US=<NORMAL|PRE_EMPTION>
- DSL_EFM_TC_CONFIG_DS=<NORMAL>
If DSL_NOTIFICATION_TYPE == DSL_INTERFACE_STATUS, these variables are
set:
- DSL_INTERFACE_STATUS=<DOWN|READY|HANDSHAKE|TRAINING|UP>
- DSL_BONDING_STATUS=<INACTIVE|ACTIVE> *
If DSL_NOTIFICATION_TYPE == DSL_DATARATE_STATUS_US, these variables are
set:
- DSL_DATARATE_US_BC0=<Upstream data rate in bit/s for Channel 0>
- DSL_DATARATE_US_BC1=<Upstream data rate in bit/s for Channel 1> *
If DSL_NOTIFICATION_TYPE == DSL_DATARATE_STATUS_DS, these variables are
set:
- DSL_DATARATE_DS_BC0=<Downstream data rate in bit/s for Channel 0>
- DSL_DATARATE_DS_BC1=<Downstream data rate in bit/s for Channel 1> *
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
The esi call was added to workaround a race condition between applying
a configured mac address to the wan interface and starting the protocol
(handler) as it was observed in a DHCP over ATM bridge configuration.
Martin Schiller, TDT GmbH was so kind to test with their local
infrastructure if the race condition still exists. The provided package
dumps captured behind the DSLAM shows that it doesn't. It was most
likely fixed with adding carrier support to the lantiq ptm/atm driver.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Fix when add 'mediatek,cd-poll' to dts cause the sd card be removed randomly.
Special for the device without card-detect pin.
Signed-off-by: Qin Wie <me@vonger.cn>
296b4a0 dhcpv6: assign all viable DHCPv6 addresses by default (FS#402, FS#524)
f4d38e0 treewide: reflect managed mode is related to RA
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Use the GPIO dt-bindings macros and add compatible strings in the
ramips device tree source files.
Signed-off-by: L. D. Pinney <ldpinney@gmail.com>
Signed-off-by: Mathias Kresin <dev@kresin.me>
The Netgear EX3800 is essentially an EX3700 with a mains output socket.
Both devices use the exact same firmware image (original firmware is named
EX3700-EX3800-version.chk).
This patch adds suport by renaming the EX3700 device to EX3700/EX3800 and
updating the necessary glue.
Signed-off-by: Thibaut VARENE <hacks@slashdirt.org>
This patch cleans up the WN3000RPv3 and EX2700 setup, bringing it in line
with other similar devices:
The power led is a bicolor one. The bootloader brings the red side on at
powerup.
Instead of blinking the red side in diag.sh and need to forcefully turn it off
in 01_leds, this patch simplifies the setup by relying on the default off state
of the gpio-led driver for the red side and blinking the green side as with
other devices.
Signed-off-by: Thibaut VARENE <hacks@slashdirt.org>
Cleanup the dtsi files and remove one layer of dtsi. Set the size of
the firmware partition to a value matching the flash size from the
board (variant) name.
Remove the usb led trigger. There is neither a default config for the
usb led trigger nor a LED for usb activity indication.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Reference the Omnima MiniEMBWiFi device tree source file in the image
build code. Otherwise the dts of the image processed before is used.
Signed-off-by: Mathias Kresin <dev@kresin.me>
So, this is kind of complicated. This has been upstream for a while,
imported from OpenWRT/LEDE with some cleanups. LEDE ramips has stayed
on linux-4.4 this whole time, with the old(er) version of the patch
that had correct behavior[0], while upstream got changed[1].
When LEDE updated to kernel 4.9, the older version of the code from
the patch got replaced with the upstream version containing the bug.
The original behavior, however, seems to be correct here, as the
official programming guide[2] indicates that bit 31 (PDRV_SW_SET)
in register PPLL_CFG1 is reserved, but bit 23 (added as PPLL_LD)
is the PPLL lock state (which also happens to line up with the
error message).
The original confusion probably comes from the double definition
of PDRV_SW_SET[3, 4] in the upstream code, with one correct definition
(31) and one incorrect one (23).
I've also used the opportunity to clean up the error message a bit -
it's still not really helpful to anyone who doesn't already know what
the PPLL is, but at least it's slightly more readable now.
This will probably need to be upstreamed as well, since with the way
it's currently set up, it's unlikely PCI ever worked for anyone who's
running an upstream kernel on that SoC.
[0]: 05d6e92594/target/linux/ramips/patches-4.4/0009-PCI-MIPS-adds-mt7620a-pcie-driver.patch (L259)
[1]: 026d15f6b9/arch/mips/pci/pci-mt7620.c (L246)
[2]: http://www.anz.ru/files/mediatek/MT7620_ProgrammingGuide.pdf
[3]: 026d15f6b9/arch/mips/pci/pci-mt7620.c (L36)
[4]: 026d15f6b9/arch/mips/pci/pci-mt7620.c (L39)
Signed-off-by: Ilya Katsnelson <me@0upti.me>
When -e option it specified a corresponding flag is set in the
custom_board. By using custom_board as fallback -e option gets respected
for unknown boards.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
01_leds had a workaround for the power led to compensate for the
inverted GPIO state. This patch was missing from my previous commit.
Signed-off-by: Thibaut VARENE <hacks@slashdirt.org>
[add the power led default-state which was omitted in the last commit
by me]
Signed-off-by: Mathias Kresin <dev@kresin.me>
Luci shows switch ports in wrong order on that device.
This patch fixes switch port numbering and matches them to the device
silkscreen.
Signed-off-by: Thibaut VARENE <hacks@slashdirt.org>
All LEDs GPIOs are active low on this device.
WAN and POWER states were inverted. Add default state for power.
Tested on Archer C50v1.
Signed-off-by: Thibaut VARENE <hacks@slashdirt.org>
With d2b6bf1416 ("ramips: fix image validation errors") the board
name was changed to fix an image validation error. But this change
wasn't applied to all other files using the board name, which broke
sysupgrade.
Revert this change and use the former board name in the metadata
instead.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Make the behaviour of clk_get_rate consistent with common clk's
clk_get_rate by accepting NULL clocks as parameter. Some device
drivers rely on this, and will cause an OOPS otherwise.
Fixes: FS#735
Signed-off-by: Mathias Kresin <dev@kresin.me>
Make the behaviour of clk_get_rate consistent with common clk's
clk_get_rate by accepting NULL clocks as parameter. Some device
drivers rely on this, and will cause an OOPS otherwise.
Fixes: FS#735
Signed-off-by: Mathias Kresin <dev@kresin.me>
Make the behaviour of clk_get_rate consistent with common clk's
clk_get_rate by accepting NULL clocks as parameter. Some device
drivers rely on this, and will cause an OOPS otherwise.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Commits since last 2017-07-11:
4bd8601 pkg_parse: fix segfault when parsing descriptions with leading newlines
Fixes FS#933.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Fix incorrect offset and size of linux partition.
Fixes: 97b36aca09 ("brcm63xx: add pflash for remaining pflash equipped boards")
Signed-off-by: Paul Wassi <p.wassi@gmx.at>
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
The kernel 4.4 patches where already removed with the bump to 4.9. Drop
the the subtarget configs as well.
Signed-off-by: Mathias Kresin <dev@kresin.me>
The WMDR-143N is a small module originally used as a Wifi client
in some Loewe smart TV sets. It is sold cheaply at german surplus
shops. The module contains a RT3662 SOC.
Specifications:
- 500 MHz CPU Clock
- 1x 10/100Mbps Ethernet (pin header)
- 32 MB of RAM
- 8 MB of FLASH
- 2T3R 2.4/5 GHz (SOC internal)
- 3 Antennas on PCB
- UART pads on PCB (J3: 1 = +3.3V, 2 = RX, 3 = TX, 4 = GND), TX
and RX are 3,3V only! The square hole is pin 1
- Power supply pads on PCB (J6: 1 and 2 = +5V, 3 and 4 = GND)
The square hole is pin 1
The original firmware has two identical kernel/rootfs images and
two "Factory" calibration data blocks in flash. The LEDE image
leaves only the first "Factory" block in place and uses both
"Kernel" blocks and the redundant "Factory" block together to gain
enough space for the jffs2 partition.
Flash instructions:
You need UART and Ethernet connections to flash the board. Use
the LEDE "sysupgrade.bin" image with tftp.
Apply power to the board and in the first 5 seconds, hit 2 to
select TFTP upload. The bootloader asks for board- and server IP
addresses and filename.
Alternate method: With the vendor firmware running, assign an IP
address to the ethernet port, tftp the firmware image to
/tmp and write to mtd4 ("KernelA").
Signed-off-by: Oliver Fleischmann <ogf@bnv-bamberg.de>
[remove pinctrl node from dts, no pin is used as GPIO]
Signed-off-by: Mathias Kresin <dev@kresin.me>
Children of the pinctrl0 node are optional. Return EINVAL (=missing)
instead of 0. Fixes a hang if the pinctrl0 has no children.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Acked-by: John Crispin <john@phrozen.org>
When a package declares a PKG_BUILD_DEPENDENCY or HOST_BUILD_DEPENDENCY on
a not existing build type, the metadata script will emit a reference to an
unresolvable build target in tmp/.packagedeps, causing the make process to
fail hard in a way not catchable by the IGNORE_ERRORS mechanism.
In a situation where a package "test-a" declares a build dependency
"PKG_BUILD_DEPENDS:=test-b/host" while the Makefile of "test-b" does not
implement a HostBuild, make fails with an unrecoverable error in the form:
make[1]: Entering directory '...'
make[1]: *** No rule to make target 'package/test-b/host/compile',
needed by 'package/test-a/compile'. Stop.
make[1]: Leaving directory '...'
.../toplevel.mk:200: recipe for target 'package/test-a/compile' failed
make: *** [package/test-a/compile] Error 2
Extend the metadata generation script to catch such unresolved references
and emit a visable warning upon detection.
After this change, the script will emit a warning similar to:
WARNING: Makefile "package/test-a/Makefile" has a build dependency on
"test-b/host" but "package/test-b/Makefile" does not implement a
"host" build type
Fixes a global build cluster outage which occured after the "python-cffi"
feed package removed its HostBuild which the "python-cryptography" package
build-depended on.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
there were 2 bugs
*) core1 came up with a bad bogo mips, looks like the clock needed time to stabilize
*) HPT frequency was not set making r4k timers not come up properly
Signed-off-by: John Crispin <john@phrozen.org>
