All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Fix SPL build for non-ARM targets
Date: Wed, 9 Jan 2013 15:56:07 -0600	[thread overview]
Message-ID: <1357768567.18196.3@snotra> (raw)
In-Reply-To: <20130109213822.GC5802@bill-the-cat> (from trini@ti.com on Wed Jan  9 15:38:22 2013)

On 01/09/2013 03:38:22 PM, Tom Rini wrote:
> On Wed, Jan 09, 2013 at 01:53:21PM -0600, Scott Wood wrote:
> > On 01/08/2013 04:57:20 PM, Albert ARIBAUD wrote:
> > >
> > >Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
> > >---
> > > drivers/mtd/nand/Makefile |    4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > >diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> > >index 2c3812c..c77c0c4 100644
> > >--- a/drivers/mtd/nand/Makefile
> > >+++ b/drivers/mtd/nand/Makefile
> > >@@ -79,6 +79,10 @@ COBJS-$(CONFIG_TEGRA_NAND) += tegra_nand.o
> > > COBJS-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
> > > COBJS-$(CONFIG_NAND_PLAT) += nand_plat.o
> > >
> > >+else  # minimal SPL drivers
> > >+
> > >+COBJS-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_spl.o
> > >+
> > > endif # drivers
> > > endif # nand
> >
> > So, it looks like this is repairing breakage that came in through a
> > manual merge resolution.  Should such merge resolutions not be
> > posted to the list for review?  Or was it posted and I missed it?
> 
> None of the above.  That powerpc was broken twice (once by this, and
> once by the arm head.S changes) was missed in my build testing.  We
> don't have spelled out rules (that I'm aware of) for manual merges  
> other
> than asking that someone check that X still works (in this case,  
> am335x
> NAND). It did, but I didn't read the merge myself was the problem.

The NAND Makefile breakage came from commit  
79f38777947ac7685e2cef8bd977f954ab198c0e, which is a manual merge by  
Albert.  Why should manual merges be exempt from the rule that all  
changes get posted to the list?  What if next time it's a functional  
breakage rather than a broken build?

I tried repeating the merge between 96764df and 9bd5c1a and the only  
conflict marker was this:

ifdef CONFIG_SPL_BUILD
<<<<<<< HEAD
ifdef CONFIG_SPL_NAND_SIMPLE
COBJS-y += nand_spl_simple.o
endif
COBJS-$(CONFIG_SPL_NAND_AM33XX_BCH) += am335x_spl_bch.o
ifdef CONFIG_SPL_NAND_LOAD
COBJS-y += nand_spl_load.o
||||||| merged common ancestors
ifdef CONFIG_SPL_NAND_SIMPLE
COBJS-y += nand_spl_simple.o
endif
ifdef CONFIG_SPL_NAND_LOAD
COBJS-y += nand_spl_load.o
=======

ifdef CONFIG_SPL_NAND_DRIVERS
NORMAL_DRIVERS=y
>>>>>>> 96764df
endif

The fsl_elbc_spl.o part was still there, so it wasn't the automatic  
part of the merge that removed it.

If this was simply due to a bad patch in the ARM tree, which specific  
patch was it?

-Scott

  reply	other threads:[~2013-01-09 21:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-08 22:57 [U-Boot] [PATCH] Fix SPL build for non-ARM targets Albert ARIBAUD
2013-01-09 13:35 ` Tom Rini
2013-01-09 19:53 ` Scott Wood
2013-01-09 21:38   ` Tom Rini
2013-01-09 21:56     ` Scott Wood [this message]
2013-01-09 22:06     ` Scott Wood
2013-01-09 22:25       ` Tom Rini
2013-01-09 22:41         ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1357768567.18196.3@snotra \
    --to=scottwood@freescale.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.