Date: Sun, 3 Mar 2013 19:39:40 -0700 From: Warner Losh <imp@bsdimp.com> To: Tim Kientzle <kientzle@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: GENERIC kernel issues Message-ID: <549B1B40-99E7-47D4-BA13-1F08507B7B58@bsdimp.com> In-Reply-To: <DF7B73D4-BE50-4E75-8D5B-FE19A4764F31@freebsd.org> References: <DF7B73D4-BE50-4E75-8D5B-FE19A4764F31@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 3, 2013, at 12:43 PM, Tim Kientzle wrote: > I spent some time yesterday putting together a kernel > configuration for a GENERIC ARM kernel that would > support both RaspberryPi and BeagleBone. >=20 > Just to see how far I could get. >=20 > Here's a list of the problems I've found so far: >=20 > ** Multiple MMU support. If you put these two lines into an > ARM kernel config, the build will fail in the MMU code: >=20 > cpu CPU_ARM1176 > cpu CPU_CORTEXA >=20 > Basically, this turns on the support for multiple MMUs but the > ARMv6/ARMv7 MMU definitions don't play nicely with run-time > MMU selection. Having looked at the defines, it could be done with variables, but I = fear that will slow things down to do a simple #define -> variable. We = may need two sets of code for performance... > ** PHYSADDR/KERNPHYSADDR hardwiring. Ian has made a > lot of progress and I'm working on some related changes to > address this. I think we understand how to eliminate these > constants and replace them with run-time detection of the > load address. I'm still not sure what changes might be needed > to the loader to make this work. >=20 > ** PIPT vs. VIVT cache management. This is currently set at compile > time; we'll need to have a way to set this at run time based on the > CPU. (I have some skeletal code to select CPU at the top of > initarm by inspecting the FDT. I presume this switch will be routine > once a robust version of that is in place.) Generally we should be doing this, both for the Core and the SoC. I = don't think we do this generally, and we should. It is one of the big = advantages of FDT: It tells you what's going on so you don't have to = guess.... > ** TI processor detection. This is currently hardwired at build = time, > so we cannot currently build a kernel that supports both AM335x > and OMAP4, for example. Can't we do this with compat field in the FDT? > Question: should we create a /projects/arm-generic/ branch > to hold this work while it's in flux? Works for me. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?549B1B40-99E7-47D4-BA13-1F08507B7B58>