ARMv6 support -- was: OMAP3530 - Beagleboard and I2C problems

[Olivier Houchard]

On Wed, Aug 11, 2010 at 08:12:23AM -0500, Mark Tinguely wrote:
> >The DB-88F6781 kernel won't rather build, as there are a couple of 
> >platform-specific bits missing (GPIO rework, PM etc.), but the common ARM 
> >code should apply to the above baseline and give you an idea what kind of 
> >changes and adaptations were introduced in order to get this working. It's 
> >an initial attempt, but working stable. The main areas are pmap / busdma 
> >rework for v6; in order to have a clear situation during development we 
> >have decided to cut off from the legacy v5 files (and come up with 
> >separate -v6 derivatives), although we could converge back to a single 
> >file approach if this proves better eventually.
> >
> >Rafal
> >  
> Rafal, I just quickly scrolled through the new ARMv6 pmap code.
> 
> I am biased in favor of branching the new ARMv6/ARMv7 to new files; they 
> are in many ways new breeds of processors. I also have a ARMv5 busdma 
> file with sync lists which I have been using here for a long time.
> 

Me too, sort of. The NetBSD way of doing things adds a lot of #ifdef, but it
avoids code duplication.


> ARMv7 also has features that is not found in ARMv6.
> 
> 1) using the (hardware/software) access flag, we do not have to emulate 
> an access fault clearing the access flag will generate a new fault 
> (section or page). The write emulation is still needed.
> 
> a) There are a few changes to the ARMv6 and ARMv7 faults. Note: when 
> the user page is read-only, so is the kernel mapping.
> 
> 2) Bit 11 of the fault status register denotes read or write fault. Do 
> not have to check the instruction in trap.c -- is implemented in Cortex A8.
> 
> 3) If we use the simple access mode (1 above) and remap TEX, we can get 
> rid of the pv_entry flag. Chunk pv_entrys (from i386/amd64 pmap) may 
> also help save space.
> 
> I think ARMv6 also supports the split TTB. One for kernel and one for 
> user. If we are willing to split the UVA/KVA to 2GB each it would 
> simplify KVA additions and uses smaller level one page tables.
> 
> We should be thinking SMP with the new code. The ARMv6/ARMv7 have 3 
> special internal registers. One can be for the thread pointer, one can 
> hold the percpu pointer, and one can be for the user. I have a ARMv5 and 
> ARMv6/7 version of switch that combines the backend of cpu_throw() and 
> cpu_switch(). On the ARMv6/7, it also maintains the special registers.
> 
> The OMAP 3530 has a nice hardware interrupt priority facility 
> (INTCPS_SIR_IRQ_ADDR).The priority can be calculated by the interrupt 
> priority number when registering the interrupt. The GPIO interrupts 
> would all have to be the same interrupt priority.
> 
> (not specific to ARMv6 or ARMv7, but implementing page cache mode 
> properties (similar to pat_mode in i386/amd64) is easy and makes mapping 
> the cache mode of the new page mapping easier).
> 
> Rafal, and Oliver: I am certain I have the Sheeva cache corruption 
> problem during cluster i/o identified and a fix.
> 

So what's going on ?

> It is exciting to see all this work on the ARM architecture.
> 

I'm quite excited by the armv6/v7 features, and finally supporting SMP.
Is your work available somewhere ? We should definitively create an armv6/v7
branch in P4 or svn.

Regards,

Olivier