Yes, I got there thru the "Advanced" setup with a single "esp32 chip"... Installation process looks fine but the result is negative (refer to the above).

Looks like the EIM approach is a long way from usable...

Hi,
I'm having trouble with the very first steps in a new IDF 6.0:

(1) Clean, fresh and virgin system
(2) Creating c:\Espressif folder to have all the stuff there
(3) Espressif-IDE downloaded and saved to c:\espressif\IDE
(4) Installing EIM -> IDF6.0 -> everything installs & gets fine in c ...

Doesn't sound like a "bug" but rather a feature request.


So-so... A feature request might have sound like this:
The system might become more flexible if BL2 is not bound to 0x1000 address. Instead, the flash at 0x0000 might have contained a 4-bytes offset of the bootloader. Dunno how this can ...

UPD. It's highy likely some intermediate procedure in .OBJ code fails to check the bounds and passes the value over.
I've scrolled the bootloader .MAP file and found dozzens of potential callers...
The developer team needs only to open the source code and add a few lines to have this fixed. Not a ...

/* This is my reply to your initial post that you have edited while I was replying to

Nope, what you are saying is an attempt to represent the issue the other way round and dillute the negative effect...

Once again:

"TERMS":
- bootloader flow MUST be consistent with the IDF docs
- IDF docs _DO ...

BUG REPORT
IDF: 5.0.1 (possibly later releases also affected)

ABSTRACT : 2nd-stage bootloader (BL hereinafter) incorrectly treats the offset of the partition table (PT hereinafter) as uint32_t whereas it should be int32_t.

Description :
ESP-IDF says the flash region 0x0000...0x1000 is used by ...

Oh...My mistake - I DID miss the point that explicilty writing 0xFF to flash in DEV_MODE will become "garbage". Then everything makes sense....
Thanks a lot
Then my post effectively gets shrinked to just accusion of capricious bootloader behaviour without trailing 0xFF in PT

Although your comments make sense in a general way there's still one thicky thing.

Look, we have a physical array of memory cells having 0xFF's after flash erase. You are right in a way WE DON'T know whether it is a valid 0xFF value or a "blank" cell just erased.

However, esp_flash_read_encrypted ...

no problem.
then calls to esp_flash_read_encrypted should tell garbage from erased.
software might be unaware whether it is reading blank (erased) flash or not. especially 3d party libraries.

Yes, technically, it is sure not the same.
And no, logically, it should be the same since we should get a container filled with 0xFF irrespective encrypted/unencrypted flash is used.

Life-case example: I'm fiddling with partition-tables at the moment. For some unknown reason Espressif bootloader ...