Hi all,
If someone has already solved the same issue, please let me know.
First, ENGcm11413 is described in IMX53CE.pdf.
Now, I am using the tool chain provided by freescale.
In the Errata, The vld code is executed in memcpy() of glibc contained in the tool chain.
It occurrs CPU exception in user application. (After it static link with glibc, it is investigated by gdb.)
The address accessed using memcpy() is the SRAM area connected to EIM.
From user application, via /dev/mem, the applicable address was mapped by mmap() and accessed.
The /dev/mem driver is using pgprot_noncached as Strong Order to the page, and it is the same as Errata and occurrs the CPU exception.
Next, workaround indicated in Linux BSP Release Note has the following description.
A. Change pgprot_noncached() to pgprot_writecombine().
B. Just before reading from Source Address Area , Execute dsb code.
(Please refer to an attached file)
mmap_mem() in /dev/mem driver (drivers/char/mem.c) can be changed about A.
But about B, the target address area is mmap() with user application, and in /dev/mem driver, "just before reading", it is unknown.
Therefore, dsb is not executed in /dev/mem driver.
Just before calling memcpy() in user application as follows, how to execute dsb code was imagined.
#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
<snip>
fd = open("/dev/mem", O_RDWR);
p = (void*)mmap(NULL, <SRAM_SIZE>, PROT_READ|PROT_WRITE, MAP_SHARED, fd, <SRAM_ADDRESS> );
dsb();
memcpy( <BUFFER>, p, <COPY_SIZE> );
Like this, is the way of executing dsb code from user application correct?
First of all, is dsb code execution necessary?
My software requirement is as follows :
kernel -> v2.6.35.3 11.01.00 for i.MX53 QSB (provided from Freescale)
toolchain -> gcc-4.4.4-glibc-2.11.1-multilib-1.0 (contained in LTIB in Linux BSP provided from Freescale)
Best Regards,
George
