On 20/03/18 01:53, Breno Matheus Lima wrote:
Hi Bryan,
2018-03-17 8:06 GMT-03:00 Bryan O'Donoghue <bryan.odonog...@linaro.org>:
On 15/03/18 16:54, Breno Matheus Lima wrote:
Hi Bryan,
2018-03-09 14:35 GMT-03:00 Bryan O'Donoghue <bryan.odonog...@linaro.org>:
This patch adds IVT_PAD_SIZE at 0xC00. The IVT header is padded to this
size. Defining the size explicitly makes it possible to use the define to
locate the start/end of an IVT header without using magic numbers in
code.
As far as I know the 0xC00 pad size is only mandatory in U-Boot/SPL
images, for instance in some U-Boot images the first 0xC00 should
include IVT + Boot data + DCD table + padding to 0xC00.
Are you using the IVT_PAD_SIZE in your current code? Or this macro
will be used in a next series?
Thanks,
Breno Lima
All of my images - kernel, u-boot, optee, boot.scr are signed in the same
first-stage format with this padding present - for simplicity.
Maybe this better named "BOOTROM_IVT_PAD_SIZE" since only the bootrom
requires it.
As far as I know the IVT has a fixed size of 0x20, and the set of IVT
+ Boot Data + DCD cannot exceed 0xC00.
This value is calculated by the following operation in function
imximage_generate() at tools/imximage.c:
alloc_len = imximage_init_loadsize - imximage_ivt_offset;
Maybe we can rename to something like UBOOT_IMX_HDR_SIZE? We also have
to ensure this definition is being used by U-Boot code.
Thanks,
Breno Lima
So.
I've stupidly called this "PAD_SIZE" and we've gone off on a padding
size discussion.
This define is supposed to represent the IVT _offset_ in that initial
BootROM image.
Note to self: the hint is in the variable "setenv ivt_offset=some_number"
Anyway Breno - we could add padding size checks to images but, _this_
define is related to IVT offset so... my bad.
I'll redo this patch with a better name :(
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
