I don't know what this means...
That dev: size erasesize name stuff is a /proc/mtd content. It should be familiar if you read through the device wiki page: Stock firmware
It maps the /dev/mtd* devices to their names.
Thanks, so here it shows:
dev: size erasesize name
mtd0: 00800000 00010000 "ALL"
mtd1: 00030000 00010000 "Bootloader"
mtd2: 00010000 00010000 "Config"
mtd3: 00010000 00010000 "Factory"
mtd4: 00180000 00010000 "Kernel_RootFS"
mtd5: 00010000 00010000 "params"
mtd6: 00010000 00010000 "user_backup"
mtd7: 00010000 00010000 "user"
mtd8: 00600000 00010000 "Rootfs" <<< this is last and the only one not in alphabetical order.
If Kernal.bin is mtd1+mtd2+mtd3+mtd4+mtd5+mtd6+mtd7+mtd8 then I cannot use this order (as I previously listed them)
ALL.bin
Bootloader.bin
Config.bin
Factory.bin
Kernel_RootFS.bin
params.bin
Rootfs.bin
user.bin
user_backup.bin
Therein lies my confusion. You did confirm that the order I listed them (just above here, alphabetically) is the order they should be joined, but then the Partitions from “cat /proc/mtd ”: shows Rootfs.bin as the last file.
I get the rest of the process, but this part is really not clear, and I assume this order matters...
Kernal.bin should be the output of your copy /B command.
Sorry. I didn't want to confirm that. (I wanted to confirm that the files would be concatenated in the same order that you put them in the command line) 
Why thought you that concatenating them in alphabetically order would be a good thing? 
As you can see they aren't alphabetically order on the flash.
And you could also see, that I clearly corrected myself about concatenating all the stuff into a bigger stuff.
You shouldn't concatenate all the backups! You should concatenate only those partitions which I wrote!
Ok, thank you. So this is what you are saying as to "those partitions which I wrote!" that need to be combined for Kernal.bin
1 Like
Tried this, no go. Basically after I power on the unit, regardless of holding down the reset button or not, both the Internet (yellow) and LAN (blue) LEDs go on SOLID and nothing happens from TFTP...
Do you remember how did you flashed that factory.bin file?
I flashed that out of LUCI Gui.
Thanks for all your help you're offering here, xabolcs! Actually, re-reading the original thread title here, I'm afraid I've mislead you:
I had actually home come here to learn and document how to go from stock TM01 to OpenWRT 19.07 or higher 
And honestly, I'm still confused about how best to do it safely, as I'm not knowledgeable about U-Boot and rootfs.
So, in order to install OpenWRT 19.07 on a stock TM01, am I hearing you recommend to install your 1536k kernel + 6144k rootfs files using the usual TFTP server (at which IP address?), instead of simply flashing ht-tm02-initramfs-kernel.bin linked on the new HT01 device page stub: Is this correct?
Hi!
I will try to reproduce your issue with my HT-TM02 and HT-TM01, but your case isn't an easy thing. 
For installation see the "snapshots and recent releases" TFTP method of RP-WD03.
Allright, xabolcs, I'm getting ready to test and document the OpenWRT installation on my TM01 using the TFTP method for the RP-WD03 
Final questions for clarification:
- Would script
EnterRouterMode.shat the rp-wd03 page on openwWRT be recommended to get a working backup of the TM01's stock FW? - your
kernelandrootfsbinaries at GitHub are for the TM02. Would they need any change to fit the TM01? - Is anything to be done about the
manifestandsysupgradefiles there, or do they just indicate what's already incorporated into your binaries?
Yes and no! 
Yes, it's recommended, as it does the job in a good way.
No, I don't recommend it, as there is a better script for that, which does that backup stuff in a more nicer way! 
There is an EnterRouterMode.sh which I recommend and does the backup in a more descriptive way:
$ ls -lgG backup-fw-WiFiSDRJ-RAV-WD02-2.000.032-8850108874/
total 16528
-rw-r--r-- 1 10719 Aug 9 2020 dmesg.txt
-rw-r--r-- 1 407 Aug 9 2020 env.txt
-rw-r--r-- 1 14 Aug 9 2020 fwinfo-filename.txt
-rw-r--r-- 1 159 Aug 9 2020 fwinfo.txt
-rw-r--r-- 1 1422 Aug 9 2020 ip_a.txt
-rw-r--r-- 1 8388608 Aug 9 2020 mtd0.bin
-rw-r--r-- 1 196608 Aug 9 2020 mtd1.bin
-rw-r--r-- 1 65536 Aug 9 2020 mtd2.bin
-rw-r--r-- 1 65536 Aug 9 2020 mtd3.bin
-rw-r--r-- 1 1572864 Aug 9 2020 mtd4.bin
-rw-r--r-- 1 65536 Aug 9 2020 mtd5.bin
-rw-r--r-- 1 65536 Aug 9 2020 mtd6.bin
-rw-r--r-- 1 65536 Aug 9 2020 mtd7.bin
-rw-r--r-- 1 6291456 Aug 9 2020 mtd8.bin
-rw-r--r-- 1 528 Aug 9 2020 mtd.md5sum
-rw-r--r-- 1 10 Aug 9 2020 mtd_sn.txt
-rw-r--r-- 1 340 Aug 9 2020 mtd.txt
-rw-r--r-- 1 82 Aug 9 2020 readme.txt
They are ready to use.
manifest is just a "for your information" file.
sysupgrade.bin is the sysupgrade image ... but it's currently useless: there aren't any other version of my community build, and my build is incompatible with the official build.
Sysupgrading back and forth between the official image and my community build causes softbrick of the device. Don't do it!
For switching between official release and my community build one should use the TFTP method.
So I've got it to work. With enough horsepower and memory to run shairport-sync 
Great xabolcs that you have provided 19.07 binaries for the TM01. Thank you for your kind help! (BTW snapcast is cool — mpd... nice... — but runs shairport-sync anyway when streaming from Apple devices. Actually, would the TM01 have enough free memory to run snapcast?)
Happy to document the steps I took on the TM01 OpenWRT ToH page.
Actually I wonder what would have happened if we had simply installed the "official" TM02 19.07.7 images that are linked on the Hootoo Tripmate OpenWRT page using the TFTP method? Should these references be deleted when editing the page?
Or should the link to xabolcs' binaries be added on that page? I wonder how to articulate the difference between the two firmware versions to readers.
I think it will overwrite the params partition (one of the device specific partitions of your device) and of course softbrick it! Without backup. 
initramfs.bin images should be used through serial access in U-Boot, and not for TFTP recovery!
Yep, those initramfs-kernel.bin files should be wiped from the "Firmware OpenWrt Install URL" column!
Leave it empty and let my builds noted in other sections of the page.
Hi there, any chance you had any luck to replicate my case, and a solution to unbrick?
Thank you
Thanks for the follow-up and sorry, I was busy in these days!
OK, so I have a HooToo HT-TM01 (firmware v2.000.046) and I would like to switch over to OpenWrt using the instructions here. However, unfortunately I'm failing on the first step, to create a system backup 
. I've created the file "EnterRouterMode.sh" (case sensitive I presume) with the code from this post and copied it onto a 1GB USB stick. With the TM01 powered up, I insert the USB stick and wait for the status light to stop flashing (I also tried much longer than that). However, the folder with the system backup files is not created. It only creates DLNA related folders. I've tried resetting the TM01 and I've tried a FAT and NTFS formatted USB stick, all without success. Does somebody know what I'm doing wrong? Thanks in advance for your help.
1GB could be to big.
Partitioning might be of importance too.
Found the solution, as per jekagan's post here:
If you copy the code for the script, make sure your text editor uses UNIX line endings (0x0A, i.e. \n), and not Windows line endings (0x0D 0x0A, i.e. \r\n). The script wouldn't work for me until I changed this. If you're on Windows, this is simple enough to do with Notepad++ (or your editor of choice). In Notepad++, choose Search -> Replace, then make sure "Extended" is selected for Search Mode.
Find what: \r\n
Replace with: \n