TP-LINK Omada ER605 v2

From TechInfoDepot
Jump to navigationJump to search
multiple revisions of this device, use caution
Omada Gigabit VPN Router
Homepage Product page
Wikipedia TP-Link
WikiDevi.wi-cat.ru TP-LINK Omada ER605
3rd Party Firmware
dd-wrt Status Unknown
OpenWrt Supported
Tomato any flavor Incompatible
Gargoyle Status Unknown
Platform
BrandModelRev TP-LINK ER605 v2.6
Serial number prefix Y23C
Board ID 2021500457
Type VPN Router
CPU1 checkY MediaTek MT7621AT
CPU1 Type MIPS 1004Kc
CPU1 Speed 880 MHz ( 2 cores ) 16-bit
Flash1 Chip ESMT F59L1G81MB-25T
Flash1 Size 128 MiB 134,217,728 B <br />1,048,576 Kib <br />131,072 KiB <br />1,024 Mib <br />0.125 GiB <br />
RAM1 Size 256 MiB 268,435,456 B <br />2,097,152 Kib <br />262,144 KiB <br />2,048 Mib <br />0.25 GiB <br />
RAM1 Chip Zentel A3T2GF40CBF-HP
ETH chip1 MediaTek MT7621AT
Switch MediaTek MT7621AT
Ethernet Port Count 2-1GbE-WAN
3-1GbE-LAN
Wired Standard IEEE 802.3i/3u/3ab
802.1q vlan Yes

Ethernet OUI: 98:25:4A

Stock bootloader U-Boot 2018.09
Stock FW OS Linux 4.4.198
Expansion IF types USB 2.0
USB ports 1
USB Hub Compatible Untested
Power 12 VDC, 1 A
Connector type barrel
5.5 mm (OD)
2.1 mm (ID)
9.5 mm (LEN)
Serial Port (UART) yes, 4-pln header, unpopulated, 3.3V TTL, (115200 8N1), J1
JTAG Port no

Flags:
heatsink, metal case

Other

Default IP address: 192.168.0.1
the IP 192.168.0.1 is used by 825 additional devices
of which 110 are TP-LINK devices

3rd Party Firmware Support OpenWrt • (List | Dev | DLs)
Retail
(Est.) release date December 2020
UPC 845973089597
(UPC DB, On eBay)
Newegg 9SIA8UCK888295
ASIN B08QTXNWZ1
Country of manuf Vietnam
Physical
Buttons 1
LEDs/Color 3
 CPU1 brandFLA1RAM1
TP-LINK Omada ER605 v1MediaTek16 MiB16,777,216 B <br />131,072 Kib <br />16,384 KiB <br />128 Mib <br />0.0156 GiB <br />128 MiB134,217,728 B <br />1,048,576 Kib <br />131,072 KiB <br />1,024 Mib <br />0.125 GiB <br />
TP-LINK Omada ER605 v2MediaTek128 MiB134,217,728 B <br />1,048,576 Kib <br />131,072 KiB <br />1,024 Mib <br />0.125 GiB <br />256 MiB268,435,456 B <br />2,097,152 Kib <br />262,144 KiB <br />2,048 Mib <br />0.25 GiB <br />

For a list of all currently documented MediaTek chipsets with specifications, see MediaTek.

For a list of all currently documented TP-LINK devices with specifications, see TP-LINK.

Overview

Hardware specification

SoC: Dual-core MIPS (1004Kc)
  • Flash: 128MB NAND
  • Memory: 256MB DDR3 (SDRAM)
  • Network: 5x GbE port
  • USB: 1x USB 2.0 port
  • Power Source: 12V/1A via barrel

Flashing

Flashing OpenWrt

Target: ramips
Subtarget: mt7621
Package architecture: mipsel_24kc
Supported Since Commit
Support started version: 23.05.0
Current supported version: 25.12.2
LAN Hardware: MediaTek MT7621AT
WLAN Hardware: none
Installation method(s):
see devicepage
Recovery method(s):
see devicepage
Comment:
v2, v2.0, v2.20, v2.26, v2.28, v2.30, v2.36, v2.38, v2.6, v2.8
git • >>
ramips: Fix root volume for tplink-er605-v2
This device has two sets of volumes: main ones (`kernel`, `rootfs`, etc) and
'backup' (`kernel.b`, `rootfs.b`, etc). Bootloader tries to determine which set of
volumes to use by looking at contens of `extra-para` and `extra-para.b` volumes.
These volumes contain JSON that looks like this:

```
{
	"dbootFlag": "1",
	"integerFlag": "1",
	"fwFlag": "GOOD",
	"score":1
}
```

It looks like the bootloader looks for `"fwFlag": "GOOD"` (as opposed to `BAD`)
then it compares `score` field - whichever 'good' volume has bigger score wins.
This determines which set of volumes to use to boot.

So for example if `extra-para` is good and has bigger score then `kernel`,
`rootfs`, etc volumes are used. This means bootloader needs to explain to the
kernel which volume to use for the rootfs. After looking at bootloader code with
disassembler I think it contains a bug. Relevant part of code looks something
like this:

```
  if (image_id == 0) {
    rootfs_volume_id = 8;
    rootfs_volume_name = "rootfs";
  }
  else {
    rootfs_volume_id = 0xf;
    rootfs_volume_name = "rootfs.b";
  }
  sprintf(
    &buffer,
    0x800,
    "console=ttyS0,115200 noinitrd ubi.mtd=3,2048 ubi.block=0,%s
    root=/dev/ubiblock0_%d DKMGT_IMAGE_ID=%d DKMGT_IMAGE_TYPE=ubi",
    rootfs_volume_name,
    rootfs_volume_id,
    image_id
    );
```

Where `image_id == 0` if 'normal' (not '*.b' set of volumes is used).
However from device dumps we know that from the factory `rootfs.b` has id 8 and
`rootfs` has id 15.

So from above we can see that ids and names of rootfs volumes do not match. More
over - they are hardcoded in the bootloader.

Both things are problematic for OpwnWRT which completely removes volumes on
update meaning that volume ids may actually change.

So instead of relying on bootloader to provide the kernel with root device this
patch forces kernel to determine root automatically - and it defaults to
`rootfs` volume which is correct for our purposes.

Overall this makes image boot fine from flash after sysupgrade from inirams.
assuming `extra-para*` volumes make bootloader use non-'*.b' set of volumes.

Pictures

Retail Images
User Images