HomeACcessoryKid / life-cycle-manager

Initial install, WiFi settings and over the air firmware upgrades for any esp-open-rtos repository on GitHub
Apache License 2.0
60 stars 11 forks source link

Question: How to go back to initial state? #17

Closed peros550 closed 4 years ago

peros550 commented 4 years ago

Assuming, we installed LCM to a device and then selected a repo of our choice, is there any way that we can return back to original state like when the LCM was first installed?

maccoylton commented 4 years ago

AFAIK not with the current tAPI though would be useful

Sent with GitHawk

HomeACcessoryKid commented 4 years ago

In and of itself it is very easy. Once you decided on an appropriate trigger, just erase the sys-param fields and boot into the secondary flash code. But no, there is no API for this. Yet it is very basic, so, why bother with an API. This should ask for wifi again and the repo.

Beware I didn’t verify this in detail, but answered of the top of my head. But it is similar to the ota to lcm switchover i did last year.

In general, all of LCM is controlled from the sys-params. Any usercode can manipulate it anyway it wants.

HomeACcessoryKid commented 4 years ago

I sense just now that your question is related to how to solve this without usercode intervention. That is impossible since LCM is a basic state machine run by the content of the sys-param fields. I could imagine a feature where a new param would be introduced and LCM would do the cleaning of the other params. But then, why bother since with the same effort to do this, one could do the previously mentioned solution.

Another train of thought could be to use the rboot feature of rebooting after gpio trigger. But then, wouldn’t it be better to use that for regular upgrades.

Be aware that all boils down to having extremely small control over what will happen at boot time.

If you see other control opportunities, please comment.

peros550 commented 4 years ago

Alright the software side of the question was pretty much covered. Agree with you, It would be an overkill to create an API for something that can easily be implemented by the upper layer firmware.

On the boot time, perhaps (if it's at all possible) you could count how often the device reboots within the last 30sec or 60sec. If something is wrong with the upper firmware and causes multiple reboots within a short periof of time, or in general if user causes reboots too often, then LCM web server could be invoked and further actions (like taking the risk to re-flash) could be offered.

PS: I don't have in mind the full logic of the LCM so please excuse me if I might be way off.

HomeACcessoryKid commented 4 years ago

Last week we started a development of changing the boot loader to consider multiple power cycles in a short sequence. If so, we would either trigger otamain or even clear the entire sysparam and then start otamain to start from zero. I think this matches most of your ideas.

We’ll see if/when this becomes available

peros550 commented 4 years ago

How could existing devices that use LCM take advantage of new boot loader?

maccoylton commented 4 years ago

To migrate exiting devices to the new boot-loader, then the easiest solution would be to re-flash over serial, we will need to see if we offer an OTA option. First as @HomeACcessoryKid we need to see if we can get it working

peros550 commented 4 years ago

there are some devices (i.e.) that were brought to LCM using OTA method (tuya convert). Serial flash may be impossible (or at least very very difficult) for some of them (i.e. smart bulbs).

maccoylton commented 4 years ago

Understood, the reason I am looking at this with @HomeACcessoryKid is exactly for this reason. I have a couple of lightbulbs I create using tuya-covert and if anything ever goes wrong with a OTA update then I have not way to recover them.

HomeACcessoryKid commented 4 years ago

some initial code has been created as a gist: https://gist.github.com/HomeACcessoryKid/ecc2dd73ceff43d79b7c84f573566c82 It contains one bug, so if you know how to solve that I will push the code...

HomeACcessoryKid commented 4 years ago

Working code available at https://github.com/HomeACcessoryKid/rboot4lcm
still need to work on documentation/guidance
Feedback appreciated

HomeACcessoryKid commented 4 years ago

test output sample here: https://gist.github.com/HomeACcessoryKid/1a612dcb0c933ffcbdaab18809d21889

HomeACcessoryKid commented 4 years ago

@peros550 wrote:

On the boot time, perhaps (if it's at all possible) you could count how often the device reboots within the last 30sec or 60sec. If something is wrong with the upper firmware and causes multiple reboots within a short periof of time, or in general if user causes reboots too often, then LCM web server could be invoked and further actions (like taking the risk to re-flash) could be offered.

I have started to look into this after the power cycle mode seems to work

But I run into the question how the boot code can tell time. I intended to use the function system_get_time BUT it is not available in the ROM code. At least it is not mentioned in the .ld files. Another idea was that maybe time is available in RTCmemory as a constantly increasing value but this seems not the case. I have read 0x60001100 x 0x300 and all is static between reset button

Anyone knows how to get time between boots in whatever way?

HomeACcessoryKid commented 4 years ago

I think I have a reasonable working next version of LCM
at https://github.com/HomeACcessoryKid/LCMdev
You can help test it and comment on the parameters for fine tuning

HomeACcessoryKid commented 4 years ago

I have published release 1.9.0. Please read the ReadMe and test? I quite like the way it has turned out

peros550 commented 4 years ago

Hi I want to help testing. Don’t really know where to start. Still looking around the read me files

HomeACcessoryKid commented 4 years ago

When setting up a device use otabootbeta.bin. Follow the diagram and ask for more if needed.

BR, HacK

On 14 Feb 2020, at 22:31, peros550 notifications@github.com wrote:

Hi I want to help testing. Don’t really know where to start. Still looking around the read me files

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

peros550 commented 4 years ago

I believe this issue has no reason to stay open! Thank you for your commitment in this wonderful project