Hello,

I have a Trendnet TEW-411BRP router (also known as a Sparklan WX-6615) which is based upon very similar - though not identical - hardware to the Linksys WRT54G.

Is anyone successfully using OpenWRT on the Trendnet?  I would like to use it but am concerned about the subtle differences in hardware.  I recently tried loading Satori from Sveasoft and found that the router's switch was not working afterwards.  Thankfully, the wireless interface was working, so I was able to enable the boot_wait flag over the wireless link (which wasn't possible with the Trendnet firmware as it lacks ping.asp) and reload the Trendnet firmware.

The non-functioning ethernet switch with Satori can be accounted for by the Trendnet using what I believe to be a Broadcom BCM5325 switch chip unlike the Linksys (which I think has an admtek 6996).  Is there a driver supporting the BCM5325 included in OpenWRT?

I would be grateful for any advice, since OpenWRT sounds like exactly what I am looking for in a firmware.

Regards,

Steve

Hi.
I've a Trendnet TEW-411BRP+ (note the '+') and I've succesfully flashed it with OpenWRT. I've used  snapshot-20041014.tar.bz2 from the web page, and I uploaded to the router the file openwrt-linux.trx from router configuration web page.

After flashing and booting OpenWRT, I've noted that boot_wait was set to off, so it could be problematic in case of bad flashing, but with luck, anything bad happens.

I've used a while withouth problems, and the problem came when I have to bring back the router to his owner, so I wanted to put in the original firmware of TEW-411BRP+.

I wrote to flash TEW-411BRP firmware (withouth +, because the + firmware isn't published in Trendnet's site) using 'mtd' command from inside OpenWRT. The result is an unusable router (the router never boots, the power led is flashing continuosly).

I'm trying now to recover it uploading a new firmware via TFTP (boot_wait=on), but I don't know the format of the file (I'm trying to get back to OpenWRT, because it worked fine in my router).
I don't know if PMON's accept a .trx or .bin file; in case of a .bin I don't know how I make the header to this with addpattern. PMON was changed when I installed OpenWrt first time?

Please help! or comment experiences with Trendnet 411BRP(+)

Bye
Daniel

How did you solve your problem?

regards, B

I didn't solve it yet . I'm waiting god's signal.
The only way I think I can solve this is soldering a serial console inside the AP (if this can be done, of course). There's a connector inside the access point in WRT54G, I don't know already if the same applies to TEW-411BRP.
With the serial console I can see what's really happen with PMON at boot time.

Any suggestions will be appreciated
Bye
Daniel

Ok...good luck then

I'll post my experiences here...

http://openwrt.org/forum/viewtopic.php?t=1174

Hey doger,

I, too, have a Trendnet TEW-411BRP+.  When I wrote to their technical support people about the lack of a firmware download available for this model on their web site, a very helpful support representative wrote me back and told me that the reason they didn't have any downloads (other than the EU version) is because the version that shipped with the router is the latest version.  When I explained to him that the reason I wanted to have a copy of the firmware on hand was because I was planning on installing a third-party firmware on it (I even mentioned OpenWRT ), he wrote the following note back to me:

Needless to say, the fact that they would divulge this information to me even though I just informed them of the fact that I plan on voiding my warranty impressed me.  We've been using/reselling Trendnets at work here recently, and I'm beginning to like this company more and more (although some of my recent setbacks re: my OWN 411BRP+ unit have been frustrating).

If you ever manage to get your 411BRP+ working again, the next time that you need to go back to the official Trendnet firmware, you might want to keep the above in mind and avoid putting the 411BRP firmware on your unit in lieu of the + version.

As far as resurrecting your TEW-411BRP+, you don't have many options, though it definitely is possible if you're willing to put some elbow-grease into it.  On my unit, I tried using boot_wait and the pin-shorting trick to load different firmware on the unit, and neither worked because the stupid version of CFE that Trendnet used accepts TFTP uploads but won't flash them to the EEPROM.  In the end, I had no choice but to use a homemade JTAG cable and HairyDairyMaid's JTAG software to fix my mess-up, and I imagine that if you want to save your router, you'll probably have to do the same.  Based on my own experiences, I would *not* recommend any longer to anybody that they use the pin-shorting trick; it's dangerous (at least to your pocketbook ).

Now, I have a question for you.   You say that you managed to get OpenWRT working smoothly for you on your 411BRP+.  I have been banging my head against a wall trying to get mine to work, however!  If I load a current experimental snapshot on it (23 Apr 05, 24 May 05, or even checking out the latest version of HEAD from CVS), everything works EXCEPT for the ethernet ports.  They get initialized during CFE, but as soon as the kernel boots (not when the et.o module gets loaded, but when the kernel boots!), all of the ethernet ports shut off and will not physically link up anymore.  No errors occur during the loading of et.o, either.

So when I ran across your post, I was hoping to find the answer in earlier builds of OpenWRT (which you claim worked for you).  Maybe if we can determine what changed between then and now, we can figure out how to make the latest builds work with the Trendnet hardware again.  Yours worked under 20041014, but the earliest one I could still find on openwrt.org for download was 20041023.  The changelog didn't indicate anything had changed between those dates, so I decided to give 20041023 a try.  Well, this version doesn't "turn off" the ethernet ports like 'experimental' does, but unfortunately the router refused to communicate with me anymore either via ethernet OR wireless (even though I could tell that it was booting up by the LED activity).  So now I'm back to 24 May 05 experimental and non-functioning ethernet ports.

I'm surprised to learn that yours worked.  I'm wondering if I have a newer "revision" of this router and something is physically different inside.  Does your 411BRP+ have an ADMtek switch and on-board wireless (no MiniPCI)?

Some more observations I've made about this issue:

1. I extracted the et.o module from Trendnet's 2.07-EU firmware (stripped the TRX header and kernel from the firmware file and mounted the CramFS filesystem on my system's loopback block device) and then uploaded that to my router to see if whatever they changed in hardware was compensated for in their version of et.o (Trendnet has not released their build tree, so I can't just look in there for the answer).  Their module loaded just fine on OpenWRT-experimental, but it didn't change the fact that all of the ethernet ports were still dead/off.

2. I installed admcfg on my 411BRP+, and discovered that it doesn't work...if I change the settings on any given port, it will "confirm" those settings, but then if I check the port again immediately afterwards, I see that the port in question "reverted" back to the settings that it started out with.  In other words, the changes I make don't "stick."  And yes, I had adm.o loaded.  It outputs "ADM: 00000000" (dmesg); what do the '0's mean?  That it didn't find the switch?  (Maybe I should look at the code? )

3. I think the fact that the switch ports die with the kernel boot and not with the loading of et.o (which also configures the switch...look through the code; it determines which switch chip you have [ADMtek or Broadcom] through boardflags and then initializes them through select GPIOs) is telling.  The 'experimental' kernel is doing something that the old snapshot kernels did not do, and it's killing the switch.

4. The GPIOs on the Trendnet are not connected to all the same things that they are on its Linksys brothers.  For example, I discovered that GPIO 0 is connected to the reset button on the 411BRP+, not GPIO 6 (so, incidentally, I cannot get into failsafe mode on a stock OpenWRT build).  GPIOs 1, 6, and 7 appear to be connected to select LEDs (the power LED, which starts out blinking, will go solid if you toggle #7, for example).  This leaves GPIOs 2, 3, 4, and 5 connected to the ADMtek chip, which DOES appear to be standard.  And the default NVRAM values for variables gpio2, gpio3, gpio4, and gpio5 in the Trendnet CFE match the values that Linksys uses on its ADMtek-equipped versions of the WRT54G/GS (et.o consults these NVRAM variables in the switch initialization code).  However, I am beginning to wonder if perhaps GPIOs 2, 3, 4, and 5 are actually connected in a non-standard order to the ADMtek switch and that this is somehow accounted for in the official Trendnet firmware (which I don't have the sources for).  If they were wired differently than was indicated in NVRAM and the OpenWRT kernel didn't know this, is it possible that its doing something funky when it hits the GPIO code in the kernel during boot-up that would cause the switch to shut down?  (I don't know how this all works; I'm just thinking out-loud here.)

If anybody has any ideas, I'm all-ears!  Everything else on the Trendnet works...OpenWRT is soooo close to having this be a supported router.  Just this one little niggling issue remains.

-- Nathan

Okay, I got everything working. :-)

The problem with the ethernet switch shutting off was a result of diag.o.  Whenever preinit caused it to load, the switch died.  Looking at the code, it appears that what was happening is that as a result of the similarity between the Motorola's board* NVRAM variables and the Trendnet's, it decided that the GPIO pin that controlled the reset button was number 5.  On the Trendnet, this happens to be wired to adm_rc on the ADMtek switch chip; toggling that GPIO causes the switch to turn off and on (and if you look at the ADMtek control code in the et.o module, located in etc_adm.c, inside the adm_enable_device function, you will see that a time-sensitive sequence needs to be followed to initialize the switch correctly...high(20ms)->low(100ms)->high(30ms)).  The reset button is actually on GPIO 0.

So, I managed to kill two birds (the ethernet switch problem and the reset button problem) with one stone by building myself a custom diag.o module for my Trendnet.  And now all is right with the world.

After this, I discovered that the wireless interface was reeeeeeeaaaallly slow...moving from LAN -> WLAN, I was barely hitting 1Mbps on average, and I peaked at 2 when I was lucky (laptop claimed it was associated to the AP @ 54Mbit/s).  So I downgraded to the latest experimental release on a whim (I had been running a recent version of HEAD which included a 3.90.xx version of the wireless driver), and that fixed the problem...11Mbps sustained.  I'm guessing that this is some problem with the 3.90 wireless driver running on the Trendnet...the 25 May 05 experimental comes with 3.60.xx.

I'm not sure what can be done to modify diag_led.c in order to include support for the Trendnet because my board* NVRAM variables are pretty generic.  Here is a record of them for posterity:

boardrev=0x10
boardtype=0x0101
boardflags2=0
boardflags=0x0388
boardnum=44

If the boardtype was bcm94710ap, then with the boardnum at 44 the way it is, it would have ended up matching the Dell TrueMobile router, which ALSO has the reset pin on GPIO 0 (Hmmm...I bet I look at the Dell's pictures on the FCC site and it looks really similar to the Trendnet ).

Hopefully the above information is of some use to the developers.  In the meantime, if anyone else out there has a TEW-411BRP+ that they want to use OpenWRT on, give me a hollar and I'll send you a pre-built TRX image for you to use on yours complete with a working diag.o and a slightly tweaked preinit script.  If you want my diag_led.c code as well, you are welcome to have it (and under GPL terms, I guess that if I hand out the TRX, I'm required to give it to you anyway ), but basically all I did was rip out support for every other device and customized it to work on the Trendnet only.

Happy hacking,

-- Nathan