arrmo
July 14, 2020, 10:41pm
323
arrmo:
merge your changes
Hmmm ... merged, can see (for example) the virtual_flash in my hootoo-tm05 branch, but git status shows no changes? It does say,
Your branch is ahead of 'origin/hootoo-tm05' by 1 commit.
(use "git push" to publish your local commits)
Perhaps because you had committed and pushed, so when I merge I don't see the changes locally?
git status
talks about your working directory state.
You merged my commit and updated your branch to my commit. You copied it with git merge
.
Git is hard!
It would be better to squash my changes to your branch without new commit.
arrmo
July 14, 2020, 11:26pm
325
That makes sense! But I figured if I merged in your changes, it would show them ... no?
xabolcs:
Git is hard
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
arrmo
July 15, 2020, 12:28am
327
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>;
};
arrmo:
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?
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
arrmo
July 15, 2020, 12:33am
329
I checked the RAVPower before, always seemed to be 4k.
=> Also just checked OEM (clean flash!),
Environment size: 172/4092 bytes
arrmo:
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>;
};
Because I'm testing you!
It's a copy-paste error! Thanks for catching it!
arrmo
July 15, 2020, 12:35am
331
xabolcs:
Because I'm testing you!
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!
arrmo
July 15, 2020, 12:50am
333
Absolutely!
Yep, that's what I'm confirming, make sure I have it correct.
xabolcs:
Sure, push it!
Will do, and by all means comment on top!
1 Like
arrmo
July 15, 2020, 1:09am
334
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!
arrmo
July 15, 2020, 1:24am
336
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
arrmo
July 23, 2020, 3:45pm
338
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?
arrmo:
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?).
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.
arrmo
July 23, 2020, 7:33pm
341
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?
xabolcs:
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