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

Update comments and README file

Browse Source
This commit is contained in:
Gregory Nutt 2016-11-26 16:02:37 -06:00
parent ba2436bdb7
commit 8dc79bb7ef
2 changed files with 40 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
arch/arm/src/imx6/chip/imx_memorymap.h
View File

@ -122,6 +122,18 @@
#define IMX_MMDCDDR_PSECTION 0x10000000 /* 10000000-ffffffff 3840 MB MMDC-DDR Controller */
/* 10000000-7fffffff 1792 MB */
/* By default, NuttX uses a 1-1 memory mapping. So the unused, reserved
* address in the top-level memory map are candidates for other mapping uses:
*
* 00018000-000fffff Reserved -- Not used
* 00400000-007fffff Reserved -- Used as the virtual address an inter-CPU,
* un-cached memory region in SMP
* configurations
* 00d00000-00ffffff Reserved -- Not used
* 0220c000-023fffff Reserved -- Not used
* 80000000-efffffff Reserved -- Level 2 page table (See below)
*/
/* i.MX6 DMA PSECTION Offsets */
#define IMX_CAAMRAM_OFFSET 0x00000000 /* 00000000-00003fff 16 KB CAAM (16K secure RAM) */
@ -973,13 +985,13 @@
*/
# ifdef CONFIG_SMP
/* Paging L2 page table offset/size */
/* Paging L2 page table offset/size */
# define PGTABLE_L2_OFFSET 0x000002000
# define PGTABLE_L2_SIZE 0x000001800
# else
/* Paging L2 page table offset/size */
/* Paging L2 page table offset/size */
# define PGTABLE_L2_OFFSET 0x000002000
# define PGTABLE_L2_SIZE 0x000001c00
@ -1007,12 +1019,12 @@
# define INTERCPU_L2_OFFSET (PGTABLE_L2_OFFSET + PGTABLE_L2_SIZE)
# define INTERCPU_L2_SIZE (0x00000400)
/* on-cached inter-processor communication page table base addresses */
/* Non-cached inter-processor communication page table base addresses */
# define INTERCPU_L2_PBASE (PGTABLE_BASE_PADDR + INTERCPU_L2_OFFSET)
# define INTERCPU_L2_VBASE (PGTABLE_BASE_VADDR + INTERCPU_L2_OFFSET)
/* on-cached inter-processor communication end addresses */
/* Non-cached inter-processor communication end addresses */
# define INTERCPU_L2_END_PADDR (INTERCPU_L2_PBASE + INTERCPU_L2_SIZE)
# define INTERCPU_L2_END_VADDR (INTERCPU_L2_VBASE + INTERCPU_L2_SIZE)

31
configs/sabre-6quad/README.txt
View File

@ -101,6 +101,14 @@ Status
+if (up_cpu_index() == 0) return 17; // REMOVE ME
2016-11-26: With regard to SMP, the major issue is cache coherency. I added
some special build logic to move spinlock data into the separate, non-
cached section. That gives an improvement in performance but there are
still hangs. These, I have determined are to other kinds of cache
coherency problems. Semaphores, message queues, etc. basically all
shared data must be made coherent. I am not sure how to do that. See
the SMP sectin below for more information.
Platform Features
=================
@ -492,12 +500,13 @@ Open Issues:
1. Currently all device interrupts are handled on CPU0 only. Critical sections will
attempt to disable interrupts but will now disable interrupts only on the current
CPU (which may not be CPU0). There is a spinlock to prohibit entrance into these critical sections in interrupt handlers of other CPUs.
CPU (which may not be CPU0). There is a spinlock to prohibit entrance into these
critical sections in interrupt handlers of other CPUs.
When the critical section is used to lock a resource that is also used by
interupt handling, the interrupt handling logic must also take the spinlock.
This will cause the interrupt handlers on other CPUs to spin until
leave_critical_section() is called. More verification is needed, however.
leave_critical_section() is called. More verification is needed.
2. Cache Concurency. This is a complex problem. There is logic in place now to
clean CPU0 D-cache before starting a new CPU and for invalidating the D-Cache
@ -536,7 +545,10 @@ Open Issues:
Another alternative would be to place all spinlocks in a non-cachable memory
region. That is problem what will have to be done.
This is a VERIFIED PROBLEM: I have seen cases where CPU0 sets a spinlock=1 then
This is a VERIFIED PROBLEM: Cache inconsistencies appear to be the root
cause of all current SMP issues.
I have seen cases where CPU0 sets a spinlock=1 then
tries to lock the spinlock. CPU0 will wait in this case until CPU1 unlocks the
spinlock. Most of this happens correctly; I can see that CPU1 does set the
spinlock=0, but CPU0 never sees the change and spins forever. That is surely
@ -546,14 +558,20 @@ Open Issues:
spinlock "g_cpu_paused[cpu]". CPU1 correctly sets g_cpu_paused[cpu] to zero
but CPU0 never sees the change.
3. Caching probabaly interferes with spinlocks as they are currently implemented.
Caching probably interferes with spinlocks as they are currently implemented.
Waiting on a cached copy of the spinlock may result in a hang or a failure to
wait.
Should all spinlocks go into a special "strongly ordered" memory region?
Update: Cache inconsistencies seem to be the root cause of all current SMP
issues.
No... that is not sufficient:
2016-11-26: With regard to SMP, the major issue is cache coherency. I added
some special build logic to move spinlock data into the separate, non-
cached section. That gives an improvement in performance but there are
still hangs. These, I have determined are to other kinds of cache
coherency problems. Semaphores, message queues, etc. basically all
shared data must be made coherent. I am not sure how to do that.
Configurations
==============
@ -644,7 +662,6 @@ Configuration sub-directories
Device Drivers: CONFIG_RAMLOG
smp
---
This is a configuration of testing the SMP configuration. It is