ESP8266 Community Forum

- Tue May 19, 2015 3:32 am #17831 Hi rab (and everyone else).
I enjoyed reading your blog about the ESP booloading internals, very informative.

In your blog entry "DECOMPILING THE ESP8266 BOOT LOADER V1.3(B3)" you write:
Why does it need 3 x 4kb sectors of the eeprom to store only a handful of bytes of config? I can’t see a good reason for that.

I'm quite sure the reason for that is that the memory used is of flash type (and not eeprom like you say in the blog). The difference being that you need to erase a whole sector before changing the data (any 0 to an 1). So to make sure you won't end up without any bootable software if the upgrade is interrupted during a flash erase or write they store the different data at different known flash positions. This way you should always at least be able to run the last code before the update.
Sorry if this is already old news for you.

A suggestion to make your code more reliable (and still simpler and more versatile then espressifs) is to add a checksum (could be as simple as xor of data (with start seed other than 0 or 0xff)) to your data structure (containing data about the roms flash storage points and sizes) and write it to 2 sectors (wait until first write is done until starting erase of second sector). This way when you boot you check the checksum of the first sector, if it's ok you use the data from it, if not you should have ok (yet older) data in the second sector. MAGIC can also be used instead of checksum (but doesn't feel as safe for me, I'm a bit paranoid )

I've used this method in the field for a number of projects over the years and it's never failed.

If this, or something similar, is implemented to make the the bootloader a bit more failsafe I'm also voting for including this in the Sming framwork (if it's ok with you rab).

Nice work!

- Tue May 19, 2015 6:02 am #17842 You're quite right about me incorrectly using flash and eeprom interchangeably, I'll fix that in my posts and readme this evening. It is flash and so I am erasing sectors appropriately.

A checksum on the config is certainly possible and should be easy enough to implement, might have a look at that tonight too.

As for the sdk boot loader using 3 sectors for config, you might be right about redundancy, but I'm not sure. Certainly the main boot loader config is only stored in one sector, what's stored in the other is a bit less clear and I think is basically a separate copy for each rom, even though it is the same. It's not clear that it will fall back to one if the other fails. However, when I realised I didn't like the original and was going to write a new one from scratch I stopped bothering trying to figure out the finer points of the sdk version.

I'd be happy for rBoot to be used in other projects, it would be nice to see some of my efforts of use to others. Even though I've enjoyed playing with it myself it's nice to see things like this get used.

Edit: esptool2 is now on github https://github.com/raburton/esp8266

Richard.

Last edited by rab on Fri Jun 12, 2015 1:49 am, edited 1 time in total.

- Tue May 19, 2015 4:04 pm #17899 Ok, I've fixed the terminology, thanks for pointing that out. Eeprom is now an unword - it never existed, all occurrences have been corrected, Oceania has always been at war with Eurasia.

I've also added a checksum to the config for you. If you are worried about being left with an unbootable system the easiest option is probably to modify the default config produced by rBoot to your particular requirements. That way if the config is lost or damaged a suitable new one will be created for you automatically, no need to keep a separate backup. The only thing you'd loose is the currently selected rom slot, on next boot after a corrupted config it would try booting from the first one.

Not had time to sort out and upload the source for esptool2 yet though, that'll have to wait till tomorrow...

- Tue May 19, 2015 4:43 pm #17903 Ok, uploaded the source for esptool2, it should compile with visual studio on windows and gcc on linux (untested, but compiles with gcc fine under cygwin). Didn't take a lot to get it to compile with gcc so got it done tonight after all, but really need some sleep now.