Unofficial TRENDnet AC2600 (TEW-827DRU v1.0R) release v19.07.2 (ipq_nand fail fix)

Community Builds, Projects & Packages
1

Device Support Status

This device is end-user ready. Wired and wireless works, LEDs work, buttons work, and factory image installation works. Testing has shown the system to be stable under load. I have a small collection of these devices operating in personal and business environments and they have proven to be reliable.

This document applies only to the 1.0R version of hardware. Other hardware revisions are not compatible nor supported by this release.

OpenWRT/LEDE Project leaders previously rejected all of my patches and I didn't see any situation where it was 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.

Currently Known Issues

There are no significant issues specific to this device.

Factory installation via the OEM web interface is not supported yet because the install will revert after next reboot due to the Safe Upgrade/redundant partition system. However, there is a Recovery Loader in u-boot which is easy to use, 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. The button currently does nothing, but it is configured in the DTS so you can write a script to use it if you want to. This button doesn't work under the OEM image either, so nothing lost.

Downloads/builds

The latest builds are based off the OpenWRT v19.07.2 (patch set v17) releases.

Minimal image files are here:

https://jmomo.net/files/lede/TRENDnet_TEW-827DRU_20200509211553_OpenWRT_v19.07.2_minimal/bin/

Minimal+luci image files are here:

https://jmomo.net/files/lede/TRENDnet_TEW-827DRU_20200509224212_OpenWRT_v19.07.2_luci/bin/

You can download older builds and patches here:

https://jmomo.net/files/lede/

The minimal builds have a basic bare-bone package set just like you would get from an official OpenWRT release image. You have roughly 45MB of free space on the overlay to work with. No LuCi web interface or anything else. Install the packages you want with opkg.

Luci builds are like the minimal builds, but with luci-ssl added to provide a web interface.

Recovery and Installation Instructions

Installing OpenWRT/LEDE on this device is very safe, relatively speaking, and it's easy to restore the OEM image if you want to go back.

This device offers three methods for installing images: The uboot http Recovery Loader, the OEM http upgrade tool, and console uboot tftp. However, installation by the OEM http upgrade tool is not yet fully supported.

Most users should use the uboot http Recovery Loader because it's easy and safe to use.

DO NOT use the OEM web/http upgrade page at this time. While the OEM upgrade tool will accept and install the OpenWRT/LEDE image, we don't yet support TRENDnet's "Fail Safe"/safeupgrade dual boot system, which means that the device will revert to the old OEM image on the next reboot.

Finally, you can install images via serial console uboot and tftp.

Be sure to download a copy of the OEM installation images in case you want to go back. See this post for more details.

uboot http Recovery Loader

Connect an ethernet cable from your PC/switch to any one of the ethernet jacks on the router. The Recovery Loader will not start if one of the ethernet ports doesn't go active/up during boot, so make sure you have a live cable plugged in before starting.

Manually configure your computer 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 five seconds. Then release the reset button.

The recovery page will be at 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.

If installing OpenWRT/LEDE, then upload the factory image file.

If you want to go back to the OEM image, use the OEM 1.00b11 firmware file (TEW827DRU_FW100B11.bin), then update to the latest version.

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

That's it. OpenWRT/LEDE should be up and running within 30 seconds of uploading the file. The OEM image takes about two minutes and boots very slowly (due to DFS).

If you are unable to access the Recovery Loader page, or if you upload upload a factory image and it doesn't install, be sure to read this post. The Recovery Loader is known to be a bit buggy.

OEM http upgrade tool

DO NOT use the OEM http upgrade tool at this time. While our factory image file conforms to the OEM requirements to be accepted and installed, we don't yet support TRENDnet's "Fail Safe"/safeupgrade redundant partition boot loader scheme. The result is that the device will successfully boot into OpenWRT/LEDE after the first reboot, but upon the second reboot it will revert to the old OEM system.

I plan to work on supporting the OEM http upgrade tool and the redundant partition system in the future, but I have not gotten around to it yet.

Console uboot tftp

The serial console on this device is fairly easy to access. A 3.3v/TTL serial port can be found in the corner next to the USB ports. You will need to soldier in header pins. Disassembling the chassis is not difficult.

JP1 = Rx
JP2 = Tx
JP3 = Ground
baud = 115200

uboot gives a 2-second "Hit any key to stop autoboot" prompt, so that's easy to break. No special key combo required.

This device uses a FIT archive file, which includes an installer script, a bootconfig image, and the UBI (kernel+squashfs+ubifs). All we really need to do is tftp the factory image into memory and execute the script embedded within it.

setenv ipaddr 192.168.0.1
setenv serverip 192.168.0.2
setenv netmask 255.255.255.0
tftpboot 0x42000000 openwrt-ipq806x-trendnet_tew827dru-squashfs-factory.bin
setenv imgaddr 0x42000000
source 0x42000000:script
reset

Future Plans

JTAG recovery is something I want to do some day. 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 and had some progress but I've not yet figured everything out and I regret that I don't have time to work on it right now.

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. If you want to use that 108MB of free space right now, see this thread on how to set up and use the "freespace" partition.

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. This would require building a custom u-boot.

Previous Forum Threads and Old Development Info

In May of 2018 the old OpenWRT forum died due to negligent administration. Previously, this is where I had kept a running log of changes and updates for this device.

This new thread replaces and supersedes any information on the old forum, but you can still read the old thread for background information on how I ported the device, previous issues, and additional technical information.

The old forum thread can be read here:
https://forum.archive.openwrt.org/viewtopic.php?id=65956

The original (now potentially invalid) URL to the old forum was:
https://forum.openwrt.org/viewtopic.php?id=65956

Then in 2019 the powers that be decided that it was a good idea to prevent the editing of forum posts after a short period of time, to combat some spam mechanics. Thus I intend to start a new thread for each new release since I can no longer edit my posts.

Previous release threads can be found here:

1 Like
2

It was recently discovered that there is a bug in the Recovery Loader which could cause installation of the factory image to fail. The Recovery Loader would successfully launch, the user would access the Recovery Loader http page, select and upload the factory installation file, and then wait for the router to reboot, but the image would not install and the router would boot with whatever image was previously installed.

In some cases this issue might even cause the Recovery Loader to not load at all, and the router boots as if the reset button had not been held down.

There were hints in the past that the Recovery Loader wasn't always reliable, but until now I had not been able to reproduce the problem.

The issue is caused by an environmental scenario which only occurs in certain circumstances. The Recovery Loader looks for an active network interface with layer-1/PHY up, but it does not stop the normal boot process or give enough time for some network interfaces on some PCs or switches to come up. The result is that the router could begin the normal boot process before the Recovery Loader senses an attached network interface. If the boot process gets far enough along, this will interfere with the Recovery Loader's installation process and the image will not install. It is even possible that if the attached PC or switch interface is slow enough, the router might fully boot and the Recovery Loader will never load.

This bug is in Trendnet's u-boot code and is not specific to OpenWRT images. The problem can also cause the OEM factory images to fail to install from the Recovery Loader as well.

I have added a workaround to my OpenWRT images which should allow the installation of the factory image from the Recovery Loader when this issue occurs. Images built on and after 2020-05-09 have this workaround.

It is also possible to avoid the issue all together by attaching to the router with a network interface which comes up fast. For example, my Pluggable USB ethernet adapter which uses an ASIX AX88179 chip never experiences this issue, but if I put a 5-port switch in between my computer and the router, the problem always occurs.

Unfortunately, without serial console access, there is no clear indicator which a user can look for to know if this bug is happening. The Recovery Loader web page doesn't provide any useful feedback.

The only way to know for sure if you have been afflicted by this bug is to get a serial console and look at the boot messages.

In older versions of my OpenWRT images, the issue can be identified by looking for serial console messages indicating that the UBI MTD has been assembled/attached before the Recovery Loader's "backup_mode_handle Using ethX device" message is seen, and then a "Failed to set ipq_nand: Quitting." message is given when attempting to install the factory image. Each main() loop in which the Recovery Loader fails to bring up a network interface is indicated by a "fail WHY" message (which I suspect is an engrish/typo for "fail PHY").

2 Likes
3

I have released new updates images here: