diff options
| author | Paul Burton <paul.burton@mips.com> | 2018-01-18 14:36:41 -0800 |
|---|---|---|
| committer | Daniel Schwierzeck <daniel.schwierzeck@gmail.com> | 2018-01-25 17:40:42 +0100 |
| commit | b2f815bb5fc02d598b31e0f3956b7cef564676d8 (patch) | |
| tree | b3435ac3eddf29c59a1eff5adea7ea69cafc2fb1 | |
| parent | fb4413295c765aa8c013650984dc2d908964c81d (diff) | |
| download | u-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>
| -rw-r--r-- | board/imgtec/boston/config.mk | 5 |
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) |