Date: Mon, 12 Oct 2009 08:21:58 -0500 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Guillaume Ballet <gballet@gmail.com> Cc: Mark Tinguely <tinguely@casselton.net>, freebsd-arm@freebsd.org, Stanislav Sedov <stas@deglitch.com> Subject: Re: Adding members to struct cpu_functions Message-ID: <4AD32D76.3090401@freebsd.org> In-Reply-To: <fd183dc60910120529h5c741449rc8ad20b29fecd2ba@mail.gmail.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <fd183dc60910120529h5c741449rc8ad20b29fecd2ba@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Guillaume Ballet wrote: > On Mon, Oct 12, 2009 at 1:36 PM, Stanislav Sedov <stas@deglitch.com> wrote: > >> On Mon, 12 Oct 2009 13:15:41 +0200 >> Rafal Jaworowski <raj@semihalf.com> mentioned: >> >> >>> On 2009-10-08, at 18:13, Mark Tinguely wrote: >>> >>> >>>> -- on a tangent about the future -- >>>> 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. We 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_<myarch>.c? That would be a good way to start that > reorganization Mark has been talking about in his email. > One thing that might be worth looking at while thinking about this is how this is done on PowerPC. We have run-time selectable PMAP modules using KOBJ to handle CPUs with different MMU designs, as well as a platform module scheme, again using KOBJ, to pick the appropriate PMAP for the board as well as determine the physical memory layout and such things. One of the nice things about the approach is that it is easy to subclass if you have a new, marginally different, design, and it avoids #ifdef hell as well as letting you build a GENERIC kernel with support for multiple MMU designs and board types (the last less of a concern on ARM, though). -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AD32D76.3090401>