Reimplemented esp_init_data_default. #1526
Conversation
To work around the pesky "rf_cal[0] !=0x05" hang when booting on a chip which doesn't have esp_init_data written to it. It is no longer possible to do the writing of the esp_init_data_default from within nodemcu_init(), as the SDK now hangs long before it gets there. As such, I've had to reimplement this in our user_start_trampoline and get it all done before the SDK has a chance to look for the init data. It's unfortunate that we have to spend IRAM on this, but I see no better alternative at this point.
|
Cool, I didn't realize we were able to run code before the SDK error. Definitely a good solution! I tested 5 cases:
👍 |
| // Note: ideally we should generate the actual init data from the | ||
| // SDK's bin/esp_init_data_default.bin during the build, and #include it | ||
| // straight into this array. E.g.: | ||
| // xxd -i esp_init_data_default | tail -n13 | head -n11 > eidd.h |
There was a problem hiding this comment.
Is there a reason that you didn't do this?
|
I tried this, and it worked in my case..... |
| // SDK's bin/esp_init_data_default.bin during the build, and #include it | ||
| // straight into this array. E.g.: | ||
| // xxd -i esp_init_data_default | tail -n13 | head -n11 > eidd.h | ||
| static uint8_t flash_init_data[128] __attribute__((aligned(4))) = |
|
I'm currently on the road and can't test but did one of you verify if the "old firmware" (0.9.x, 1.4, etc.) -> 1.5.4.1 upgrade runs smoothly? IIRC there were some fundamental init data changes between 1.5.1 and 1.5.4.1. |
|
Upgrading from old firmware would still require an erase first. This code only covers the case where the beginning of the init data is blank. I don't think you can do anything more generic without running the risk of overwriting a user's custom init data. |
|
@marcelstoer Upgrade from 1.5.1 to 1.5.4.1 worked fine here. Tested:
|
Can we reliably determine the size (i.e. length) of the init data block on the device? If so then we can compare it against the SDKs init block size and still overwrite if they don't match. |
|
No, the init data block is always 128 bytes, but there's no (sane) way to differentiate between a custom init block and an old SDK one. If we had heaps of IRAM we could keep copies of all previous SDK defaults and compare against each, but we don't, so i think #1527 is as good as we're going to get at this point. |
|
That would indeed be a waste of space if all we care about is whether the defaults were changed or not. So, if we could guard all functions that alter init data we'd only need a single bit of IRAM. |
|
To my knowledge there are no functions which alter the init data (other than our initial installation thereof). Custom init data typically gets flashed at the same time (or soon after) the NodeMCU image is flashed to the chip, and there is no way for us to detect that short of a full comparison. And even then, if the user explicitly wants/needs the values from e.g. SDK 1.4.0, we wouldn't be able to tell that intent apart from someone who just upgraded from a 1.4.0 build and would like to have the init data updated. |
Fixes #1500.
- This PR is for the
- This PR is compliant with the other contributing guidelines as well (if not, please describe why).
- I have thoroughly tested my contribution.
- The code changes are reflected in the documentation at
Reimplemented esp_init_data_default to work around the pesky "rf_cal[0] !=0x05" hang when booting on a chip which doesn't have esp_init_data written to it.devbranch rather than formaster.docs/en/*.It is no longer possible to do the writing of the esp_init_data_default
from within nodemcu_init(), as the SDK now hangs long before it gets
there. As such, I've had to reimplement this in our user_start_trampoline
and get it all done before the SDK has a chance to look for the init data.
It's unfortunate that we have to spend IRAM on this, but I see no better
alternative at this point.
With this patch, NodeMCU should finally be back to "it just works" when flashed onto a fresh(ly erased) ESP, and the previously documented approach should be correct once more.
I'd really appreciate it if a few more people could try this PR before considering merging - while it's working fine for me, I'm always a bit hesitant messing with the early boot stuff.