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

[Eric Nelson <eric.nelson@boundarydevices.com>]

On 09/10/2012 08:56 PM, Fabio Estevam wrote:
> Hi Stefano,
>
> On Thu, Apr 12, 2012 at 7:52 AM, Stefano Babic<sbabic@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,

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.

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?

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

Regards,


Eric