kondaveetiarungopal wrote: ↑
Mon Oct 08, 2018 7:38 am
iam working on tft lcd interfacing to spi controller.so here communication is spi.
so here iam using DMA communication for spi transfer.so during transfer of DMA i need to transfer data to directly to ram.
not sync with the caches.every time i need to write the fresh data to ram.instead of flushing l2 cache.
SPI display support is fairly standard. Unless you have some very good reasons not to, then work with the kernel frameworks rather than inventing your own.
A cache flush is generally more efficient as it will be doing big writes to memory instead of many small and inefficient ones.
It is possible to map memory into userspace bypassing the cache, but the real uses cases are fairly rare.
kondaveetiarungopal wrote:2)During Boot time why we need to disable the l2cache?is there any particular reason for disabling that one.
If you are referencing the config.txt / "vcgencmd get_config int" option of "disable_l2cache" then it's not doing what you are thinking it does.
https://www.raspberrypi.org/documentati ... /memory.md
Setting this to 1 disables the CPU's access to the GPU's L2 cache, and requires a corresponding L2 disabled kernel. Default value is 0.
(Minor correction needed on that - the default on a Pi 2 (BCM2836) or 3 (BCM2837) is 1, whilst on Pi 0/1 (BCM2835) is 0.)
Note that that is the GPU's L2 cache. On 2836/7 the ARMs have their own L2 cache, therefore there is a performance hit by feeding all the ARM accesses through the GPUs L2 cache as well (it'll evict stuff that the GPU wants).
kondaveetiarungopal wrote:3)is there any possibility to boot a kernel image from 2nd cpu instead of first cpu.
Many things are possible, but often the thought processes behind that desire are erroneous.
Why try to move the kernel rather than isolate the 2nd (or 3rd or 4th) cpu for your purposes?
It's a chicken and egg situation - you'd normally specify this on the Linux command-line, so which CPU has done the parsing of the command line to find that you want to reserve the 1st core? If anything has set up interrupt routines then those have to be moved too.
allows you to remove a CPU from the scheduler, and you can then manually schedule your processes to those isolated cores.
Alternatively if you look in the device tree setup for BCM2836
then you can knock out complete CPUs. However if you've done that then nothing can run on it as AIUI the MMU is common between all ARM CPU cores. A CPU with no memory is of limited use.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.