aboutsummaryrefslogtreecommitdiff
path: root/target/linux/ramips/dts/mt7621_tplink_archer-c6u-v1.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: clean up useless dts partition labelsShiji Yang2024-02-21
| | | | | | | | | | The previous NVMEM eeprom conversions[1][2] left a lot of partition labels that were no longer used. They can be removed now. [1] https://github.com/openwrt/openwrt/pull/13584 [2] https://github.com/openwrt/openwrt/pull/13587 Signed-off-by: Shiji Yang <yangshiji66@qq.com>
* ramips: convert to new LED color/function format where possibleChristian Marangi2024-02-07
| | | | | | | | Initial conversion to new LED color/function format and drop label format where possible. The same label is composed at runtime. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
* ramips: mt7621: nix mac-address-incrementRosen Penev2023-11-26
| | | | | | nvmem-layout allows removal Signed-off-by: Rosen Penev <rosenp@gmail.com>
* ramips: mt7621: convert to nvmem-layoutRosen Penev2023-11-26
| | | | | | Allows replacing mac-address-increment with mac-base. Signed-off-by: Rosen Penev <rosenp@gmail.com>
* ramips: convert MT7613 and MT7615 EEPROM to NVMEM format for MT7621Shiji Yang2023-10-09
| | | | | | | This patch converts MT7613 and MT7615 WiFi calibration data to NVMEM format. The EEPROM size is 0x4da8. Signed-off-by: Shiji Yang <yangshiji66@qq.com>
* ramips: convert MT7603 EEPROM to NVMEM formatShiji Yang2023-10-09
| | | | | | | This patch converts MT7603 WiFi calibration data to NVMEM format. The EEPROM size is 0x400. Signed-off-by: Shiji Yang <yangshiji66@qq.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: mt7621-dts: do not claim rgmii2 group as gpio for certain devicesArınç ÜNAL2022-08-20
| | | | | | | | | | | | | | | These devices do not use rgmii2 as gpio, therefore remove rgmii2 pin group from state-default. Remove overwriting the ethernet node for these devices. Move claiming the rgmii2 group from mt7621_zyxel_nwa-ax.dtsi to mt7621_zyxel_nwa50ax.dts as it's only the latter using rgmii2 pins as gpio. Remove duplicate ethernet overwrite from mt7621_tplink_archer-x6-v3.dtsi. Claim rgmii2 group as gpio on mt7621_bolt_arion.dts as it uses an rgmii2 pin, 26, as gpio. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
* ramips: convert mtd-mac-address to nvmem implementationAnsuel Smith2021-07-19
| | | | | | | 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>
* ramips: add support for TP-Link Archer C6U v1 (EU)Georgi Vlaev2021-05-26
This patch adds support for TP-Link Archer C6U v1 (EU). The device is also known in some market as Archer C6 v3. This patch supports only Archer C6U v1 (EU). Specifications: -------------- * SoC: Mediatek MT7621AT 2C2T, 880MHz * RAM: 128MB DDR3 * Flash: 16MB SPI NOR flash (Winbond 25Q128) * WiFi 5GHz: Mediatek MT7613BEN (2x2:2) * WiFi 2.4GHz: Mediatek MT7603EN (2x2:2) * Ethernet: MT7630, 5x 1000Base-T. * LED: Power, WAN, LAN, WiFi 2GHz and 5GHz, USB * Buttons: Reset, WPS. * UART: Serial console (115200 8n1), J1(GND:3) * USB: One USB2 port. Installation: ------------ Install the OpenWrt factory image for C6U is from the TP-Link web interface. 1) Go to "Advanced/System Tools/Firmware Update". 2) Click "Browse" and upload the OpenWrt factory image: openwrt-ramips-mt7621-tplink_archer-c6u-v1-squashfs-factory.bin. 3) Click the "Upgrade" button, and select "Yes" when prompted. Recovery to stock firmware: -------------------------- The C6U bootloader has a failsafe mode that provides a web interface (running at 192.168.0.1) for reverting back to the stock TP-Link firmware. The failsafe interface is triggered from the serial console or on failed kernel boot. Unfortunately, there's no key combination that enables the failsafe mode. This gives us two options for recovery: 1) Recover using the serial console (J1 header). The recovery interface can be selected by hitting 'x' when prompted on boot. 2) Trigger the bootloader failsafe mode. A more dangerous option is force the bootloader into recovery mode by erasing the OpenWrt partition from the OpenWrt's shell - e.g "mtd erase firmware". Please be careful, since erasing the wrong partition can brick your device. MAC addresses: ------------- OEM firmware configuration: D8:07:B6:xx:xx:83 : 5G D8:07:B6:xx:xx:84 : LAN (label) D8:07:B6:xx:xx:84 : 2.4G D8:07:B6:xx:xx:85 : WAN Signed-off-by: Georgi Vlaev <georgi.vlaev@konsulko.com>