That makes sense! But I figured if I merged in your changes, it would show them ... no?
No (poop)! ... LOL
Err, sure, that sounds great ... LMAO. Let me dig on that one. Thanks!
if you:
- soft reset your branch to your latest commit (
git reset --soft f0bfa63)
$ git merge xabolcs/hootoo-tm05
Updating f0bfa630c8..5ac0ffdd9e
Fast-forward
package/boot/uboot-envtools/files/ramips | 5 +++++
target/linux/ramips/dts/mt7620n_hootoo_tm05.dts | 39 +++++++++++++++++++++++++++++++++++----
target/linux/ramips/image/Makefile | 4 ++++
target/linux/ramips/image/mt7620.mk | 10 +++++-----
target/linux/ramips/mt7620/config-4.14 | 1 +
target/linux/ramips/mt7620/config-5.4 | 1 +
6 files changed, 51 insertions(+), 9 deletions(-)
$ git status
On branch hootoo-tm05
nothing to commit, working tree clean
$ git reset --soft f0bfa630c8
$ git status
On branch hootoo-tm05
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: package/boot/uboot-envtools/files/ramips
modified: target/linux/ramips/dts/mt7620n_hootoo_tm05.dts
modified: target/linux/ramips/image/Makefile
modified: target/linux/ramips/image/mt7620.mk
modified: target/linux/ramips/mt7620/config-4.14
modified: target/linux/ramips/mt7620/config-5.4
, or
- hard reset your branch, then you could use
git merge --squash xabolcs/hootoo-tm05
$ git merge xabolcs/hootoo-tm05
Updating f0bfa630c8..5ac0ffdd9e
Fast-forward
package/boot/uboot-envtools/files/ramips | 5 +++++
target/linux/ramips/dts/mt7620n_hootoo_tm05.dts | 39 +++++++++++++++++++++++++++++++++++----
target/linux/ramips/image/Makefile | 4 ++++
target/linux/ramips/image/mt7620.mk | 10 +++++-----
target/linux/ramips/mt7620/config-4.14 | 1 +
target/linux/ramips/mt7620/config-5.4 | 1 +
6 files changed, 51 insertions(+), 9 deletions(-)
$ git reset --hard f0bfa630c8
HEAD is now at f0bfa630c8 ramips: Add support for HooToo TM05
$ git merge xabolcs/hootoo-tm05 --squash
Updating f0bfa630c8..5ac0ffdd9e
Fast-forward
Squash commit -- not updating HEAD
package/boot/uboot-envtools/files/ramips | 5 +++++
target/linux/ramips/dts/mt7620n_hootoo_tm05.dts | 39 +++++++++++++++++++++++++++++++++++----
target/linux/ramips/image/Makefile | 4 ++++
target/linux/ramips/image/mt7620.mk | 10 +++++-----
target/linux/ramips/mt7620/config-4.14 | 1 +
target/linux/ramips/mt7620/config-5.4 | 1 +
6 files changed, 51 insertions(+), 9 deletions(-)
$ git status
On branch hootoo-tm05
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: package/boot/uboot-envtools/files/ramips
modified: target/linux/ramips/dts/mt7620n_hootoo_tm05.dts
modified: target/linux/ramips/image/Makefile
modified: target/linux/ramips/image/mt7620.mk
modified: target/linux/ramips/mt7620/config-4.14
modified: target/linux/ramips/mt7620/config-5.4
and you could amend your latest commit, and it will include my changes: git commit --amend 
1 Like
Thanks!!! Went and read up on this, makes sense - appreciate it!
OK, looking over the code, I have to ask - in target/linux/ramips/dts/mt7620n_hootoo_tm05.dts, why partition@60000 (vs 51000)?
firmware2: partition@60000 {
label = "firmware2";
reg = <0x51000 0x17f000>;
};
Has it really always been like this?
Is it like this on both HooToo's?
Merging is copying of a commit, you will see it in git log
git status shows you changes before it is committed
1 Like
I checked the RAVPower before, always seemed to be 4k.
=> Also just checked OEM (clean flash!),
Environment size: 172/4092 bytes
Because I'm testing you! 
It's a copy-paste error! Thanks for catching it!
Whew, I think I passed ... LOL. I had updated it here, building - will install from clean. I will update the commit message as well, with the two files now. Wondering if it's easier to push the commit, let you review it there (and update if needed)? Thoughts?
Thanks!
FYI, build done => doing a check from scratch ... flash OEM, then TFTP (button press) install. Make sure first!
1 Like
You had to talk about why those changes are needed!
All the mtd-concat, factory install, CONFIG_MTD_VIRT_CONCAT=y stuff started by fixing the config + u-boot-env partitions. 
Sure, push it!
And write all the flash instructions in the commit message! 
Absolutely!
Yep, that's what I'm confirming, make sure I have it correct.
Will do, and by all means comment on top!
1 Like
Done! Hopefully I explained all the changes sufficiently (and accurately 
). By all means comment or correct.
Thanks again so much for all the help!
Now, to get it in to master => then the RAVPower. I have those changes here, ready to include ... but I think wait for HooToo in master (agreed?).
1 Like
I would like to thank @mpratt14 and @xabolcs for their help getting the lzma loader to work!
" ... for their help to getting all the magic to work!" 
Rebase that RAVPower branch onto this HooToo branch and we could continue the work on that!
AGREED!
Sure, will do! => will do that, continue in the other thread (that we set up for that).
1 Like
I'm thinking about creating a full-blown firmware.bin which works as the original, OEM Firmware.
What do you think @arrmo ?
With this firmware.bin we would be able to
- do the initial flash without buggy-erase-all-the-things TFTP
- automatically back up original flash contents to the pendrive
No big issue here, but ... with the latest, we don't touch those (noted) sections, so I do have to wonder - what does this buy us vs. what is there now? A script to do an (automated) backup would be nice, but even that has some requirements (like a USB drive in place, to save the files ... right?).
Thoughts?
I already wrote what it buys:
- it avoids the buggy-erase-all-the-things TFTP recovery
- it have fewer requirements:
- no UTP cable needed
- no TFTP server needed
- just a pendrive with a few mbytes free space
- easier install method: put stuff on pendrive, plug the pendrive to device
Quoting Adrian:
The name "factory.bin" implies that the image can be used "as a whole" for flashing as intended by the vendor, i.e. via GUI or TFTP.
With this new firmware.bin, the user could follow the official firmware upgrade process (User Guide 1.0 - HT-TM05 TripMate.pdf from HooToo homepage, section "Firmware Upgrade" starting on page 115)
I would like to keep the TFTP method, but I propose this new firmware.bin to be the primary OEM -> OpenWrt flashing method.
Ahh, OK - I get your point. You want a "second option", similar to the OEM approach. No issue here! But to that end, as the fw file from the vendor already has an embedded script - why not use / start from that, perhaps with a minor extension to backup?
LMAO - too funny! You do need more to do
I want to debloat that script, and minimize => easier to rewrite from scratch ... it would be included in the OpenWrt tree anyway
So it could be a longer journey, and I don't want to delay the Pull Request with this.
If it's ready then you could include it, if it isn't then it would arrive as a separate PR.
1 Like
No problem at all - and I'm fine with a new script. Was just thinking that may be an easy place to start, but no issue here for sure.
Thanks!
Let's continue the factory.bin talk in another thread:
And leave this for your Pull Request!
1 Like