TP-LINK Festa FR205
From TechInfoDepot
Jump to navigationJump to search
| Festa Gigabit VPN Router | |
|
| |
| Homepage | Product page |
|---|---|
| Wikipedia | TP-Link |
| WikiDevi.wi-cat.ru | TP-LINK Festa FR205 |
| 3rd Party Firmware | |
| dd-wrt | Status Unknown |
| OpenWrt | Supported |
| Tomato any flavor | Incompatible |
| Gargoyle | Status Unknown |
| Platform | |
| Brand • Model • Rev | TP-LINK Festa FR205 v1.0 |
| Board ID | 2021500457 |
| Type | VPN Router |
| CPU1 | 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 /> (NAND) |
| 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 /> (DDR3 SDRAM) |
| 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 |
|
Ethernet OUI: 40:AE:30 | |
| Stock bootloader | U-Boot 2018.09 |
| Stock FW OS | Linux 4.4.198 OpenWrt |
| 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-pin header, unpopulated, J1, 3.3V TTL, (115200 8N1) |
|
Flags: | |
|
| |
| Other | |
|
Default IP address: 192.168.0.1 | |
| 3rd Party Firmware Support |
OpenWrt • (List | Dev | DLs) |
| Retail | |
| (Est.) release date | July 2024 |
| UPC |
810142820707 (UPC DB, On eBay) |
| Newegg | 9SIA8UCKC44566 |
| ASIN |
B0D8M7RHZ3 |
| Country of manuf | China |
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
This device appears to be a re-labeled TP-LINK Omada ER605 v2 as
- the hardware is identical right down to the PCB ID.
Hardware specification
- CPU: MediaTek MT7621AT @880MHz
- SoC: Dual-core MIPS (1004Kc)
- Flash: 128MB (NAND) flash
- Memory: 256MB (DDR3) SDRAM
- Network: 5x GbE ports
- USB: 1x USB 2.0 port
- Power Source: 12V/1A via barrel
Flashing
| NOTE: During configuration or flashing a device, the only things that should be hooked to the device is the computer and power. |
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
Subtarget: mt7621
Package architecture: mipsel_24kc
Supported Since Commit
Support started version: 23.05.0
Current supported version: 25.12.2
LAN Hardware: MediaTek MT7530 in MT7621AT
WLAN Hardware: none
WLAN Comment: No WLAN
Installation method(s):
see devicepage
Install Comment:
Re-labeled ER605 v2, uses identical OpenWrt firmware and instructions
Recovery method(s):
see devicepage
Comment:
Disabled because kernel to big for uboot see https://git.openwrt.org/openwrt/openwrt/commit/?id=2cce634a9e63d25cd23ab30e86263eed3bce4f3e
WLAN Hardware: none
WLAN Comment: No WLAN
Installation method(s):
see devicepage
Install Comment:
Re-labeled ER605 v2, uses identical OpenWrt firmware and instructions
Recovery method(s):
see devicepage
Comment:
Disabled because kernel to big for uboot see https://git.openwrt.org/openwrt/openwrt/commit/?id=2cce634a9e63d25cd23ab30e86263eed3bce4f3e
| 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
See also
- TP-LINK Festa FR205 • VPN (B0D8M7RHZ3)
- TP-LINK Festa FR365 • AX3000 (B0D8M44Q91)
- TP-LINK Omada ER605 v2 • VPN (B08QTXNWZ1)