OpenWrt Forum Archive

Topic: Unable to flash a Planex MZK-W04NU

The content of this topic has been archived on 28 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi everyone,

I saw several posts with people saying they succedded to first flash their MZK-W04NU via the original Planex web interface. But I never succeeded. I tried from all different available Planex firmwares (from 1.00.03 to 1.03.23) but still impossible. I tried tftp at boot but seems it can't work.

I tried to flash with the firmware openwrt_r14959_manyUSB1_ar71xx-mzk-w04nu-squashfs.webui and openwrt_r14959_manyUSB1_ar71xx-mzk-w04nu-squashfs.bin from this page : http://sites.google.com/a/roundsparrow. … nwrt_ap81/


Did someone succeeded ? Do I have to use a serial cable ?

Thanks for your help

Well, I answer to myself (the night was long !)

After comparing official firmwares to openWRT ones with an hex editor, I could figure out why it was not working.

MZK-W04NU firmwares seems to have a constant size, whatever you decide to include inside. The generated .webui openWRT firmware size was 7,798,818 bytes where the official one was 7,864,320 bytes.

The actual process is the following :

1. Padd with 0x00 the .uImage kernel to reach 1,441,792 bytes (dd bs=1408k conv=sync)
2. Padd with 0x00 the .squashfs file to reach 6,356,992 bytes (dd bs=6208k conv=sync)
3. Concatenate the 2 above files (.uImage + .squashfs = .bin). We now have the .bin file
4. Add the Planex header (34 bytes) using (mkplanexfw). We now have the .webui file

1,441,792 + 6,356,992 + 34 = 7,798,818 bytes. 65,502 bytes were missing in the target/linux/ar71xx/image/Makefile in order the firmware could be uploaded via the Planex http interface :

5. Padd with 0x00 the .webui image to reach 7,864,320 bytes (dd if=.webui bs=7680k sync=conv of=.webui2)

After that, I could upload the firmware successfully.

Note : The last padd must be done AFTER the Planex header writing, if done before, the header won't be accepted by Planex GUI.

After that, I could begin to play. Unfortunately, I made a mistake when uploading a new firmare with mtd and I briked it. I just bought a 3.99 euro Nokia cable.

Note sure how to upload a new firmare with mtd for the lastesk trunk version. Anyone can help about that ?

Thanks !

cailleaux wrote:

Note sure how to upload a new firmare with mtd for the lastesk trunk version. Anyone can help about that ?

For example: mtd -r write openwrt-ar71xx-mzk-w04nu-squashfs.bin firmware

BTW, planex flashes with 7798818 bytes .webui without any problem in my case.

Igor wrote:

For example: mtd -r write openwrt-ar71xx-mzk-w04nu-squashfs.bin firmware

Ok, it was "firmware"... shit (sorry). I saw on some other website the following :

mtd write <file>.uImage kernel
mtd -r write <file>.squashfs rootfs

And of course, now only the switch lights are working... (ToT)

I have to wait for my Nokia cable now... and hope I'll be able to reflash it...

If only there was a tftp safety boot like the WRT54GL...

Igor wrote:

BTW, planex flashes with 7798818 bytes .webui without any problem in my case.

When I tried to flash with the 7798818 bytes .webui file, the Planex web interface was working, working, working and finally raised an error 500. When checking the log, it said "Terminate CGI pid xxxx timeout" or something like that. The same happened whatever the Planex firmware version. But as soon as I added the 65,502 extra null bytes, the countdown appeared just after the upload finished and the OpenWRT booted successfully when the countdown reached 0.

My PCB shows : 21514MKW04NU1A1 Rev.:A1. What about yours ?

Thanks for your answer, I'll try it asap.

Hi,

I could unbrick my MZK-W04NU with a Nokia DKU-5 cable.

For information, this cable has three wires : White for RX, Green for TX and Blue for Ground.

I used putty (115200 bauds, 8 bits, no parity, bit stop 1 and XON/XOFF for flow control.

From here, I could use the commands given in this post : http://forum.openwrt.org/viewtopic.php?id=18434

ar7100> erase 0xbf050000 +0x770000
ar7100> setenv serverip 192.168.1.254; setenv ipaddr 192.168.1.1
ar7100> tftp 0xa0800000 openwrt-ar71xx-mzk-w04nu-squashfs.bin
ar7100> cp.b 0xa0800000 0xbf050000 0x770000
ar7100> reset

I used tftpd from http://tftpd32.jounin.net

Nicolas

Sorry for bumping up this old post.  Hopefully someone hear can answer my question.

So here is my understanding of all possibilities to flash MZK-W04NU
1.  use mtd to flash the firmware partition. 
2.  use serial port to get into serial concole and flash with tftp

Is there some other way like boot_wait?  I know that u-boot also has boot-delay boot-env variable, but I didn't figure out how to access that part.  Any guide will be greatly appreciated!!

Or is it possible to change the bootloader from u-boot to CFE, which is running on the classic Linksys 54GL router and has a neat boot_wait feature.

Thanks a lot in advance!

(Last edited by jintao on 16 Nov 2009, 23:39)

jintao,

Unfortunately, you are correct to the best of my knowledge. Boot_delay only controls the seconds that uboot waits for serial input before performing the default boot action. Uboot does not have any tftp server support, as would be needed for a "push tftp" reflash.

This is really too bad, as the need to hook up a serial line is all that prevents this board from being the perfect openwrt platform.

However, here is something that might help reduce the pain of doing a "pull tftp" flash via serial console. Uboot can can run simple scripts from environment variables. So here is what I use to automate the process instead of typing the commands in by hand every time:


filesize=770000
fileaddr=A0800000
imageaddr=bf050000
filename=openwrt-ar71xx-mzk-w04nu-squashfs.bin
loadtftp=tftp 0x${fileaddr} ${filename}
wipeflash=erase 0x${imageaddr} +0x${filesize}
copyflash=cp.b 0x${fileaddr} 0x${imageaddr} 0x${filesize}
flashimage=run loadtftp; run wipeflash; run copyflash; reset

Then you just need to set ipaddr and serverip to correct values for your network. At the serial console prompt, you can type "run flashimage" and it will flash from the tftp server.

Edit: Oh yeah. Put these in using setenv. For example:
setenv loadtftp="tftp 0x${fileaddr} ${filename}"

Once you are satisfied (use printenv to check for typos), you can use saveenv to put these into flash.

Uboot doesn't deal well with backspace characters, so I suggest writing this up in a text editor before hand and pasting it into the console.

(Last edited by thalience on 17 Nov 2009, 19:03)

Hi thalience,

Thanks a lot for your concrete reply!! 

Have you ever tried using mtd approach to flash this?  I guess I would avoid touching the uboot method as long as I dont have to.

Thanks again

jintao

thalience wrote:

filesize=770000
fileaddr=A0800000
imageaddr=bf050000
filename=openwrt-ar71xx-mzk-w04nu-squashfs.bin
loadtftp=tftp 0x${fileaddr} ${filename}
wipeflash=erase 0x${imageaddr} +0x${filesize}
copyflash=cp.b 0x${fileaddr} 0x${imageaddr} 0x${filesize}
flashimage=run loadtftp; run wipeflash; run copyflash; reset

Hi thalience,

I have another quick question.  So what do these memory address stand for? 

Is 0xbf050000 the starting address of initrd partition?  and 0xA0800000 the starting address for firmware partition?  That's just my guess.
So what's the different between this approach and mtd?  I remembered that mtd only overwrites the firmware partition.
thanks in advance!

jintao wrote:

I have another quick question.  So what do these memory address stand for? 

Is 0xbf050000 the starting address of initrd partition?  and 0xA0800000 the starting address for firmware partition?  That's just my guess.
So what's the different between this approach and mtd?  I remembered that mtd only overwrites the firmware partition.
thanks in advance!

0xbf050000 is the start address of the kernel partition in flash (this is also the boot address), and 0xA0800000 is somewhere in ram which is not used by uboot itself. We first tftp the firmware image file into ram, then wipe flash, and finally copy the firmware into flash.

The "firmware" mtd partition overlaps all of the kernel, squashfs and jffs2 partitions. It represents "the area we need to flash with the firmware file". So the start of the kernel partition (0xbf050000) is also the start of the firmware partition. There is no difference between flashing with mtd under linux and flashing the same firmware image file with uboot. Both overwrite the same flash areas.

Now, actually there is one potential difference between the two methods. Mtd is capable of being smarter than just writing a file into an area of flash. It can interpret the firmware image being written and integrate data into the empty jffs2 area. This is how the sysupgrade script (and webui) is able to preserve settings over a firmware upgrade.

But the default method with mtd is still to just write the raw file to flash.

thalience, thank you so much for your response!   very helpful!!

Hi thalience,

I am still waiting for my Nokia cable.  A quick question.  You need to run any command in the hyperterminal to enter uboot serial console?  or once the session is connected, everything will be pulled out automatically.

thanks a lot!

jintao

cailleaux wrote:

Hi,

I could unbrick my MZK-W04NU with a Nokia DKU-5 cable.

For information, this cable has three wires : White for RX, Green for TX and Blue for Ground.

I used putty (115200 bauds, 8 bits, no parity, bit stop 1 and XON/XOFF for flow control.

From here, I could use the commands given in this post : http://forum.openwrt.org/viewtopic.php?id=18434

ar7100> erase 0xbf050000 +0x770000
ar7100> setenv serverip 192.168.1.254; setenv ipaddr 192.168.1.1
ar7100> tftp 0xa0800000 openwrt-ar71xx-mzk-w04nu-squashfs.bin
ar7100> cp.b 0xa0800000 0xbf050000 0x770000
ar7100> reset

I used tftpd from http://tftpd32.jounin.net

Nicolas

jintao wrote:

Hi thalience,

I am still waiting for my Nokia cable.  A quick question.  You need to run any command in the hyperterminal to enter uboot serial console?  or once the session is connected, everything will be pulled out automatically.

On power-on, uboot prints some basic info to the serial console and then waits 4 seconds (by default) for input. Any keypress in that time will drop you to a uboot prompt, interrupting the default boot process. While it waits, you should see it counting down.

The discussion might have continued from here.