- Thu Dec 31, 2015 8:50 am
#37553
Long posts with lots of questions, and once again I'm at work, so I'll try and give a quick answer to what I easily can.
Esptool2 (or the sdk equivalent tools) extract elf sections from a fully linked executable binary compiled for the xtensa core in the esp8266 and packages them into a format suitable for use on the device. The built in loader reads a header from the flash (first part of the image created by esptool2/other, which sets a number of options such as the flash size and mode, then loads the ram sections from from the flash to ram. Section lengths, ram positions and the program entry point are also in the header. The rom boot loader never touches the irom section. It then starts to run code from the ram section at the specified entry point. This will normally be SDK code. The SDK is then responsible for setting up the memory mapping (not the boot loader), after which the bulk of the sdk and user code is run from there.
The memory mapping works by mapping a 1mb chunk of flash to 0x40200000. So if your irom section is stored on flash from 0x10000 onwards (for example), it will be accessible at memory address 0x40210000. So the linker script needs to have this address specified as the base base address for this section, so that the code it creates will correctly work at this address once running on the device. Where you put this section in flash/mapped memory so doesn't matter so long as they match up (except at the very start where the header needs to be, and the very end where the sdk will write it's stored config).
rBoot is compiled and linked like any other app, because that's exactly what it is, it just does something a bit different and doesn't include any sdk code. It is made into a normal rom and flashed to the device in the normal way at 0x00000 (normal for a standard non-bootloaded app, the only type the rom bootloader can handle), but it has no irom section. Its ram sections are copied to ram where it is executed. It then copies a second stage loader to a spare area of memory, transfers execution to that code, which loads up the user app into the normal memory area (overwriting it's own main code), then jumps to the apps entry point. End result is indistinguishable from an app loaded by the rom bootloader, it was just achieved differently (i.e. we did it ourselves), which means we can do more things like choose from multiple roms to load, etc.
Esptool2 (or the sdk equivalent tools) extract elf sections from a fully linked executable binary compiled for the xtensa core in the esp8266 and packages them into a format suitable for use on the device. The built in loader reads a header from the flash (first part of the image created by esptool2/other, which sets a number of options such as the flash size and mode, then loads the ram sections from from the flash to ram. Section lengths, ram positions and the program entry point are also in the header. The rom boot loader never touches the irom section. It then starts to run code from the ram section at the specified entry point. This will normally be SDK code. The SDK is then responsible for setting up the memory mapping (not the boot loader), after which the bulk of the sdk and user code is run from there.
The memory mapping works by mapping a 1mb chunk of flash to 0x40200000. So if your irom section is stored on flash from 0x10000 onwards (for example), it will be accessible at memory address 0x40210000. So the linker script needs to have this address specified as the base base address for this section, so that the code it creates will correctly work at this address once running on the device. Where you put this section in flash/mapped memory so doesn't matter so long as they match up (except at the very start where the header needs to be, and the very end where the sdk will write it's stored config).
rBoot is compiled and linked like any other app, because that's exactly what it is, it just does something a bit different and doesn't include any sdk code. It is made into a normal rom and flashed to the device in the normal way at 0x00000 (normal for a standard non-bootloaded app, the only type the rom bootloader can handle), but it has no irom section. Its ram sections are copied to ram where it is executed. It then copies a second stage loader to a spare area of memory, transfers execution to that code, which loads up the user app into the normal memory area (overwriting it's own main code), then jumps to the apps entry point. End result is indistinguishable from an app loaded by the rom bootloader, it was just achieved differently (i.e. we did it ourselves), which means we can do more things like choose from multiple roms to load, etc.
