ESP8266 Community Forum

- Tue Aug 18, 2015 11:51 pm #26426 Ive been putting off for a while covering the linking process of building a program and deploying it. However, like the elephant in the room, I can't put it off any longer.

I understand compiling a source file to an object file. I think I event understand linking object files to an executable in ELF format. Where I am getting stumped is the relationship between the ELF formatted file and the "binaries" that are written to the flash memory of the ESP-12. For example, I compiled and linked some source files and have an executable (ELF) where if I dump the sections, I am presented with:

Code: Select allSections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000540  3ffe8000  3ffe8000  000000e0  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  1 .rodata       0000039c  3ffe8540  3ffe8540  00000620  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .bss          000091f0  3ffe88e0  3ffe88e0  000009c0  2**4
                  ALLOC
  3 .text         0000630a  40100000  40100000  000009bc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  4 .irom0.text   00029848  40240000  40240000  00006cd0  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  5 .xtensa.info  00000038  00000000  00000000  00030518  2**0
                  CONTENTS, READONLY
  6 .xt.prop      00024504  00000000  00000000  00030550  2**0
                  CONTENTS, READONLY
  7 .xt.lit       00001100  00000000  00000000  00054a54  2**0
                  CONTENTS, READONLY
  8 .comment      00001a18  00000000  00000000  00055b54  2**0
                  CONTENTS, READONLY
  9 .debug_frame  000001d0  00000000  00000000  0005756c  2**2
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_info   0000228c  00000000  00000000  0005773c  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_abbrev 0000095c  00000000  00000000  000599c8  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_loc    0000178c  00000000  00000000  0005a324  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_aranges 00000300  00000000  00000000  0005bab0  2**3
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_line   000028d9  00000000  00000000  0005bdb0  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_str    00000827  00000000  00000000  0005e689  2**0
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_ranges 00000118  00000000  00000000  0005eeb0  2**0
                  CONTENTS, READONLY, DEBUGGING

Now I have a plethora of tools called:

o gen_appbin
o esptool.py
o esptool-ck

I have various Makefiles that use these tools in different ways and result in "success" ... but what I want to do is understand the process so that I can write it up for others to subsequently understand it themselves.

I get the impression that the ELF file is now "decomposed" into two binary files and these are separately loaded into the Flash memory of the ESP-12 ... but that's where I end. Can some kind souls help me to understand what is going on here so that I may write it down and help others?

If there is reading I should do, am happy to do that ... and would welcome some pointers.

Neil

Free ESP8266 book available for download here.

- Wed Aug 19, 2015 1:55 am #26438 Hi Neil,

Best place to start from is probably Richard Burton's blog posts: http://richard.burtons.org/2015/05/17/e ... t-process/ (and followup posts regarding developing rBoot). He explains the ESP8266 bootloader binary format well.

In short: The binary file which is flashed to offset zero has a special header and contains all of the sections loaded into RAM (.text, .rodata, .data, etc.) with headers telling the ROM-based bootloader where to load them. Following a reset, the ROM-based bootloader reads the headers and loads the sections into RAM before jumping to the start address (which is also given in the headers).

The second binary file placed at offset 0x40000 (or some other offset) is just the raw binary contents of the irom0 section. It gets copied to the flash at that specific offset (which has to match the offset given in the linker script, so when the flash maps to RAM then the addresses used in the code match the flash offsets where the code is stored).

Using "rboot" or the new "v1.2" OTA-compatible boot loader binary format, all of the image goes in a single binary file (not two), with a complex series of headers - the first set of headers match the ROM bootloader headers, but they just load a second stage bootloader into IRAM. Then that second stage bootloader runs and it reads a second set of headers that explains where to load which sections from the main image into RAM.

- Fri Aug 21, 2015 11:37 am #26708 Howdy guys, am making progress and thanks for the posts. My latest puzzle that I am not yet getting my head around works as follows.

I have an assumption (which VERY well may not be true) that the ESP8266 has an onboard RAM of 64K and that (in my ESP12 case) I have flash of 512K.

When I compile C to object files and then link them together, we provide some linker instructions in the form of files found in the Espressif SDK directory called "<SDK>/ld"

These files have names like "eagle.app.v6.ld".

Here is where I start to get fuzzy.

When I look in the file I see the following at the start

Code: Select allMEMORY
{
  dport0_0_seg :                        org = 0x3FF00000, len = 0x10
  dram0_0_seg :                         org = 0x3FFE8000, len = 0x14000
  iram1_0_seg :                         org = 0x40100000, len = 0x8000
  irom0_0_seg :                         org = 0x40240000, len = 0x3C000
}

What I don't (at all) understand are the meanings of these and their lengths. I almost sense that dram0 and iram0 are RAM but the total would be 114K and the ROM (which I think maps to flash) is only 245K (which is not enough flash).

Obviously I'm going to continue to study, but if anyone has some high level pointers, that would be great.

Neil

Free ESP8266 book available for download here.

- Fri Aug 21, 2015 11:52 am #26711 The *.ld you are looking at are the old ones from Espressif. They were limiting the flash size to allow OTA, so removing configs location from flash and then splitting it in 2 areas for firmware updates.
You can also look at *.ld files from ArudinoIDE, you will see all the flavors according to flash sizes of the different boards, 512K, 1M, 2M, and 4M.