From owner-freebsd-arm@FreeBSD.ORG Thu Mar 31 21:23:51 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51D2E1065670 for ; Thu, 31 Mar 2011 21:23:51 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 019888FC0A for ; Thu, 31 Mar 2011 21:23:50 +0000 (UTC) Received: by yxl31 with SMTP id 31so1345412yxl.13 for ; Thu, 31 Mar 2011 14:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1REPll+tm4QCH/pYbCIwtttECHT50VZxwCObIKR9WnI=; b=jOu3djN8cCHQdUIqmX6SYeFzD2rhoEk6/nlOOgxLarzxGMyKE2Jta96g0gG9JFfyiV Y4ZRzKlLVOp3yycVxKmRfEpLWV+n9+dBhmyqf4TiLIW7VxfvpGXkozBXM96BD+hu7EdT aDbI/itmRI5i6lXNj0eltjTSWZpkXH/zzU/Gg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=xS5ttLCQIZXvM9Hd2KYv1tjvLuCTMrNadTikCKR2wKiLYifUrivY8iDZ5xJbwxuube Gs+ft4bAf4UqKAN1e6xh1XA7JARf3iobCpGwvFviNxUcKXaObRC2Gon8ZUaf+cBN37OB +ZD3Diy3L1IjZLF+LaTXrRZ6XUwFgxwk25USU= Received: by 10.236.152.4 with SMTP id c4mr628142yhk.283.1301606629940; Thu, 31 Mar 2011 14:23:49 -0700 (PDT) Received: from [192.168.1.100] (c-24-245-26-12.hsd1.mn.comcast.net [24.245.26.12]) by mx.google.com with ESMTPS id z22sm769196yhc.30.2011.03.31.14.23.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2011 14:23:49 -0700 (PDT) Message-ID: <4D94F0E0.9050805@gmail.com> Date: Thu, 31 Mar 2011 16:23:44 -0500 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Ben Gray References: <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> In-Reply-To: <4D94A964.1050000@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Beagleboard stuff X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 21:23:51 -0000 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: > > > > 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.