1 of 1 people found this helpful
If you see the UEFI Firmware Writer's Guide https://communities.intel.com/docs/DOC-22477 you’ll see that if you want to increase the speed you’ll need to follow the physical address range, this is located in table 12 page 24 “eSRAM, Memory Msg Port 5:R82h 512 KB, (Address=80000000h)” If you would like to change this range for another this must be done in the BIOS first.
Does this mean that there is something wrong with the Intel provided ESRAM driver in the BSP? Dealing with the mapping and physical addresses is the drivers job as far as I know.
I am following "Intel® Quark™ Software Developer's Manual for Linux" documentation that describes the esram driver. I am using "intel_qrk_esram_map_range()" function (BSP 1.0.1) that takes a virtual address range. I am not playing with the physical addresses.
I'm trying to do exactly the same thing as Ehsan. I've just posted a question on yet another related problem:
Well, maybe this means that I should upgrade the BSP...
But anyway, I don't understand you answer, JPMontero_Intel. Maybe I must think again...
Yet another thought...
Eshan, how exactly did you test the memory bandwidth? Please note that there is cache involved, 16kB, not much but anyway. To test what improvement is available with eSRAM you must overlay (in the kernel) and mmap to user space a considerably larger memory and design the test to generate as many cache misses as possible. And of course any final gain depends on the actual usage scenario.
But maybe I miss something... Comments welcome.
JPMontero_Intel, I'm trying to understand your message...
In the datasheet (Intel ® Quark™ SoC X1000 Datasheet, page 38) I can read:
"The SoC also features a 512 Kbyte on-die embedded SRAM (eSRAM) that can be
configured to overlay regions of DRAM to provide low latency access to critical portions
of system memory."
and later (page 127):
"The Host Bridge contains an interface to 512KB of on-chip, low latency, embedded
SRAM (eSRAM). The eSRAM memory may be used as either 128 x 4KB pages, or in
block mode as a single contiguous 512KB block page. The eSRAM pages may be
mapped anywhere in the physical address space as a DRAM overlay."
Both "per page" and "block" mode seem not to differ much...
The datasheet seems to say: "eSRAM is not available directly in physical address, but can be configured to overlay (steal) some physical addresses of DRAM (either a 512kB block or chosen 4kB pages)". And it seems to offer performance gain.
Could you elaborate a little more and point me to some relevant part of the datasheet and/or "Intel ® Quark™ SoC X1000 UEFI Firmware Writer’s Guide" to get a better understanding?
I wrote a kernel module that allocates some memory and maps it to the ESRAM. "stats" interface shows that the mapping is done. It then copies two arrays inside that region. I could get only 20% speedup but the documentation says 3x speedup is expected.
It was a while ago but I think I tried to use the whole ESRAM to avoid cache effects.
I have tried mmap also (wrote a module that provides a file interface). It made my user code a bit slower!
Ehsan, my measurements are summarized here:
I think I observe similar behaviour as you did. Weird. I'm still trying to finish this investigation and reach some results/understanding. But this is done on a very background and mostly starving thread...
Ehsan, Intel Collegues,
I've ended up with measurements which are consistent and allow up to 40% perfomence gain using eSRAM from user space (an upper limit not reachable in real life scenarios in my opinion). Please see:
So this is "kind of" solved for me. Kind of because I'd like to understand the unexpected "features" I observe...