This comit fixes warnings that occur on kernel 5.15:
...
[ 2.269736] Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.5 / v1.6 1e108000.switch-mii:00:
PHY has delays (e.g. via pin strapping), but phy-mode = 'rgmii'
[ 2.269736] Should be 'rgmii-id' to use internal delays txskew:1500 ps rxskew:1500 ps
...
Ref: be393dd685
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
The CPU port should define the phy-mode and and a PHY phandle or
fixed-link to indicate how the CPU port is connected to the SoC's
Ethernet controller. On xRX200 this is all internal connection, so use
phy-mode = "internal" along with a fixed-link that matches the
definition inside ð0.
Linux 6.0 shows a warning since upstream commit e09e9873152e3f ("net:
dsa: make phylink-related OF properties mandatory on DSA and CPU
ports"). when these properties are missing. Adding the properties
before OpenWrt is updated to Linux 6.0 is harmless.
Suggested-by: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
There are forum reports that 2 LAN ports are still not working,
the phy-mode settings are adjusted to fix the problem.
Fixes: #10371
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
There are forum reports that 2 LAN ports are not working, the
GPIO settings are adjusted to fix the problem.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
lantiq,bus-clock, interrupt-map-mask and interrupt-map are already
defined with these exact values in vr9.dtsi. Drop them from
vr9_tplink_tdw8980.dts to just have one place where these are
maintained.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
ar9.dtsi and danube.dtsi only have one reset controller and they are
naming it "reset". This is equivalent to "reset0" in vr9.dtsi. Fix the
references to the reset controller in the recently added PCI controller
reset line.
Fixes: 087f2cba26 ("lantiq: dts: Add the reset line for the PCI controller")
Reported-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
The PCI controller has it's reset line wired up to bit 13 of RCU.
Describe this in our .dtsi files.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
FRITZ!Box 7360 V2 and FRITZ!Box 7360 SL both use GPIOs 37 (for &phy0)
and GPIO 44 (for &phy1) to control the PHY's reset lines. FRITZ!Box 7362
SL however uses GPIO 45 (for &phy0) and GPIO 44 (for &phy1). Move the
GPIO reset definitions to each individual board .dts and while at it,
fix the GPIOs for the FRITZ!Box 7362 SL.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Without a partition subnode ofpart_core still parses direct subnodes as
partitions, but it ignores nodes with a compatible property. Due to
this, the switch to nvmem-cells made the urlader partition inaccessible.
As a result, the wireless network was broken, as the calibration data
is read from that partition by a script.
Fixes: #8983
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
The &spi node has #address-cells = <1> and #size-cells = <0>. Drop the
extra 0 in the reg property from the SPI flash node to ensure it's
number of cells matches the definition in the parent node. This also
makes the reg property for the SPI flash node consistent with all other
VR9 boards.
Fixes: eae6cac6a3 ("lantiq: add support for AVM FRITZ!Box 7362 SL")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
All buttons of the FritzBox 7360 family are active-low, not active-high.
Corrent the GPIO flag. This fixes release triggers upon push of a button.
Reported-by: Jan-Niklas Burfeind <git@aiyionpri.me>
Signed-off-by: David Bauer <mail@david-bauer.net>
With Kernel 5.10 the ar7 FRITZ!Box are not booting the initramfs nor the
sysupgrade image any more. Presumably due to the grown kernel.
Use the okli preloader to workaround the bootloader issue. No solution
so far for the initramfs.
Signed-off-by: Mathias Kresin <dev@kresin.me>
This commit contains a series of fixes for DMA. The burst length
patch significantly improves Ethernet performance. Patches were
tested on the xRX200 and xRX330.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
The devicetree property mac-address is expected to be set by the
bootloader and has priority over the nvmem supplied one.
Drop the mac-address address property from the dtsi files, to let the
mac address from nvmem-cells get used.
Signed-off-by: Mathias Kresin <dev@kresin.me>
OpenWrt maintains two special out-of-tree DT properties:
"qca,disable-5ghz" and "qca,disable-2ghz". These are implemented
in a mac80211 ath9k patch "550-ath9k-disable-bands-via-dt.patch".
With the things being what they are, now might be a good
point to switch the devices to the generic and upstream
"ieee80211-freq-limit" property. This property is much
broader and works differently. Instead of disabling the
drivers logic which would add the affected band and
channels. It now disables all channels which are not
within the specified frequency range.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> # HH5A
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
When trying to add support for another device with Micron NAND chips,
it was discovered that the default setting in the kernel source does
not work with Micron Chips, since the device trees setting is
overwritten and hard coded by the kernel xway_nand driver. This was
the original reason for this PR.
A kernel patch sets the default ECC mode to soft without overwriting
the device tree settings and the device tree for devices using it
are updated with new parameters because the old ones are deprecated
by torvalds/linux@533af69.
A patch for kernel 5.4 is provided to support the new settings
because kernel 5.4 does not support it.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.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>
Enable the XRX200 PMAC, GSWIP DSA tag and GSIP DSA drivers in the 5.4
kernel config. Update the existing vr9_*.dts{,i} to use the new
Ethernet and switch drivers. Drop the swconfig package from the xrx200
target because swconfig doesn't manage DSA based switches.
The new /etc/config/network format for the DSA driver is not compatible
with the old (swconfig) based one. Show a message during sysupgrade
notifying users about this change and asking them to start with a fresh
config (or forcefully update and then migrate the config manually).
Failsafe mode can now automatically bring up the first lan interface
based on board.json including DSA based setups. Drop
05_set_preinit_iface_lantiq from the xRX200 sub-target as this is not
needed anymore. For now we are keeping it for the ase, xway and
xway_legacy until there's some confirmation that it can be dropped from
there as well.
While here, some boards also receive minor fixups:
- Use LAN1 as LAN1 (according to a photo this port can also be
configured as WAN) on the Buffalo WBMR-300HPD. This makes it easier to
read the port mapping because otherwise we would have LAN{2,3,4} and
WAN (which was the case for the non-DSA version previously).
- vr9_avm_fritz3390.dts: move the "gpio" comment from port 0 and 1 to
their corresponding PHYs
- vr9_tplink_vr200.dtsi: move the "gpio" comment from port 0 to PHY 0
- vr9_tplink_tdw89x0.dtsi: move the "gpio" comment from port 0 to PHY 0
Acked-by: Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
Tested-by: Notupus <notpp46@googlemail.com> # TD-W9980/DM200/FRITZ 7430
Tested-by: Martin Schiller <ms@dev.tdt.de> # tested on TDT VR2020
Tested-by: Martin Schiller <ms@dev.tdt.de> # tested on TP-Link TD-W8980B
Tested-by: Martin Schiller <ms@dev.tdt.de> # tested on ZyXEL P-2812HNU-F1
Tested-by: Daniel Kestrel <kestrel1974@t-online.de> # tested on Fritzbox 7490
Tested-by: Daniel Kestrel <kestrel1974@t-online.de> # tested on Fritzbox 3490
Tested-by: @jospezial <jospezial@gmx.de> # tested on VGV7510KW22 (o2 Box 6431)
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Use the device_type property to mark PCI host bridges as such. With
linux 5.10 it is mandatory, otherwise the PCI IO space is flages as PCI
memory and the PCI init fails.
Signed-off-by: Mathias Kresin <dev@kresin.me>
The FRITZ!Box 3390 actually contains two SoCs, one Lantiq with a
5GHz WiFi and one AR9342 with a 2.4GHz WiFi. Only the Lantiq
has access to the flash memory, the Atheros runs fully from RAM.
Specifications
--------------
- Lantiq 500 MHz
- 128MiB RAM
- 128MiB NAND
- 256k Flash
- AR9580 5GHz WiFi
- AR9342 560 MHz
- 64MiB RAM
- AR9328 2.4GHz WiFi
Remarks
-------
This commit only adds support for the Lantiq side of things and
prepares the drivers for communication with the Atheros SoC. Thus,
only 5GHz WiFi works by default, the 2.4GHz WiFi will be added via
another target.
Some kernel patches will be required to add support for the Atheros SoC.
Installation
------------
Use the eva_ramboot.py script to boot the initramfs image. Then, transfer
the sysupgrade image to the device and run sysupgrade to flash it to the
NAND.
Signed-off-by: Andreas Böhler <dev@aboehler.at>
Acked-by: Aleksander Jan Bajkowski A.Bajkowski@stud.elka.pw.edu.pl
Signed-off-by: Joachim Cerny <cocktail_yogi@web.de>
Assign the usbdev trigger via devicetree and drop the userspace
handling of the usb leds.
Drop the now unused userspace helper code as well.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Acked-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Assign the usbdev trigger via devicetree and drop the userspace
handling of the usb leds
Add the PCI attached usb controller as trigger sources for the usb led
as well.
Signed-off-by: Mathias Kresin <dev@kresin.me>
The USB ports if a FRIZZ!Box 7320 do not supply power to connected
devices.
Add the GPIOs enabling USB power as regulator, to enable USB power
supply as soon as the USB driver is loaded.
Fixes FS#3624
Signed-off-by: Mathias Kresin <dev@kresin.me>
FRITZ!Box 7412 loads the firmware for fast ethernet PHY and mii is
more accurate in this case.
Gmii is used by Gigabit ethernet PHYs.
Signed-off-by: Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
Reviewed-by: Mathias Kresin <dev@kresin.me>
[minor commit title/message adjustments]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
These parameters are the same as in vr9.dtsi. This patch removes
redundant parameters.
Signed-off-by: Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
Hardware:
- SoC: Lantiq VRX 220
- CPU: 2x MIPS 34Kc 500 MHz
- RAM: 128 MiB 250 MHz
- Flash: 128 MiB NAND
- Ethernet: Built-in Fast Ethernet switch, 4 ports used
- Wifi: Atheros AR9381-AL1A b/g/n with 2 pcb/internal and 1 external antennas
- USB: 1x USB 2.0
- DSL: Built-in A/VDSL2 modem
- DECT: Dialog SC14441
- LEDs: 1 two-color, 4 one-color
- Buttons: 1x DECT, 1x WIFI
- Telephone connectors: 1 FXS port via TAE or RJ11 connector
With the exception of FXS/DECT everything works
(there are no drivers for AVM's FXS or DECT implementation),
DSL is yet untested.
Installation:
Boot up the device and wait a few seconds. Run the eva_ramboot.py script
in scripts/flashing/ to load the initramfs image on the device:
$ ./scripts/flashing/eva_ramboot.py 192.168.178.1 <path to your initramfs image>
If the script fails to reach the device, maybe try 169.254.120.1.
Wait until booting is complete. You should now be able to reach your device
under the default ip address 192.168.1.1.
Before flashing, check if linux_fs_start is not set to 1 in the tffs partition:
$ fritz_tffs_nand -d /dev/mtd1 -n linux_fs_start
If linux_fs_start is 1, you will need to reset it to 0, either by FTP,
upgrading FritzOS or doing a recovery.
Now you should be able to flash the device using sysupgrade.
Signed-off-by: Leon Maurice Adam <leon.adam@aol.de>
Acked-by: Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
[drop BOARD_NAME, use wpad-basic-wolfssl, drop 4.19, drop dts-v1,
remove model prefix from LED names]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The target uses 5.4 as default kernel since 06/2020.
Kernel 4.19 support is not really maintained anymore, it does not
seem to be needed and upcoming changes (mainly DSA) will break
backward-compatibility 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>
Duplicate kernel 4.19 config and patches for kernel 5.4.
Duplicate the devicetree source files as well, they need kernel 5.4
specific adjustments.
Signed-off-by: Mathias Kresin <dev@kresin.me>
For some reason pin 7 (gphy0_led1_pins) need to be set to output prior
to loading the PCI driver. Otherwise the wireless doesn't appear on the
PCI bus. Of course, it doesn't make much sense, since pin 7 is used to
drive the LAN1 led.
It can either be done by setting the pins function to GPHY or GPIO +
direction output. However, the pinctrl driver doesn't provide a way to
switch a pin to GPIO. It is done indirectly by the pinctrl driver at the
time a GPIO is requested (requesting a GPIO always resets the function
to GPIO).
Do it via pinmux driver, as it is always loaded first. Use the GPHY
function as it's the pins intended purpose for this board.
Fixes: FS#2895
Signed-off-by: Mathias Kresin <dev@kresin.me>
The mux need to be defined in a subnode to be considered by the pinctrl
framework. These muxes aren't set as expected and might cause not
working subsystems.
Fixes: 8e7b573b7a ("lantiq: dts: assign the PCI pins to the PCI controller node")
Fixes: dcb5e52209 ("lantiq: dts: assign the STP pins to the STP GPIO controller node")
Fixes: 660200e53d ("lantiq: dts: assign the GPHY LED pins to the Ethernet controller node")
Signed-off-by: Mathias Kresin <dev@kresin.me>
This moves the include of lantiq.dtsi from the DTS files to the
parent falcon_lantiq_easy98000.dtsi.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This renames lantiq DTS(I) files to follow soc_vendor_device scheme.
This will make DTS files easier to maintain.
As a side effect, DTS file name can be derived from device node
names now, only having to specify a SOC variable in Makefiles.
While at it, move files to arch/mips/boot/dts/lantiq subfolder.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Assign the ASC pins to the serial controller node instead of using pin
hogging (where pins are assigned to the pin controller).
This is the preferred way of assigning pins upstream.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Assign the PCI pins to the PCI controller node instead of using pin
hogging (where pins are assigned to the pin controller).
This is the preferred way of assigning pins upstream.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Assign the STP pins to the STP GPIO controller node instead of using
pin hogging (where pins are assigned to the pin controller).
This is the preferred way of assigning pins upstream.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Assign the GPHY LED pins to the Ethernet controller node instead of
using pin hogging (where pins are assigned to the pin controller).
This is the preferred way of assigning pins upstream.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Assign the NAND pins to the NAND controller node instead of using pin
hogging (where pins are assigned to the pin controller).
This is the preferred way of assigning pins upstream.
While here, define all NAND pins (CLE, ALE, read/RD, ready busy/RDY and
CE/CS1). This means that the pinctrl subsystem knows that these pins are
in use and cannot be re-assigned as GPIOs for example.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Define the SPI pins in the corresponding SoCs.dtsi and assign them to
the SPI controller node. All known boards use CS4 and it's likely that
this is hardcoded in bootrom so this doesn't bother with having
per-board SPI pinmux settings.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Assign the MDIO pins to the switch node instead of using pin hogging
(where pins are assigned to the pin controller).
This is the preferred way of assigning pins upstream.
This converts amazonse, ar9 and vr9. danube is skipped because the pin
controller doesn't define a pinmux for the MDIO pins (some of the SoC
pads may be hardwired to the MDIO pins instead of being configurable).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
The "/dts-v1/;" identifier is supposed to be put once at the beginning
of a device tree file. Thus, it makes no sense to provide it a second
time in to-be-included DTSI files.
This removes the identifier from all DTSI files in /target/linux.
Most of the DTS files in OpenWrt do contain the "/dts-v1/;". It is
missing for most of the following targets, though:
mvebu, ipq806x, mpc85xx, ipq40xx
This does not touch ipq806x for now, as the bump to 4.19 is close.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This commit unifies the LED mapping of the AVM Fritz!Box routers, which
have a combined Power/DSL LED.
With the stock firmware, the Power LED has the following
characteristics:
- Blink when DSL sync is being established
- Solid when DSL sync is present
We can't completely resemble this behavior in OpenWrt. Currently, the
Power LED is completely off, when DSL sync is missing. This is not
really helpful, as a user might have the impression, that he bricked his
device.
Instead, map the Info-LED to the state of the DSL connection.
There is no consistent behavior for the Info-LED in the stock
firmware, as the user can set it's function by himself. The DSL
connection state is one possible option for the Info LED there.
Also use the red Power LED to indicate a running upgrade, in case the
board has a two-color Power LED.
Signed-off-by: David Bauer <mail@david-bauer.net>
