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>
* Remove micro-DTSI mt7621_dlink_dir-882-x1.dtsi to ease reading
config without too much inheritance
* Use "separate" partitioning DTSIs so we can use the partitioning
without a complete match on the other settings (i.e. without the
former parent DTSI)
* Rename files to express the new organization
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
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>
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>
This patch adds support for D-Link DIR-867 A1 and D-Link DIR-882 A1. Given
the similarity of these devices, this patch also introduces a common DTS
shared between DIR-867 A1, DIR-878 A1 and DIR-882 A1.
Specifications:
* Board: AP-MTKH7-0002
* SoC: MediaTek MT7621AT
* RAM: 128 MB (DDR3)
* Flash: 16 MB (SPI NOR)
* WiFi: MediaTek MT7615N (x2)
* Switch: 1 WAN, 4 LAN (Gigabit)
* Ports: 1 USB 2.0, 1 USB 3.0
* Buttons: Reset, WiFi Toggle, WPS
* LEDs: Power (green/orange), Internet (green/orange), WiFi 2.4G (green),
WiFi 5G (green), USB 2.0 (green), USB 3.0 (green)
Notes:
* WiFi 2.4G and WiFi 5G LEDs are wired directly to the wireless chips
* DIR-867 wireless chips are limited to 3x3 streams at hardware level
* USB ports and related LEDs available only on DIR-882
Serial port:
* Parameters: 57600, 8N1
* Location: J1 header (close to the Reset, WiFi and WPS buttons)
* Pinout: 1 - VCC
2 - RXD
3 - TXD
4 - GND
Installation:
* D-Link Recovery GUI: power down the router, press and hold the reset
button, then re-plug it. Keep the reset button pressed until the power
LED starts flashing orange, manually assign a static IP address under
the 192.168.0.xxx subnet (e.g. 192.168.0.2) and go to http://192.168.0.1
* Some modern browsers may have problems flashing via the Recovery GUI,
if that occurs consider uploading the firmware through cURL:
curl -v -i -F "firmware=@file.bin" 192.168.0.1
Signed-off-by: Mateus B. Cassiano <mbc07@live.com>
[move DEVICE_VARIANT to individual definitions]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Specifications:
SoC: MT7621AT
RAM: 128MB
Flash: 16MB NOR SPI flash
WiFi: MT7615N (2.4GHz) and MT7615N (5Ghz)
LAN: 5x1000M
Firmware layout is Uboot with extra 96 bytes in header
Base PCB is AP-MTKH7-0002
LEDs Power Green,Power Orange,Internet Green,Internet Orange
LEDs "2.4G" Green & "5G" Green connected directly to wifi module
Buttons Reset,WPS,WIFI
Flashing instructions:
Upload image via emergency recovery mode
Push and hold reset button (on the back of the device) until power led
starts flashing (about 10 secs or so) while powering the device on.
Give it ~30 seconds, to boot the recovery mode GUI
Connect your client computer to LAN1 of the device
Set your client IP address manually to 192.168.0.2 / 255.255.255.0.
Call the recovery page for the device at http://192.168.0.1
Use the provided emergency web GUI to upload and flash a new firmware to
the device. Some browsers/OS combinations are known not to work, so if
you don't see the percentage complete displayed and moving within a few
seconds, restart the procedure from scratch and try anoher one,
or try the command line way.
Alternative method using command line on Linux:
curl -v -i -F "firmware=@openwrt-xxxx-squashfs-factory.bin" 192.168.0.1
Signed-off-by: Mathieu Martin-Borret <mathieu.mb@protonmail.com>
[use of generic uimage-padhdr in image generation code]
Signed-off-by: Petr Štetiar <ynezz@true.cz>