Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[21.02] ramips: mt7620: fix ethernet with external switches #4303

Conversation

mpratt14
Copy link
Contributor

these 10 commits should be backported after getting enough people to test

the first 7 commits are needed in order to backport the rest without conflicts when doing git cherry-pick -x

LGA1150 and others added 17 commits June 23, 2021 17:55
The kernel bump to 5.4 has removed the mx25l25635f hack, and the
mx25l25635f compatible is no longer required.

Signed-off-by: DENG Qingfang <dqfext@gmail.com>
(cherry picked from commit 06af45e)
Youku YK-L1 has a huge storage space up to 32 MB. It is better to
use a higher spi clock to read or write serial nor flash chips.
Youku YK-L1 has Winbond w25q256fvfg on board that can support
104 MHz spi clock so 48 MHz is safe enough.
The real frequency can only be sysclk(580MHz ) /3 /(2^n) so 80 MHz
defined in dts file will set only 48 MHz in spi bus.

Signed-off-by: Shiji Yang <yangshiji66@qq.com>
(cherry picked from commit bf7ddb1)
1. rename led pin "air" to a more common name "wlan" and use "phy0tpt" to trigger it.
2. led "wan" can be triggered by ethernet pinctrl by default so just drop it.

Signed-off-by: Shiji Yang <yangshiji66@qq.com>
(cherry picked from commit 882a611)
Device specifications:
* Model: Youku YK-L1/L1c
* CPU: MT7620A
* RAM: 128 MiB
* Flash: 32 MiB (YK-L1)/ 16 MiB (YK-L1c)
* LAN: 2* 10M/100M Ports
* WAN: 1* 10M/100M Port
* USB: 1* USB2.0
* SD: 1* MicroSD socket
* UART: 1* TTL, Baudrate 57600

Descriptions:
  Previous supported device YOUKU yk1 is actually Youku YK-L1. Though they look
  really different, the only hardware difference between the two models is flash
  size, YK-L1 has 32 MiB flash but YK-L1c has 16MiB. It seems that YK-L1c can
  compatible with YK-L1's firmware but it's better to split it to different models.

  It is easy to identify the models by looking at the label on the bottom of the
  device. The label has the model number "YK-L1" or "YK-L1c". Due to different flash
  sizes, YK-L1c that using previous YK-L1's firmware needs to apply "force update"
  to install compatible firmware, so please backup config file before system upgrade.

Signed-off-by: Shiji Yang <yangshiji66@qq.com>
[use more specific name for DTSI]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit 4a9f389)
About the device
----------------

SoC: MediaTek MT7620a @ 580MHz
RAM: 64M
FLASH: 8MB
WiFi: SoC-integrated: MediaTek MT7620a bgn
WiFi: MediaTek MT7612EN nac
GbE: 2x (RTL8211F)
BTN: - WPS
- Reset
- Router/Repeater/AP (3-way slide-switch)
LED: - WPS (blue)
- 3-segment Wifi signal representation (blue)
- WiFi (blue)
- WAN (blue)
- LAN (blue)
- Power (blue)
UART: UART is present as Pads with through-holes on the PCB. They are
located next to the reset button and are labelled Vcc/TX/RX/GND as
appropriate. Use 3.3V, 57600-8N1.

Installation
------------

Using the webcmd interface
--------------------------

Warning: Do not update to the latest Wavlink firmware (version
20201201) as this removes the webcmd console and you will need to
use the serial port instead.

You will need to have built uboot/sqauashfs image for this device,
and you will need to provide an HTTP service where the image can
be downloaded from that is accessible by the device.
You cannot use the device manufacturers firmware upgrade interface
as it rejects the OpenWrt image.

1. Log into the device's admin portal. This is necessary to
   authenticate you as a user in order to be able to access the
   webcmd interface.
2. Navigate to http://<device-ip>/webcmd.shtml - you can access
   the console directly through this page, or you may wish to
   launch the installed `telnetd` and use telnet instead.
   * Using telnet is recommended since it provides a more
     convenient shell interface that the web form.
   * Launch telnetd from the form with the command `telnetd`.
   * Check the port that telnetd is running on using
     `netstat -antp|grep telnetd`, it is likely to be 2323.
   * Connect to the target using `telnet`. The username should
     be `admin2860`, and the password is your admin password.
3. On the target use `curl` to download the image.
   e.g.  `curl -L -O http://<some-other-lan-ip>/openwrt-ramips-mt7620-\
          wavlink_wl-wn579x3-squashfs-sysupgrade.bin`.
   Check the hash using `md5sum`.
4. Use the mtd_write command to flash the image.
   * The flash partition should be mtd4, but check
     /sys/class/mtd/mtd4/name first. The partition should be
     called 'Kernel'.
   * To flash use the following command:
     `mtd_write -r -e /dev/mtd<n> write <image-file> /dev/mtd<n>`
     Where mtd<n> is the Kernel partition, and <image-file> is
     the OpenWrt image previously downloaded.
   * The command above will erase, flash and then reboot the
     device. Once it reboots it will be running OpenWrt.

Connect via ssh to the device at 192.168.1.1 on the LAN port.
The WAN port will be configured via DHCP.

Using the serial port
---------------------

The device uses uboot like many other MT7260a based boards. To
use this interface, you will need to connect to the serial
interface, and provide a TFTP server. At boot follow the
bootloader menu and select option 2 to erase/flash the image.
Provide the address and filename details for the tftp server.
The bootloader will do the rest.

Once the image is flashed, the board will boot into OpenWrt. The
console is available over the serial port.

Signed-off-by: Ben Gainey <ba.gainey@googlemail.com>
(cherry picked from commit a509b80)
The basic mode control register of the ESW PHYs is modified in this
codeblock. Use the respective macros to make this code more readable.

Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 6a15abb)
This enables autonegotiation for all ephy ports on probe.
Some devices do not configure the ports, particularly port 4.

Signed-off-by: Gaspare Bruno <gaspare@anlix.io>
[replace magic values ; reword commit message]
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 0056ffb)
There are only 2 options in the driver
for the function of mt7620 internal switch port 4:

  EPHY mode (RJ-45, internal PHY)
  GMAC mode (RGMII, external PHY)

Let the DTS property be boolean instead of string
where EPHY mode is the default.

Fix how the properties are written
for all DTS that use them,
and add missing nodes where applicable,
and remove useless nodes,
and minor DTS formatting.

Signed-off-by: Michael Pratt <mcpratt@pm.me>
(cherry picked from commit 953bfe2)
These nodes are used for configuring a GMAC interface
and for defining external PHYs to be accessed with MDIO.

None of this is possible on MT7620N, only MT7620A,
so remove them from all MT7620N DTS.

When the mdio-bus node is missing, the driver returns -NODEV
which causes the internal switch to not initialize.
Replace that return so that everything works without the DTS node.

Also, an extra kernel message to indicate for all error conditions
that mdio-bus is disabled.

Fixes: d482356 ("ramips: mt7620n: add mdio node and disable port4 by default")
Fixes: aa5014d ("ramips: mt7620n: enable port 4 as EPHY by default")
Signed-off-by: Michael Pratt <mcpratt@pm.me>
(cherry picked from commit a2acdf9)
A workaround was added to the switch driver
to set SOC port 4 as an RGMII GMAC interface
based on the DTS property mediatek,port4-gmac.
(previously mediatek,port4)

However, the ethernet driver already does this,
but is being blocked by a return statement
whenever the phy-handle and fixed-link properties
are both missing from nodes that define the port properties.

Revert the workaround, so that both the switch driver
and ethernet driver are not doing the same thing
and move the phy-handle related lines down
so nothing is ending the function prematurely.

While at it, clean up kernel messages
and delete useless return statements.

Fixes: f6d81e2 ("mt7620: gsw: make IntPHY and ExtPHY share mdio addr 4 possible")
Signed-off-by: Michael Pratt <mcpratt@pm.me>
(cherry picked from commit afd60d6)
When the new variable ephy_base was introduced,
it was not applied to the if block for mdio_mode.

The first line in the mdio_mode if block
sets the EPHY base address to 12 in the SOC by writing a register,
but the corresponding variable in the driver
was still set to the default of 0.

This causes subsequent lines that write registers with the function
_mt7620_mii_write
to write to PHY addresses 0 through 4
while internal PHYs have been moved to addresses 12 through 16.

All of these lines are intended only for PHYs on the SOC internal switch,
however, they are being written to external ethernet switches
if they exist at those PHY addresses 0 through 4.
This causes some ethernet ports to be broken on boards with AR8327 or QCA8337 switch.

Other suggested fixes move those lines to the else block of mdio_mode,
but removing the else block completely also fixes it.

Therefore, move the lines to the mt7620_hw_init function main block,
and have only one instance of the function mtk_switch_w32
for writing the register with the EPHY base address.

In theory, this also allows for boards that have both external switches
and internal PHYs that lead to ethernet ports to be supported.

Fixes: 391df37 ("ramips: mt7620: add EPHY base mdio address changing possibility")
Signed-off-by: Michael Pratt <mcpratt@pm.me>
(cherry picked from commit de5394a)
Set the PHY base address to 12 for mt7530 and 8 for others,
which is based on the default setting for some devices
from printing the register with the following command
after it is written to by uboot during the boot cycle.

`md 0x10117014 1`

PHY_BASE option only uses 5 bits of the register,
bits 16 to 20, so use 8-bit integer type.

Set the option using the DTS property mediatek,ephy-base
and create the gsw node if missing.

Also, added a kernel message to display the EPHY base address.

Note:
If anything is written to a PHY address that is greater than 1 hex char (greater than 0xf)
then there is adverse effects with Atheros switches.

Signed-off-by: Michael Pratt <mcpratt@pm.me>
(cherry picked from commit 0976b6c)
The function mt7620_mdio_mode is only called once
and both the function and mdio_mode block have been named incorrectly,
leading to confusion and useless commits.

These lines in the mdio_mode block of mt7620_hw_init
are only intended for boards with an external mt7530 switch.
(see commit 194ca61)

Therefore, move lines from mdio_mode to the place in soc_mt7620.c
where the type of mt7530 switch is identified,
and move lines from mt7620_mdio_mode to a main function.

mt7620_mdio_mode was called from mt7620_gsw_init
where the priv struct is available,
so the lines must stay in mt7620_gsw_init function.

In order to keep things as simple as possible,
keep the DTS property related function calls together,
by moving them from mt7620_gsw_probe to init.

Remove the now useless DTS properties and extra phy nodes.

Fixes: 5a6229a ("ramips: remove superfluous & confusing DT binding")
Fixes: b85fe43 ("ramips: mt7620: add force use of mdio-mode")
Signed-off-by: Michael Pratt <mcpratt@pm.me>
(cherry picked from commit 6972e49)
Add back the register write to disable internal PHYs
as a separate option in the code that can be set using a DTS property.

Set the option to true by default
when an external mt7530 switch is identified.

This makes the driver more in sync with original SDK code
while keeping the lines separated into different options
to accommodate any board with any PHY layout.

Signed-off-by: Michael Pratt <mcpratt@pm.me>
(cherry picked from commit cc6fd6f)
the register bits for TX delay and RX delay are opposites:
when TX delay bit is set, delay is enabled
when RX delay bit is set, delay is disabled

So, when both bits are unset, it is RX delay
and when both bits are set, it is TX delay

Note: TXID is the default RGMII mode of the SOC

Fixes: 5410a8e ("ramips: mt7620: add rgmii delays support")
Signed-off-by: Michael Pratt <mcpratt@pm.me>
(cherry picked from commit 26c84b2)
Define and use some missing macros,
and use them instead of BIT() or numbers for more readable code.

Add comment for a bit change that seems unrelated to ethernet
but is actually needed (PCIe Root Complex mode).

Remove unknown and unused macro RST_CTRL_MCM
(probably from MT7621 / MT7622)

This is the last of a series of fixes, so bump version.

Signed-off-by: Michael Pratt <mcpratt@pm.me>
(cherry picked from commit 88a0ceb)
These boards have AR8327 or QCA8337 external ethernet switch.
The SOC also has it's own internal switch
where VLAN is now enabled by default.

Changes to preinit caused all switches to have VLANs enabled by default
even if they are not configured with a topology in uci_defaults
(see commit f017f61)

When both internal and external switches have VLANs,
and the external switch has both LAN and WAN,
the TX traffic from the SOC cannot flow to the tagged port on the external switch
because the VLAN IDs are not matching.

So disable the internal switch VLANs by default on these boards.

Also, add a topology for the internal switch,
so that on LuCI there is not an "unknown topology" warning.

In theory, it may be possible to have LAN ports on both switches
through internal and external PHYs, but there are no known boards that have this.

Signed-off-by: Michael Pratt <mcpratt@pm.me>
(cherry picked from commit 2adeada)
@aparcar aparcar added release/21.02 pull request/issue targeted (also) for OpenWrt 21.02 release target/ramips pull request/issue for ramips target labels Jun 24, 2021
@polex
Copy link
Contributor

polex commented Jun 30, 2021

It works on Sitecom WLR-4100 V1 002

@JiiPee74
Copy link
Contributor

JiiPee74 commented Oct 4, 2021

I have been running these changes on my Telewell TW-4G (LTE) router what is clone of lava lr25g001 router which is supported by openwrt.

Switch has been working great, I haven't run any issues.

@polex
Copy link
Contributor

polex commented Nov 16, 2021

Sitecom WLR-4100 did not work in 21.02 without this patch (I tested few months ago).
Did somebody test the last 21.02.00 on similar router?

  • LAVA LR-25G001
  • EnGenius ESR600

I expect they do not work as well.

@polex
Copy link
Contributor

polex commented Apr 6, 2022

I just tested the WLR-4100 V1 002 which does not work without this PR.
The device become unaccessible (UART access for recovery).

@polex
Copy link
Contributor

polex commented Apr 14, 2022

I am waiting for the embedding of this PR, before submitting a new PR for adding WLR-4100 in to 21.02 branch (like i did for Master branch).
The outcome of my test is that Sitecom WLR-4100 v1 002 requires this PR like in the master branch. Without it the device will be bricked and the UART recovery will be needed because the MT7620 losses the connection with QCA83x7 therefore the device cannot be controlled any longer.
I expect the very same behavior from any other MT7620A + AR 83x7 device like:

  • D-Link DWR-961 A1
  • EnGenius ESR600
  • LAVA LR-25G001

In other words those device will be bricked by an update from 19.07 to 21.02.
In my understanding the bricking of those devices is a very good reason for embedding this PR in 21.02.

these 10 commits should be backported after getting enough people to test

I understand @mpratt14 is concerned because this PR may be harmful for others device i.e.:

  • MT7620A alone (i.e.: Ai-BR100, AC1200RM...)
  • MT7620N (i.e.: WMR-300, DWR-921 C1...)
  • MT7620A + other switches (i.e. Edimax BR-6478AC v2, EW-7478APC, ZyXEL Keenetic Viva...)

But I do not expect people with devices above to test this PR, just because they do not need it.

@mpratt14
Copy link
Contributor Author

mpratt14 commented Apr 14, 2022

I'm not "concerned" necessarily but is it "possible"... however the changes have been in master for a while, I would imagine that something wrong would have showed up already

also I don't know how appropriate it is to pull other unrelated commits so that it merges cleanly, or if they actually prefer edited backports

maybe just email the development mail list

@ynezz ynezz self-assigned this Apr 16, 2022
@ynezz ynezz added the ready for merge pull request reviewed and prepared for merge label Apr 16, 2022
@ynezz
Copy link
Member

ynezz commented Apr 19, 2022

Merged, thanks.

@ynezz ynezz closed this Apr 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready for merge pull request reviewed and prepared for merge release/21.02 pull request/issue targeted (also) for OpenWrt 21.02 release target/ramips pull request/issue for ramips target
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants