Hi there,
I'm working on altera cyclone V SoC equipped with a Dual Core Cortex-A9. It runs Linux socfpga 3.13. I'm trying to disable (and enable) the SCU at runtime, but I have a segmantation fault: unable to handle kernel paging requet at virtual address FFFEF1000.
I think that the conversion from virtual to physical address deny me to access a the SCU Control Register. Obviously, I cannot disable the MMU because I cannot flush caches.
Can anyone help me? How can I proceed?
Thanks in advance.
MI
I Pete,
From a cetrain point of view is what I want. I have to test some unexpected behaviour. Obviously, I'm testing it form a kernel module. In my opinion I should create a flat address at startup in order to allow the access to the SCU register also at runtime. What do you think ?
I'm not entirely sure what is failing - either the SCU isn't mapped at that address or it's throwing a permissions error (from Linux's point of view these two may look similar).
As Koumoto-san mentioned in his earlier post, if this a permissions issue then you'll need your secure boot code to enable access to the SCR (SCU Control Register) for "non-secure" software by setting the appropriate bits in the SAC (SCU Access Control) and the SNAC (SCU Non-secure Access Control) registers. If you don't do this then it doesn't matter what MMU mapping you set up, it's going to throw a bus error or slave error due a to a permissions failure.
Once you've done that then you'll need some form of mapping so that the non-secure kernel can see the physical address range for the PL310 control registers. A flat mapping at boot won't work - Linux will replace whatever you set up with its own page tables - so you'll need a run-time mapping when you load your kernel model (I'm a bit rusty on Linux kernel driver development, but look at the ioremap family of functions for a starting point on how to set up the mapping at runtime).
Note that the kinds of failures you are going to get are going to be very unpredictable - any cache fetch or evictions from the processors in your system will cause some form of desync. It wouldn't surprise me if you start getting kernel crashes very quickly unless you forcefully flush the caches of, and then sleep, the other CPUs in the system before disabling the SCU.
HTH, Pete