Re: [OpenWrt-Devel] [WDR3600] factory using WPS-button and tftp doesn't work anymore (new hardware?)
-BEGIN PGP SIGNED MESSAGE- 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 (8192512). 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVuofgAAoJEPImwNGZR6nx1dMIANVEkO3ERaqLn9sPRUWxQrSo 5BN9locEKM43DbV0qFFLQOZdOGjyfhon2WQTnh1yLf/1uiM5YcmJNSQSg8Cmt9cG h0Z+JgMVCj7T++6VYMqfqChilN1NXo6UB27qLiC2PGlp0MiTJB/XQzUQHS77jzTR p0ihP2Ie82DsLXCBLB0UAMyG6eyqxvWnwlTgrq6AWN/8nKWWQBIESoGltW016qMT DRfQc8Z9vy/HMcPC9yBRRD3Vk4tzUZ+5Y+5sTum9eBEmEUaQJXzmJAmJ9nNzgzrY NUjzhNIrnmYmDu0HHaecXL/aDIb4ZyvqtBbQMwBROtK45z+ZpZV2I4F67pJ1O1Q= =/A24 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [WDR3600] factory using WPS-button and tftp doesn't work anymore (new hardware?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVuRlUAAoJEPImwNGZR6nxiNUH/RrfGmGI22Y5Vx3VwL3ub42v aTHAYGCEAKSLH3XFoxGOMJD0WU7YY1RqB7SAWghyghnGf1rK9IT+TELnjRkseB5u HpvG2sCb95ORCSXbxoPo9h6HRjZIH478MzVjoVAFO5EK37F/z4wSZd3rRz12Z6R2 NOej/Ie1mFO5Aqdzbpw7yhdDWNId+kzhULQeahyzIP7rExZzxOzLmnfhbb4gWueQ BK8TPtlFi7qQLyvE9SKsiXPWt6koprWbqW3EQOS/640AERaZbDgrzre5QZXBtrkI q+pSZw9KY98suPgZJe33/5nP23QaXsZjtAbg81KN9Smcelp6QeqS9f9ZMC5yI2I= =jBUP -END PGP SIGNATURE- U-Boot 1.1.4 (Oct 21 2014 - 12:49:00) U-boot DB120 DRAM: 128 MB id read 0x10ff flash size 8MB, sector count = 128 Flash: 8 MB Using default environment PCIe Reset OK!! In:serial Out: serial Err: serial Net: ag934x_enet_initialize... No valid address in Flash. Using fixed address wasp reset mask:c03300 WASP S17 PHY * : cfg1 0x7 cfg2 0x7114 eth0: ba:be:fa:ce:08:41 athrs17_reg_init: complete eth0 up eth0 dup 1 speed 1000 Using eth0 device TFTP from server 192.168.0.66; our IP address is 192.168.0.86 Filename 'wdr3600v1_tp_recovery.bin'. Load address: 0x8006 Loading: # # # # # # # # # # # #
