Hash: SHA256

Just in case anybody was following this;

i've worked around the issue by prepending the first 257 blocks from
an official firmware-upgrade and than padding to the required size

It seems that the automatic process now expects u-boot and and an
ominous info-block to also be contained in the image.

that might not be the proper solution. if anyone of you has a better
idea - i'd like to hear it :-)

kind regards

On 29.07.2015 20:20, Leon George wrote:
> Hi :-)
> briefing: the automatic flashing-process - holding down the 
> WPS-button in order to flash an image downloaded via TFTP - no 
> longer works for certain WDR3600-devices with hardware revision
> 1.5 that have only minor (visible) differences to working devices
> with the same revision.
> .. this is going to be long - sorry for that. i'm trying to
> provide as many details as possible.
> I'm working on a factory-process for TP-Link WDR3600. Last week we 
> have encountered an error where we were ( headache-english :-D ) 
> not able to flash the last shipment using an automated process. 
> There seems to be new hardware with the revision still being 1.5 
> but the u-boot behaving differently.
> From the outside, these devices look quite similar - the only 
> differences we've found so far are: -there are four labels on the 
> backside (as opposed to 3) the new one showing custom SSIDs (much 
> like the one on the Archer-C5) -a label on the inside on the
> yellow LAN-ports has a string "4FC-1", which we have not seen yet -
> the working boards have "3FC-3"
> The only way to flash our image to this new hardware is to either: 
> -flash manually using the u-boot-prompt (t ; e; cp.b; reset) 
> -upload it to the firmware-update-page of the stock-firmware The 
> images then boot and seem to be happy.
> That, however, is not acceptable for a factory-process.. Turns out 
> that our image was 6815748 bytes in size (we forked from openwrt a 
> while ago) which is not accepted by these new devices using the 
> existing process. The router instantly resets after the firmware 
> has been received (before hte flash is erased). Have a look at 
> "Flashing via TFTP" in 
> http://wiki.openwrt.org/toh/tp-link/tl-wdr4300 to see what we're 
> doing - no magic involved :-)
> 'wrong_filesize.log' contains the serial-output when the file size 
> is not 'correct'.
> So far, i've come to the conclusion that only files with size 
> 8192512 / $7D0200 (bigger than the rootfs-mtd!) make it past the 
> tftp download. I've tried padding the file with \x00 or \xFF. The 
> file is then copied to the flash but will not boot. See 
> 'successfull_flash.log' for the output. Notice the 'boot up image' 
> after the transmission. <---- You can see the error while booting 
> at the end of that file (LZMA-length ).
> The last thing i've tried, is to use an image produces from 
> OpenWRT-trunk - i gather you have introduced padding to the image 
> since our fork. That image would also NOT be copied to the flash. 
> Flashing does work if the file is padded to the 'magic' size but 
> the boot-issue remains.
> I'm still working on this and will keep you informed - but if 
> anyone of you has an idea on how to address this issue.. any help 
> would be highly appreciated!
> The next thing on my TODO-list is to see how the image can be 
> modified to make it boot. I'm comparing it to the
> firmware-upgrades from TP-Link (which do work using this process).
> But first: a good night's sleep :-p
> hoping this might help someone,
> kind regards, nice evenings to you,
> Leon M. George
> _______________________________________________ openwrt-devel 
> mailing list openwrt-devel@lists.openwrt.org 
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Version: GnuPG v2

openwrt-devel mailing list

Reply via email to