Sorry for the delay -- I've been extremely busy lately.
On Thu, 13 Dec 2012, Leo Yan wrote:
On 12/11/2012 07:10 PM, Leo Yan wrote:
On 12/11/2012 08:47 AM, Leo Yan wrote:
Yes, i have used tc2_pm_api's patches. But here may have one difference is i have not directly used your branch, instead i migrate your patches into my own kernel.
Please use the kernel I'm suggesting you to try first. It has been tested and is known to work.
I'd suggest you start from the following repository at this point:
http://git.linaro.org/gitweb?p=landing-teams/working/arm/kernel.git%3Ba=shor...
That's where the latest patches are currently located.
Here have some things want to confirm:
- now i use the boot-wrapper is:
http://git.linaro.org/git-ro/arm/models/boot-wrapper.git; because in bootwrapper there have some stuffs related with trustzone related registers, so the boot-wapper's setting is enough for non-secure world, right?
I can't tell about non secure world. I've always tested RTSM with the kernel running in secure world via a simplistic boot wrapper.
I know that Tixy did test the boot wrapper from that repository above so he might be able to help.
It is still lacking an important patch though. This patch can be found here:
http://article.gmane.org/gmane.linux.linaro.devel/14457
- When we use the DCSCB to release the core, do we need to invalidate
I$/D$/TLB or not? For CA9, we need do that, but for CA7/CA15, we can skip all these operations, right?
The generic kernel code already takes care of invalidating those upon entry in the kernel.
- When we launch the fast model, do we need enable the cluster's
configuration for l1_dcache-state_modelled/l1_icache-state_modelled/l2_cache-state_modelled,
because i saw the spec in Cortex_A15_A7_RTSM_UG.pdf, these configurations are related with memory attribute with TLB, but i have not enabled them yet.
It is always a good idea to enable those to validate the code for correctness. But things should just work without those options nevertheless.
- I saw the code in dcscb.c, before the core run into "wfi", it will
flush the l1 cache twice, the code likes below: flush_cache_louis(); -> cpu_proc_fin(); -> flush_cache_louis(); -> clear SMP bit; -> wfi(); so there have some special reason need flush the cache twice? it's caused by fast model?
Here's the comment right before that code:
/* * Flush all cache levels for this cluster. * * A15/A7 can hit in the cache with SCTLR.C=0, so we don't need * a preliminary flush here for those CPUs. At least, that's * the theory -- without the extra flush, Linux explodes on * RTSM (maybe not needed anymore, to be investigated). */
hi Nico,
Today i also get one VE TC2 board to try your kernel image. With your kernel image, it can only boot up one core (the first CA15 core); i reviewed the code, tc2_pm_api branch have changed to use SPC's bxadd register.
so i just wander i need update the boot monitor; could u kindly tell me there have some modification for the boot sequence? Can i get the code for the updated sequence (such as the boot monitor)?
You do need a new set of firmware files for TC2 to work with this code. Unfortunately, it has not been officially released by ARM yet, although they should release it soon.
hi Nico,
I used the modeldebugger to dig into the code for the core's power off, and found some issues in the code.
In the ARM spec, it recommend the flow for core's suspend should look like below:
- clear SCTLR.C bit;
- flush l1 cache;
- clear ACTLR.SMP bit;
- dsb;
- wfi;
But in dcscb.c or tc2_pm.c files, when the core what to run into LPM, we use the function *flush_cache_louis()* to flush L1 cache. But in this function it will NOT only flush l1 cache by set/way, but also it will invalidate I cache with below command: mcr p15, 0, r0, c7, c1, 0; From my experiment result, i believe this sentence will introduce unexpected behavior so that later instructions cannot execute properly. so i manually re-write the flush l1 cache flow for core's power off (almostly same with *flush_cache_louis()*, except remove invalidate I cache instruction), then i saw it's much more stable.
Could you describe what you mean by "more stable" ?
Nicolas