Okay! Seems like kmod-mtd-rw, then unlock and then a write ot mtd1 to u-boot worked and I was able to boot with a new bootloader now! Looking in Wireshark now it does ask for "Who has 10.10.10.254?" so it looks promising
Now... Do I have to just flash kernel since mtd8 is already included there or do I still have to rename mtd8 to rootfs and flash that too?
YUP! Damn! I never thought I'd see this device work again, awesome!
Thanks so much for your help man! After many, MANY years of not being able to use that thing anymore it finally comes back to life as it's supposed to be I'll definitely put the stuff we talked about here in my blog for other people to easily find and being able to follow it too in case theirs is/was also as screwed up as mine!
TripMate-0E58 ... very interesting.
This is my device's MAC.
Please try factory reset on your device! Hold reset for a long time (30s? 1min?) while the TripMate is powered on.
It was easy, wasn't it?
get OEM u-boot binary
flash it with the help of kmod-mtd-rw and write
set up a TFTP recovery environment
get kernel and rootfs
from someone else's backup
extract from stock firmware upgrade file (with nice tools)
But don't forget to note how important that backup directory is!
And create a new for yourself with EnterRouterMode.sh (saved at pendrive's root directory) below:
EnterRouterMode.sh
#!/bin/sh
SDCARD=/data/UsbDisk1/Volume1/
USB=/data/UsbDisk2/Volume1/
FWCFPT="/proc/vstinfo"
FWFIRMWARE="/etc/firmware"
FWINFO=
if [ -r $FWFIRMWARE ]; then
FWINFO=$FWFIRMWARE
elif [ -r $FWCFPT ]; then
FWINFO=$FWCFPT
fi
readfwinfo() {
grep $1 $FWINFO | cut -d= -f2
}
WORKDIR=`find /data -name EnterRouterMode.sh`/..
cd ${WORKDIR}
CURFILE=`readfwinfo CURFILE`
CURVER=`readfwinfo CURVER`
VENDOR=`readfwinfo VENDOR`
PRODUCTLINE=`readfwinfo PRODUCTLINE`
MTD_SN=`get_mtd_sn`
FWBACKUPPREFIX=fw-${PRODUCTLINE}-${VENDOR}-${CURFILE}-${CURVER}-${MTD_SN}
mkdir -p backup-${FWBACKUPPREFIX}
cd backup-${FWBACKUPPREFIX}
if ! (md5sum -s -c mtd.md5sum); then
for mtd in `grep ^mtd /proc/mtd | cut -d: -f1`; do
dd if=/dev/$mtd of=$mtd.bin
done
sync
cp $FWINFO fwinfo.txt
echo $FWINFO > fwinfo-filename.txt
cp /proc/mtd mtd.txt
md5sum mtd*.bin *.txt > mtd.md5sum
dmesg > dmesg.txt
ip a > ip_a.txt
env > env.txt
get_mtd_sn > mtd_sn.txt
cat > readme.txt <<EOM
This directory contains a backup from your $VENDOR device.
Put it to a safe place!
EOM
fi
cd ..
# nvram_get > $SDCARD/nvram_get.txt
# nvram_get rt2860_nvram_show >> $SDCARD/nvram_get.txt
# nvram_get show >> $SDCARD/nvram_get.txt
# nvram_get chkcrc >> $SDCARD/nvram_get.txt
# nvram_get gen > $SDCARD/nvram_get_gen.txt
/etc/init.d/teld.sh restart
@xabolcs , Thanks for providing all of the files and information. I have the exact problem you guys were talking about. If the offer still stands, could you make that custom sysupgrade.bin? It's a bit over my head.
Yep that’s why I’m holding off for now Until everything’s set up so others can easily follow along in case theirs is screwed up too.
I guess there’s no way to supply a sysupgrade image for people already on a working OpenWrt to easily revert? And then additional steps for people who screwed their install up beyond repair
I tried upgrading the firmware of my HooToo Tripmate Nano (HT-TM02) but failed, now the device's blue LED keep on blinking and I am not able to see the WIFI network, device became unusable, I have tried to reset by inserting the pin but it seems not to be working.
Can anybody help me to get my HT-TM-02 back to life
Thanks for creating the new openWRT page for the HooToo TM01. I'm happy to add instructions there, but please confirm what is the recommended installation procedure for a factory-new TM01:
install the OpenWrt 19.07 "Install" firmware linked there straight from the stock menu?
install wingspinner's TM02 image (using an empty USB stick), and then sysupgrade to 19.07?
Well, it's a little bit complicated. Let me explain.
Sadly the current support isn't as good as it could (should? ) be:
it overwrites device specific parts of the device: the params partition
it changes the way of the TFTP recovery
it listens on another address
it uses different filename
it uses one file instead of separate kernel and rootfs files
it creates a full backup to the usb drive where from the user installed, but
the user doesn't know about it, and wouldn't put it to a safe place
Because of the above I won't recommend the current way of installation.
I did my experiments (thanks @jwmullally for the initial work) about creating a safer device support which uses only the 1536 k Kernel_RootFS for kernel, and the 6144 k Rootfs partition for rootfs.
It's safe to use, and compatible with the official releases (currently 19.07.7).
(It's not finished yet, in terms of documentation )
But it's still a community build from a random guy from the Forum. So I couldn't recommend this too!
So what's the best way forward, given the situation?
happy to install your random-guy community build. I'd trust you And I'd happily contribute to user-friendly documentation
also fine to keep a USB stick in a safe place. Actually, if I get to install OpenWRT once on my TM01, I assume I'll be fine. I will run shairport-sync and that's it. If needed, I could live without OpenWRT updates etc.
it would be nice to be assured that with OpenWRT, the TM01's internal battery can still power the device. E.g. so that my TM01 can run for a while without external power attached, and re-charge later again when external power is available.
And in turn, ideally, that the battery could run in a way that the TM01 can still charge other devices if needed.