ESP8266-12F Flashing: Address Offsets for NONOS_SDK-2.2.1 Firmware

Hello, I'm starting to play with the ESP8266 (in my case it's version 12F), I wanted to upload the original FW and I'm starting to get nystagmus.

I've downloaded probably the latest version marked as NONOS_SDK-2.2.1 (that is, the one without the operating system), but reading the manual I don't really know at which addresses (offsets) to upload the different parts (binary images) of the software I'll add that I'm using ESP Flash Download Tool.

There is a description in the README.md from the bin/at directory, but it is nowhere near the naming of the files contained in the package.
From what I understand, in order to upload the simpler version (the one without the ability to update the FW via WiFi - direct Flash programming) I am interested in NON-BOOT MODE##, according to which for the ESP-12F version (4MB) I upload the following
eagle.flash.bin 0x00000
eagle.irom0text.bin 0x10000
Flash size 32Mbit: 0x7e000 & 0x3fe000

However, in the downloaded package I have the following files:
blank.bin
boot.bin
esp_init_data_default.bin
user1.1024.new.2.bin
user2.1024.new.2.bin
and I don't really know what to put where?

shel82 wrote:

according to which, for the ESP-12F version (4MB) I upload the following
eagle.flash.bin 0x00000
eagle.irom0text.bin 0x10000

.

These binaries have to be built yourself unfortunately
https://github.com/espressif/ESP8266_NONOS_SDK

Don't go down this road. The only valid SDK for ESP8266 is ESP8266_RTOS_SDK, which is successively being rewritten in esp-idf style. That is, it is being developed intensively, and ESP8266 and ESP32 support is also being unified. There the firmware update is simplified - you have one soft image file. Anyway, uploading software is done from within the built-in makefile, so you don't have to fiddle with it at all.

Nagus wrote:

The only valid SDK for the ESP8266 is the ESP8266_RTOS_SDK, which is successively being rewritten in esp-idf style. That is, it is being developed intensively, and ESP8266 and ESP32 support is also being unified.

.
Exactly the same can be said for the NONOS_SDK version, and the choice should not be ideological, but driven by specific user needs.

As for 'successive rewrites' and 'intensive development:
" ESP8266_RTOS_SDK's framework is quite outdated and different from the current esp-idf and we are planning to migrate ESP8266_RTOS_SDK to esp-idf eventually after v2.0.0. However, we will firstly provide a new version of ESP8266 SDK (ESP8266_RTOS_SDK v3.0), which shares the same framework with esp-idf (esp-idf style), as a work-around , because the multi-CPU architecture is not supported by esp-idf for the time being. "
Source .

NONOS_SDK is mainly used where there is a need for higher-level programming languages (Lua, MicroPython) and involves the implementation of a suitable interpreter, e.g. NodeMCU.

Both SDKs are being developed in parallel and each addresses different application areas.

Even after removing the ideological wording, NONOS_SDK is non-perspective, as the development burden has been shifted towards esp-idf. An additional advantage of esp-idf is that ESP8266 software can be ported to ESP32 and vice versa, with only minor adjustments. Also, there is no need to combine coarse features such as native http server support, which is unlikely to be present in NONOS, while it is just starting to be introduced in RTOS (ESP32 already had it).

Nagus wrote:

An additional advantage of esp-idf is the ability to port ESP8266 software to ESP32 and vice versa, with only minor adjustments.

.
Please provide a source for this information.

OK, too much of a mental shortcut....
The ESP32 has much beefier peripherals, so if something is based on peripherals unique to the ESP32, then porting it to the 8266 at face value isn't going to work.
But, for example, such support for a basic UART. In the ESP8266 there is no pin setting for the UART and the uart_driver_install function has one less parameter. Everything else qualifies under ctrl-c ctrl-v. Knocking one command and one parameter out of another can hardly be considered code ploughing.
There are hardly any drastic differences in WLAN interface handling either.
I've done a bit of practice with both, used large chunks of code on both platforms, and apparently I've developed some strange beliefs.