add support for ESP32-S2 ESP32-S3 32MB ... 128MB (ESPTOOL-331)

[ESP32DE]

ESP32-S2 and ESP32-S3
supports up to 1 GB of external flash and RAM
add support for

32MB
64MB
128MB ( example NOR spiFLASH 1G-BIT W25Q01JVZEIQ Winbond 0xEF 0x40 0x21 )

squashed the commits and rebased
in this new PR

I have tested this change with the following hardware & software combinations:
Winbond
NOR spiFLASH 1G-BIT W25Q01JVZEIQ 0x21 )
ESP32-S2-DevKitC-1
ESP32-S3-DevKitC-1
ESP-IDF v4.4-dev-3235-g3e370c4296-dirty

[radimkarnis]

Hi @ESP32DE,
thank you for contributing and combining your PRs.

I have to ask you for one more thing: When you change the source code of the flasher stub (stub_flasher.h in this case) , it is necessary to build it and embed its code into esptool (see flasher stub README for instructions).

You can see a failing test because the stub code and its sources differ.

[ESP32DE]

Hi @radimkarnis
u are welcome

to be honest, I thought that the "online check" would do that stub stuff :)
no problem, I can do it and make up for it. it builds fine and I can embed it with make embed.

What I'm still struggling with, however, is the fact that the direct write_flash process (UART - ROM-LOADER) terminates bin files > 0x1000000
The test.bin is near 26MB.
It shouldn't be after all. Do you know of any problem with the ESP32-S3 Rev0?
Do we have a hidden limit > 16MB write flash in ones?
I'm still looking for the cause of the crashes, but unfortunately I can't (yet) locate this problem in the software.
Wear Levelling works so far - the size of the bin file is not big
Any idea for the 0x1000000 break?

Info: I have adjusted something on the TIMEOUT for the 1G-BIT NOR Flash because the standard setting was not sufficient. CHIP_ERASE_TIMEOUT = 180 seems to cover the used 150 well. Do you want to see this value in PR?

I added pics operations from flash_id, erase_flash and write_flash.
write_flash (without compression) aborts exactly at 0x1000000, which corresponds to exactly 16MB.

I noted we have on ESP32-S3 no --no-stub way.

Strangely enough, it breaks even earlier with compression (at about 29%).
( i used also slower baudrate - same result )

@radimkarnis
update 2021-Oct-23 (PM 08:03)
I suspect a small mistake - let me test it once - I think I'll get it baked
I will run asap hw test and update the post

[radimkarnis]

The stub currently supports 32-bit flash addressing only for GigaDevice chips, that is why the write process fails after getting to 0x1000000. You can try with the --no-stub option.

I would focus this PR only on esptool itself, as there is much more to do on the stub side. It is planned to add stub support for ESP32S2 and S3 (other flash chips than GD) in the future.

[ESP32DE]

Hi @radimkarnis
thank you for your help.

the --no-stub works so far -

i was working at weekend at support winbond in the stub - there are many things to do that all works right on stub side.
Cause it is planned to add stub support for ESP32S2 and S3 (other flash chips than GD) in the future, i rolled back the stub_flasher.h and focus this PR only on esptool itself.

If any, please let me know and i will try my best.

Thank you for your kind manner and help.
edit: grammar

[radimkarnis]

Thank you @ESP32DE for your contribution!