Commit Graph

12 Commits

Author SHA1 Message Date
Arınç ÜNAL
3ea6125c50 ramips: mt7621-dts: describe switch PHYs and adjust PHY muxing
Currently, the MT7530 DSA subdriver configures the MT7530 switch to provide
direct access to switch PHYs, meaning, the switch PHYs listen on the MDIO
bus the switch listens on. The PHY muxing feature makes use of this.

This is problematic as the PHY may be attached before the switch is
initialised, in which case, the PHY will fail to be attached.

Since commit 91374ba537bd ("net: dsa: mt7530: support OF-based registration
of switch MDIO bus") on mainline Linux, we can describe the switch PHYs on
the MDIO bus of the switch on the device tree.

When the PHY is described this way, the switch will be initialised first,
then the switch MDIO bus will be registered. Only after these steps, the
PHY will be attached.

Describe the switch PHYs on mt7621.dtsi and remove defining the switch PHY
on the SoC's mdio bus node. When the PHY muxing is in use, the interrupts
for the muxed PHY won't work, therefore delete the "interrupts" property on
the devices where the PHY muxing feature is in use.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
2024-05-01 13:50:54 +01:00
Arınç ÜNAL
f1c9afd801 ramips: mt7621-dts: mux phy0/4 to gmac1
Mux the MT7530 switch's phy0/4 to the SoC's gmac1 on devices where RGMII2
pins are available. This achieves 2 Gbps total bandwidth to the CPU using
the second RGMII.

The ports called "wan" are muxed where possible. On a minority of devices,
this is not possible. Those cases:

mt7621_ampedwireless_ally-r1900k.dts: lan3
mt7621_ubnt_edgerouter-x.dts: eth0
mt7621_gnubee_gb-pc1.dts: ethblue
mt7621_linksys_re6500.dts: lan1
mt7621_netgear_wac104.dts: lan4
mt7621_tplink_eap235-wall-v1.dts: lan0
mt7621_tplink_eap615-wall-v1.dts: lan0
mt7621_ubnt_usw-flex.dts: lan1

The "wan" port is just what the vendor designated on the board/plastic
chasis of the device. On a technical level, there is no difference between
a lan and wan port on MT7621AT, MT7621DAT and MT7621ST SoCs. Prefer
connecting to WAN via the port described above for these devices to benefit
the feature brought with this patch.

mt7621_d-team_newifi-d2.dts cannot benefit this feature, although it looks
like it should, because the rgmii2 pins are wired to unused components.

Tested on a range of devices documented on the GitHub PR.

Link: https://github.com/openwrt/openwrt/pull/10238
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
2022-08-20 22:56:12 +02:00
Adrian Schmutzler
c846dd91f0 ramips: remove model name from LED labels
Like in the previous patch for ath79 target, this will remove the
"devicename" from LED labels in ramips as well.

The devicename is removed in DTS files and 01_leds, consolidation
of definitions into DTSI files is done where (easily) possible,
and migration scripts are updated.

For the latter, all existing definitions were actually just
devicename migrations anyway. Therefore, those are removed and
a common migration file is created in target base-files. This is
actually another example of how the devicename removal makes things
easier.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-10-02 14:51:57 +02:00
Adrian Schmutzler
621297e867 ramips: move dts-v1 statement to top-level DTSI files
The "/dts-v1/;" identifier is supposed to be present once at the
top of a device tree file after the includes have been processed.

In ramips, we therefore requested to have in the DTS files so far,
and omit it in the DTSI files. However, essentially the syntax of
the parent mtxxxx/rtxxxx DTSI files already determines the DTS
version, so putting it into the DTS files is just a useless repetition.

Consequently, this patch puts the dts-v1 statement into the top-level
SoC-based DTSI files, and removes all other occurences.
Since the dts-v1 statement needs to be before any other definitions,
this also moves the includes accordingly where necessary.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-09-25 23:26:40 +02:00
John Thomson
74438d5419 ramips: add support for MikroTik RouterBOARD 760iGS (hEX S)
This patch adds support for the MikroTik RouterBOARD 760iGS router.
It is similar to the already supported RouterBOARD 750Gr3.
The 760iGS device features an added SFP cage, and passive
PoE out on port 5 compared to the RB750Gr3.

https://mikrotik.com/product/hex_s

Specifications:

- SoC: MediaTek MT7621A
- CPU: 880MHz
- Flash: 16 MB
- RAM:  256 MB
- Ethernet: 5x 10/100/1000 Mbps
- SFP cage
- USB port
- microSD slot

Unsupported:

- Beeper (requires PWM driver)
- ZT2046Q (ADS7846 compatible) on SPI as slave 1 (CS1)
  The linux driver requires an interrupt, and pendown GPIO
  These are unknown, and not needed with the touchscreen
  only used for temperature and voltage monitoring.
  ads7846 hwmon:
  temp0 is degrees Celsius
  temp1 is voltage * 32

GPIOs:

- 07:  input passive PoE out (lan5) compatible (Mikrotik) device connected
- 17:  output passive PoE out (lan5) switch

Installation through RouterBoot follows the usual MikroTik method
https://openwrt.org/toh/mikrotik/common

To boot to intramfs image in RAM:

1. Setup TFTP server to serve intramfs image.
2. Plug Ethernet cable into WAN port.
3. Unplug power, hold reset button and plug power in.
   Wait (~25 seconds) for beep and then release reset button.
   The SFP LED will be lit in RouterBoot, but will not be lit in OpenWRT.
4. Wait for a minute. Router should be running OpenWrt,
   check by plugging in to port 2-5 and going to 192.168.1.1.

To install OpenWrt to flash:

1. Follow steps above to boot intramfs image in RAM.
2. Flash the sysupgrade.bin image with web interface or sysupgrade.
3. Once the router reboots you will be running OpenWrt from flash.

OEM firmware differences:

- RouterOS assigns a different MAC address for each port
- The first address (E01 on the sticker) is used for wan (ether1 in OEM).
- The next address is used for lan2.
- The last address (E06 on the sticker) is used for sfp.

[Initial port work, shared dtsi]
Signed-off-by: Vince Grassia <vincenzo.grassia@zionark.com>
[SFP support and GPIO identification]
Signed-off-by: Luka Logar <luka.logar@iname.com>
[Misc. fixes and submission]
Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
[rebase, drop uart3 from state_default on 750gr3, minor commit
title/message facelift]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-08-13 12:47:45 +02:00
Adrian Schmutzler
ddf3e5c22d ramips/mt7621: create common DTSI for Mikrotik devices
This moves some common definitions for Mikrotik devices, mainly
routerboot partitions and reset key, to a common DTSI file.

While at it, remove unused hard_config DT label.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-08-13 12:47:45 +02:00
John Thomson
2d9db93397 ramips: use gpio-export for Mikrotik RouterBOARD 750Gr3 beeper
This beeper hardware requires a PWM driver for frequency selection.
Since the GPIO driver does not provide that, revert the beeper
support to a simple gpio-export.

This effectively reverts the corresponding changes from
6ba58b7b02 ("ramips: cleanup the RB750Gr3 support")

Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
[commit title/message facelift]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-08-13 02:12:12 +02:00
Adrian Schmutzler
5549b84388 ramips: drop useless label-mac-device for RouterBOARD 750Gr3
With the new driver, MAC addresses are not set up in DTS anymore,
and therefore label-mac-device will be useless there.

Setup is done properly in 02_network, so this just removes the
obsolete alias.

Fixes: 5e50515fa6 ("ramips/mt7621: mikrotik: don't use
mtd-mac-address in DTS")

Suggested-by: John Thomson <git@johnthomson.fastmail.com.au>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-06-13 13:53:27 +02:00
Thibaut VARÈNE
5e50515fa6 ramips/mt7621: mikrotik: don't use mtd-mac-address in DTS
As evidenced here[1] the device MAC address can be stored at a random
offset in the hard_config partition. Rely on sysfs to update the MAC
address correctly.

Adjust config so that WAN is base MAC and LAN is base MAC +1 to better
match label and vendor OS.

[1] https://github.com/openwrt/openwrt/pull/2850#issuecomment-610809021

Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
2020-05-08 15:17:18 +02:00
Thibaut VARÈNE
21869e8f80 ramips: mikrotik: use routerbootpart partitions
Enable routerbootpart partitions on MikroTik devices.

Tested-by: Tobias Schramm <t.schramm@manjaro.org>
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
2020-05-08 15:17:17 +02:00
DENG Qingfang
a10537f674 ramips: fix MikroTik 750Gr3 ports MAC addresses
According to a user in OpenWrt forum, on RouterOS the MAC addresses are
ether1(WAN) = MAC
ether2(LAN2) = MAC+1
ether3(LAN3) = MAC+2
etc.

Fix the MAC addresses in OpenWrt.

Ref: https://forum.openwrt.org/t/few-dumb-question-about-mt7530-rb750gr3-dsa/61608
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
[remove label_mac in 02_network]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-04-28 10:57:17 +02:00
Adrian Schmutzler
f761f4052c ramips: mt7621: harmonize naming scheme for Mikrotik
So far, image/device/board names for Mikrotik devices in mt7621 have
been used quite inconsistently.

This patch harmonizes the naming scheme by applying the same style
as used lately in ath79, i.e. using "RouterBOARD" as separate word
in the model name (instead of RB prefix for the number) and deriving
the board/device name from that (= make lower case and replace spaces
by hyphens).

This style has already been used for most the model/DEVICE_MODEL
variables in mt7621, so this is essentially just adjusting the remaining
variables to that.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-04-08 13:46:30 +02:00