Commit Graph

3 Commits

Author SHA1 Message Date
Sungbo Eo
1d56a7b75d ramips: mt76x8: fix bogus mediatek,portmap
mt76x8 uses esw_rt3050 driver, which does not accept mediatek,portmap with
string values. Convert the strings to integers to make it work.

According to its switch setup, WRTnode 2P/2R have a WAN port at port 0,
so the correct value should be 0x3e.

tplink_8m.dtsi uses "llllw", but it does not match switch setups of any
device using the DTSI. Remove it from the DTSI and add correct value to DTS
for each device.

These devices have a WAN port at port 0. Set the value to 0x3e.
- tplink,archer-c20-v4
- tplink,archer-c50-v3
- tplink,tl-mr3420-v5
- tplink,tl-wr840n-v4
- tplink,tl-wr841n-v13
- tplink,tl-wr842n-v5

These devices have only one ethernet port. They don't need portmap setting.
- tplink,tl-wa801nd-v5
- tplink,tl-wr802n-v4
- tplink,tl-wr902ac-v3

Signed-off-by: Sungbo Eo <mans0n@gorani.run>
(backported from commit 7a387bf9a0)
[removed TL-WR841N v14 which is not present in 19.07]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-01-21 13:54:18 +01:00
Adrian Schmutzler
62d5ece70b ramips: remove bogus ralink,mtd-eeprom with offset 0x4
Several devices in mt76x8 subtarget use the following line to set
up wmac in their DTS(I) files:

ralink,mtd-eeprom = <&factory 0x4>

This is strange for several reasons:
- They should use mediatek,mtd-eeprom on this SOC
- The caldata is supposed to start at 0x0
- The parent DTSI mt7628an.dtsi specifies mediatek,mtd-eeprom anyway,
  starting from 0x0
- The offset coincides with the default location of the MAC address
  in caldata

Based on the comment in b28e94d4bf ("ramips: MiWiFi Nano fixes"),
it looks like the author for this device wanted to actually use
mtd-mac-address instead of ralink,mtd-eeprom. A check on the same
device revealed that actually the MAC address start at offset 4 there,
so the correct caldata offset is 0x0.

Based on these findings, and the fact that the expected location on
this SOC is 0x0, we remove the "ralink,mtd-eeprom = <&factory 0x4>"
statement from all devices in ramips (being only mt7628an anyway).

Thanks to Sungbo Eo for finding and researching this.

Reported-by: Sungbo Eo <mans0n@gorani.run>
Fixes: b28e94d4bf ("ramips: MiWiFi Nano fixes")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit 09d38a3bc3)
2019-12-28 02:34:41 +01:00
Davide Fioravanti
7c91144ae6 ramips: add CUDY WR1000 support
Cudy WR1200 is an AC1200 AP with 3-port FE and 2 non-detachable antennas

Specifications:

MT7628 (580 MHz)
64 MB of RAM (DDR2)
8 MB of FLASH
2T2R 2.4 GHz (MT7628)
2T2R 5 GHz (MT7612E)
3x 10/100 Mbps Ethernet (2 LAN + 1 WAN)
2x external, non-detachable antennas (5dbi)
UART header on PCB (57600 8n1)
7x LED, 2x button

Known issues:
The Power LED is always ON, probably because it is connected
directly to power.

Flash instructions
------------------
Load the ...-factory.bin image via the stock web interface.

Openwrt upgrade instructions
----------------------------
Use the ...-sysupgrade.bin image for future upgrades.

Revert to stock FW
------------------
Warning! This tutorial will work only with the following OEM FW:
  WR1000_EU_92.122.2.4987.201806261618.bin
  WR1000_US_92.122.2.4987.201806261609.bin
If in the future these firmwares will not be available anymore,
you have to find the new XOR key.

1) Download the original FW from the Cudy website.

   (For example WR1000_EU_92.122.2.4987.201806261618.bin)

2) Remove the header.

   dd if="WR1000_EU_92.122.2.4987.201806261618.bin" of="WR1000_EU_92.122.2.4987.201806261618.bin.mod" skip=8 bs=64

3) XOR the new file with the region key.

   FOR EU: 7B76741E67594351555042461D625F4545514B1B03050208000603020803000D
   FOR US: 7B76741E675943555D5442461D625F454555431F03050208000603060007010C

   You can use OpenWrt's tools/firmware-utils/src/xorimage.c tool for this:

   xorimage -i WR1000..bin.mod -o stock-firmware.bin -x -p 7B767..

   Or, you can use this tool (CHANGE THE XOR KEY ACCORDINGLY!):
   https://gchq.github.io/CyberChef/#recipe=XOR(%7B'option':'Hex','string':''%7D,'',false)

4) Check the resulting decrypted image.

   Check if bytes from 0x20 to 0x3f are:
   4C 69 6E 75 78 20 4B 65 72 6E 65 6C 20 49 6D 61 67 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00

   Alternatively, you can use u-boot's tool dumpimage tool to check
   if the decryption was successful. It should look like:

   # dumpimage -l stock-firmware.bin
   Image Name:   Linux Kernel Image
   Created:      Tue Jun 26 10:24:54 2018
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    4406635 Bytes = 4303.35 KiB = 4.20 MiB
   Load Address: 80000000
   Entry Point:  8000c150

5) Flash it via forced firmware upgrade and don't "Keep Settings"

   CLI: sysupgrade -F -n stock-firmware.bin

   LuCI: make sure to click on the "Keep settings" checkbox
         to disable it. You'll need to do this !TWICE! because
         on the first try, LuCI will refuse the image and reset
	 the "Keep settings" to enable. However a new
         "Force upgrade" checkbox will appear as well.
         Make sure to do this very carefully!

Signed-off-by: Davide Fioravanti <pantanastyle@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
[added wifi compatible, spiffed-up the returned to stock instructions]
2019-05-31 10:36:36 +02:00