So, as I'm sure everyone probably realises; the uBoot is pretty useless if you don't have a serial cable to hand or don't want to open your box up in the first place.

As a result of bricking my box with a bad OpenWRT image and not having a Serial TTL cable to hand, I've downloaded the uBoot source code from TP-Link and modified it to perform a TFTP RAM-boot and TFTP Flash depending on whether you press the QSS or QSS + Reset buttons.

If you have a serial link anyway, this uBoot is also useful since it increases the boot interrupt window from 1 second to 4 seconds... Now, unfortunately, I haven't been able to test this myself yet since I already borked my router with a bad OpenWRT image and I'm still waiting for my TTL converter to arrive.

Anyhow, if someone with direct flash access (or at least serial) could please try this, I'd very much appreciate it; in order to use it you will need to firstly have a version of OpenWRT running that allows you to write mtd0 (if you make your own builds, locate mach-tl-wr1043nd.c and delete the .mask_flags line from the u-boot section.

Next, make a copy of your mtd0 and use dd to overwrite it with the new uBoot code, for example: dd if=uboot-realflash.bin of=mymtd0.bin conv=notrunc

Please ensure you don't miss out the conv=notrunc otherwise the area storing your MAC will be erased; if in doubt, make sure the filesize doesn't change after the dd operation.

uboot-realflash.bin is the "real" uboot and will actually provide the TFTP ramboot and flash modes when you hold the applicable buttons. uboot-testonly.bin will simply report over serial what button(s) were held in and won't actually change anything and effectively behaves identically to the stock uboot (except for the extended wait period)

I will first point out that for all I know, the GPIO address is wrong and it doesn't work at all - what I *DO* know however is that this code doesn't actually execute if you interrupt the boot process via serial (so if you use the tpl command during the 4 second window, my code will never run) meaning that if the new code is bad in some way, you should still be safe since you can interrupt it with tpl and reflash or manually issue the boot command.

Now for the usage info - the device expects the TFTP server to be on 192.168.0.5 and its own IP will be 192.168.0.2 - if you are performing TFTP ramboot you are expected to name the file uImage_boot (case sensitive) and if you are flashing you are expected to name the file uImage_flash - I made it this way to avoid damage if you only want to boot something.
Once you have TFTP setup, hold in the QSS button while powering the device up to go to TFTP RAMBoot mode (do be aware that there is a 4 second timeout beforehand so be patient with it) - if you have serial it should say on screen that it's detected the TFTP Boot button, additionally, the QSS and USB LED lights should come on.
If you want to perform a TFTP flash, you need to hold in both the QSS and Reset buttons together and again, be patient, there's a 4 sec timeout beforehand. as the above, it will tell you on serial that it has detected TFTP Flash button combo and will also light up the QSS LED (ONLY the QSS LED comes on for Flash mode)

The source code is included; just get the original uBoot from TP-Link's GPL section and drag and drop everything in the src folder over to it.

Final Health Warning: Whilst the binaries appear sane to me and I'm relatively confident they can and will function, I have no way of knowing that right now, so therefore, there is always the possibility that flashing this will result in a totally non-functioning bootloader.

DOWNLOAD: http://wikisend.com/download/525032/uBo … 3ND-mod.7z

(Last edited by Olipro on 27 Feb 2011, 20:14)

First of all thank you for your effort.

Here we have no howtos about bootloaders:  http://wiki.openwrt.org/doc/techref/bootloader  but at least some links.
Here is the description of one U-Boot-Mod:  http://wiki.openwrt.org/toh/tp-link/tl- … -boot.mods  "Making uboot mtd device writeable"

Now if you want to explain stuff about U-Boot, that could help others to more easily modify it to their wishes, that would be cool.

I cannot download your file, because I have cookies disabled. I also have JavaScript and JAVA disabled. And no ActiveX....  If I had a to JTAG/Serial cable, why would I risk bricking my baby?

JTAG can only read the flash, not write it... but that said, if you have JTAG, you could just load an entire bootloader and/or OpenWRT image into RAM and execute it.

as for serial... if my image turns out to be "insane" which is unlikely in my opinion, but never say never, then your only option would be JTAG.

Olipro: I would be interested in a way how to write and execute bootloader in RAM using JTAG. Could you describe that?
Right now I am on verge on desoldering the flash, so if I could solder JTAG connector instead, it will be preferable solution. Using JTAG to boot from RAM then using u-boot in RAM to flash u-boot in flash, and then finally flash linux image.
But I am curious, aren't there any absolute adresses in u-boot?

If you take a look at this page you should find information on JTAG debuggers: http://www.linux-mips.org/wiki/JTAG - you can use OCD Commander to load code to MIPS processors although it appears it requires the code be in a specific format (i.e. one that specifies where it needs to get placed in RAM) although this shouldn't be a problem to supply. On the other hand urJTAG seems to allow you to write any file directly into device memory. OpenOCD offers a lot of features, but you'll need to actually get it working first

According to the uBoot source code, the RAM base starts at 0x80000000 - however, it also defines a memtest range spanning 0x80200000 to 0x83800000 which is a range of 54MB (and therefore larger than the total RAM.) My bet is that the RAM most probably runs from 0x80000000 to 0x82000000

It also defines a static load address of 0x81000000 - generally speaking, if you want to load anything, use this address, you'll have 16MB available.

anyway, someone please test

Olipro: Thanks for tips. I am not much worried about physical stuff (i.e. how I will put the binary into RAM), but I was concerned about the memory layout and where it would be best to put. I am not familiar with MIPS (I am more ARM guy ), so bear with me.

For example, my understanding was that u-boot starts executing from flash, but when I had a look at the binary, it seemed to me there are some data at the very beginning of the image, something like vectors or memory layout, so I was wondering if this is simply relocatable to RAM without any addon. I have not looked at sources yet, but I am going to do it right away.

Also I assume the JTAG pinout on WR1043ND corresponds to EJTAG (which is different from e.g. ARM pinout), right?

Hmm, after having look at init sequence of u-boot, it seems u-boot is doing some DRAM initialization at the very beginning. So I wonder how is this supposed to work in case I use JTAG to load the u-boot into RAM - if it is even possible without prior init.
And if I need to do DRAM init before, then how to do it with JTAG?

mmm, ARM is much nicer, MIPS asm code sucks.

I see your point about initing the DDR... I do have the code for that from uBoot so if your JTAG app is able to feed a sequence of instructions directly into the CPU then you could get around it that way, otherwise the only other possibility I can see is allowing uBoot to run first, then using JTAG to take over and execute another image.

Anyhow, in the meantime, after a bit of make file fiddling (and fist pounding), I have also managed to successfully port the Atheros board package to the latest stable release of uBoot which is considerably newer and better featured than the archaic tosh they currently use. I've additionally adjusted the old version so that it compiles successfully with the latest cross compiler tools; this appears to result in a markedly smaller image (101 Kb instead of around 130) Although the newer uBoot produces images around 70Kb with the default options. However, the new uBoot uses a different (and arguably better) image format to the old uBoot, so I believe OpenWRT images would need to be modified for the new format.

In any case, really need to test this bad boy.

(Last edited by Olipro on 28 Feb 2011, 14:53)

OK, unfortunately the reason the newer uBoot was so small was because of a bug, it wasn't actually building in any features

Anyway, that's now fixed - unfortunately, if I compile UBoot with the new TFTP flash feature (and it is a pretty good feature) then it balloons to over 150Kb, which is rather a shame, although I could still put in my TFTP button boot mod since that's just a few lines of code.

The other option of course, and a bit of a nuclear one, is to grow the MTD0 partition to 256KB and thusly adjust the layout to suit, this actually wouldn't be too difficult to do since once you've flashed the enlarged uBoot you can then use its swish new TFTP feature to flash an image.

The reason the feature is so great is because essentially, uBoot will try to load from TFTP automatically on every boot - the image it downloads has to be in a specific format (a tool is provided to make your images into the appropriate format) and it can write absolutely any combination of things depending purely on what you build into your TFTP image.

At this point, some cooperation from the guys who did the board support for the WR1043ND in OpenWRT would be greatly appreciated... perhaps build images that are able to detect both styles of layout.

OpenWrt / Report from failed attempt with TL-WR1043ND

Adding to fyi post (which references mine), and Olipro comment:

It seems JTAG is not yet proven concept (to recover u-boot). Since there is "relatively" non-trivial initialization necessary. So killing u-boot, might as well leave you with desoldering option only. Do not take me wrong, I would love to have an option to recover through JTAG, but so far it is neither developed nor tested.

Apart from that, I am not OpenWRT developer, so I hope maybe some of them can give more insight, but changing either mtd layout or image format looks like a big problem to me. It does not mean I am against new features (or fixing bugs), but breaking the compatibility means, breaking toolchain - which now produces image format according to original TP-LINK u-boot and breaking it for people who are coming from/to TP-LINK original firmware.

And I also think that "normal" OpenWRT user should not be asked to flash u-boot, which usually gives the last resort when anything goes wrong. And which works quite well using serial cable.

And last comment on changing boot sequence to automatically TFTP to server - this can present serious security issue (especially if RTL8366 stays in switching mode during boot).

So if anything should be done to u-boot, I would say it should not change external compatibility (i.e. image format), should not automatically run binary from net (using serial console to TFTP and flash is fine) and possibly should fix the bug with RTL8366 initialization, by putting it into non switching mode.

If a user were to flash to a new uBoot that had an MTD partition size of 256Kb, it would automatically cause their existing OS image to stop working and obviously, they would know this when flashing.

From that point they would obviously need to then get uBoot to flash a compatible image over TFTP (which would of course be provided along with the uBoot update) - If I hadn't already made it clear; the new uBoot utilises its own image update format that enables for specifying explicit addresses inside the file so that the end-user doesn't need to concern themselves at all with this, all they simply need to do is bring up a TFTP server with the file, the bootloader takes care of everything else.

Clearly, once a user had flashed the new uBoot the OpenWRT image provided alongside it should naturally be modified to ensure that old layout images cannot be flashed.

All in all, I do not see any problem with offering a transition to a 256Kb boot partition providing you implement appropriate safeguards in OpenWRT.

(Last edited by Olipro on 2 Mar 2011, 01:09)

Hi Olipro,
You seem to know a lot about JTAG'ing. I need to figure out how to JTAG my Pirelli A125G router, using OpenOCD. However, I can't find neither Broadcom, nor any MIPS configuration files for the targets, although OpenOCD say they have support for at least one MIPS target. Everything is working and ready to go, but I just can't find an appropriate OOCD configfile...

Do you know where I can find it?

(I don't use UrJTAG since my USB-JTAG dongle is not yet supported by it.)

BTW. My Pirelli board data are as follows:

SoC                 Broadcom 6348 Rev.b0 / 00029107 @ 240 MHz
CPU                 vBCM6348KPBG V0.7
Flash               AMD? 29LV320CBTC-90G, 4MB (4M*8b | 2M*16b)
SDRAM               Winbond W9812G6GH-6, 16MB (2M*4Banks*16b)
LAN Switch          BCM5325e
Wireless Card       Broadcom BCM4318KFBG

[Openocd-development] FASTDATA bulk write optimization for mips_m4k file transfers

Have anybody managed to use JTAG for uBoot testing ?

I'd like to try some overclocking mods in uBoot, but don't currently have flash programmer for recovering

Hello.
I can help you create the initialization script for the program OpenOCD (OCD Commander).
As the example of the script, ar71xx.cfg - I created a script ar724x.cfg.
http://wiki.openwrt.org/ru/toh/tp-link/ … using.jtag
https://forum.openwrt.org/viewtopic.php?id=34993

As I understood the CPU ar9xxx need your own lowlevel_init_ar9100.S file in source - this means that you need a other (not ar71xx.cfg) configuration file for OpenOCD
The script sends commands via JTAG and runs the CPU to be able to download u-boot loader to the SDRAM memory, and then run it.

Because the I do not have this device, I need some registers from memory JTAG, so I can make this configuration file.
OpenOCD:

mdw 0xb8000000 0x10 
mdw 0xb8050000
mdw 0xb8050008
mdw 0xb805000c

Also, I want to see that the registers in u-boot loader (via console, when the processor is initialized).
U-boot:

md 0xb8000000 0x10 
md 0xb8050000 0x1
md 0xb8050008 0x1
md 0xb805000c 0x1

Glad to help you.

Sorry how do you get the registers again?

Connect to EJTAG on WR1043ND router (use special JTAG adapter - this is not the same as UART)
http://wiki.openwrt.org/toh/tp-link/tl-wr1043nd#jtag

Build OpenOCD for Linux or use this.

Run OpenOCD with parameters:

openocd -f interface\<cfg file for your JTAG adapter> -f target\ar71xx.cfg

for example, to use the LPT port with Wiggler - interface\parport.cfg

1. Turn-on router
2. Detect CPU-ID (0x00000001) in OpenOCD
3. Connect to telnet using localhost:4444
4. Enter the CPU in halt mode using command - halt
5. Use the above described commands that I gave you (mdw)
need the result

Same for u-boot (using UART):
1. Use TFTP method for connect to u-boot console
2. Use the above described commands that I gave you (md)
need the result

(Last edited by Dioptimizer on 1 May 2012, 16:50)

Can anyone give me uBoot-WR1043ND-mod.7z?

I made some modification for uboot 1043ND V1.8 , following some sort adjustment for flash size 16 MB.

ap83.h diff :

17c17
< #define CFG_FLASH_SIZE          0x00800000 /* Total flash size */
---
> #define CFG_FLASH_SIZE          0x01000000 /* Total flash size */
49c49
< #define CONFIG_BOOTARGS_FL     "console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ar9100-nor0:128k(u-boot),1024k(kernel),4096k(rootfs),64k(art)"
---
> #define CONFIG_BOOTARGS_FL     "console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ar9100-nor0:128k(u-boot),1024k(kernel),8192k(rootfs),64k(art)"
52c52
< #define MTDPARTS_DEFAULT    "mtdparts=ar9100-nor0:4096k(rootfs),256k(u-boot),128k(u-boot-env),1024k(uImage)"
---
> #define MTDPARTS_DEFAULT    "mtdparts=ar9100-nor0:8192k(rootfs),256k(u-boot),128k(u-boot-env),1024k(uImage)"

ar7100.h diff :

10c10
< #define CONFIG_BOOTDELAY    1// 4    /* autoboot after 4 seconds    */
---
> #define CONFIG_BOOTDELAY    3// 4    /* autoboot after 4 seconds    */

flash.c diff:

25c25
<     printf ("flash size 8MB, sector count = %d\n", flash_info->sector_count);
---
>     printf ("flash size 16MB, sector count = %d\n", flash_info->sector_count);

Bootlog : http://pastebin.com/ZfeDx5TM

U-boot bin : https://www.box.com/s/6wbl4omlfhqpd57v7hvo

(Last edited by xopal on 27 Jan 2013, 12:44)

Hi xopal! I also have a v1.8 1043ND and looking to increase the flash size to accommodate VPN and also usb and JFFS functions which need more space.

Is that possible?

I see you prepared a u-boot but what happens next? I have an SPI programmer and I am quite experienced using it along with HxD editor for binary modifications.

Please guide me.

BR,
F

I hardbricked my WR1043ND v1.8

Please correct me if I'm wrong:

Use JTAG to load u-boot to RAM, run instructions from RAM und get into u-boot. Then I could load the correct image via serial or TFTP and write it to FLASH.

Could someone provide an original u-boot? Or something, which could be use for an unmodified version?
(no modifications to the flash layout, RAM size or flash size)

Check the wiki page on how to strip off the first 128kb of a stock firmware image (basically the opposite of what they do there) and then load it into your flash chip. JTAG will probably not work, so SPI is probably the way to go.

Thank you.

At the moment I can't desolder the chip so it will be a future project.
Do you have an explanation, why a sideload of the u-boot via JTAG into the RAM will not work?

for the record : I used the tpl-tool from the firmware-mod-kit.

Give it a try and document it in the wiki. Someone always has to go first.