summaryrefslogtreecommitdiff
path: root/board/imgtec
diff options
context:
space:
mode:
authorPaul Burton <paul.burton@mips.com>2018-01-18 14:36:41 -0800
committerDaniel Schwierzeck <daniel.schwierzeck@gmail.com>2018-01-25 17:40:42 +0100
commitb2f815bb5fc02d598b31e0f3956b7cef564676d8 (patch)
treeb3435ac3eddf29c59a1eff5adea7ea69cafc2fb1 /board/imgtec
parentfb4413295c765aa8c013650984dc2d908964c81d (diff)
downloadu-boot-b2f815bb5fc02d598b31e0f3956b7cef564676d8.tar.gz
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>
Diffstat (limited to 'board/imgtec')
-rw-r--r--board/imgtec/boston/config.mk5
1 files changed, 4 insertions, 1 deletions
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)