Memory Layout

Post links and attach files for documentation here, also chat about these docs freely
 Reply

User avatar

Re: Memory Layout

By hexentropy
- Wed Sep 03, 2014 1:40 pm #145
1) Serial flash can't be memory mapped, only parallel flash can.


I've seen memory-mapped SPI flashes before. To do so requires:

- a CPU that supports waiting on bus transactions
- a memory-mapper that translates bus-reads into SPI-flash fetches

Specifically, certain realtek chipsets do this for non performance-sensitive code. That said, I have no idea if the ESP8266 does this.

I think the best reference is the linker script from the SDK. The linker script shows .text going into "iram" and .data into ".dram", which leads to an interpretation favouring what "obvy" initially said: that 'iram' and 'dram' are both SRAM blocks mapped into a 32bit memory space with 32k of IRAM and 80k of DRAM. There isn't anything that shows code going into a mapped external flash (at least not in the linker script in the SDK).
User avatar

Re: Memory Layout

By obvy
- Wed Sep 03, 2014 3:24 pm #149
There isn't anything that shows code going into a mapped external flash (at least not in the linker script in the SDK).


Well, linker script has:

Code: Select all.irom0.text ... >irom0_0_seg


And lot of stuff in SDK lib/ dir has code exactly in .irom0.text. But trying handful of symbols, I see that ones which are defined in lib/* are never in eagle.rom.addr.v6.ld , and vice versa. In other words, lib/* is not source for entire system image. Also note that:

Code: Select allirom0_0_seg :                         org = 0x40240000,


while symbols in eagle.rom.addr.v6.ld appear to start at ~0x40000000 (e.g. xthal_memcpy = 0x400006c4) and don't go above 0x40010000. So well, we don't have even all object files for complete system image and would need to extract it from an actual module.

Also note that 0x240000 (offset from "ROM" symbols at which .irom0.text starts) is 2.25MBytes, i.e. Flash ROM is pretty funkily (chunkily) memory-mapped, or those symbols are not in Flash after all.
User avatar

Re: Memory Layout

By Squonk
- Thu Sep 04, 2014 4:32 pm #193 OK, let's reconsider something about Flash memory access: first, the XTensa CPU seems to be clocked @ 80 MHz. It is fast, but nothing compared to more powerful WiSoC running at 400~800 MHz.

Then these Flash SPI chips can also run pretty fast... Not only do they support "simple" single bit wide SPI access, but also dual and quad bit wide access, at speed reaching 80~104 MHz!

I found something prety interesting in Winbond's W25Q16CV 16M-bit Serial Flash Memory datasheet general description:
The W25Q16CV (16M-bit) Serial Flash memory provides a storage solution for systems with limited
space, pins and power. The 25Q series offers flexibility and performance well beyond ordinary Serial
Flash devices. They are ideal for code shadowing to RAM, executing code directly from Dual/Quad SPI
(XIP) and storing voice, text and data. The device operates on a single 2.7V to 3.6V power supply with
current consumption as low as 4mA active and 1μA for power-down.


In quad bit mode, these chips thus provide a throughput of 416 Mb/s or 52 MB/s... I don't know much about the particular Xtensa CPU architecture, but CPU and memory speeds are close...

Maybe the SPI Flash chip is just "shadowed into RAM"? Whatever this means, my guess is that accessing some locations in the 32-bit memory space is mapped directly to an access to the corresponding address in Flash memory with little latency, or that Flash memory regions are cached into SRAM?

As the same pins that are used to access the SPI Flash chip can also be used for accessing an "SDIO 2.0"-compatible SD Card, let's look at the SDIO .20 spec too:
This specification defines two types of SDIO cards. The Full-Speed card supports SPI, 1-bit SD and the 4-bit SD
transfer modes at the full clock range of 0-25MHz. The Full-Speed SDIO cards have a data transfer rate of over
100 Mb/second (10 MB/Sec). A second version of the SDIO card is the Low-Speed SDIO card. This card
requires only the SPI and 1-bit SD transfer modes. 4-bit support is optional. In addition, Low-Speed SDIO cards
shall support a full clock range of 0-400 KHz.


So 10 MB/s seems to be the max here. However, depending on their speed class, SD Card can actually range from 2~30 MB/s, so slower than the SPI Flash chips in quad mode, but still not ridiculous compared to the CPU speed.

My point is that an application stored in the SPI Flash chip or on the SD Card may be cached into SRAM and execute from it, with the "shadow" mechanism.

This doesn't mean that everything is executed from there: it looks like there is indeed a 200KB ROM that contains the low-level functions (including bootstrap loader at least from UART) for which the linker definition file contains the entries, and this mask/write once ROM cannot be modified. In the "write once" case, this may explain why SPI Flash is not mandatory: the SoC may be self-contained, with all the code stored in write-once ROM.

Again, all the above are just guesses!
User avatar

Re: Memory Layout

By RichardS
- Thu Sep 04, 2014 5:47 pm #197 A little off topic, I wonder how fast the ESP8266 reads the SPI flash, what is the CLK freq basically on boot up?

Richard.
 Reply
Return to Documentation