From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Babic Date: Tue, 19 Nov 2013 10:02:59 +0100 Subject: [U-Boot] [PATCH 3/5] i.MX6: nitrogen6x/sabrelite: override set_board_name() In-Reply-To: <528ADD95.3050205@boundarydevices.com> References: <1384708667-22489-1-git-send-email-eric.nelson@boundarydevices.com> <1384708667-22489-4-git-send-email-eric.nelson@boundarydevices.com> <5289F2A5.2020201@denx.de> <528ADD95.3050205@boundarydevices.com> Message-ID: <528B2943.1050804@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 =====================================================================