aboutsummaryrefslogtreecommitdiff
path: root/target/linux/ramips/dts/mt7621_iptime_a6004ns-m.dtsi
Commit message (Collapse)AuthorAge
* ramips: limit max spi clock frequency to 50 MHzShiji Yang2024-07-10
| | | | | | | | | | In the past few years, we have received several reports about SPI Flash not working properly. This is caused by excessively fast clock frequency. It's really annoying to fix them one by one. Let's reduce these aggressive frequencies to 50 MHz. This is a safe and suggested value in the vendor SDK. Signed-off-by: Shiji Yang <yangshiji66@qq.com>
* 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: 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: 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: add support for ipTIME A6004NS-MSeongUk Moon2022-01-15
ipTIME A6004NS-M is a 2.4/5GHz band AC1900 router, based on MediaTek MT7621A. Specifications: - SoC: MediaTek MT7621A (880MHz, Duel-Core) - RAM: DDR3 256MB - Flash: SPI NOR 16MB (Winbond W25Q128BV) - WiFi: MediaTek MT7615E (2.4GHz, 5GHz) - Ethernet: MediaTek MT7530 (WAN x1, LAN x4, SoC built-in Estimated) - USB: USB 3.0 x1 - UART: [3.3V, TX, RX, GND] (57600 8N1) Installation via web interface: 1. Flash initramfs image using OEM's Firmware Update page. 2. Connect to OpenWrt with an SSH connection to `192.168.1.1`. 3. Perform sysupgrade with sysupgrade image. Revert to stock firmware: 1. Flash stock firmware via OEM's Recovery mode How to use OEM's Recovery mode: 1. Power on the device and connect the shell through UART. 2. Connect to the shell and press the `t` key on the keyboard. 3. Set fixed IP with `192.168.0.2` with subnet mask `255.255.255.0` 4. Flash image via TFTP to `192.168.0.1` Additional Notes: 1. The higher the 5Ghz Frequency, the lower the stability. It is recommended to use less than 5.775Ghz. 2. If the 5Ghz frequency is too high, 5Ghz may not work. 3. A6ns-M use shared dtsi file of A6004NS-M. (reference: /mt7621_iptime_a6004ns-m.dtsi). Signed-off-by: SeongUk Moon <antegral@antegral.net> [convert CRLF to LF] Signed-off-by: Sungbo Eo <mans0n@gorani.run>