Date: Thu, 8 Oct 2009 11:13:55 -0500 (CDT) From: Mark Tinguely <tinguely@casselton.net> To: freebsd-arm@freebsd.org, gballet@gmail.com Subject: Re: Adding members to struct cpu_functions Message-ID: <200910081613.n98GDt7r053539@casselton.net> In-Reply-To: <fd183dc60910080718v73c66089w3341d8bfe0f14006@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I am continuing my effort to port FreeBSD to the BeagleBoard. I > reached the point where the system prompts for the root filesystem. I > am therefore cleaning up my code and will then post it to this list > for comments. I still have a few hacky fixups to remove before it > becomes readable :) Congratulations. > I know that Mark Tinguely, whose help has been precious in this > endeavor, has some patches ready for ARMv6 cache management, so I did > not focus on this. It is all untested. I am wondering to myself with small number of TBL on the OMAP, should we use the new ASID process identifier and not flush the TBLs or just flush them on context switch. > At the moment, I am using backward-compatibility for the TLB format. I > want to start using the ARMv6 TLB format. My current problem is that > most of the arch-dependent code uses macros that are defined to match > the pre-ARMv6 TLB format. There are several ways of fixing this, > including defining these macros depending on some symbol such as > _ARM_ARCH_* or CPU_ARM*. I am however no friend of heavy preprocessor > flagging. What if instead, cpu_functions was extended to include > fields like the prototype for TLB entries of each size? For example, > take this patch to the following excerpt from pmap_map_chunk in > sys/arm/arm/pmap.c: [deleted example] > Now, assuming people agree with this change, that would only be a > first step because all values for cpufuncs are defined in the same > file (cpufunc.c), which is guarded with as many CPU_ARMx defines as > there are cpu flavors. Is there a specific reason for all these > structures to be defined in a same file, instead of defining it in a > platform- or cpu-specific file and using the files.* to select the > appropriate cpufunc flavor in the build system? I have been pondering the current L1/L2 (in this context we mean Page Directory entries and Page Table entries, not cache levels) values for cache, protection, the C/B/TEX (and now the global, secure, and no execute) and masks for a while. Some of these values are variables and some are defines. It can be confusing to track down a value for a ARCH/board. ARM kernels are very specific for processor and board. IMO, we should be moving some of these settings into a processor [and board] directories/files and make them more consistant. I am not saying anything bad about NetBSD that originate these files nor the additions that have been made since, what I am saying is it would be nice to have a big reorganization; that takes time and therefore money. -- 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. --Mark Tinguely.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200910081613.n98GDt7r053539>