HooToo TM-05, Add LZMA Loader

This has nothing to do with the state of flash. The u-boot environment partition has a checksum at the start, if it doesn't exist or is corrupted (via checksum) then it is ignored.

I did, and it is! :smile:. I also saved a variable, still in u-boot (yay!), and in OpenWrt, once I set /etc/fw_env.config to /dev/mtd5 0x4000 0x1000 0x1000 => update in package/boot/uboot-envtools/files/ramips?

Yes, agreed - I may not have said that, but that's what I was meaning. It likely got messed up at some point ... so I went back to OEM, reflashed with the "final" version => all good now!

Sure, the flash instructions on that OpenWrt Device page should be cleaned up and refreshed!

Rolling back to OEM firmware has to be noted also! I posted links to unpack scripts and files. They could be noted there.
The best would be to write the instructions (or include the helper script) on Wiki about extracting rootfs and kernel from the OEM binary (which is a ext2 filesystem, btw.).

But linking to OpenWrt device page is not sufficient, as it's volatile compared to the commit message! :wink:
Just "copy-paste" the flash instructions into the commit message, and you are done!

Browse "add support" commits for more hint! git log

Sorry? The code below isn't correct? At least the first two arguments?! :frowning:

hootoo,tm05)
	idx="$(find_mtd_index u-boot-env)"
	[ -n "$idx" ] && \
		ubootenv_add_uci_config "/dev/mtd$idx" "0x0" "0x10000" "0x10000"
	;;

Do we need to test this? Thinking we do, agreed?

Makes sense, agreed!

Doesn't seem to be. Update to the values I noted?

Interesting ... u-boot reads from 0x4000,

raspi_read: from:1d4000 len:1000
*** Warning - bad CRC, using default environment

but then saveenv writes from 0x0 to 0x10000:

MT7620 # saveenv
Saving Environment to SPI Flash...
raspi_read: from:1d0000 len:10000
Erasing SPI Flash...
raspi_erase: offs:1d0000 len:10000
.
Writing to SPI Flash...
raspi_write: to:1d0000 len:10000
.
done

This is at least interesting. Please hexdump your u-boot-env partition!

Do you have any clue about the meaning of third and fourth parameter? Yeah, they are envsize and secsize, but ... :thinking:

Sure, I will update, but let's find the correct values first!

Agreed! That's how I found the values I came up with ... LOL. Man, we are on the same page :wink:. Here it is,

root@OpenWrt:/# cat /dev/mtd5ro | hexdump -C
00000000  00 00 00 00 31 39 32 2e  31 36 38 2e 31 2e 33 38  |....192.168.1.38|
00000010  00 00 00 00 32 35 35 2e  32 35 35 2e 32 35 35 2e  |....255.255.255.|
00000020  30 00 00 00 31 39 32 2e  31 36 38 2e 31 2e 31 00  |0...192.168.1.1.|
00000030  00 00 00 00 31 39 32 2e  31 36 38 2e 31 2e 32 30  |....192.168.1.20|
00000040  31 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |1...............|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  00 00 00 00 50 4f 57 45  52 37 00 00 00 00 00 00  |....POWER7......|
00000410  00 00 00 00 57 69 66 69  44 69 73 6b 00 00 00 00  |....WifiDisk....|
00000420  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000430  00 00 00 00 31 2e 30 2e  30 2e 31 00 31 30 35 30  |....1.0.0.1.1050|
00000440  30 30 30 30 30 33 00 00  00 00 00 00 00 00 00 00  |000003..........|
00000450  00 00 00 00 00 00 00 00  00 00 00 00 30 30 3a 31  |............00:1|
00000460  63 3a 63 32 3a 30 32 3a  36 32 3a 31 63 00 00 00  |c:c2:02:62:1c...|
00000470  00 00 00 00 00 b7 bf a1  00 00 00 00 00 00 00 00  |................|
00000480  00 00 00 00 00 00 00 00  00 00 00 00 2a 00 00 00  |............*...|
00000490  32 30 31 32 30 39 30 33  6d 6b 38 36 35 31 30 78  |20120903mk86510x|
000004a0  45 43 47 45 44 53 52 50  4d 4b 4a 66 65 62 5a 59  |ECGEDSRPMKJfebZY|
000004b0  6f 6e 6c 39 37 36 32 31  47 46 00 00 00 00 00 00  |onl97621GF......|
000004c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000510  40 00 00 00 39 33 64 34  38 61 39 65 65 36 63 38  |@...93d48a9ee6c8|
00000520  61 35 33 35 38 66 31 36  34 65 65 34 64 38 34 66  |a5358f164ee4d84f|
00000530  39 32 62 65 63 31 62 36  35 66 32 39 62 37 31 62  |92bec1b65f29b71b|
00000540  62 66 37 39 33 66 66 36  38 30 36 63 65 35 63 64  |bf793ff6806ce5cd|
00000550  38 39 34 35 00 00 00 00  00 00 00 00 00 00 00 00  |8945............|
00000560  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00004000  b9 a3 e6 57 62 6f 6f 74  63 6d 64 3d 74 66 74 70  |...Wbootcmd=tftp|
00004010  00 62 6f 6f 74 64 65 6c  61 79 3d 32 00 62 61 75  |.bootdelay=2.bau|
00004020  64 72 61 74 65 3d 35 37  36 30 30 00 65 74 68 61  |drate=57600.etha|
00004030  64 64 72 3d 22 30 30 3a  41 41 3a 42 42 3a 43 43  |ddr="00:AA:BB:CC|
00004040  3a 44 44 3a 31 30 22 00  69 70 61 64 64 72 3d 31  |:DD:10".ipaddr=1|
00004050  30 2e 31 30 2e 31 30 2e  31 32 38 00 73 65 72 76  |0.10.10.128.serv|
00004060  65 72 69 70 3d 31 30 2e  31 30 2e 31 30 2e 32 35  |erip=10.10.10.25|
00004070  34 00 67 61 74 65 77 61  79 69 70 3d 31 30 2e 31  |4.gatewayip=10.1|
00004080  30 2e 31 30 2e 31 00 73  74 64 69 6e 3d 73 65 72  |0.10.1.stdin=ser|
00004090  69 61 6c 00 73 74 64 6f  75 74 3d 73 65 72 69 61  |ial.stdout=seria|
000040a0  6c 00 73 74 64 65 72 72  3d 73 65 72 69 61 6c 00  |l.stderr=serial.|
000040b0  6f 77 6e 65 72 3d 72 6d  6f 72 72 69 73 40 72 6b  |owner=rmorris@rk|
000040c0  6d 6f 72 72 69 73 2e 75  73 00 00 00 00 00 00 00  |morris.us.......|
000040d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00010000

And, this matches to what I saw in printenv from u-boot.

Thanks!

And what happens (to OpenWrt, to u-boot) if you flood your u-boot-env partition (with a script) with long variable names assigned with long values? Lorem ipsum will help! :grinning:

I would try the following for the third and fourth parameter in the hope that

  • envsize is the size of the u-boot environment: 0x10000 - 0x4000 = 0xc000, and
  • secsize is the sector size: the erase size: 0x1000
hootoo,tm05)
	idx="$(find_mtd_index u-boot-env)"
	[ -n "$idx" ] && \
		ubootenv_add_uci_config "/dev/mtd$idx" "0x4000" "0xc000" "0x1000"
	;;

Here is it: hootoo-tm05-lzma-loader-08.tar.gz

About the AR71XX_FLASH_START variable ...

@981213 suggested me (for mt7621) to use 0x1fc00000:

But I found it to be 0x10000000.

And now, you @arrmo found it as 1C000000 for mt7620:

Looking for OpenWrt image... found at 0xbc200000

I'm afraid that AR71XX_FLASH_START should be renamed to CONFIG_FLASH_START or something like and moved to config.h ... and had to be set up in target/linux/ramips/image/Makefile like KERNEL_LOADADDR or LOADER_PLATFORM.

And because of that, this change should be sent to ML.

When this HT-TM05 PR hits master I would prepare a commit for this.

OK, you're confusing me a bit :frowning_face:. I did check, in u-boot, and it does say,

Environment size: 198/4092 bytes

=> So environment is only 1 sector, 0x1000 long ... agreed? And from u-boot, it does seem to start at 1d4000, agreed? So 0x4000 (start), 0x1000 length?

Not quite sure what you're after here. We do have the start address correct, no?

Agreed ... just weird to waste 60 K flash space for that 4 K environment.
Would you try to concatenate that 60K to firmware and try out if it crashes on saveenv? :slight_smile:

Yes we do, but it's a negative offset. It works but it doesn't looks good! :wink:

Yup, it would be nice to confirm it (without hard-bricking any other router! :rofl:).

Here are the files:

And here is the splitting / extracting tool. More on the network

The download part could left out.

Latest OEM firmware is at HooToo homepage. See below!

Screenshot_2020-07-14 HooToo com Future Network for Today

No argument - agreed there!

Concatenate to firmware? Not sure what you're thinking there, sorry!

It's math - who cares :rofl:. To me, working is what matters :wink:.

Just try the firmware I prepared (with those bad parameters about sizing), and try to flood the u-boot environment to exceed that 4K size!

Done, and works! No issue here, I can always re-flash now :laughing:

Will do. Trying to figure out an easy way to flood it. I'll just generate a large file, copy/paste in.

BASE64 encode the loader partition, delete the new lines and store it to environment twice. :grinning:

Ya, was trying something similar - arrgh, u-boot won't let me save variables longer thatn 248 bytes. Dang!

u-boot stops me at 4K!

## Error: environment overflow, "test16" deleted
1 Like

You need to do that only 20x! :laughing:

But you could try it with fw_setenv --script too:

root@GL-AR300M-NOR-F5E ~ # fw_setenv --help
Usage: fw_setenv [OPTIONS]... [VARIABLE]...
Modify variables in U-Boot environment

 -h, --help           print this help.
 -v, --version        display version
 -c, --config         configuration file, default:/etc/fw_env.config
 -l, --lock           lock node, default:/var/lock
 -s, --script         batch mode to minimize writes

Examples:
  fw_setenv foo bar   set variable foo equal bar
  fw_setenv foo       clear variable foo
  fw_setenv --script file run batch script

Script Syntax:
  key [space] value
  lines starting with '#' are treated as comment

  A variable without value will be deleted. Any number of spaces are
  allowed between key and value. Space inside of the value is treated
  as part of the value itself.

Script Example:
  netdev         eth0
  kernel_addr    400000
  foo            empty empty empty    empty empty empty
  bar

Edit /etc/fw_env.config to cover the whole partition and try to overflow with OpenWrt!

I just did it the manual way ... LOL!

So seems the limit really is 4K. To your question ... ya, they throw away 65K, but they also limit the kernel to 1.5 MB ... :stuck_out_tongue_winking_eye:

So just update these addresses (0x4000, 0x1000) => then I'll pull in your latest changes, make sure the build works (locally) ... update the instructions / commit, and push (the "final"?!?!) code?

Just trying to make sure I know what's left to do. Getting a bit confused, sorry.

Thanks!

:heart_eyes:

Let me push the correct u-boot-env values finally.
After that you are ready to go! :+1:

Pushed commit 5ac0ffdd9e.