From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 16:31:43 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 05145CA4 for ; Mon, 4 Mar 2013 16:31:43 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id C2C616FC for ; Mon, 4 Mar 2013 16:31:42 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r24GVeT3073171; Mon, 4 Mar 2013 16:31:40 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id znqtej69gvyumqdwyx9hqdcaxa; Mon, 04 Mar 2013 16:31:40 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <549B1B40-99E7-47D4-BA13-1F08507B7B58@bsdimp.com> Date: Mon, 4 Mar 2013 08:31:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9C4AD429-7134-4433-A713-5DFA12628AE9@freebsd.org> References: <549B1B40-99E7-47D4-BA13-1F08507B7B58@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Mar 2013 16:31:43 -0000 On Mar 3, 2013, at 6:39 PM, Warner Losh wrote: >=20 > On Mar 3, 2013, at 12:43 PM, Tim Kientzle wrote: >=20 >> 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. >=20 > 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=85 The MMU management I really know nothing about. If you do =85 ;-) >> ** 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.) >=20 > 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.... >=20 >> ** 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. >=20 > Can't we do this with compat field in the FDT? I have prototype code that does exactly this, but it needs a lot of cleanup before it can be committed. Tim