HooToo TM-05, Add LZMA Loader

arrmo · July 4, 2020, 11:06pm

Agreed - thanks!

To understand ... which HEAD does this reset to? Meaning .... master, or another branch?

mpratt14 · July 5, 2020, 12:05am

HEAD^ actually means "the commit right before HEAD"

if you were on branch hootoo-tm05 and you did git checkout -b <something else>
the new branch will be an exact copy, so you need to undo your HooToo commit which is HEAD on the original branch (aka the first commit you see in git log while on that branch)

arrmo · July 5, 2020, 12:28am

That actually makes sense . Thanks!

arrmo · July 5, 2020, 12:51am

BTW, if you're interested - while I have been waiting on some of these longer runs, did give me a bit of time to get back to this,

Being a battery powered device, I wanted the web interface to show me battery status! This is from the HooToo,

mpratt14 · July 5, 2020, 6:32am

Wow thats really cool. Too much JS for me, I am not a web developer lol

However I see that you have an accidental extra commit, looks like you merged instead of rebased.

arrmo · July 6, 2020, 2:07am

BTW, perhaps a dumb question, but - on this part of the recipe, why pad-to 64k, and then compress? Just to understand.

  COMPILE/loader-$(1).bin := loader-okli-compile | pad-to 64k | lzma | \
        uImage lzma

Thanks!

xabolcs · July 6, 2020, 4:57am

Because it just hangs without pad-to!
See my mailing list mail for DIR-860L at the beginning of this thread! I had to use pad-to 32k.

Try with smaller values too!
Delete loader-*.bin and do make!

You should also try without pad-to too!

You could also try as uImage none:

  COMPILE/loader-$(1).bin := loader-okli-compile | uImage none

mpratt14 · July 6, 2020, 6:55am

The bootloaders for whatever reason cannot handle (or maybe rejects) an image that small after decompression. Fortunately you can pad as much as you want before compression, and it doesn't really effect the size of the image after compression.

edit: meant to say "decompression"

arrmo · July 6, 2020, 11:12am

LOL - OK, NP! Just wasn't understanding, but that makes sense ... and I wasn't completely crazy

Agreed, I noticed that as well, and it makes sense. So no real reason to mess with it - I was just trying to understand.

xabolcs · July 6, 2020, 11:54am

But please, test it!

with pad-to 16k, 24k, 32k
and without pad-to: loader-okli-compile | uImage none

xabolcs · July 9, 2020, 1:32pm

@arrmo, what if I add a commit on top of your HooToo branch which fixes the real u-boot-env partition usage, with the cost of 64k flash space?

Would you incorporate those changes?

arrmo · July 9, 2020, 3:52pm

No issues at all! My thought - we're all in this together, make it better and I'm good with it . To understand though ... what are you changing? Not 100% getting your point, sorry .

xabolcs · July 9, 2020, 4:05pm

Fixing the "saveenv overwrites OpenWrt" bug by defining a 64k partition for u-boot env, and mtd-concat the remaining but now splitted firmware partition.
Exactly as @mpratt14 did for ENS202EXT.

arrmo · July 9, 2020, 4:24pm

Sure, NP - sounds great! Hoping it won't delay (too much) the PR - been trying for a long time to get this one in place ... LOL.

BTW, with mtd-concat we won't lose the 1.5 MB, right? And there will still be a loader partition?

Thanks!

xabolcs · July 9, 2020, 5:00pm

We would loose only 64 KByte.

arrmo · July 9, 2020, 5:23pm

Sounds good to me!

xabolcs · July 9, 2020, 9:41pm

Meh!

Almost done with the u-boot-env partition, but I had to figure out how to flashing works on this device!
@arrmo please flash your HooToo TM-05 through TFTP recovery with

OEM firmware
your latest factory.bin and sysupgrade.bin
one of my initramfs.bin (!) - does the recovery detect it to not flash but run?

and paste each serial logs about the flash and (successful??) restart!

Before you flash OEM firmware please save a dumb variable with the saveenv, and check it after TFTP flashing!

I don't know how to keep the params / u-boot-env partition intact.
Without writing a full-blown factory.bin (like fw-7620-WiFiDGRJ-HooToo-HT-TM05-2.000.084 from device support page or from the network):

I could pad loader-okli to 1600K to overwrite params / u-boot-env, or
if you could dump a default / empty environment, then I could include it to factory.bin

None of above make sense to me!

Well ... sort of.

I mean: because of the partition split, the whole kernel + rootfs have to be fitted in the last three OEM partition:

user_backup - 64 K
user - 64 K
Rootfs - 6M

When flashing OpenWrt is done, mtd-concat kicks in, and the router could use the extra ~1.5M space from OEM Kernel_Rootfs partition.

arrmo · July 9, 2020, 11:07pm

sysupgrade.bin via TFTP? It doesn't include the loader, so can't really do that ... agreed? I can flash it from the web interface (or ssh / console). OK?

Need to go find that . I never use it. That said ... I realized that we need to find a clean version of the u-boot-env .. would it be in the OEM build perhaps?

So meaning ... save from u-boot, then OEM, make sure it starts => then check the variable?

Ya, this is sort of my question too - I don't have this.

Sorry, but what is user_backup and user? You lost me there. And Rootfs => it's really 3 partitions in the end, right (i.e. loader, kernel, rootfs)?

xabolcs · July 9, 2020, 11:25pm

I'm interested how the recovery TFTP works, but if you test it with factory.bin then it not needed to try sysupgrade.bin.
Btw, it would soft-bricked!

I linked some page in my comment, you could find some OEM upgrade binary!

Exactly!

A saveenv without defining dummy variables doesn't creates a correct environment?

I referenced the OEM partition names.
Please have a look at OpenWrt Device page's Flash Layout!

xabolcs · July 10, 2020, 1:18am

Step 8 from Wiki:

The HT-TM05 will look for your computer at 10.10.10.254 and install the kernel file. Once it has finished installation of the kernel file, it will search for a (nonexistent) rootfs file — when it begins searching for this file, shut down the HT-TM05 by holding the power button normally.

So this is it ... @arrmo could you verify this?
If this really works, the OpenWrt factory.bin is really two file:

kernel - the 3 KByte loader
rootfs - the OKLI uImaged OpenWrt kernel + rootfs

Back to the loosing the size limitation. If we create a recovery TFTP acceptable file pair (kernel + rootfs), then the OpenWrt kernel + rootfs should fit in the OEM firmware partition, the 6144 K = 6 M sized Rootfs partition.
After OpenWrt boot, the semi-wasted 1660 KByte would be usable again (thanks to mtd-concat).

For testing you could find OEM kernel and rootfs at cryptographrix / HooToo_HT-TM05-hacking, extracted from fw-7620-WiFiDGRJ-HooToo-HT-TM05-2.000.022.

On the long run, when the 6 MByte size limit hits the device, we could tune the new factory recipe to slice the kernel + rootfs blob at 6 MByte and append the tail to the loader.bin.