Yes, I did set 16MB in dts/dtsi files and it successfully compiles. Then I upgraded the router using the newly compiled sys-upgrade image, updated successfully. After that bad things happens, when I reboot the router it goes into boot-loop. Then I directly backed up the corrupted image from flash chip and analysed with hex-editor, I found that the art and tplink partitions are completely corrupted.
Of course you have to move the ART data to its new location at the end of the chip. If you leave it at 0x7f0000 which is right in the middle of the new chip it's going to get clobbered when the jffs is formatted.
Corrupted ART should not cause a failure to boot though, the wifi will not work but everything else should.
Yes, as you've said, I read somewhere that corrupted art will not cause a boot failure but wifi will not work. Also I raw backed up all the partitions when the meantime after up-gradation the router is working before reboot. Then I replaced the art, tplink partition with the non-corrupted one to the raw backed up 16MB ROM. After that I re-flashed the whole 16MB modified raw backup into the flash chip using external programmer. Same thing happened, it didn't boot.
With the 8MB Flash sizes of all partitions as follows:
u-boot:128KB
mac:64KB
firmware:7808KB
tplink:128KB
art:64KB
Total: 8MB
With the 16MB Flash sizes of all partitions as follows:
u-boot:128KB
mac:64KB
firmware:16000KB
tplink:128KB
art:64KB
Total: 16MB
Have You tried flash 'factory' image? through tftp? And remember:
ALWAYS USE -factory.img instead of sysupgrade one, because factory.img apply new DTS(partition tables) while sysupgrade won't.
(link to some tutorial for Netgear R7800, but idea is the same).
this is not true on newer devices, i had boot failures on both qca9531 and qca9558 with missing art
it won't work that way, you need to modify sources, in this case tools/firmware-utils/src/tplink-safeloader.c i think.
change
{"radio", 0x7f0000, 0x10000},
to
{"radio", 0xff0000, 0x10000},
other variables in that safeloader section might need to be adjusted as well
Yes, I also did it using tftp didn't worked, back to the previous firmware and normally boots.
OK, I will look into this...
Yes, finally I found the reasons why the custom 16MB firmware bricks the router. I need to do lots of modifications in "tplink-safeloader.c" and also in "qca9563_tplink_archer-x6-v2.dtsi". Previously I just modified the "qca9563_tplink_archer-x6-v2.dtsi" as follows:
partition@30000 {
compatible = "denx,uimage";
label = "firmware";
reg = <0x030000 0x7a0000>;
};
to
partition@30000 {
compatible = "denx,uimage";
label = "firmware";
reg = <0x030000 0xfa0000>;
};
also the firmware image is not the last image "tplink" and "art" comes after that. Also I need to modify their starting offset as well as size offset.
partition@7d0000 {
label = "tplink";
reg = <0x7d0000 0x020000>;
read-only;
};
art: partition@7f0000 {
label = "art";
reg = <0x7f0000 0x010000>;
read-only;
};
and also modified "generic-tp-link.mk" as follows:
define Device/tplink_archer-c6-v2
$(Device/tplink-safeloader-uimage)
ATH_SOC := qca9563
IMAGE_SIZE := 7808k
DEVICE_TITLE := TP-Link Archer C6 v2
TPLINK_BOARD_ID := ARCHER-C6-V2
DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9888-ct
endef
TARGET_DEVICES += tplink_archer-c6-v2
to
define Device/tplink_archer-c6-v2
$(Device/tplink-safeloader-uimage)
ATH_SOC := qca9563
IMAGE_SIZE := 16000k
DEVICE_TITLE := TP-Link Archer C6 v2
TPLINK_BOARD_ID := ARCHER-C6-V2
DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9888-ct
endef
TARGET_DEVICES += tplink_archer-c6-v2
I didn't know about the "tplink-safeloader.c" has to be modified, thanks psyborg for pointing out me. I think I have found the code that I need to change in "tplink-safeloader.c". Here is the code section:
/** Firmware layout for the C6v2 */
{
.id = "ARCHER-C6-V2",
.vendor = "",
.support_list =
"SupportList:\r\n"
"{product_name:Archer C6,product_ver:2.0.0,special_id:45550000}\r\n"
"{product_name:Archer C6,product_ver:2.0.0,special_id:52550000}\r\n"
"{product_name:Archer C6,product_ver:2.0.0,special_id:4A500000}\r\n",
.support_trail = '\x00',
.soft_ver = "soft_ver:1.0.0\n",
.partitions = {
{"fs-uboot", 0x00000, 0x20000},
{"default-mac", 0x20000, 0x00200},
{"pin", 0x20200, 0x00100},
{"product-info", 0x20300, 0x00200},
{"device-id", 0x20500, 0x0fb00},
{"firmware", 0x30000, 0x7a9400},
{"soft-version", 0x7d9400, 0x00100},
{"extra-para", 0x7d9500, 0x00100},
{"support-list", 0x7d9600, 0x00200},
{"profile", 0x7d9800, 0x03000},
{"default-config", 0x7dc800, 0x03000},
{"partition-table", 0x7df800, 0x00800},
{"user-config", 0x7e0000, 0x0c000},
{"certificate", 0x7ec000, 0x04000},
{"radio", 0x7f0000, 0x10000},
{NULL, 0, 0}
},
.first_sysupgrade_partition = "os-image",
.last_sysupgrade_partition = "file-system",
}
I rebuilt the openwrt firmware with all proper modification and all the partition offsets replaced with proper calculation in the source code of openwrt, compiled and flashed successfully. Running with >8MB free space, everything is ok until I reboot the router!!! Then I found the same problem, u-boot is culprit here it checks for the partition offsets and if it's found any tweaking then it prevent the loading of kernel to the memory and goes to the recovery mood. Sets router ip address to 192.168.0.1 then when I open the ip from web browser it shows a tplink firmware recovery page insisting browse and upload a firmware. All the modifications are not enough it definitely needs a custom u-boot.
This doesn't make a lot of sense since the partition changes are in the OpenWrt code that the bootloader would not be aware of. Perhaps the bootloader is looking for some piece of data in the tplink or ART partitions which no longer exist in their expected places. Have you looked at the bootloader serial log?
I searched on the net about tp_uart, what I found is tp_uart is a proprietary 1wire protocol which then father translate into uart. Also I've found in a datasheet of microchip that there is a 1wire half duplex uart protocol and interface also. Tp-link makes difficult things these days so that no one can easily do a mod.
I don't think this is the same as Siemens TP-UART aka KNX. That is a standard for building HVAC control involving long cable runs and multi-drop taps.
More likely it is a simple wired-or connection of 3.3 volt TX and RX. If you connect only the RX wire of your converter it may work in a receive-only manner.
I think so... No output then how I will get the u-boot logs?
i'd help you but fccid photos are shit as usual. try looking on the board and find tp_uart out. if there is no any you'll need to discover it. probably is pulled out and left unmarked.
I did not found either. I've another idea in my mind, Archar-C6 v2.0 US version has same hardware only the difference in some LED GPIOs and the 16MB flash, if I get a raw backup of stock firmware taken directly from the flash rom then with some tweaking with serial number in tplink partition that might work on Archar-C6 v2.0 EU/RU version. Previously I restored the RU version of firmware upgrade image from tplink website and then I flashed using openwrt firmware upgrade, it worked!
Can you trace it to a CPU pin# ? I guess Tx will be somewhere around.