On Fri, Oct 05, 2012 at 01:03:10PM -0700, Eric Nelson wrote: > On 10/05/2012 12:00 PM, Tom Rini wrote: [snip] > >And we can't deal with this by factoring the code differently? > > > Hi Tom, > > There are two bits to this question: > - Can we represent the policy differences outside of a > board structure? These differences are all inside of > include/configs/nitrogen6x. > > I'm not certain how, but I suspect that we can get > a different _config to work for this. > > - Can we represent the board differences without a > board structure? This is a bit harder, since the > boards are slightly different. The Nitrogen6X has > a different ethernet PHY reset pin and an optional > SDIO Wi-Fi module. > > We could add code to SABRE Lite to accommodate these, > but it seems that sets a bad precedent. Would this > be done for every vendor that bases a design on > SABRE Lite? > > The precise diffs for the configs and sources is attached for > reference. > > I've also been pondering how to simply re-use the code within > the board setup file (mx6qsabrelite.c), but I haven't figured > anything out. Clearly a lot of the code is duplicated, but at > the same time it's board-specific. > > For example, we could create a common module that sets up > the SD card pads "like SABRE Lite", and a similar one to > configure ethernet pads. Since SABRE Lite is a reference design, > perhaps that makes sense. > > Does anybody have thoughts about how and where this might be > sliced?
Dice some bits of board/freescale/mx6qsabrelite/mx6qsabrelite.c into arch/arm/cpu/armv7/mx6/board.c (or some other filename in mx6/) ? This is what we do on the various OMAP families, and use a few hooks for "let the board fill in this part of setup". Possibly re-use and update mx6/soc.c even. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
