I don’t really understand if I urgently have to do something, should do something (basically I hate collecting all ESPs and doing a local USB flash) or if can safely ignore this - for a while or forever.
Can some ESP(Home) expert please translate this to regular users’ language?
40K extra IRAM on original ESP32 (#14874): A new option reclaims 40KB of previously reserved SRAM1 as IRAM, expanding the flash cache window and reducing cache misses for WiFi, BLE, and API operations, at no cost to heap. ESPHome will automatically detect your bootloader version at boot and suggest enabling this option only when it is safe to do so. Do not enable this option without the bootloader check confirming it is safe; enabling it with a pre-v5.1 bootloader will brick the device (requiring USB reflash to recover). See the ESP32 documentation for details.
So do NOT use the new option sram1_as_iram and you are fine. If you want to use the new option, you have to update the bootloader.
Just to make sure: I did not change my config (.yaml files). So I did not “opt-in” for
That’s why this confuses me a bit. Seems like it got automatically enabled during the update? Anyway, a local/USB flash is so annoying. And I still don’t know if it’s necessary.
“enabling it with a pre-v5.1 bootloader will brick the device”
The flasher warns you have the old bootloader
Your device is not bricked
Ergo: it not enabled.
Your device works
Ergo: it is not needed.
“expanding the flash cache window and reducing cache misses for WiFi, BLE, and API operations”
If you want that, make sure you update the bootloader first. Then enable the option if the flasher says it is safe.
The message is telling you that your bootloader is old (which it now is).
It probably is a good idea to update the bootloader, but as long as you do NOT want to use the new feature you do NOT need to update the bootloader.
The new bootloader is REQUIRED to use the new feature, as long as you didn’t update your YAML, you aren’t using the new feature that is incompatible with your old bootloader.
The features coming with it sound good for safe operation. Maybe other future features are bound with a new bootloader directly or indirectly. So if that’s the coming mainstream, I want it.
But: my devices are spread and built-in all everywhere. Isn’t there a chance to update the bootloader OTA? Maybe with an intermediate build?
I found myself in the same situation. I decided I wanted to get up to date, mostly because I have plans to add some other functionality to these devices. I documented the process here:
For the minimum_chip_revision, if there's no warning about that, you shouldn't add it. I kind of mixed two things together since I was seeing both warnings. I'm going to remove all mentioned of that flag - it's not really relevant.
I struggle with Wordpress formatting. The edit mode seemed to be understanding my markdown markup. I just looked again at the published page and I'm seeing the lack of formatting too.
Thank you for letting me know. I just published the changes. I hope it makes more sense now.
One other thing... it's ok (kind of, to try) to flash with the --bootloader option.even if you're not sure you set allow_partition_access. It'll fail with a clear message. I'm mentioning this now because without updating minimum_chip_revision you may not be able to tell for sure whether the flash succeeded. Seems there's no risk if it failed.
Yeah, that actually kept another board from booting. It would compile and upload, but then would hang and I had to power cycle to get it to revert to the working image. Once I removed minimum_chip_revision everything went fine including updating the bootloader OTA.
Do you know if sram1_as_iram: true will become the default at some point?
Did you have a warning message that told you to add the minimum_chip_revision or were you just trying it out? I just updated a pair of Athom plugs with ESP32C3 and it didn't tell me to add either of these flags (so I didn't). Glad it was easy to recover either way.
I have no idea. I didn't even test whether setting it on a device with an old bootloader would actually brick the device or whether the firmware knows to disable it if the bootloader is too old.
I was on my forth device and probably blindly copied it in. The unfortunate thing was it compiled and uploaded just fine and even appeared to connect but then just hung. Power cycling brought it back to the previous boot just fine. This is a device, outdoors, on the far range of my wifi, so wasn't really sure of the reason.
Your logic of attempting first to do the OTA update made so much sense when I read this thread. I was just putting it off since I have devices outside that I'd have to take apart to get to the USB connector. Thanks again.
I have a tool I use to compile and upload esphome firmwares to the espdevice builder. I added code to there to update the bootloader on my esp32 devices and I'm 5/5 on it being sucessful.
I did it in 4 stages, which it automated.
Update to latest firmware.
Update to latest firmware with partition access enabled
Update bootloader
Reupload 1.
Then I would check the startup logs for the device, and set the min-revision and sram settings if they showed up.
