Topic: TRENDnet AC2600 (TEW-827DRU)

The content of this topic has been archived between 25 Mar 2018 and 29 Apr 2018. Unfortunately there are posts – most likely complete pages – missing.

Page 1 of 6

Post #1

jmomo

2 Jul 2016, 02:15

Device Support Status Report
See edited date above for last update

This device is end-user ready. Wired and wireless works, most LEDs work, buttons work, and factory image installation works. Testing has shown the system to be very stable, even under load. However, there are a few issues -- see below.

LEDE Project has previously rejected all of my patches thus far and I don't see any situation where it's possible to get them merged so I gave up trying. If someone else wants to take my work and move on with it, you are welcome to do so.

----------------------------------------------------------------------------------------------------

Current Known Issues

If a USB3 flash drive is already in one of the USB ports when the device boots, then USB3 devices won't work in that port until the next reboot. This issue has apparently now been confirmed on other devices using the same IPQ806x SoC chip, so it's a driver issue and not hardware specific. Also, apparently, work has been done on the driver upstream and eventually those fixes will get merged into LEDE, so this will probably get fixed some day. There has been some work merged in on this already, but I am under the impression it's not 100% fixed yet.

802.11/wireless activity LEDs don't work. Waiting on the ath10k driver to get fixed. Multiple other devices are also waiting on this.

Only one of the two possible factory installation methods currently works. We can't install via the OEM web interface yet because the install will revert after next reboot. However, there is a recovery loader in u-boot which is easier to use anyway, so we can and should install our image that way instead.

The "LED on/off" button can't be made to work because we currently can't shut off the ethernet switch port LEDs. This may be fixed in the future if I am able to support it.

----------------------------------------------------------------------------------------------------

Future Plans

JTAG recovery. It may be possible to recover from JTAG by booting from RAM or programming the NAND flash on this device. I've already experimented with this but I've not yet figured everything out.

Expand the NAND partitions, or otherwise fully use the NAND flash space. The default "rootfs" partition is 64MB in size, but there is 108MB of completely-unused space on the NAND flash, outside of smem/mtd partitions. There is also an additional 64MB of space used by the redundant rootfs_1 partition. It may eventually be possible to have a rootfs file-system of 228MB in size.

Custom u-boot. This depends upon being able to safely recover. We would need either TRENDnet's broken "Fail Safe" system to be fixed, or JTAG recovery. Otherwise the risk of permanently breaking the device is too great.

Boot from USB. This is not possible right now because the OEM u-boot wasn't built with the right modules, but it is possible. This depends upon building a custom u-boot.

----------------------------------------------------------------------------------------------------

Builds

You can download my builds and patches here:

http://jmomo.net/files/lede/

The minimal builds are minimal defaults. You have 45MB of free space on the overlay to work with. No LuCi web interface or anything else. Install the packages you need with opkg.

The big builds have a bunch of extra packages built in: LuCi-ssl, nmap, bash,vim-full, openssl, openvpn, strongswan, full-versions of common tools usually in busybox, horst, and some drivers that I use. There is still 35MB of free space on the overlay, so plenty of space left over for more packages.

Install the factory image using this using the "RECOVERY INSTRUCTIONS" documented below. DO NOT use the TRENDnet OEM web interface system to flash the file. If you do, it will revert to the OEM system on the second boot, or it might not work at all.

To get back to the OEM system, just use the same recovery tool again and flash the TRENDnet OEM firmware instead (TEW827DRU_FW100B11.bin).

The latest builds are based off the LEDE v17.01.0 release. The patch set for this build is v6.

Minimal factory image is here:
http://jmomo.net/files/lede/TRENDnet_TE … actory.bin

Minimal sysupgrade is here:
http://jmomo.net/files/lede/TRENDnet_TE … pgrade.tar

Big build factory image is here:
http://jmomo.net/files/lede/TRENDnet_TE … actory.bin

Big build sysupgrade is here:
http://jmomo.net/files/lede/TRENDnet_TE … pgrade.tar

I removed older builds since they were pre-release anyway.

(Last edited by jmomo on 20 Mar 2017, 12:48)

Post #2

jmomo

2 Jul 2016, 02:24

Additional Resources:

Image gallery of the TEW-827DRU board/internals:
http://imgur.com/a/5cSfg

WikiDevi page for this device:
https://wikidevi.com/wiki/TRENDnet_TEW-827DRU_v1.0R

LEDE Project nightly snapshot builds (WARNING: Sometimes snapshots are broken, be careful)
https://downloads.lede-project.org/snap … x/generic/

Qualcomm Atheros Announces New Internet Processor Category - IPQ8064 and IPQ8062
Old Anandtech news article about the ipq806x SoCs

This combo of ipq806x + qca8990 is fairly prolific. There are a large number of other similar devices:

Support for TP-Link Archer C2600
This is the OpenWrt forum thread for the TP-Link version of this device. It is the most active forum thread for ipq806x.

Linksys EA8500 support
Forum thread for the Linksys version of this device.

Openwrt port for Linksys EA8500
Ianchi's Github page for the EA8500

EA8500 OpenWRT Wiki page

(Last edited by jmomo on 25 Oct 2016, 00:36)

Post #3

jmomo

7 Jul 2016, 11:21

I combined some of my older posts here so that I could top-post:

----------------------------------------------------------------------------------------------------

https://www.trendnet.com/products/wifi/ … TEW-827DRU

I am looking into replacing some old routers with something new, and the QCA IPQ8064 based devices seem like a good idea based on community support.

There is a huge thread for the TP-LINK Archer C2600 here: https://forum.openwrt.org/viewtopic.php?id=54973

Other nearly-identical models (same chips) include:
Linksys EA8500
Netgear R7500 v2 (the v1 uses a different Quantenna QT3840BC chip)
ASRock G10
Amped Wireless ATHENA AC2600 (RTA2600)
Amped Wireless ATHENA-EX AC2600 (RE2600M)
TP-LINK TGR1900 (Google OnHub)
ASUS SRT-AC1900 (ASUS OnHub)

I would go with the TP-LINK AC2600, but for the same price I can get a TRENDnet TEW-827DRU with 4X the flash (128MB vs 32MB). Also I'm not happy with TP-Link's recent anti-OSS/FCC-related public statements and how difficult they intentionally made getting a console on the device (need for a level-shifter, removal of components after FCC review).

Unfortunately there seems to be nothing out there right now for the TEW-827DRU.

DD-WRT has the device listed as "WIP"

https://dd-wrt.com/wiki/index.php/Supported_Devices

Before I go buying one and start the work on porting, does anyone have any comments regarding this device?

Updates and other things I've learned since the original post:

The TEW-827DRU actually has 256MB of NAND flash and uses UBI for block management. The Linksys EA8500 is also NAND flash.

The TP-Link Archer C2600's 32MB flash is NOR flash.

The Netgear R7800 has the IPQ8065, which offers some additional features (at an increased price). Reference: https://forum.openwrt.org/viewtopic.php … 68#p331368

----------------------------------------------------------------------------------------------------

I am somewhat surprised by the lack of info on this device online. Smallnetbuilder and Tweaktown has a couple of internal board pictures, but that's it.

http://www.tweaktown.com/reviews/7699/t … ndex2.html

http://www.smallnetbuilder.com/wireless … o-reviewed

If you look in the upper-right corner of the picture there appears to be holes for a serial port.

I guess I'll have to buy one and find out.

----------------------------------------------------------------------------------------------------

The price of this router is in freefall. It's down to $130 USD on Amazon, which makes it $40 cheaper than the TP-Link AC2600.

http://camelcamelcamel.com/TRENDnet-Str … B00S7NK8Y0

EDIT: This was back around Amazon Prime Day. The price of the router got down to $120 in the US, which was an awesome deal. Now it's back up to $172, which is $20 more than than the TP-Link Archer C2600, but less than the Linksys EA8500 or either the Netgear R7800/R7500v2.

(Last edited by jmomo on 18 Oct 2016, 00:03)

Post #4

jmomo

10 Jul 2016, 01:51

I just got hardware in.

3.3v/TTL serial port near upper-right corner of the board. Drilled holes. Super easy to connect.
JP1 = Rx
JP2 = Tx
JP3 = Ground

baud = 115200

It has a JTAG interface too.

Lots of debug interfaces. I suspect those are for the 802.11 chips.

Uploading pictures, console log, and more soon.

Post #5

jmomo

10 Jul 2016, 02:28

I am confused by the flash chip. It's a Spansion (Cypress). It says MS02G200BHI00.

I think that's a S34MS02G200BHI000. It says here that's a 2Gb (256MB) chip?

http://www.cypress.com/file/294596/download

So the flash situation is double what I thought it was.

The flash overlay on the default/OEM system is only 32GB though. Not surprised there.

UPDATE:

Datasheet:
http://www.mouser.com/ds/2/100/S34MS01G … 933064.pdf

So this is what the NAND flash layout looks like:

(IPQ) # smeminfo
smem: SMEM_PARTITION_TABLE_OFFSET failed
flash_type:             0x2
flash_index:            0x0
flash_chip_select:      0x0
flash_block_size:       0x20000
partition table offset 0x0
No.: Name             Attributes            Start             Size
  0: 0:SBL1           0x0000ffff              0x0          0x40000
  1: 0:MIBIB          0x0000ffff          0x40000         0x140000
  2: 0:SBL2           0x0000ffff         0x180000         0x140000
  3: 0:SBL3           0x0000ffff         0x2c0000         0x280000
  4: 0:DDRCONFIG      0x0000ffff         0x540000         0x120000
  5: 0:SSD            0x0000ffff         0x660000         0x120000
  6: 0:TZ             0x0000ffff         0x780000         0x280000
  7: 0:RPM            0x0000ffff         0xa00000         0x280000
  8: 0:APPSBL         0x0000ffff        0x53a0000         0x500000
  9: 0:APPSBLENV      0x0000ffff        0x1180000          0x80000
 10: 0:ART            0x0000ffff        0x1200000         0x140000
 11: rootfs           0x0000ffff        0x58a0000        0x4000000
 12: 0:BOOTCONFIG     0x0000ffff        0x5340000          0x60000
 13: 0:APPSBL_1       0x0000ffff         0xc80000         0x500000
 14: rootfs_1         0x0000ffff        0x1340000        0x4000000

Note real order is out of logical order after like part8(RPM).

rootfs (the UBI) ends at 0x989FFFF, 160038912 bytes in. Only about 160MB is being used.

0x98A0000 to 0xFFFFFFF is apparently unused. That's 108MB of unused flash space.

(Last edited by jmomo on 16 Jul 2016, 03:40)

Post #6

jmomo

10 Jul 2016, 06:10

Image gallery here: http://imgur.com/a/5cSfg

I'm not going to bother popping the lids on the RF cages unless someone asks. We already know what is under there.

I will upload a console log and other info tomorrow. I need to probe the GPIOs to figure out LED and button mappings and then I'll try a build later in the week after I've poked around. This is going to be a great OpenWRT/LEDE supported router, assuming ath10k keeps working out it's bugs.

(Last edited by jmomo on 10 Jul 2016, 06:17)

Post #7

jmomo

12 Jul 2016, 02:10

I tried doing an mtd dump to USB but I'm getting a ton of "msm_nand_read_oob 5408000 800 0 failed -74, corrected 0" type errors. Something seems to be preventing read access, or mtd may need fixing.

Post #8

jmomo

13 Jul 2016, 12:36

OEM software v1.00b11 on HW v1.0R

Boot log:
http://pastebin.com/T5NyVM1n

Console system info (cat /proc/mtd, lsmod, ps w,...):
http://pastebin.com/SXK9eKY2

uboot console info:
http://pastebin.com/syiDHmet

(Last edited by jmomo on 14 Jul 2016, 01:54)

Post #9

jmomo

14 Jul 2016, 06:14

While googling around, I found this:

https://www.trendnet.com/emulators/TEW- … tatus.html

It's a presentation page for what the user interface is supposed to look like.

I found it because the system log page had some keywords that I was interested in.

Post #10

jmomo

16 Jul 2016, 03:46

The flash has a ton of free space on it. If I could write a new OS there, I could leave everything intact and boot from the new partition.

However, uboot is booting from a UBI volume. The bootcmd is "bootipq", which is a black box to me. I think I need to ask for the source code from TRENDnet, but it might be in the QSDK too.

bootipq just seems to ready the nand, set up the UBI, and then boots the kernel volume within it.

I don't know anything about how OpenWRT does UBI volumes.

I'm going to need help because I don't know WTF I'm doing anyway.

This might be a few weeks. I'm not in a big rush anyway and doing a tiny bit each day and learning as I go.

(Last edited by jmomo on 16 Jul 2016, 03:49)

Post #11

jmomo

17 Jul 2016, 19:43

I was trying to do a new LEDE build yesterday, but it failed. This is my first build on LEDE instead of OpenWRT and there are some differences in the build script I use which I think broke stuff. So, first I have to fix the differences in LEDE (packages directories and some other junk) before I can figure out what is causing the linux make to fail (my patches).

My current top issues:

No idea what this router needs in regards to the factory image. It's obvious that the OEM image is packaged in a particular way, but I don't know if that's the standard trx/WRT method or something new that I need to account for. This is my first TRENDnet router since 2009. I need to unpack the OEM image and figure out if I need to account for that.

I don't understand how LEDE/OpenWRT does the UBI images. Will the UBI volumes be named correctly to match up with what bootipq in uboot is passing to the kernel ("kernel" and "ubi_rootfs")? Otherwise I'm going to need to change that in LEDE or change my uboot saved env parameters. I need to look at the LEDE source to figure this out.

Post #12

jmomo

20 Jul 2016, 06:18

I am trying to dump the nand flash mtd partitions, but when I try to read nand to memory, I get an error:

(IPQ) # nand info

Device 0: nand0, sector size 128 KiB
  Page size      2048 b
  OOB size        128 b
  Erase size   131072 b
(IPQ) # nand read 45000000 0 40000

NAND read: device 0 offset 0x0, size 0x40000
NAND read from offset 0 failed -74
 0 bytes read: ERROR

From what I've googled, this may be an ecc problem, which makes sense. Uboot needs to know about the ecc blocks in the nand. However, I have no idea how to make uboot nand-ecc aware.

There is no nandecc command in uboot. Attempts at using "nand ecc" have failed.

... I just realized this is the same error code the mtd command in the OEM OS gave. It even said oob in the error type but I didn't think of it at the time.

(Last edited by jmomo on 20 Jul 2016, 06:46)

Post #13

jmomo

20 Jul 2016, 08:09

I was fooling around in uboot more just now. I turnes out I can, in fact, read some partitions into RAM, but not others. Some kind of read protection? I have no idea. I'm not that knowledgeable about uboot.

    nand read 45000000 0x0 0x40000              NAND read from offset xxx failed -74
    nand read 45000000 0x40000 0x140000         NAND read from offset xxx failed -74
    nand read 45000000 0x180000 0x140000        NAND read from offset xxx failed -74
    nand read 45000000 0x2c0000 0x280000        NAND read from offset xxx failed -74
    nand read 45000000 0x540000 0x120000        NAND read from offset xxx failed -74
    nand read 45000000 0x660000 0x120000        read okay
    nand read 45000000 0x780000 0x280000        NAND read from offset xxx failed -74
    nand read 45000000 0xa00000 0x280000        NAND read from offset xxx failed -74
    nand read 45000000 0x53a0000 0x500000       NAND read from offset xxx failed -74
    nand read 45000000 0x1180000 0x80000        read okay
    nand read 45000000 0x1200000 0x140000       read okay
    nand read 45000000 0x58a0000 0x4000000      read okay
    nand read 45000000 0x5340000 0x60000        read okay
    nand read 45000000 0xc80000 0x500000        NAND read from offset xxx failed -74
    nand read 45000000 0x1340000 0x4000000      read okay

Then I tried to tftpput some of those read partitions, but I'm running into what seems to be a networking problem.

(IPQ) # tftpput 0x45000000 0x120000 dump.bin
Mac1 unit failed
Using eth1 device
TFTP to server 192.168.111.109; our IP address is 192.168.111.250
Filename 'dump.bin'.
Save address: 0x45000000
Save size:    0x120000
Saving: ##T ###T ####T #####T ######T #####T #####T #####T #####T #####T #####T #####T #####
Abort

I know the tftp server works because I successfully put a file from a known-working host.

I suspected some duplex mismatch issue, but that doesn't seem to be it either. I used some mii commands in uboot to check out the network interface and it seems to work. I can ping the server.

None of this shit works.

(Last edited by jmomo on 20 Jul 2016, 08:10)

Post #14

jmomo

22 Jul 2016, 03:07

I was going to email TRENDnet and ask for GPL files, but I don't have to. It's already on their website:

GPL download: https://www.trendnet.com/downloads/list_gpl.asp

I just downloaded it. 1GB in size.
Looks like a full build environment. Very good. My opinion of TRENDnet keeps going up. They even have a nice README file describing their build environment (Ubuntu 14.04), requirements, etc. Build scritpt seems to be there.

It looks like the uboot code is in there too (qsdk_gpl/qca/src/u-boot/), but I need to look into the QSDK docs to see how that gets built.

Also while I am documenting stuff:

OEM default info
    Administrator User Name            admin
    Administrator Password            Please refer to sticker or device
    Router Default URL                label
    Router IP Address                http://tew-827dru
    Router Subnet Mask                192.168.10.1
    DHCP Server IP Range            255.255.255.0
    Wireless 2.4GHz & 5GHz            192.168.10.101-192.168.199
    Wireless 2.4GHz Network            Enabled
    Name/Encryption                    Please refer to sticker or device
    Wireless 2.4GHz & 5GHz Guest    label
    Network                            Disabled
    USB SMB & FTP Settings            Disabled
    USB SMB & FTP User Name            Same as Administrator
    USB SMB & FTP Password            Same as Administrator

Post #15

jmomo

26 Jul 2016, 07:16

My TFTP problems turned out to be uboot's buggy TFTP code. It violates standards/RFCs and is basically crap.

I don't have problems when I use the tftpboot (get) command, but tftpput against my Linux systems failed. This is because the packets the uboot system was sending were obviously malformed.

I went over to my Windows PC and used tftpd32, which works fine for receiving files. It doesn't care about silly things like data integrity or the difference between 1s and 0s.

Post #16

jmomo

26 Jul 2016, 12:54

What is currently bugging me is the NAND ECC/OOB data.

It's there. I can read pages with "nand dump". For example; "nand dump.oob 0x58a0000" shows me the OOB info for the first page worth of the rootfs part.

But on this uboot build, there are apparently no nand support commands! No "nandecc" or "nand ecc" support. So, I can't seem to actually read out the ECC info to back it up. That makes working with the UBI part difficult. I already erased it once and was barely able to restore the OEM linux install enough that I could do a recovery.

There seems to be a recovery method built into uboot itself. If you boot with the reset button held down, uboot goes into some kind of http recovery mode. The problem with that is I don't know what IP address it's listening on. I tried to set a static arp entry, but some idiot who wrote the code thought it would be a great idea to validate the IP for some reason, making that impossible.

If I could get the reset button boot mode working, I could probably safely start nuking stuff.

I should probably just buy a jtag device. I'd like to compile a new uboot for fun anyway and I'll probably need that. I suspect some kind of read/write protection on most of the uboot-related partitions, though I've not tried overwriting any of them yet so who knows.

The following uboot commands will fill out the mtdparts to be identical to smeminfo:

setenv mtddevname rootfs
setenv mtddevnum 0
setenv mtdids nand0=nand0
setenv partition nand0,11

# mtdparts notation with 0: garbage in part names to be accurate.
setenv mtdparts mtdparts=nand0:0x40000@0x0(0:SBL1),0x140000@0x40000(0:MIBIB),0x140000@0x180000(0:SBL2),0x280000@0x2c0000(0:SBL3),0x120000@0x540000(0:DDRCONFIG),0x120000@0x660000(0:SSD),0x280000@0x780000(0:TZ),0x280000@0xa00000(0:RPM),0x500000@0x53a0000(0:APPSBL),0x80000@0x1180000(0:APPSBLENV),0x140000@0x1200000(0:ART),0x4000000@0x58a0000(rootfs),0x60000@0x5340000(0:BOOTCONFIG),0x500000@0xc80000(0:APPSBL_1),0x4000000@0x1340000(rootfs_1)

NOTE: copy/paste into uboot might not work for that big command all at once. Paste half at a time. To permanently save, do a "saveenv" before rebooting.

This will then allow mounting the ubi (WARNING: Read the uboot UBI docs, some commands are very dangerous).

# Mount the rootfs part
ubi part rootfs

# Show some basic info
ubi info

# Show the UBI volumes too
ubi info l

Note that this is from the OEM UBI:

(IPQ) # mtdparts

device nand0 <nand0>, # parts = 15
 #: name                size            offset          mask_flags
 0: 0:SBL1              0x00040000      0x00000000      0
 1: 0:MIBIB             0x00140000      0x00040000      0
 2: 0:SBL2              0x00140000      0x00180000      0
 3: 0:SBL3              0x00280000      0x002c0000      0
 4: 0:DDRCONFIG         0x00120000      0x00540000      0
 5: 0:SSD               0x00120000      0x00660000      0
 6: 0:TZ                0x00280000      0x00780000      0
 7: 0:RPM               0x00280000      0x00a00000      0
 8: 0:APPSBL_1          0x00500000      0x00c80000      0
 9: 0:APPSBLENV         0x00080000      0x01180000      0
10: 0:ART               0x00140000      0x01200000      0
11: rootfs_1            0x04000000      0x01340000      0
12: 0:BOOTCONFIG        0x00060000      0x05340000      0
13: 0:APPSBL            0x00500000      0x053a0000      0
14: rootfs              0x04000000      0x058a0000      0

active partition: nand0,0 - (0:SBL1) 0x00040000 @ 0x00000000

defaults:
mtdids  : none
mtdparts: none



(IPQ) # ubi part rootfs
FIXME: had wrong info previously

(IPQ) # ubi info
FIXME: had wrong info previously

(IPQ) # ubi info l
FIXME: had wrong info previously

(Last edited by jmomo on 7 Aug 2016, 06:20)

Post #17

jmomo

26 Jul 2016, 12:55

I tried another LEDE compile today. It failed. I'll fix it tomorrow. I F-ed up patching a patch file somehow.

Applying patch platform/800-devicetree.patch
patching file arch/arm/boot/dts/Makefile
patch: **** malformed patch at line 28:         qcom-msm8974-sony-xperia-honami.dtb

Post #18

jmomo

26 Jul 2016, 12:56

Oh, and if you need a raw nand dump of a freshly-installed never-booted rootfs, let me know. I dumped one today. However, since I'm missing the OOB data, I'm not sure if restoring it will work. How do I write it and either clear the old OOB data, or dump/write OOB data? No clue.

Post #19

jmomo

26 Jul 2016, 13:05

I guess you could use the mtdparts add command to add those partitions too:

mtdparts add nand0 0x40000@0x0 0:SBL1
mtdparts add nand0 0x140000@0x40000 0:MIBIB
mtdparts add nand0 0x140000@0x180000 0:SBL2
mtdparts add nand0 0x280000@0x2c0000 0:SBL3
mtdparts add nand0 0x120000@0x540000 0:DDRCONFIG
mtdparts add nand0 0x120000@0x660000 0:SSD
mtdparts add nand0 0x280000@0x780000 0:TZ
mtdparts add nand0 0x280000@0xa00000 0:RPM
mtdparts add nand0 0x500000@0x53a0000 0:APPSBL
mtdparts add nand0 0x80000@0x1180000 0:APPSBLENV
mtdparts add nand0 0x140000@0x1200000 0:ART
mtdparts add nand0 0x4000000@0x58a0000 rootfs
mtdparts add nand0 0x60000@0x5340000 0:BOOTCONFIG
mtdparts add nand0 0x500000@0xc80000 0:APPSBL_1
mtdparts add nand0 0x4000000@0x1340000 rootfs_1

(Last edited by jmomo on 7 Aug 2016, 06:18)

Post #20

pepe2k

26 Jul 2016, 13:07

jmomo wrote:

[...]
There seems to be a recovery method built into uboot itself. If you boot with the reset button held down, uboot goes into some kind of http recovery mode. The problem with that is I don't know what IP address it's listening on. I tried to set a static arp entry, but some idiot who wrote the code thought it would be a great idea to validate the IP for some reason, making that impossible.
If I could get the reset button boot mode working, I could probably safely start nuking stuff.
[...]

Could you post output from serial console during this "http recovery mode"?
Have you tried set "ipaddr" environment variable (ex. setenv ipaddr 192.168.1.1; saveenv) and then try reach the device on this IP (using static IP on PC from same subnet)?

Post #21

jmomo

26 Jul 2016, 14:26

Hey Pepe! Exactly the man who would know about this...

I get something like this:

Hit any key to stop autoboot:  0 
Mac1 unit failed
Mac2 unit failed
fail WHY
MMC Device 0 not found
MMC Device 0 not found
Mac1 unit failed
Mac2 unit failed
fail WHY
Mac1 unit failed
backup_mode_handle Using eth1 device
localMac is:
49chttp init
hostmac = default_mac_from_artblock: 00:03:7F:XX:YY:ZZ
 00:03:7f:xx:yy:zz
hostaddr = 0xa8c00100 
ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.ip: packet not for us.httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
ip: packet not for us.httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
ip: packet not for us.httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
httpd: PTM UIP_ETHTYPE_ARP, uip_len=60

Console will not accept input at this time, so I can't get any more info.

I see "hostaddr = 0xa8c00100", but that's 192.168.1.0. I connected my computer to the switch port1 and nmap-scanned the /24 network but came back with nothing to report. I also was doing a tcpdump at the time, looking for any frames coming in, but got nothing at all.

I took your advice and tried setting ipaddr into the env, but this didn't seem to have fixed the issue. I might try setting hostaddr next, but that will have to wait until when I have some time tomorrow.

FYI I do have the TRENDnet source code for this, but I'm a nub and don't know what I'm looking at. I looked at the board config file and didn't see any addresses defined there. Not sure else where to look. printenv didn't give me any clues, and like I said, I can't provide any input in this mode.

Post #22

pepe2k

26 Jul 2016, 15:14

Based on the sources, it looks like a "standard" uIP based recovery mode, taken from D-Link (they even forgot to change title/vendor name on all web pages...).

uIP/httpd sources are located in: qsdk_gpl/qca/src/u-boot/httpd/...

Recovery mode is started in function backup_mode_handle(), located in: qsdk_gpl/qca/src/u-boot/common/main.c:

#if defined(CONFIG_HTTPD)
DECLARE_GLOBAL_DATA_PTR; // for export gd_t *gd
void backup_mode_handle(void)
{
    udelay(30000);
    net_init();
    eth_halt();
    eth_set_current();
    if (eth_init( gd->bd) < 0) {
        eth_halt();
        printf("fail WHY\n");
        return;
    }
    net_init();
    eth_halt();
    eth_set_current();
    udelay(30000);
    if (eth_init ( gd->bd ) == -1) {
        printf ("Using %s device Fail\n", eth_get_name());
        return;
    }
    printf ("%s Using %s device\n", __FUNCTION__, eth_get_name());
    httpd ( 0, NULL );
}
#endif //CONFIG_HTTPD

It looks like it might work (based on code and your output).
Is your PC LAN cable connected before you power up the router? Have you tried on WAN port?

Message "packet not for us" comes from uIP (httpd/uip.c):

    /* Check if the packet is destined for our IP address. */  
    DEBUG_MSG("uip_hostaddr[0] = 0x%X and destipaddr[0] = 0x%X\n", uip_hostaddr[0],BUF->destipaddr[0]);
    if(BUF->destipaddr[0] != uip_hostaddr[0]) {
        UIP_STAT(++uip_stat.ip.drop);
        UIP_LOG("ip: packet not for us.");        
        DEBUG_MSG("packet not for us!\n");
        goto drop;
    }
    if(BUF->destipaddr[1] != uip_hostaddr[1]) {
        UIP_STAT(++uip_stat.ip.drop);
        UIP_LOG("ip: packet not for us.");
        DEBUG_MSG("ip: packet not for us -2 \n");
        goto drop;
    }

Which means that the uIP is getting some packets, but they are dropped as the destination address is wrong.

PS. Default address should be 192.168.0.1, as in sources:

tew-827dru_v1/u-boot$ grep -rni "DEFAULT_IP_ADDRESS" .
./httpd/httpd.c:743:    bi_ip_addr = DEFAULT_IP_ADDRESS;
./httpd/defaultConf.h:8:#define     DEFAULT_IP_ADDRESS          IP_ADDR(192,168,0,1)
./httpd/defaultConf.h:12:#define     DEFAULT_IP_ADDRESS          IP_ADDR(192,168,0,1)
./httpd/httpd.c.orig:745:    bi_ip_addr = DEFAULT_IP_ADDRESS;

(Last edited by pepe2k on 26 Jul 2016, 15:17)

Post #23

jmomo

27 Jul 2016, 10:51

Ahha, you were right Pepe. It was listening on the WAN port. Thank you for your sage advice.

RECOVERY INSTRUCTIONS:

Connect an ethernet cable from your PC/switch/whatever to either the LAN1 port or the WAN port on the router.

Manually configure your host with an IP on the 192.168.0.0/24 network. The router does not offer DHCP services in this mode.

Press and HOLD down the RESET button on power-up for four seconds. Then release the reset button. NOTE: My testing shows the recovery system will not load if no cable is plugged into the LAN1 or WAN port.

Be sure to hold the reset button down the entire time from the very moment power is started. I've noticed that sometimes the flash will fail because the UBI gets started/attached, even though the recovery page loaded.

The recovery page is at http://192.168.0.1/

The page should say "TRENDnet Recovery Mode" in blue text at the top and there is a "Choose File" button and "Upload" button.

In this case, the OEM firmware file is named "TEW827DRU_FW100B11.bin".

While the file is uploading, the Internet LED will blink. You can watch progress on the serial console too. Beware the progress/percent animation is fake/placebo.

Below is a log from the console from boot until flashing from the recovery page.

U-Boot 2012.07 [Standard IPQ806X.LN,r40331] (Nov 17 2015 - 19:33:37)

smem ram ptable found: ver: 0 len: 5
DRAM:  491 MiB
NAND:  SF: Unsupported manufacturer 00
ipq_spi: SPI Flash not found (bus/cs/speed/mode) = (0/0/48000000/0)
256 MiB
MMC:   
PCI0 Link Intialized
PCI1 Link Intialized
In:    serial
Out:   serial
Err:   serial
cdp: get part failed for 0:HLOS
Net:   MAC1 addr:0:3:7f:xx:yy:zz
athrs17_reg_init: complete
athrs17_vlan_config ...done
S17c init  done
MAC2 addr:0:3:7f:xx:yy:zz
eth0, eth1
Hit any key to stop autoboot:  0 
backup_mode_handle Using eth0 device
localMac is:
41chttp init
hostmac = default_mac_from_artblock: 00:03:7F:xx:yy:zz
 00:03:7f:xx:yy:zz
hostaddr = 0xa8c00100 
httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
offset is 0, offset = 1 is GET , = 0 is POST
Open index.html
httpd_appcall 414 : Send file later len:859:
offset is 0, offset = 1 is GET , = 0 is POST
httpd_appcall 414 : Send file later len:1135:
httpd: PTM UIP_ETHTYPE_ARP, uip_len=60
offset is 0, offset = 1 is GET , = 0 is POST
Open index.html
httpd_appcall 414 : Send file later len:859:
offset is 1, offset = 1 is GET , = 0 is POST
mime_content_body 360: Current_Length: 26988486 content_len: 27053747
mime_content_body 360: Current_Length: 26988998 content_len: 27053747
mime_content_body 360: Current_Length: 26989510 content_len: 27053747
mime_content_body 360: Current_Length: 26990022 content_len: 27053747
mime_content_body 360: Current_Length: 26990534 content_len: 27053747
mime_content_body 360: Current_Length: 26991046 content_len: 27053747
mime_content_body 360: Current_Length: 26991558 content_len: 27053747
mime_content_body 360: Current_Length: 26992070 content_len: 27053747
mime_content_body 360: Current_Length: 26992582 content_len: 27053747
mime_content_body 360: Current_Length: 26993094 content_len: 27053747
mime_content_body 360: Current_Length: 26993606 content_len: 27053747
mime_content_body 360: Current_Length: 26994118 content_len: 27053747
mime_content_body 360: Current_Length: 26994630 content_len: 27053747
mime_content_body 360: Current_Length: 26995142 content_len: 27053747
mime_content_body 360: Current_Length: 26995654 content_len: 27053747
mime_content_body 360: Current_Length: 26996166 content_len: 27053747
mime_content_body 360: Current_Length: 26996678 content_len: 27053747
mime_content_body 360: Current_Length: 26997190 content_len: 27053747
mime_content_body 360: Current_Length: 26997702 content_len: 27053747
mime_content_body 360: Current_Length: 26998214 content_len: 27053747
mime_content_body 360: Current_Length: 26998726 content_len: 27053747
mime_content_body 360: Current_Length: 26999238 content_len: 27053747
mime_content_body 360: Current_Length: 26999750 content_len: 27053747
mime_content_body 360: Current_Length: 27000262 content_len: 27053747
mime_content_body 360: Current_Length: 27000774 content_len: 27053747
mime_content_body 360: Current_Length: 27001286 content_len: 27053747
mime_content_body 360: Current_Length: 27001798 content_len: 27053747
mime_content_body 360: Current_Length: 27002310 content_len: 27053747
mime_content_body 360: Current_Length: 27002822 content_len: 27053747
mime_content_body 360: Current_Length: 27003334 content_len: 27053747
mime_content_body 360: Current_Length: 27003846 content_len: 27053747
mime_content_body 360: Current_Length: 27004358 content_len: 27053747
mime_content_body 360: Current_Length: 27004870 content_len: 27053747
mime_content_body 360: Current_Length: 27005382 content_len: 27053747
mime_content_body 360: Current_Length: 27005894 content_len: 27053747
mime_content_body 360: Current_Length: 27006406 content_len: 27053747
mime_content_body 360: Current_Length: 27006918 content_len: 27053747
mime_content_body 360: Current_Length: 27007430 content_len: 27053747
mime_content_body 360: Current_Length: 27007942 content_len: 27053747
mime_content_body 360: Current_Length: 27008454 content_len: 27053747
mime_content_body 360: Current_Length: 27008966 content_len: 27053747
mime_content_body 360: Current_Length: 27009478 content_len: 27053747
mime_content_body 360: Current_Length: 27009990 content_len: 27053747
mime_content_body 360: Current_Length: 27010502 content_len: 27053747
mime_content_body 360: Current_Length: 27011014 content_len: 27053747
mime_content_body 360: Current_Length: 27011526 content_len: 27053747
mime_content_body 360: Current_Length: 27012038 content_len: 27053747
mime_content_body 360: Current_Length: 27012550 content_len: 27053747
mime_content_body 360: Current_Length: 27013062 content_len: 27053747
mime_content_body 360: Current_Length: 27013574 content_len: 27053747
mime_content_body 360: Current_Length: 27014086 content_len: 27053747
mime_content_body 360: Current_Length: 27014598 content_len: 27053747
mime_content_body 360: Current_Length: 27015110 content_len: 27053747
mime_content_body 360: Current_Length: 27015622 content_len: 27053747
mime_content_body 360: Current_Length: 27016134 content_len: 27053747
mime_content_body 360: Current_Length: 27016646 content_len: 27053747
mime_content_body 360: Current_Length: 27017158 content_len: 27053747
mime_content_body 360: Current_Length: 27017670 content_len: 27053747
mime_content_body 360: Current_Length: 27018182 content_len: 27053747
mime_content_body 360: Current_Length: 27018694 content_len: 27053747
mime_content_body 360: Current_Length: 27019206 content_len: 27053747
mime_content_body 360: Current_Length: 27019718 content_len: 27053747
mime_content_body 360: Current_Length: 27020230 content_len: 27053747
mime_content_body 360: Current_Length: 27020742 content_len: 27053747
mime_content_body 360: Current_Length: 27021254 content_len: 27053747
mime_content_body 360: Current_Length: 27021766 content_len: 27053747
mime_content_body 360: Current_Length: 27022278 content_len: 27053747
mime_content_body 360: Current_Length: 27022790 content_len: 27053747
mime_content_body 360: Current_Length: 27023302 content_len: 27053747
mime_content_body 360: Current_Length: 27023814 content_len: 27053747
mime_content_body 360: Current_Length: 27024326 content_len: 27053747
mime_content_body 360: Current_Length: 27024838 content_len: 27053747
mime_content_body 360: Current_Length: 27025350 content_len: 27053747
mime_content_body 360: Current_Length: 27025862 content_len: 27053747
mime_content_body 360: Current_Length: 27026374 content_len: 27053747
mime_content_body 360: Current_Length: 27026886 content_len: 27053747
mime_content_body 360: Current_Length: 27027398 content_len: 27053747
mime_content_body 360: Current_Length: 27027910 content_len: 27053747
mime_content_body 360: Current_Length: 27028422 content_len: 27053747
mime_content_body 360: Current_Length: 27028934 content_len: 27053747
mime_content_body 360: Current_Length: 27029446 content_len: 27053747
mime_content_body 360: Current_Length: 27029958 content_len: 27053747
mime_content_body 360: Current_Length: 27030470 content_len: 27053747
mime_content_body 360: Current_Length: 27030982 content_len: 27053747
mime_content_body 360: Current_Length: 27031494 content_len: 27053747
mime_content_body 360: Current_Length: 27032006 content_len: 27053747
mime_content_body 360: Current_Length: 27032518 content_len: 27053747
mime_content_body 360: Current_Length: 27033030 content_len: 27053747
mime_content_body 360: Current_Length: 27033542 content_len: 27053747
mime_content_body 360: Current_Length: 27034054 content_len: 27053747
mime_content_body 360: Current_Length: 27034566 content_len: 27053747
mime_content_body 360: Current_Length: 27035078 content_len: 27053747
mime_content_body 360: Current_Length: 27035590 content_len: 27053747
mime_content_body 360: Current_Length: 27036102 content_len: 27053747
mime_content_body 360: Current_Length: 27036614 content_len: 27053747
mime_content_body 360: Current_Length: 27037126 content_len: 27053747
mime_content_body 360: Current_Length: 27037638 content_len: 27053747
mime_content_body 360: Current_Length: 27038150 content_len: 27053747
mime_content_body 360: Current_Length: 27038662 content_len: 27053747
mime_content_body 360: Current_Length: 27039174 content_len: 27053747
mime_content_body 360: Current_Length: 27039686 content_len: 27053747
mime_content_body 360: Current_Length: 27040198 content_len: 27053747
mime_content_body 360: Current_Length: 27040710 content_len: 27053747
mime_content_body 360: Current_Length: 27041222 content_len: 27053747
mime_content_body 360: Current_Length: 27041734 content_len: 27053747
mime_content_body 360: Current_Length: 27042246 content_len: 27053747
mime_content_body 360: Current_Length: 27042758 content_len: 27053747
mime_content_body 360: Current_Length: 27043270 content_len: 27053747
mime_content_body 360: Current_Length: 27043782 content_len: 27053747
mime_content_body 360: Current_Length: 27044294 content_len: 27053747
mime_content_body 360: Current_Length: 27044806 content_len: 27053747
mime_content_body 360: Current_Length: 27045318 content_len: 27053747
mime_content_body 360: Current_Length: 27045830 content_len: 27053747
mime_content_body 360: Current_Length: 27046342 content_len: 27053747
mime_content_body 360: Current_Length: 27046854 content_len: 27053747
mime_content_body 360: Current_Length: 27047366 content_len: 27053747
mime_content_body 360: Current_Length: 27047878 content_len: 27053747
mime_content_body 360: Current_Length: 27048390 content_len: 27053747
mime_content_body 360: Current_Length: 27048902 content_len: 27053747
mime_content_body 360: Current_Length: 27049414 content_len: 27053747
mime_content_body 360: Current_Length: 27049926 content_len: 27053747
mime_content_body 360: Current_Length: 27050438 content_len: 27053747
mime_content_body 360: Current_Length: 27050950 content_len: 27053747
mime_content_body 360: Current_Length: 27051462 content_len: 27053747
mime_content_body 360: Current_Length: 27051974 content_len: 27053747
mime_content_body 360: Current_Length: 27052486 content_len: 27053747
mime_content_body 360: Current_Length: 27052998 content_len: 27053747
mime_content_body 360: Current_Length: 27053510 content_len: 27053747
mime_content_body 360: Current_Length: 27053747 content_len: 27053747
mime_content_body 371 congraturation! size: 27053536, go to count down
http_appcall() : send count down page 
httpd_appcall 414 : Send file later len:1135:
Hit any key to stop autoboot:  0 
## Executing script at 42000000
crc32+ Flashing mibib:                         ## Copying 'mibib-93f26d3b30c92443495b75e54fa3b08fb807342b' subimage from FIT image at 42000000 ...
crc32+ 
NAND erase: device 0 offset 0x40000, size 0x140000
Erasing at 0x160000 -- 100% complete.
OK

NAND write: device 0 offset 0x40000, size 0x40000
 262144 bytes written: OK
[ done ]
Flashing bootconfig:                    ## Copying 'bootconfig-f1050e638265203cd2a74f220c37aeaa88edfc7e' subimage from FIT image at 42000000 ...
crc32+ 
NAND erase: device 0 offset 0x5340000, size 0x60000
Erasing at 0x5380000 -- 100% complete.
OK

NAND write: device 0 offset 0x5340000, size 0x800
 2048 bytes written: OK
[ done ]
Flashing sbl1:                          ## Copying 'sbl1-74af66c2817f48dbeb5b7db940602e3f8685e628' subimage from FIT image at 42000000 ...
crc32+ 
NAND erase: device 0 offset 0x0, size 0x40000
Erasing at 0x20000 -- 100% complete.
OK

NAND write: device 0 offset 0x0, size 0x10800
 67584 bytes written: OK
[ done ]
Flashing sbl2:                          ## Copying 'sbl2-9c8ca5eeedd3034d4724d3c871bca6a5094b908a' subimage from FIT image at 42000000 ...
crc32+ 
NAND erase: device 0 offset 0x180000, size 0x140000
Erasing at 0x2a0000 -- 100% complete.
OK

NAND write: device 0 offset 0x180000, size 0x1a800
 108544 bytes written: OK
[ done ]
Flashing sbl3:                          ## Copying 'sbl3-2294ac1e51eb1f3766f7c9a8591d85594d5ec552' subimage from FIT image at 42000000 ...
crc32+ 
NAND erase: device 0 offset 0x2c0000, size 0x280000
Erasing at 0x520000 -- 100% complete.
OK

NAND write: device 0 offset 0x2c0000, size 0x26800
 157696 bytes written: OK
[ done ]
Flashing u-boot:                        ## Copying 'u-boot-9cc8e3f383c200a36019759aa7a9ea47920fd8cf' subimage from FIT image at 42000000 ...
crc32+ 
NAND erase: device 0 offset 0xc80000, size 0x500000
Erasing at 0x1160000 -- 100% complete.
OK

NAND write: device 0 offset 0xc80000, size 0x68800
 428032 bytes written: OK
[ done ]
Flashing ddr-ap148:                     ## Copying 'ddr-ap148-cc27ffaa2e91ff18aeb210c9645ff6a913fbbc7c' subimage from FIT image at 42000000 ...
crc32+ 
NAND erase: device 0 offset 0x540000, size 0x120000
Erasing at 0x640000 -- 100% complete.
OK

NAND write: device 0 offset 0x540000, size 0x800
 2048 bytes written: OK
[ done ]
Flashing ssd:                           ## Copying 'ssd-bf62fff20be4503e8cbb6c0999a6d8f218325865' subimage from FIT image at 42000000 ...
crc32+ 
NAND erase: device 0 offset 0x660000, size 0x120000
Erasing at 0x760000 -- 100% complete.
OK

NAND write: device 0 offset 0x660000, size 0x2000
 8192 bytes written: OK
[ done ]
Flashing tz:                            ## Copying 'tz-5371ff12800ec75037875b90289bbafe482dee9f' subimage from FIT image at 42000000 ...
crc32+ 
NAND erase: device 0 offset 0x780000, size 0x280000
Erasing at 0x9e0000 -- 100% complete.
OK

NAND write: device 0 offset 0x780000, size 0x2a800
 174080 bytes written: OK
[ done ]
Flashing rpm:                           ## Copying 'rpm-f7ae6c6e3b03b2c11b4d154cf0db219dafdb96e3' subimage from FIT image at 42000000 ...
crc32+ 
NAND erase: device 0 offset 0xa00000, size 0x280000
Erasing at 0xc60000 -- 100% complete.
OK

NAND write: device 0 offset 0xa00000, size 0x13800
 79872 bytes written: OK
[ done ]
Flashing ubi:                           ## Copying 'ubi-4247a56920048807ca170b332e81164b8067496f' subimage from FIT image at 42000000 ...
crc32+ 
NAND erase: device 0 offset 0x1340000, size 0x4000000
Erasing at 0x5320000 -- 100% complete.
OK

NAND write: device 0 offset 0x1340000, size 0x1860000
 25559040 bytes written: OK
[ done ]
resetting ...

Resetting with watch dog!

Note that the 0:APPSBLENV partition isn't touched, which has your uboot env. So that won't get reset (it probably should).

This makes my recovery process easier.

(Last edited by jmomo on 2 Sep 2016, 01:40)

Post #24

jmomo

27 Jul 2016, 11:02

An observation:

The NAND flash has a second UBI partition (rootfs_1) and second uboot partition (0:APPSBL_1), but I have thus far seen no evidence that they are used for anything.

I've dumped these partitions, but I've not done much investigation into their contents yet. The one notable fact was that the compile dates on the two uboot versions are very different. These are not mirror copies of the primaries.

It is possible that TRENDnet was working on a recovery system like Linksys has in the EA8500, but I don't see any support for that in uboot or elsewhere.

Maybe it's for a feature they never finished? I have no idea.

Post #25

jmomo

27 Jul 2016, 12:11

Pffffffftt

I just realized UBI doesn't use the NAND flash OOB area. I figured since this was SLC NAND it would, but no.

http://www.linux-mtd.infradead.org/faq/ … why_no_oob

Now I'm confused about why my uboot backup and restore previously caused corruption in the UBI partition volumes. I guess I don't care since I can use the recovery method now, but maybe I'll come back to that later and tinker with it more.

Page 1 of 6