V4 - Bootloader

[netmindz]

Key to the successful release of 0.16 will be handling the issue of devices with older, incompatible bootloader.
It is expected that we will need to issue a new 0.15.x release that users update to before they swap to 0.16

Required:

• OTA to check the version of your bootloader before applying OTA and prevent install if bootloader is not as expected

Nice to have:

• Ability to update bootloader from within WLED

[netmindz]

@willmmiles can we detect what bootloader is installed?

[willmmiles]

@willmmiles can we detect what bootloader is installed?

IIRC that feature was added in IDF 5.3. We can pull out the code and vendor it in, I expect.

[willmmiles]

We will probably also need a way to tag the OTA files with metadata so we can apply the checks. (I strongly advise against using the filename for this purpose - people rename files all the time.) Whatever we come up with, we should consider making it extensible to cover other install compatibility metadata, such as S3 hardware details.

[netmindz]

What metadata do we require?

[netmindz]

As the web installer has actually been using the V4 bootloader for a long time, I'm hopeful that we do not have too many users with devices with older bootloaders but we certainly need to offer an upgrade path that can identify issues before they get in a boot loop of fail

[willmmiles]

What metadata do we require?

For bootloaders? We need to indicate to the old code what bootloaders the new code supports, so the check can be done before the flash.

For other cases? I'm not 100% sure - IIRC flash size and type seem to be the big ones causing headaches for the installer with S3s, but that might only matter for the initial serial flash. I don't know if it applies to OTAs.

[blazoncek]

FYI bootloader for ESP32 is different if using 4M or 8M flash.

[mattpiper99]

I just synced my personal WLED fork to the latest and had a hell of a time getting it to compile again. I was getting a bunch of sdkconfig.h errors. I suspected it was related to #4836 and tried to reconcile all the changes in my platformio_override (for example switching from platform = ${esp32.platform} to platform = ${esp32_idf_V4.platform}) but was still having trouble.

I found a conversation in discord #dev-general from someone else who was experiencing that same issue back in January and dedehai replied "that is due to the update to V4." and recommended clearing cache and stuff which didnt really seem to help.

Then I noticed a comment from Kilrah below that which said "ok i get that sdkconfig error if i don't include board_build.flash_mode". He didnt specify what value he used to get it to work but I found some references to setting it to "dio", so i added that and I think that was the final trick to get wled to compile again... but now its just stuck in an endless cycle of rebooting itself during boot, which i think is what this discussion is referring to. I could see in the WLED debug output that its getting through some of the initilization before it reboot itself.

Then out of curiosity I decided to try "qio" instead since I saw other references to that, and then it totally seems to have bricked my "QuinLED Dig-Uno" controller, it never gets into wled anymore and just loops on this:

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:184
load:0x40078000,len:12680
=> 0x40078000: ?? ??:0
load:0x40080400,len:2908
=> 0x40080400: _init at ??:?
entry 0x400805c4
=> 0x400805c4: ?? ??:0
Ada
ets Jul 29 2019 12:21:46

Then i decided to recompile back to "board_build.flash_mode = dio" and its still stuck in that loop, im not seeing the same wled debug output that i was seeing before....

So..... then I went to the web installer at https://install.quinled.info/dig-uno/ and reinstalled an old version 0.14 and got it working again, but I'm afraid if I try to re-compile and install from the latest build its going to brick the controller again? What can I do to ensure the boot loader is correct for installing it (assuming thats what the issue is)?

[netmindz]

@mattpiper99

flash_mode is required as part of your board definition or env, see examples of this on our platformio.ini

As for the boot loop, you will see there is currently an issue open saying that nightly builds are boot looping in general

As for the stability of your own fork, if you want a stable build, please base your branch of the release branch (0_15_x)

If your fork is to contribute PRs then off course base of main and raise any regressions in the dev-general channel on discord

[netmindz]

Recommendation from @willmmiles

Right, I'd suggested we backport esp_ota_get_bootloader_description() - it returns the bootloader header, one of these: https://github.com/espressif/esp-idf/blob/2044fba6e71422446986f9ae0909b1ab67e57815/components/esp_bootloader_format/include/esp_bootloader_desc.h#L25