Is the boot loader in ROM or Flash?

[KarlBrosner]

It''s unclear what Espressif defines as "ROM" and what it contains. Some vendors define ROM to include flash storage (Flash ROM), however, ROM traditionally means storage containing non-volatile, read-only, permanent or semi-permanent data programmed at the factory, which can't be modified without either replacement or reprogramming using specialized equipment.

Reading through the documentation, it claims the first stage boot loader is in "ROM". There's also evidence of this reading through the boot loader scripts containing "provides" for various runtime functions and Newlib. This is a bit odd, since such code is ordinarily part of the firmware rather than stored in ROM so it can be easily updated in response to a last-minute change, bug, or vulnerability by the vendor.

There's evidence also supporting that it's not "ROM". There are different linker scripts for different build scenarios. There's what appears to be a full and nano size Newlib definition, suggesting the code resides in flash and possibly shared across multiple apps. If indeed the code is stored "ROM" rather than Flash, then there would be no need to have different linker scripts, since the number function definitions has no impact on the code size.

So which one is it, ROM or Flash? What does it contain?

[ESP_Sprite]

The ROM that the 1st stage bootloader is in is mask ROM, in other words the ROM contents are part of the design of the chip and cannot be changed. Our ROM includes the code that allows serial flashing as well as parts for some commonly used libraries (newlib and libgcc, if memory serves). The reasoning for this is that these are stable (as in: we don't expect them to change in newer versions of those libraries) and that having them in ROM frees up precious RAM and/or stops cache churn from happening. You're right that every now and then a routine does change, and in that case we include the updated routine in flash and use that instead. From what I recall, for the original ESP32, the 'nano' implementation is in ROM; if you need the 'full' implementation we link to routines that get added to flash instead.

[MicroController]

You can inspect the linker scripts to find which (application-usable) functions there are in the ROM.

Among other things, there's some very basic stuff in ROM that gcc itself requires an implementation of, like 64-bit integer division or memcpy. These things are independent of the C lib in use and will never require to be updated.

The ROMs' contents are also published as binaries here.

[KarlBrosner]

Thanks for your response. I still don't understand why there's a need for selecting different ROM symbol declarations in the esp_rom folder. Why not have a single configuration per SoC declaring all the symbols and their addresses? Declaring them shouldn't have any impact on memory, or am I missing something here?

[ESP_Sprite]

It's because they handle some configuration options. For instance, the ROM version of printf doesn't handle 64-bit values. If that is not a problem, you can select that in menuconfig, and the build system will include esp32.rom.newlib-nano.ld. The functions defined in there are defined as 'strong' symbols and as such will override the same functions that would otherwise go into flash; the build system won't need the latter anymore and you saved a bit on flash space. If you need 64-bit values, esp32.rom.newlib-nano.ld is not included and the build system will resolve calls to printf() to the newlib that is in esp-idf and will be located into flash instead.

In other words: the action of declaring them means that they will get used instead of the ones in esp-idf, meaning that we can control if they're used or not by declaring them or not.