aboutsummaryrefslogtreecommitdiff
path: root/target/linux/ramips/dts/mt7621_mikrotik_routerboard-750gr3.dts
Commit message (Collapse)AuthorAge
* ramips: mt7621-dts: describe switch PHYs and adjust PHY muxingArınç ÜNAL2024-05-01
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* ramips: mt7621-dts: mux phy0/4 to gmac1Arınç ÜNAL2022-08-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ramips: remove model name from LED labelsAdrian Schmutzler2020-10-02
| | | | | | | | | | | | | | | | | 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>
* ramips: move dts-v1 statement to top-level DTSI filesAdrian Schmutzler2020-09-25
| | | | | | | | | | | | | | | | | 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>
* ramips: add support for MikroTik RouterBOARD 760iGS (hEX S)John Thomson2020-08-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ramips/mt7621: create common DTSI for Mikrotik devicesAdrian Schmutzler2020-08-13
| | | | | | | | | 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>
* ramips: use gpio-export for Mikrotik RouterBOARD 750Gr3 beeperJohn Thomson2020-08-13
| | | | | | | | | | | | | 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 6ba58b7b020c ("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>
* ramips: drop useless label-mac-device for RouterBOARD 750Gr3Adrian Schmutzler2020-06-13
| | | | | | | | | | | | | | 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: 5e50515fa6b3 ("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>
* ramips/mt7621: mikrotik: don't use mtd-mac-address in DTSThibaut VARÈNE2020-05-08
| | | | | | | | | | | | | 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>
* ramips: mikrotik: use routerbootpart partitionsThibaut VARÈNE2020-05-08
| | | | | | | Enable routerbootpart partitions on MikroTik devices. Tested-by: Tobias Schramm <t.schramm@manjaro.org> Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
* ramips: fix MikroTik 750Gr3 ports MAC addressesDENG Qingfang2020-04-28
| | | | | | | | | | | | | | | 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>
* ramips: mt7621: harmonize naming scheme for MikrotikAdrian Schmutzler2020-04-08
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>