Closed peros550 closed 4 years ago
AFAIK not with the current tAPI though would be useful
Sent with GitHawk
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.
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.
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.
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
How could existing devices that use LCM take advantage of new boot loader?
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
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).
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.
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...
Working code available at https://github.com/HomeACcessoryKid/rboot4lcm
still need to work on documentation/guidance
Feedback appreciated
test output sample here: https://gist.github.com/HomeACcessoryKid/1a612dcb0c933ffcbdaab18809d21889
@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?
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
I have published release 1.9.0. Please read the ReadMe and test? I quite like the way it has turned out
Hi I want to help testing. Don’t really know where to start. Still looking around the read me files
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.
I believe this issue has no reason to stay open! Thank you for your commitment in this wonderful project
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?