From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 03:31:50 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 7149B1B0; Sun, 3 Mar 2013 03:31:50 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id 26D7D152; Sun, 3 Mar 2013 03:31:49 +0000 (UTC) Received: from mxin1-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MJ200MKYF4SGQ00@smtp4.clear.net.nz>; Sun, 03 Mar 2013 16:31:41 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin1.paradise.net.nz with ESMTP; Sun, 03 Mar 2013 16:31:40 +1300 Date: Sun, 03 Mar 2013 16:31:39 +1300 From: Andrew Turner Subject: Re: About board-specific files.* In-reply-to: <58FF3A9F-2782-429F-BE82-27728E8D209D@bsdimp.com> To: Warner Losh Message-id: <20130303163139.3af41ae5@bender> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 8BIT References: <58FF3A9F-2782-429F-BE82-27728E8D209D@bsdimp.com> 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: Sun, 03 Mar 2013 03:31:50 -0000 On Sat, 2 Mar 2013 16:20:54 -0700 Warner Losh wrote: > > On Mar 2, 2013, at 2:05 PM, Tim Kientzle wrote: > > > Now that I think I understand some of the issues in building > > a GENERIC arm kernel, I'm starting to piece together > > a kernel that has both RPi and BBone bits that I can > > use as a testbed. > > > > Next Problem: A lot of the boards are using > > board-specific files.* to control what files get > > linked into the kernel. > > > > This seems like a real problem for a GENERIC kernel, > > so I propose merging them into sys/conf/files.arm. > > > > Here's how I'm doing it right now for my current > > experiments. If anyone has a better idea, I'm > > definitely interested. > > > > Basically, I'm using "device bcm2835" to represent > > all of the basic support for that particular SoC. > > (An SoC is, after all, just another piece of hardware.) > > > > Then the files marked "standard" in > > arm/bcm2835/files.bcm2835 move to > > files.arm as "optional bcm2835". > > > > With this approach, the GENERIC arm kernel will > > list the SoCs as devices: > > > > device bcm2835 > > device am335x > > device omap4 > > … etc … > > > > That will bring in the basic support for those SoCs > > (e.g., interrupt handler, gpio, clock management, etc). > > Additional drivers (SDHCI, UART, USB, etc) will > > be separate devices. > > > > I think this makes sense, but I'm open to other ideas. > > I think this is perfect. It is what atmel uses to bring in different > atmel things. I don't think there are any atmel files specified as > std any more, and if there are they could transition to this. I know > this isn't an issue for a GENERIC for armv6, since there is not way > an armv4 and an armv6 kernel could be built today... I don't think that is a problem. We can have two GENERIC kernels, i.e. an arm and an armv6 kernel. Having two GENERIC like kernels doesn't preclude having a single GENERIC in the future, quite the opposite. We are unlikely to have a GENERIC kernel for any hardware that doesn't have fdt, or some other way to detect which SoC & board we are running on. Andrew