progress on the adi pronghorn metro board

[John Hay]

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?

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.

> 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.

John
-- 
John Hay -- John.Hay at meraka.csir.co.za / jhay at FreeBSD.org