[U-Boot] [PATCH] boston: Pad binary in .mcs to a multiple of 16 bytes

When flashing U-Boot on a Boston board using Xilinx Vivado tools, the final 0x00 byte which ends the .relocs section seems to be skipped & left in flash as 0xff unless the data contained in the .mcs is padded out to a 16 byte boundary. Without our final zero byte relocation will fail with an error about a spurious reloc:
Avoid this problem by padding out the data in the .mcs file to a 16 byte boundary using srec_cat's -range-pad functionality.
Signed-off-by: Paul Burton paul.burton@mips.com Cc: Daniel Schwierzeck daniel.schwierzeck@gmail.com
---
board/imgtec/boston/config.mk | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/board/imgtec/boston/config.mk b/board/imgtec/boston/config.mk index 2775727744..0ba8802da0 100644 --- a/board/imgtec/boston/config.mk +++ b/board/imgtec/boston/config.mk @@ -3,7 +3,10 @@ #
quiet_cmd_srec_cat = SRECCAT $@ - cmd_srec_cat = srec_cat -output $@ -$2 $< -binary -offset $3 + cmd_srec_cat = srec_cat -output $@ -$2 \ + $< -binary \ + -fill 0x00 -within $< -binary -range-pad 16 \ + -offset $3
u-boot.mcs: u-boot.bin $(call cmd,srec_cat,intel,0x7c00000)

On 18.01.2018 23:36, Paul Burton wrote:
When flashing U-Boot on a Boston board using Xilinx Vivado tools, the final 0x00 byte which ends the .relocs section seems to be skipped & left in flash as 0xff unless the data contained in the .mcs is padded out to a 16 byte boundary. Without our final zero byte relocation will fail with an error about a spurious reloc:
Avoid this problem by padding out the data in the .mcs file to a 16 byte boundary using srec_cat's -range-pad functionality.
Signed-off-by: Paul Burton paul.burton@mips.com Cc: Daniel Schwierzeck daniel.schwierzeck@gmail.com
board/imgtec/boston/config.mk | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
applied to u-boot-mips, thanks.
participants (2)
-
Daniel Schwierzeck
-
Paul Burton