diff --git a/arch/arm/src/imx6/chip/imx_memorymap.h b/arch/arm/src/imx6/chip/imx_memorymap.h index f71eecb4327..38632b9a225 100644 --- a/arch/arm/src/imx6/chip/imx_memorymap.h +++ b/arch/arm/src/imx6/chip/imx_memorymap.h @@ -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) diff --git a/configs/sabre-6quad/README.txt b/configs/sabre-6quad/README.txt index c7d7fc57c7d..afd83b14a9d 100644 --- a/configs/sabre-6quad/README.txt +++ b/configs/sabre-6quad/README.txt @@ -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