[U-Boot] [PULL] Please pull u-boot-imx

[Albert ARIBAUD]

Hi Stefano,

On Tue, 16 Sep 2014 17:07:34 +0200, Stefano Babic <sbabic at denx.de>
wrote:

> Hi Albert,
> 
> On 16/09/2014 16:38, Albert ARIBAUD wrote:
> > Hi Stefano,
> > 
> > On Fri, 12 Sep 2014 16:03:15 +0200, Stefano Babic <sbabic at denx.de>
> > wrote:
> > 
> >> Hi Albert,
> >>
> >> please pull from u-boot-imx, thanks !
> >>
> >> The board cm_fx6 cannot be built due to a couple of missing patches that
> >> are already merged into u-boot-spi. Please ignore this issue, the board
> >> will be compiled clean at the next iteration after Jagan's tree will be
> >> merged by Tom.
> >>
> >> The following changes since commit a6bc0195dba895fa0e9facc718d17eb098695685:
> >>
> >>   Merge branch 'u-boot-sunxi/master' into 'u-boot-arm/master'
> >> (2014-09-09 09:19:10 +0200)
> >>
> >> are available in the git repository at:
> >>
> >>
> >>   git://www.denx.de/git/u-boot-imx.git master
> >>
> >> for you to fetch changes up to 4c97f16911e229f6d5bbea5bee52449916e5fa92:
> >>
> >>   imx: mx6slevk: Change to use generic board (2014-09-11 11:04:26 +0200)
> >>
> >> ----------------------------------------------------------------
> >> Fabio Estevam (9):
> >>       net: fec_mxc: Adjust RX DMA alignment for mx6solox
> >>       net: fec_mxc: Poll FEC_TBD_READY after polling TDAR
> >>       tools: imximage: Fix the maximum DCD size for mx53/mx6
> >>       mx6dlsabresd: Use its own DCD table
> >>       mx6qsabreauto: Remove imx6q-sabreauto.dts
> >>       mx6: imx-regs: Provide a structure for GPC registers
> >>       pcie_imx: Add mx6solox support
> >>       mx6sxsabresd: Add PCI support
> >>       README.imximage: Fix the maximum DCD size
> >>
> >> Guillaume GARDET (1):
> >>       imx: nitrogen6x: Replace 'fatload' by 'load' command in env
> >> settings to be filesystem independent
> >>
> >> Nikita Kiryanov (16):
> >>       mx6: add clock enabling functions
> >>       compulab: eeprom: add support for defining eeprom i2c bus
> > 
> > The commit above (52658fda7abc) breaks trimslice build (and later will
> > break cm_fx6 when it is introduced by 0991866cf7, or possibly before
> > that, at f66113c0ef) with the following errors :
> > 
> 
> This is due to the fact that some patches were already merged by Jagan
> into u-boot-spi and not by me. In fact, I have cherry-picked the
> relevant patches from Jagan's tree:
> 
> a7434e2efa6d514b449c51d57e7af79387761349
> [next d709570] spl: replace CONFIG_SPL_SPI_* with CONFIG_SF_DEFAULT_*
>  Author: Nikita Kiryanov <nikita at compulab.co.il>
> 
> fd2dd067fa4f0ea28e80071806850b058dd9555d
> [next 8cca248] spi: mxc: fix sf probe when using mxc_spi
>  Author: Nikita Kiryanov <nikita at compulab.co.il>
>  16 files changed, 79 insertions(+), 33 deletions(-)
> 
> bdb070e9810017711cff5486eb09c387043be7c6
> [next 92c569e] mtd: spi: add support for M25PE16 and M25PX16
>  Author: Nikita Kiryanov <nikita at compulab.co.il>
>  1 file changed, 2 insertions(+)
> 
> and then the board is built without any issue.
> ./MAKEALL cm_fx6
> boards.cfg is up to date. Nothing to do.
> Building cm_fx6 board...
>    text	   data	    bss	    dec	    hex	filename
>  252164	  26298	 318528	 596990	  91bfe	./u-boot
>   27088	   2464	    112	  29664	   73e0	./spl/u-boot-spl
> 
> 
> However, patches were already merged. The issue should be solved when
> u-boot-spi and u-boot-arm will be pulled by Tom. Or do you think we have
> to do something before ?

There is not much we can do now, so we'll have to make sure u-boot-arm
and u-boot-spi et merged into mainline properly.

The problem I see with this type of situation is that non-mainline
U-Boot trees (imx, arm, spi...) are supposed to be useable code ontheir
own right, and here, imx and arm trees become (slightly) unusable,
which prevents things like bisecting in case you end up on a non-
buildable commit.

The only solution I can think of -- and it does not solve all cases --
is to never pull in commits or merges from an unrelated tree (e.g., to
not pull from spi to arm tree), only from an upstream tree (e.g. pulling
from mainline to arm is ok, as is pulling from mainline or arm to imx),
and to avoid scattering a patch series over several trees, but rather,
apply it to a single tree, with Acks from other custodians and/or
maintainers involved.

> Best regards,
> Stefano

Amicalement,
-- 
Albert.