[U-Boot] [PATCH] mx6qsabresd: Add basic support

[stefano babic]

Am 11/09/2012 16:43, schrieb Eric Nelson:
> On 09/10/2012 08:56 PM, Fabio Estevam wrote:
>> Hi Stefano,
>>
>> On Thu, Apr 12, 2012 at 7:52 AM, Stefano Babic<sbabic at denx.de>  wrote:
>>
>>> This file is identical to imximage.cfg for the mx6qsabrelite board. I
>>> can imagine this is derived board. Why cannot we implement it as a
>>> variant of the original one ? We have several example in u-boot, for
>>> example the efika (MX51), or the TAM3517 (ok, I admit I know this very
>>> well because I did it...), or imx27-lite /magnesium, or....
>>
>> After a long time, I am returning on adding support to mx6qsabresd.
>>
>> I have been comparing mx6qsabrelite against mx6qsabresd and I have
>> started to do as you suggested: unify the 2 boards into
>> mx6qsabrelite.c.
>>
>> What I realize is that the differences are relevant: UART1 pin muxing,
>> SDHC ports, SDHC card detect GPIO, USB Host enable port, I2C devices,
>> Ethernet PHY, etc.
>>
>> It seems to me that the code is becoming polluted by all the ifdef's I
>> need to place in order to handle both boards, and I am starting to
>> think if it wouldn't be better to follow with the original approach of
>> adding a board/freescale/mx6qsabresd directory.
>>
>> After I finish mx6qsabresd, I also plan to add one more mx6q board,
>> and this would mean even more ifdefs, which would make the code even
>> harder to read.
>>
>> Please let me know what you think.
>>
> 
> Hi Fabio and Stefano,
> 

Hi Eric,

> We also need to add support for a board (our Nitrogen6x) which
> is a slight variation on Sabre Lite.
> 
> We have been patching the board/freescale/mx6qsabrelite, and our
> needs can in general be handled without ifdefs, but it seems that
> this approach doesn't scale well.

It seems you want also to put the board with your vendor name, and then
goes into a separate directory.

> 
> When other vendors produce boards which are also slight variations,
> where do we draw the line, and more importantly, how do we track
> and test the needs of each?

There is no strict rule. And of course, if the code is in the same
directory, any change should be tested on all boards belonging to this
directory. In your case, I understand you prefer to have your board
identified with your vendor name and not mixed up with Freescale's boards.

> 
> Our thinking is that if it's a different board, it should have
> a different directory, and common code should be clearly separated.

I like this approach. If we can identify common code, it is better to
put it in a common place and make available to all boards, and each
board has still its own identity.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================