On Monday, February 18, 2013 8:37:29 PM, Scott Wood wrote:
On 02/17/2013 10:16:49 AM, 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.thebaudeau@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.binI 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.
Before this patch, PAD_TO was used, but there is no such definition for this board for generic SPL, so this board seems broken,
"--pad-to=" with no argument behaves the same as "--pad-to=0", though since it's undocumented we now avoid relying on that behavior as you observed in a followup post.
OK.
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?
I don't follow. CONFIG_SYS_TEXT_BASE is for where the payload gets loaded to, and has nothing to do with its position in the SPL-concat image, nor with the address that the SPL starts running at.
Right, sorry, I meant CONFIG_SYS_NAND_U_BOOT_OFFS. It is 0, which is not compatible with the payload being appended to the SPL in the programmed image.
Best regards, Benoît