Awesome, thanks! Will get back to you - in a few days ... seems I can't get that clip until mid-next week. Will get ready for it though 
.
Thanks again.
This HooToo and RavPower thing is interesting:
- there is a long running PR for introducing HT-TM05
- there are must have fixes:
- 1.5M kernel limit
-
configpartition
- there are nice to have fixes:
- common DTSI
-
paramspartition - splitted
factory.bin:kernel+rootfs
About the last two "nice to have" fixes: the OpenWrt flash layout gets closer to the OEM flash layout, but it has a few drawbacks, like losing another 64K flash space (for u-boot-env), and 6 MB soft limit of kernel + roots (currently ~ 4 MB).
I would implement all the fixes, even if it has some drawbacks.
And about the PRs:
- finish the current HT-TM05 PR. including all the fixes, except the common DTSI
- open the RavPower PR with: common DTSI, LZMA_TEXT_START, common recipe
Sadly OpenWrt is short on GitHub reviewers, just be patient! 
No worries, understand. Appreciate you capturing the list, thanks!
Anything you need me to do? We can still test these items on the RAVPower, just not on the HooToo (right now). And perhaps let's not try the step back to OEM 
.
Inspect and understand my extra commit on top of your branch!
It would be nice if you could verify the ubootenv parameters and its functionality under OpenWrt! Just modify LZMA_TEXT_START for RavPower, rebuild my branch!
It would be awesome, if you could test the TFTP recovery with kernel and rootfs renamed from the factory.* files.
And if it successed, then please test the sysupgrade.bin too!
1 Like
Will do! Just give me a couple days - only because when I moved the RAVPower today, one of the wires came loose. I'd fix it tomorrow, but tied up as my daughter is looking for an apartment (yikes!).
Thanks!
Actually, got the wire fixed, hoping to still try it tonight ... but I admit, a bit (git) confused about how to take your commit, apply to my branch. Let me fiddle with it 
Hmmm, this compare looks odd to me, I see changes that are in my code as well (like mt7620n_hootoo_tm05.dts, Huh?!?!
Yeah working on someone else's tree....can't seem to fetch or checkout the normal way....
this time you actually HAVE to add a remote label (or at least this makes it easy)
Adding his tree with label "xabolcs"
git remote add xabolcs https://github.com/xabolcs/openwrt.git
you can see the status of all remote repositories
git remote -v
then you can fetch index and checkout his branch
git fetch xabolcs
git checkout xabolcs/hootoo-tm05
Now this leaves you in detached state, which means you are neither working on a local or remote branch, but a temporary one. If you wanna save it to a local branch you can
git checkout -b <new-branch-name>
as they show in directions 
1 Like
BTW in
git log
you can see his changes are HEAD (first commit) right on top of yours, so to see the changes he is making in patch form you can
git show HEAD
Note to self: make index dynamic!
Makes sense, will look at this a bit more tonight (if back in time), or tomorrow - thanks!
Gotcha. Was thinking GitHub would show a proper diff I could use, but NP - will do it this way. Thanks!
Perfect, thanks!
BTW, came across this doing some digging last night,
http://manpages.ubuntu.com/manpages/xenial/man8/flashrom.8.html
This also exists on RPi.
1 Like
You updated your branch, and I had to rebase my work to your new commit. Thats it.
Here is the compare view.
And in the case that you go wrong with git commands, just append .patch to the URL above, and you get a patch file which you could git apply. 
Glad to hear that - it means I'm not 100% losing my mind ... 
.
No issue - thanks! And the info from @mpratt14 above makes sense ... do you two recommend going that route, or just apply the patch? I'm good with either one.
I did, and it (mostly) makes sense! Just a couple questions,
- why number the (concatenated) partitions like you did? Or is it in decreasing order of size? Does it have to be that way? May help flash life, just wondering.
- why split out firmware3 and firmware1? They are contiguous (right?), so why not just make them a single block?
Will do! RAVPower is repaired, and actually fully reassembled (with wires coming out, all snapped back together nicely!). Just a few scratches ... LOL. What do you want me to test first? FYI, I did save an environment variable, like you asked. With legacy firmware, I get (as expected),
OpenWrt kernel loader for MIPS based SoC
Copyright (C) 2011 Gabor Juhos <juhosg@openwrt.org>
Looking for OpenWrt image... found at 0xbc051000
Decompressing kernel... failed, data error!
System halted!
I'll get the build ready, but thinking to TFTP factory.bin with your changes (and using git, not patch). Yell if you disagree though!
OK, went ahead, built it up ... flashed openwrt-ramips-mt7620-hootoo_tm05-squashfs-factory.rootfs => right?
Rebooted, checked environment (printenv) - variable is not there. Would you have expected it? I was initially thinking yes, but I guess as that partition is above 0x50000 ... factory overwrites it. Agreed?
OK, so then ... set an env variable, rebooted => it's there! Fooled me for a minute, it re-sorted alphabetically ... LOL. Rebooted, to check out loader / Openwrt ...
Initialize vs configure module
raspi_read: from:1d0000 len:1000
Initialize GPIO
check: 0
Input i key to enter menu 0
raspi_read: from:50000 len:180000
## Booting image at 80500000 ...
Bad Magic Number,4F4B4C49
Won't boot. I saw this before, when the loader isn't there. So I did some md's, try to find the loader,
MT7620 # md bc050000
bc050000: 494c4b4f 244d765d 37190a5f fc8f1900 OKLI]vM$_..7....
bc050010: 00000080 00000080 8ba769f0 03020505 .........i......
bc050020: 5350494d 65704f20 7472576e 6e694c20 MIPS OpenWrt Lin
bc050030: 342d7875 2e34312e 00373831 00000000 ux-4.14.187.....
OK, OKLI is at the start - that matches the boot issue above. Also checked binwalk, matches. I notice you removed factory.bin, which is loader + kernel + rootfs. Don't we still need that?
And BTW, as I figured you'd like to see this,
MT7620 # md bc1d0000
bc1d0000: 75a4b398 4178741e 9bf9785f fee2e546 ...u.txA_x..F...
bc1d0010: e266642e fdf0157d 57a56b49 70b6afec .df.}...Ik.W...p
bc1d0020: 53d046a0 8aa94d28 37c4d140 0e8f8daa .F.S(M..@..7....
OK, never mind - that confuses me
Thoughts? Thanks!
The way I described is better for testing, grabbing his commit across branches is done with git cherry-pick. But for your purposes once you are sure the code is good git apply on your original branch would be easier, you have to git commit --amend after i think.
Yeah the OKLI kernel image cannot be run without the loader
Agreed! So re-added factory.bin, changed the LOADER_FLASH_OFFS := 0xFD051000, built and reinstalled ... OKLI not found (was also not found at 0xFD200000. OK, have to noodle on that a bit more ... LOL.
But binwalk looks better now,
DECIMAL HEXADECIMAL DESCRIPTION
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0x973654D5, created: 2020-07-11 19:55:35, image size: 3295 bytes, Data Address: 0x80000000, Entry
Point: 0x80000000, data CRC: 0x679C36DF, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt
Linux-4.14.187"
64 0x40 LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 65536 bytes
4160 0x1040 LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 5292318 bytes
1679420 0x19A03C Squashfs filesystem, little endian, version 4.0, compression:xz, size: 2750190 bytes, 1363 inodes, blocksize: 262144 bytes, created: 2020-07-11 19:55:35
Hmmm ... why not found at 0xFD051000. Seems odd. Will dig.
REALLY odd, as in U-Boot - it's there!
MT7620 # md bc051000
bc051000: 494c4b4f 244d765d 37190a5f fc8f1900 OKLI]vM$_..7....
bc051010: 00000080 00000080 8ba769f0 03020505 .........i......
bc051020: 5350494d 65704f20 7472576e 6e694c20 MIPS OpenWrt Lin
bc051030: 342d7875 2e34312e 00373831 00000000 ux-4.14.187.....
bc051040: 8000006d 50c11e00 00000000 6f000000 m......P.......o
Hang on ... arrrgh, loader needs to be manually deleted. Let me try that again
Is this not because @xabolcs changed LZMA_TEXT_START so that the "negative offset" of 0xFD is not needed anymore? I thought that's one of the things you all were working on
Just rebuilt, and it found it now => loader doesn't get rebuilt if it exists. Close ... loader hung, but that's because of the 24 / 32 MB LZMA TEXT I think (running this on RAVPower, 32 MB device, for now).
Changed that address (for debug) => loader works! But, not seeing the partitioning? This one again,
[ 0.824642] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[ 0.839621] Please append a correct "root=" boot option; here are the available partitions:
[ 0.856282] 1f00 192 mtdblock0
[ 0.856288] (driver?)
[ 0.869313] 1f01 64 mtdblock1
[ 0.869317] (driver?)
[ 0.882350] 1f02 64 mtdblock2
[ 0.882354] (driver?)
[ 0.895387] 1f03 4 mtdblock3
[ 0.895392] (driver?)
[ 0.908417] 1f04 1532 mtdblock4
[ 0.908422] (driver?)
[ 0.921448] 1f05 64 mtdblock5
[ 0.921453] (driver?)
[ 0.934488] 1f06 128 mtdblock6
[ 0.934493] (driver?)
[ 0.947518] 1f07 6144 mtdblock7
[ 0.947522] (driver?)
[ 0.960546] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 0.978061] Rebooting in 1 seconds..
Will let @xabolcs comment, I may be breaking things with this factory.bin - but the rootfs wasn't really working (no loader), and the kernel file has no rootfs. No panic though!