Date: Wed, 11 Aug 2010 08:12:23 -0500 From: Mark Tinguely <marktinguely@gmail.com> To: Rafal Jaworowski <raj@semihalf.com> Cc: "freebsd-arm@FreeBSD.org" <freebsd-arm@freebsd.org> Subject: Re: ARMv6 support -- was: OMAP3530 - Beagleboard and I2C problems Message-ID: <4C62A1B7.5050601@gmail.com> In-Reply-To: <82A49B7C-23F2-400C-B726-2FF13FD6D282@semihalf.com> References: <4C607639.9050506@gmail.com> <20100810090533.GA56784@ci0.org> <82A49B7C-23F2-400C-B726-2FF13FD6D282@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Rafal Jaworowski wrote: > On 2010-08-10, at 11:05, Olivier Houchard wrote: > >> On Mon, Aug 09, 2010 at 10:42:17PM +0100, Ben Gray wrote: >>> I've been working on a port of FreeBSD to Texas Instruments OMAP3530 >>> for a while now. I have the basic drivers, Clocks, MMC, DMA, GPIO's, >>> etc. The kernel is coming up, however it crashes with a seg fault when >>> starting the init process, this is probably caused by the hacks I had to >>> put in the pmap code to get it to work with ARMv7 MMU's, but that's an >>> email for another day. >>> >> That's great to hear ! >> How hackish is your work ? There's an ongoing work to support armv6/armv7, so >> maybe it's best to avoid duplicating efforts ? >> > > Olivier, > As we spoke, I've put a diff of our ARMv6 work to freefall, see: http://people.freebsd.org/~raj/patches/arm/dove_v6.diff > > This is against HEAD 2009.08.03, and is part of support for the following hardware: > - CPU core: Marvell Sheeva2 (88SV581x), ARMv6 > - SOC: 88F6781 (Armada 500 alias Dove) > > 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. 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. It is exciting to see all this work on the ARM architecture. --Mark Tinguely
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C62A1B7.5050601>