You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would be great. As it is now, any IO is brutally interrupted. A smart user isn't likely to knowingly be doing important IO while flashing their EC; nevertheless, it's better safe than sorry, and the current instant-off that happens is definitely not ideal.
System reset due to WDT timeout is unavoidable, and is in fact desired behavior.
The problem is using WDT timeout to restart the EC after a firmware update. Preferably, the EC moves from Scratch ROM back to main app without triggering an EC reset.
Host signals to EC to enter Scratch ROM before starting flash
EC performs minimal operations while waiting for flash to complete
Host signals to EC to exit Scratch ROM after finishing flash
EC disables host writing to flash and jumps to main app, exiting scratch ROM
EC detects that this "soft reset" has occurred and performs any additional required logic
EC operations continue normally
Some questions about this:
What should the EC actually be doing while in Scratch ROM?
Can we jump to main()? Is it possible to even know where main() is?
If not, can we jump to the reset vector? Will whatever SDCC injects there before jumping to main() cause issues?
What are the differences in initialization between EC reset and this "soft reset"?
What state is lost and would have to be reacquired?
Does state stored in RAM need to be declared at fixed addresses?
What integration with system firmware would be required?
crawfxrd
changed the title
Prevent system reset on EC reset
Prevent system reset on firmware update
Jul 15, 2024
No description provided.
The text was updated successfully, but these errors were encountered: