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: sba...@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
