search

raburton / rboot

An open source bootloader for the ESP8266
https://richard.burtons.org/tag/rboot/?order=ASC
MIT License
300 stars 72 forks source link

New option: skip to next image via GPIO #19

Open DutchFox2 opened 8 years ago

DutchFox2 commented 8 years ago

Hi Richard,

I have added a new feature to rBoot, because the existing GPIO feature didn't suit my needs. It might be useful to others as well.

Background: I am using rBoot with 2 slots. Firmware updates (downloading and flashing) are performed by the user program, where the active program in slot 0 will flash into slot 1 or vice versa. In the situation where flashing was succesful (ROM checksum is ok), but the program itself contains a bug, rBoot will keep booting into that new ROM image. If the networking or firmware upgrade code is broken, I'm stuck. The 'normal' GPIO functionality is no solution here, because it can only boot into a predefined slot. If this slot happens to contain the 'broken' firmware, it doesn't help. The new option uses GPIO to simply mark the current slot as 'invalid', and lets the existing code search for an other ROM to boot from. In my case, it will find the previous firmware in the other slot, which can be used to re-flash a new (hopefully fixed) image.

Commit f04392b contains the new option mentioned above. In commit 3c68cc9 I have separated the reading of the GPIO pin from configuring it as an input. In my opinion, the pin should be set as input as early in the boot process as possible, to prevent large currents when the pin is also driven externally. Furthermore, once the pin is configured as an input, there is a lot more time for the voltage at the pin to stabilize at the required level before the pin state is read back.

I couldn't convince Github to exclude bb7421d from the pull request, please ignore it.

Cheers,

Matthijs

raburton commented 8 years ago

Could you please take a look at the 'test' branch. I've implemented your request (slightly differently), please check it meets your needs before I merge with master.

DutchFox2 commented 8 years ago

On 03-09-16 14:05, Richard Antony Burton wrote:

Could you please take a look at the 'test' branch. I've implemented your request (slightly differently), please check it meets your needs before I merge with master.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raburton/rboot/pull/19#issuecomment-244542704, or mute the thread https://github.com/notifications/unsubscribe-auth/ARRvJZ01AnYfsIi-DEUZKsB_GAjuVOfhks5qmWJsgaJpZM4JjCQP.

Thanks Richard, I'm glad that you liked the 'skip to next image' idea.

I have looked through the diff on Github, your implementation looks fine to me. Of course, mine was a bit minimalistic (to keep the maintenance effort of a separate branch/patch low), yours is better integrated with the rest of the code.

I'm afraid that I will not have the opportunity to do a real test in my esp8266 project for at least the next few weeks. However, looking at just the code I'm pretty confident that it will fit my application. I'll leave it up to you whether you prefer to wait for a real test first, or to merge the test branch into the trunk asap.

One thing which comes to mind right now is: would other users be helped with an extra compile-time option, so they can choose between skipping to the 'next' (/romToBoot = romconf->current_rom + //1/) or the 'previous' (/romToBoot = romconf->current_rom - //1/) ROM? In my situation (with only 2 slots) it doesn't matter, but I can image that in case of multiple ROM slots, someone would like to skip back to the previous one instead of skipping forward to the next one. Of course, one could also solve the same problem by inverting the direction in which he flashes new ROMs: if the newest ROM is flashed into /'current-1'/ instead of/'current+1/', then skipping to the 'next' ROM is actually the previous (most recent) working ROM.

Kind regards,

Matthijs