What does "Image contains multiple DROM segments. Only the last one will be mapped." mean?

[Gfast2]

Hi ESP-IDF,

I did my best trying to avoid asking questions on each problem I'm experiencing. But I've to say, as a junior, the chance from some "simple" error log to figure out what is hidden behinde the scene is hard to google and with my own experience to figure out.

After experiencing compiling time warnings like this:

Code: Select all

/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tbss.op_timestampsToReturn2 lma 0x40150b98 adjusted to 0x40150b9c
/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tbss.op_sub lma 0x40150b98 adjusted to 0x40150ba0
/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tbss.op_publishingEnabled lma 0x40150b98 adjusted to 0x40150ba4
/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tbss.op_timestampsToReturn lma 0x40150b98 adjusted to 0x40150ba5
/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tbss.op_releaseContinuationPoint lma 0x40150b98 adjusted to 0x40150ba9
/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tbss.g_exchangeBufferCallbackHandle lma 0x40150b98 adjusted to 0x40150baa
/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tbss.g_exchangeBufferCallback lma 0x40150b98 adjusted to 0x40150bae
/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tbss.g_end lma 0x40150b98 adjusted to 0x40150bb2
/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tbss.g_pos lma 0x40150b98 adjusted to 0x40150bb6
/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tbss.g_customTypesArray lma 0x40150b98 adjusted to 0x40150bba
/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tbss.g_customTypesArraySize lma 0x40150b98 adjusted to 0x40150bbe
/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tdata.UA_rng lma 0x40150b98 adjusted to 0x40150bc2

I got my library porting project passed the compiling successful. After many times trials, I always got the same result:

Code: Select all

MONITOR
--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5724
load:0x40078000,len:0
load:0x40078000,len:13804
entry 0x40079030
I (68) boot: Detected ESP32
I (32) boot: ESP-IDF v3.0-dev-1390-g22489d70-dirty 2nd stage bootloader
I (32) boot: compile time 21:43:05
I (33) boot: Enabling RNG early entropy source...
I (39) boot: SPI Speed      : 40MHz
I (43) boot: SPI Mode       : DIO
I (47) boot: SPI Flash Size : 4MB
I (51) boot: Partition Table:
I (54) boot: ## Label            Usage          Type ST Offset   Length
I (62) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (69) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (76) boot:  2 factory          factory app      00 00 00010000 00100000
I (84) boot: End of partition table
I (88) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x20c9c (134300) map
I (144) esp_image: segment 1: paddr=0x00030cc4 vaddr=0x3ffb0000 size=0x04800 ( 18432) load
I (151) esp_image: segment 2: paddr=0x000354cc vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _iram_start at /home/gfast2/esp/esp-idf/components/freertos/./xtensa_vectors.S:1685

I (152) esp_image: segment 3: paddr=0x000358d4 vaddr=0x40080400 size=0x0a73c ( 42812) load
I (177) esp_image: segment 4: paddr=0x00040018 vaddr=0x400d0018 size=0x80b50 (527184) map
0x400d0018: _stext at ??:?

I (360) esp_image: segment 5: paddr=0x000c0b70 vaddr=0x4008ab3c size=0x05690 ( 22160) load
0x4008ab3c: bt_correct_bbgain at ??:?

I (370) esp_image: segment 6: paddr=0x000c6208 vaddr=0x400c0000 size=0x00000 (     0) load
I (370) esp_image: segment 7: paddr=0x000c6210 vaddr=0x00000000 size=0x0a950 ( 43344) 
I (393) esp_image: segment 8: paddr=0x000d0b68 vaddr=0x40150b68 size=0x00010 (    16) map
I (403) boot: Loaded app from partition at offset 0x10000
I (403) boot: Disabling RNG early entropy source...
E (404) boot: Image contains multiple DROM segments. Only the last one will be mapped.

What could that mean? It seems like the "the last one" is some bad DROM, which won't crash the freeRTOS, but won't do any thing meaningful neither.

This is the related question.

Cheers

Gfast2

[ESP_Angus]

Hi Gfast2,

It looks like some of the source files in your library are being compiled to unexpected section names, and these section names are being linked into the ELF file and then the binary in a way which the ESP-IDF bootloader isn't designed to handle. This is probably in the open62541 library that you're building with CMake and then linking into ESP-IDF.

The clue is in these messages:

.tbss.g_customTypesArraySize lma 0x40150b98 adjusted to 0x40150bbe
/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tdata.UA_rng lma

.tbss and .tdata aren't "normal" section names, or sections recognised by the IDF linker script. My only guess is that open62541 build process is using these section names for some reason. Try to modify their build system so you end up with names like .bss and .data (these are the common names for these sections), and the ESP-IDF linker script will produce a binary that the bootloader can load.

[Gfast2]

Hi Gfast2,

It looks like some of the source files in your library are being compiled to unexpected section names, and these section names are being linked into the ELF file and then the binary in a way which the ESP-IDF bootloader isn't designed to handle. This is probably in the open62541 library that you're building with CMake and then linking into ESP-IDF.

The clue is in these messages:

.tbss.g_customTypesArraySize lma 0x40150b98 adjusted to 0x40150bbe
/home/gfast2/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/gfast2/workspace/open62541_port03/build/open62541_port.elf: section .tdata.UA_rng lma

.tbss and .tdata aren't "normal" section names, or sections recognised by the IDF linker script. My only guess is that open62541 build process is using these section names for some reason. Try to modify their build system so you end up with names like .bss and .data (these are the common names for these sections), and the ESP-IDF linker script will produce a binary that the bootloader can load.

Hi Angus,

Thanks for your tips, it does help a lot!

I greped all parent git repo of the project, and figured out these:

tdss_tdata.png (332.12 KiB) Viewed 5940 times

And then I believe This Link helps me to understand, that it's some problem about "per-thread local storage (TLS)".

in file "open62541/src/ua_util.h" there is something about how should the compiler trate this feature for the library:

Code: Select all

 20 /* Thread-Local Storage
 21  * --------------------
 22  * Thread-local variables are always enabled. Also when the library is built
 23  * with ``UA_ENABLE_MULTITHREADING`` disabled. Otherwise, if multiple clients
 24  * run in separate threads, race conditions may occur via global variables in
 25  * the encoding layer. */
 26 #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L
 27 # define UA_THREAD_LOCAL _Thread_local /* C11 */
 28 #elif defined(__cplusplus) && __cplusplus > 199711L
 29 # define UA_THREAD_LOCAL thread_local /* C++11 */
 30 #elif defined(__GNUC__) && !defined(_WRS_KERNEL) //defining __thread gave error of missing __tls_lookup in VxWorks
 31 # define UA_THREAD_LOCAL __thread /* GNU extension */
 32 #elif defined(_MSC_VER)
 33 # define UA_THREAD_LOCAL __declspec(thread) /* MSVC extension */
 34 #else
 35 # warning The compiler does not support thread-local variables
 36 # define UA_THREAD_LOCAL
 37 #endif

I know ESP-IDF is starting to support POXIS thread. But how should I treat this per-thread local variable? I will surely trying to let marco "UA_THREAD_LOCAL" being nothing (like in line 36 above do). But why I encounter this issue?

Cheers

Gfast2

[Gfast2]

After the small hack for "__thead". I make the OPC UA up'n running firstly without crash immediately (This is what happened of the version 0.2 of the library).

Thanks again!

Cheers

Gfast2