From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 12:29:21 2009 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 6CD7E1065693 for ; Mon, 12 Oct 2009 12:29:21 +0000 (UTC) (envelope-from gballet@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id EC40B8FC14 for ; Mon, 12 Oct 2009 12:29:19 +0000 (UTC) Received: by ewy18 with SMTP id 18so2772271ewy.43 for ; Mon, 12 Oct 2009 05:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jWV1MN+d3mw9ZunglJwb4XUA4ls/mbUsXiVqYDaU3HU=; b=m1vw/m6oanKVzPNRZA/TvafTlaGzDga/wiigWkC7SIcfN6MvHhYIH+YWfReF+Dr2e6 Fe7wQyaonU4rDarJI0TO+/B0i+FBUPmFbDfNbkFRWacR4HYNfBnhzFADBGv4VG9/MtLi AV+sW6wEUBmcExd++C0kL2MrQkay4NeaWJhyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=L4xnzu5Rr0a8NWJeY0ieOjmYn6asJ8SOpWRQuhRmsKB2etTOjTCbGqIjDrWhAES8DM HVxgY+jjlSafCffGWwHbEaTmVMHAoMg3Bug2aYJx1yoHYJeN+d5dng8a4dpy4H5ATPtf yHC/FDndESJUGh6E00DWvRWGX/JorcvNVXuIc= MIME-Version: 1.0 Received: by 10.211.160.19 with SMTP id m19mr2713903ebo.50.1255350559040; Mon, 12 Oct 2009 05:29:19 -0700 (PDT) In-Reply-To: <20091012153628.9196951f.stas@deglitch.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> Date: Mon, 12 Oct 2009 14:29:19 +0200 Message-ID: From: Guillaume Ballet To: Stanislav Sedov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mark Tinguely , freebsd-arm@freebsd.org Subject: Re: Adding members to struct cpu_functions 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: Mon, 12 Oct 2009 12:29:21 -0000 On Mon, Oct 12, 2009 at 1:36 PM, Stanislav Sedov wrote: > On Mon, 12 Oct 2009 13:15:41 +0200 > Rafal Jaworowski mentioned: > >> >> On 2009-10-08, at 18:13, Mark Tinguely wrote: >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- on a tangent about the futu= re -- >> > Since the ARMv7 is coming to FreeBSD, there are other ARMv4/5 vrs >> > ARMv6/7 >> > questions, the most important is should we break the new ARM chips >> > with >> > their physical tagged caches to another subbranch or define it into >> > the >> > existing code? One example of the existing pmap code that does not >> > mesh >> > well with ARMv6/7 is the exisiting flush of the level 2 cache >> > because the >> > old archs have VIVT level 2 caches). ARMv6/7 level 2 caches are PIPT, >> > and would not be flushed until DMA time. A simple solution would be if >> > an arch needs to flush the level 2 cache when it flushes the level 1 >> > cache, then it should do so in the level 1 cache flushing routine. >> >> I was wondering whether a separate pmap module for ARMv6-7 would not >> be the best approach. After all v6-7 should be considered an entirely >> new architecture variation, and we would avoid the very likely #ifdefs >> hell in case of a single pmap.c. >> > > Yeah, I think that would be the best solution. =A0We could conditionally > select the right pmap.c file based on the target CPU selected (just > like we do for board variations for at91/marvell). > pmap.c is a very large file that seems to change very often. I fear having several versions is going to be difficult to maintain. Granted, I haven't read the whole file line after line. Yet it seems to me its content can be abstracted to rely on arch-specific functions that would be found in cpufuncs instead of hardcoded macros. Is there something fundamentally wrong with enhancing struct cpufunc in order to let the portmeisters decide what the MMU and caching bits should look like? This is a blocking issue for me, since it looks like the omap has some problem with backward compatibility mode. Without fixing up the TLBs in my initarm function, it doesn't work. Speaking of #ifdef hell, why not breaking cpufuncs.c into several cpufuncs_.c? That would be a good way to start that reorganization Mark has been talking about in his email. Guillaume