sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update TODO and sabre-6quad/README.txt regarding SMP

Browse Source 
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
This commit is contained in:
Masayuki Ishikawa 2020-11-14 18:41:28 +09:00 committed by Xiang Xiao
parent a20463642e
commit 064451b4ee
2 changed files with 1 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
TODO
View File

@ -448,34 +448,6 @@ o Task/Scheduler (sched/)
o SMP
^^^
Title: SMP AND DATA CACHES
Description: When spinlocks, semaphores, etc. are used in an SMP system with
a data cache, then there may be problems with cache coherency
in some CPU architectures: When one CPU modifies the shared
object, the changes may not be visible to another CPU if it
does not share the data cache. That would cause failure in
the IPC logic.
Flushing the D-cache on writes and invalidating before a read is
not really an option. That would essentially effect every memory
access and there may be side-effects due to cache line sizes
and alignment.
For the same reason a separate, non-cacheable memory region is
not an option. Essentially all data would have to go in the
non-cached region and you would have no benefit from the data
cache.
On ARM Cortex-A, each CPU has a separate data cache. However,
the MPCore's Snoop Controller Unit supports coherency among
the different caches. The SCU is enabled by the SCU control
register and each CPU participates in the SMP coherency by
setting the ACTLR_SMP bit in the auxiliary control register
(ACTLR).
Status: Closed
Priority: High on platforms that may have the issue.
Title: MISUSE OF sched_lock() IN SMP MODE
Description: The OS API sched_lock() disables pre-emption and locks a
task in place. In the single CPU case, it is also often

53
boards/arm/imx6/sabre-6quad/README.txt
View File

@ -691,58 +691,7 @@ Open Issues:
This will cause the interrupt handlers on other CPUs to spin until
leave_critical_section() is called. More verification is needed.
2. Cache Concurrency. Cache coherency in SMP configurations is managed by the
MPCore snoop control unit (SCU). But I don't think I have the set up
correctly yet.
Currently cache inconsistencies appear to be the root cause of all current SMP
issues. SMP works as expected if the caches are disabled, but otherwise there
are problems (usually hangs):
This will disable the caches:
diff --git a/arch/arm/src/armv7-a/arm_head.S b/arch/arm/src/armv7-a/arm_head.S
index 27c2a5b..2a6274c 100644
--- a/arch/arm/src/armv7-a/arm_head.S
+++ b/arch/arm/src/armv7-a/arm_head.S
@@ -454,6 +454,7 @@ __start:
* after SMP cache coherency has been setup.
*/
+#if 0 // REMOVE ME
#if !defined(CPU_DCACHE_DISABLE) && !defined(CONFIG_SMP)
/* Dcache enable
*
@@ -471,6 +472,7 @@ __start:
orr r0, r0, #(SCTLR_I)
#endif
+#endif // REMOVE ME
#ifdef CPU_ALIGNMENT_TRAP
/* Alignment abort enable
diff --git a/arch/arm/src/armv7-a/arm_scu.c b/arch/arm/src/armv7-a/arm_scu.c
index eedf179..1db2092 100644
--- a/arch/arm/src/armv7-a/arm_scu.c
+++ b/arch/arm/src/armv7-a/arm_scu.c
@@ -156,6 +156,7 @@ static inline void arm_set_actlr(uint32_t actlr)
void arm_enable_smp(int cpu)
{
+#if 0 // REMOVE ME
uint32_t regval;
/* Handle actions unique to CPU0 which comes up first */
@@ -222,6 +223,7 @@ void arm_enable_smp(int cpu)
regval = arm_get_sctlr();
regval |= SCTLR_C;
arm_set_sctlr(regval);
+#endif // REMOVE ME
}
#endif
3. Recent redesigns to SMP of another ARMv7-M platform have made changes to the OS
2. Recent redesigns to SMP of another ARMv7-M platform have made changes to the OS
SMP support. There are no known problem but the changes have not been verified
fully (see STATUS above for 2019-02-06).