search

homieiot / homie-esp8266

💡 ESP8266 framework for Homie, a lightweight MQTT convention for the IoT
http://homieiot.github.io/homie-esp8266
MIT License
1.36k stars 308 forks source link

Request: Checking flash size during OTA #182

Closed Gulaschcowboy closed 7 years ago

Gulaschcowboy commented 7 years ago

Hi Marvin,

I don't know if it possible and how much work it would be. I have different ESP models with different flash sizes/configurations. And I always forget to adjust it correctly, before I export the binary. So it would be handy, to have a function to check the correct flash size before ending up with an OTA, that erased (or doesn't find) the config.json anymore.

Thanks, Alex

marvinroger commented 7 years ago

I searched if it was possible to get the flash size at compile time, so we can embed the flash size with magic bytes, but I can't find a way.

ghost commented 7 years ago

The physical flash size the new firmware expects is encoded in the first 4 bytes of the firmware binary.

During update, the esp8266/Arduino Updater class (which Homie is using) verifies that the new firmware to be programmed fits into the space between the current firmware and the SPIFFS file system where the Homie config is stored. Updater also verifies that the new firmware physically fits into the SPI flash. Note that everything is aligned at flash erase block boundaries (64KB).

What Updater doesn't verify is that the new firmware won't overwrite the old SPIFFS section when the new firmware is launched. I think Updater is correct in allowing to re-partition the flash layout with a firmware update. AFAIK, the SPIFFS address is only embedded as a linker symbol in the firmware:

extern "C" uint32_t _SPIFFS_start;

So Homie cannot trivially determine it by "looking" at a file header or something in new firmware. The only option I see is that Homie COULD add a new magic bytes sequence like with the firmware name. Then, during OTA, Homie could search these magic bytes, compare the new SPIFFS location against the current one and reject the update on mismatch.

Still, I'm not sure this is something Homie SHOULD do. Why? Because, also with Homie, users might want to re-partition their flash layouts, for example when re-purposing ESP hardware.

marvinroger commented 7 years ago

I agree with @mrpace2, this "feature" would actually limit the possibilities offered by OTA updates.

Gulaschcowboy commented 7 years ago

I understand your point. Just my 2 cents: Would it be a good idea, to offer a function/flag within the sketch, that avoids such unwanted repartitioning? -> Homie.allowRepartition with a default of true? So both approaches could be satisfied.

marvinroger commented 7 years ago

The second problem is it needs a state machine to parse the magic bytes, as the firmware comes splitted into multiple packets. In other words, we've determined with @mrpace2 that it would be too much of an hassle to implement this, for what it's worth.

Gulaschcowboy commented 7 years ago

OK, thanks, I will close this issue