progress on the adi pronghorn metro board

[Sam Leffler]

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