Date: Thu, 31 Mar 2011 16:23:44 -0500 From: Mark Tinguely <marktinguely@gmail.com> To: Ben Gray <ben.r.gray@gmail.com> Cc: freebsd-arm@freebsd.org Subject: Re: Beagleboard stuff Message-ID: <4D94F0E0.9050805@gmail.com> In-Reply-To: <4D94A964.1050000@gmail.com> References: <E1Q4X5B-000J64-DJ@groundzero.grondar.org> <20110329150903.GA4069@ci0.org> <7519F558-CEA3-41A9-8AA6-5A3234C4F1A8@gmail.com> <1301451934.2217.19.camel@nsl> <4D92EE2D.8000107@gmail.com> <4D947EF5.90108@gmail.com> <9BD97855-B47E-4CF0-8DC5-29F1F4A8EA27@gmail.com> <4D94A418.9070608@gmail.com> <4D94A964.1050000@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/31/2011 11:18 AM, Ben Gray wrote: > Hi Mark, > > I don't think the OMAP4430 techref manual is available on the TI > website, however you can get it via the Pandaboard site: > > <http://www.pandaboard.org/content/resources/omap-device>; > > In terms of cache coherency - the OMAP4430 has separate L1 caches > (32KB inst/32KB data) for each core with a snoop control unit (ARM > SCU?) which "ensures memory coherency between the two CPUs". > > > In regards to the ARMv6/v7 roadmap, have you started work on this? > I would love to see some of these changes in the tree and can help out > in some areas, however if you look at the hacks in my pmap.c code for > armv7 you'll notice that I'm not very experienced in this area of the > kernel ;-). > > > Thanks, > Ben. The SCU does snoop the internal processors' cache but the external processors (DMA) do not snoop the cache, so certain pre and post DMA commands still need to flush and/or invalidate the internal caches. Since the caches could still be active on any processor (because the process is on multiple processors or because the process recently switched processors), we have to perform the needed pre/post DMA cache operation on every processor. Without the multiprocessing extensions, this involves sending a message (IPI) from the current processor to all other processors telling them to perform necessary cache operation. Multiprocessor extensions performs the cache operations on the remote processors without sending a IPI. I have started to rewrite the easiest parts of the low level code. See the "toc.txt" file on my website. These rewrites use instructions (ldrex, strex, clrex, isb, dsb, etc) that the current compiler and binutils do not understand. A new binutils can be easily dropped into the source tree. We need a new compiler that can understand these instructions and also be able to generate VFP/Neon user instructions. I have been using a hacked up compiler to make kernels but it won't compile world and it is starting to become inadequate for kernels also. I have studied the i386 and amd64 low level routines to see what we could use and what we can't use. Right now, I do not have the financial resources to finish a rewrite the low level code. --Mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D94F0E0.9050805>