[U-Boot] [PATCH 3/5] i.MX6: nitrogen6x/sabrelite: override set_board_name()

[Stefano Babic]

Hi Eric,

On 19/11/2013 04:40, Eric Nelson wrote:

>> I have a major question: if it is possible to detect at runtime, as you
>> have already implemented, which is the board where code is running, why
>> is it possible to override it for the operator ?
>>
> First off, I want to clarify things. There are two levels of override
> possible here:
>     - weak functions can be over-ridden by board files
>     - environment variables can be overridden through saveenv()
> 
> The first is to allow auto-detection of a "board" as shown in
> nitrogen6x.c. I assume you're okay with that bit.

Right.

>> I agree that forcing environment variables inside code is bad, but
>> in this case it is a hardware related stuff. It is like to the
>> processor type or the serial-id of the processor (variable dieid#
>> on OMAP). Overriding seems weird.
>>
> There is a reason for this, and it mostly involves custom pin-muxing.
> 
> All of our boards support a wide variety of peripherals, and we make
> assumptions about what the various connectors will be used for.
> 
> For instance, we define a particular connector for use as a parallel
> (RGB) display.
> 
> Lots of customers have other needs though, and through the magic of
> pin-muxing, they build their own "board" files in the kernel and
> use the parallel display pins for connecting SPI devices or additional
> I2C or RS-232 pins. Or simply as GPIOs.
> 
> The easiest, most maintainable way to do that is by cloning our board
> files and editing the pin muxes.
> 
> With the addition of device tree support, this becomes even easier.
> 
> So is it a different board? Maybe not, but it's useful to name things
> differently in the kernel tree so you can easily perform a diff
> against the original or boot to the original DTB for comparison.
> 
> SOM customers blur the lines even further, and it's not uncommon
> for someone to boot a different carrier with our stock U-Boot if
> the changes are minor or their needs are modest.

ok, understood, thanks for clarification.

> 
> Re-reading the patch, it seems that there's no good reason to have
> set_imx_type(void) declared __weak.

Agree.

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-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================