From owner-freebsd-arm@FreeBSD.ORG Fri Mar 23 23:13:34 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 A3F8C16A401 for ; Fri, 23 Mar 2007 23:13:34 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6071213C43E for ; Fri, 23 Mar 2007 23:13:34 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l2NNDTfo040668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Mar 2007 16:13:30 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46045F19.2050308@errno.com> Date: Fri, 23 Mar 2007 16:13:29 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.9 (X11/20070208) MIME-Version: 1.0 To: John Hay References: <20070322080335.GA52745@zibbi.meraka.csir.co.za> <46029AF5.20903@errno.com> <20070322152708.GA79016@ci0.org> <20070322171742.GA76915@zibbi.meraka.csir.co.za> <46030332.30007@errno.com> <20070323061806.GA15599@zibbi.meraka.csir.co.za> In-Reply-To: <20070323061806.GA15599@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 23 Mar 2007 23:13:34 -0000 John Hay wrote: > On Thu, Mar 22, 2007 at 03:29:06PM -0700, Sam Leffler wrote: >> John Hay wrote: >>> On Thu, Mar 22, 2007 at 04:27:08PM +0100, Olivier Houchard wrote: >>>> On Thu, Mar 22, 2007 at 08:04:21AM -0700, Sam Leffler wrote: >>>>> 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. >>>>> >>>>> However if this flexibility is desirable it might be better to use >>>>> ivar's hung off the nexus. >>>>> >>>>> Sam >>>> I tend to agree. >>>> I think one config file per board is not too much to handle, and detecting >>>> which board we're currently running can be difficult. >>>> >>>> Olivier >>> I think my code changes are mostly in the attach routines or routines that >>> are used by them, so I don't think it will have an influence on run-time >>> speed. The biggest win for me would be that one could build a single >>> distro that would be able to run any of the two boards. They are so >>> similar, same cpu, 2 ethernets, 4 mini-pcis. But I guess in reality few >>> groups/companies will source more than one board for a product. >> I thought I saw you change some #define's to variable refs in code the >> fiddled with the gpio pins for things like pci interrupt handling. If > > I think the only pci code that patch touch are these functions: > > ixdp425_pci.c:ixp425_md_attach() > ixdp425_pci.c:ixp425_md_route_interrupt() > ixp425.c:ixp425_alloc_resource() > ixp425.c:ixp425_setup_intr() > ixp425_pci.c:ixppcib_conf_setup() > > As far as I know none of them are in the fast path? Sounds good; consider me happy. > > Where I do have changes in the fast path is in the iic code. I changed > all the GPIO_I2C_SDA_BIT and GPIO_I2C_SCL_BIT to sc->sc_sda_bit and > sc->sc_scl_bit. I doubt if that will make a difference in the real > world though. I agree that spending some cycles in the i2c path is ok. > >> no changes affect the fast paths then I'm fine with adding a board >> descriptor and using it instead of hardwired values--but I still think >> you might be able to do this more cleanly by hanging the data off the >> nexus instead of adding a global variable. > > I'll have a look at ivars from the nexus. I will have to check if the > nexus is already alive by the time the console is initialized. The > boards use different uarts for their console. > > Interesting that Warner's description of how linux does it, sounds a > lot like my try. Except that I do not pass the board type in from the > loader. The board description for linux is more extensive. If we continue down this path of parameterizing board params ours will grow too. Sam