Date: Wed, 11 Aug 2010 16:16:19 +0200 From: Olivier Houchard <mlfbsd@ci0.org> To: Mark Tinguely <marktinguely@gmail.com> Cc: "freebsd-arm@FreeBSD.org" <freebsd-arm@freebsd.org> Subject: Re: ARMv6 support -- was: OMAP3530 - Beagleboard and I2C problems Message-ID: <20100811141619.GA2927@ci0.org> In-Reply-To: <4C62A1B7.5050601@gmail.com> References: <4C607639.9050506@gmail.com> <20100810090533.GA56784@ci0.org> <82A49B7C-23F2-400C-B726-2FF13FD6D282@semihalf.com> <4C62A1B7.5050601@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100811141619.GA2927>