From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 16:57:52 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C88E316A405 for ; Thu, 22 Mar 2007 16:57:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 349AC13C4DD for ; Thu, 22 Mar 2007 16:57:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id l2MGrMKd016465; Thu, 22 Mar 2007 09:53:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 22 Mar 2007 10:53:30 -0600 (MDT) Message-Id: <20070322.105330.-1350499346.imp@bsdimp.com> To: sam@errno.com From: "M. Warner Losh" In-Reply-To: <46029AF5.20903@errno.com> References: <20070322080335.GA52745@zibbi.meraka.csir.co.za> <46029AF5.20903@errno.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 22 Mar 2007 10:53:24 -0600 (MDT) Cc: freebsd-arm@freebsd.org Subject: Re: progress on the adi pronghorn metro board X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2007 16:57:52 -0000 In message: <46029AF5.20903@errno.com> Sam Leffler writes: : John Hay wrote: : > Hi Guys, : > : > With this patch I am at the stage where both an Avila 2348-4 and the : > ADI Pronghorn Metro boot from the same kernel binary. The "main" stuff : > is working, ie. console, ethernet and mini-pci slots. The iic bus on : > the Avila is still working. The one for the Pronghorn is configured, : > but I must still write a driver for their max6652 temperature/voltage : > sensor before I will know if it is really working. : > : > The biggest difference between the 2 boards are in the 16 GPIO pins. : > I think there is only 1 pin that have the same function. :-/ : > : > So what I did was to create a structure and then have 2 instances of : > it, one with Avila values in it and one with Pronghorn values. Then : > early in the boot phase, the board type gets detected and a pointer : > gets set to the relevant structure. All the drivers then use this : > pointer to get the correct values. The efect is that most of the : > drivers needs no checks for the different boards. : > : > What I would like to know is, if this approach is acceptable? Should : > I use different files to put the stuff in? : > : > My code is not finished yet, but I thought that I would like to get : > some feedback. I still have to replace some of the numbers in the : > structure with defined values. I would also like to try and really : > probe the iic devices and not just assume that they are there. : : I'm not sure whether it makes sense to support different boards in a : single binary (variations on a board design yes). My experience is that : embedded applications are often cycle starved and giving up cycles for : flexibility like this is ok only for devel/bringup. I suspect : compile-time configuration is preferable. I've noticed that Linux actually does support one kernel for each 'type' of CPU. Their kernel can support multiple different AT91RM9200 boards at least. The boot loader tells the kernel the board type (assigned out of a central location, it seems), and then there's a table in the kernel that is keyed to this type. As each device in the system is initialized, the necessary data is used to for things like sd card write protect line, mii details, etc. There's no way to disable this. It has been very handy to have one kernel or the different boards I'm using here at work as well. Or it was until I broke it with a couple of TSC specific configuration things for our board... I've also noticed that many people just download a prebuilt linux kernel and/or flash image to try on their boards. At least judging from the traffic on the linux lists, this is a highly useful feature. Warner