On Monday, February 18, 2013 5:50:59 PM, Tom Rini wrote:
> On Sun, Feb 17, 2013 at 05:16:49PM +0100, Beno??t Th??baudeau wrote:
>
> > Hi Poonam, Andy,
> >
> > On Friday, February 15, 2013 9:54:19 PM, Beno??t Th??baudeau wrote:
> > > PAD_TO is not a generic SPL configuration option, so use
> > > CONFIG_SPL_MAX_SIZE
> > > instead.
> > >
> > > We want to use --pad-to with a size, but this option expects an address,
> > > so
> > > use
> > > u-boot-spl.bin instead of u-boot-spl as the input file in order to get
> > > addresses
> > > starting at 0.
> > >
> > > Signed-off-by: Beno??t Th??baudeau <benoit.thebaud...@advansee.com>
> > > ---
> > > Changes in v7:
> > > - Use u-boot-spl.bin instead of u-boot-spl in order to avoid having to
> > > use
> > > --change-addresses.
> > >
> > > Changes in v6:
> > > - Fix size passed to --pad-to thanks to --change-addresses.
> > >
> > > Changes in v5: None
> > > Changes in v4:
> > > - New patch.
> > >
> > > Changes in v3: None
> > > Changes in v2: None
> > >
> > > Makefile | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index a8c7b7b..317dffc 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -486,7 +486,8 @@ $(obj)u-boot.dis: $(obj)u-boot
> > > $(OBJDUMP) -d $< > $@
> > >
> > > $(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
> > > - $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
> > > $(obj)spl/u-boot-spl
> > > $(obj)spl/u-boot-spl-pad.bin
> > > + $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SPL_MAX_SIZE) \
> > > + -I binary -O binary $< $(obj)spl/u-boot-spl-pad.bin
> > > cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $@
> > > rm $(obj)spl/u-boot-spl-pad.bin
> >
> > I would like to let you know what is going on, and to get your feedback for
> > this
> > patch.
> >
> > include/configs/p1_p2_rdb_pc.h seems to be the only current user of
> > u-boot-with-spl.bin, triggered for example by the P2020RDB-PC_NAND config.
>
> cam_enc_4xx also uses this target. Heiko? It looks like this change
> should be safe there as well.
And MPC8313ERDB too.
But I've just seen that commit 74752ba did something for that in u-boot/master,
and this commit is not in u-boot-imx/master on which I based this series. Why
is u-boot-imx/master not sync'ed with u-boot/master? How am I supposed to handle
patch sets depending on several custodian repositories?
Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)' on u-boot-spl.
I could use this CONFIG_SPL_PAD_TO for this series too, but is it really
necessary to have both CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE? In other
words, is there any case for which CONFIG_SPL_PAD_TO could be different from
CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE for a valid reason?
> > Before this patch, PAD_TO was used, but there is no such definition for
> > this
> > board for generic SPL, so this board seems broken, all the more none of the
> > various values defined for CONFIG_SYS_TEXT_BASE relatively to
> > CONFIG_SPL_TEXT_BASE would be compatible with an image built by appending
> > U-Boot
> > to the generic SPL. Can you confirm?
> >
> > This patch won't fix this board, but I want to make sure that it won't be
> > an
> > issue for you now or later.
Best regards,
Benoît
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
