On Tue, 2018-04-17 at 11:28 +0200, Marek Vasut wrote: > On 04/17/2018 11:11 AM, See, Chin Liang wrote: > > > > On Tue, 2018-04-17 at 11:01 +0200, Marek Vasut wrote: > > > > > > On 04/17/2018 10:52 AM, See, Chin Liang wrote: > > > > > > > > > > > > On Tue, 2018-04-17 at 10:46 +0200, Marek Vasut wrote: > > > > > > > > > > > > > > > On 04/17/2018 10:40 AM, See, Chin Liang wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Marek, > > > > > > > > > > > > On Sun, 2018-04-15 at 15:37 +0200, Marek Vasut wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > The Arria10 uses slightly different boot image header > > > > > > > than > > > > > > > the > > > > > > > Gen5 > > > > > > > SoCs, > > > > > > > in particular the header itself contains an offset from > > > > > > > the > > > > > > > start > > > > > > > of > > > > > > > the > > > > > > > header to which the Arria10 jumps. This offset must not > > > > > > > be > > > > > > > negative, > > > > > > > yet > > > > > > > the header is placed at offset 0x40 of the bootable > > > > > > > binary. > > > > > > > Therefore, to > > > > > > > jump into U-Boot, add a trampoline just past the Arria10 > > > > > > > boot > > > > > > > header > > > > > > > and > > > > > > > point to this trampoline at fixed offset from the header > > > > > > > generated > > > > > > > using > > > > > > > the mkimage -T socfpgaimage_v1 . Note that it is not > > > > > > > needed > > > > > > > to > > > > > > > jump > > > > > > > back > > > > > > > to offset 0x0 of the image, it is possible to jump > > > > > > > directly > > > > > > > at > > > > > > > the > > > > > > > reset > > > > > > > label and save processing two instructions. > > > > > > > > > > > > > > Signed-off-by: Marek Vasut <ma...@denx.de> > > > > > > > Cc: Dinh Nguyen <dingu...@kernel.org> > > > > > > > Cc: Chin Liang See <chin.liang....@intel.com> > > > > > > > --- > > > > > > > arch/arm/mach-socfpga/include/mach/boot0.h | 4 ++-- > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > diff --git a/arch/arm/mach-socfpga/include/mach/boot0.h > > > > > > > b/arch/arm/mach-socfpga/include/mach/boot0.h > > > > > > > index d6b9435d33..06bbe27d2c 100644 > > > > > > > --- a/arch/arm/mach-socfpga/include/mach/boot0.h > > > > > > > +++ b/arch/arm/mach-socfpga/include/mach/boot0.h > > > > > > > @@ -18,10 +18,10 @@ _start: > > > > > > > .word 0xcafec0d3; /* Checksum, > > > > > > > zero- > > > > > > > pad */ > > > > > > > nop; > > > > > > > > > > > > > > - b reset; /* SoCFPGA jumps here */ > > > > > > > - nop; > > > > > > > + b reset; /* SoCFPGA Gen5 jumps > > > > > > > here > > > > > > > */ > > > > > > > nop; > > > > > > > nop; > > > > > > > + b reset; /* SoCFPGA Gen10 > > > > > > > trampoline > > > > > > > */ > > > > > > Our mkpimage tools from SOCEDS is using 0x14 as offset. > > > > > > Wonder > > > > > > can > > > > > > we > > > > > > standardize that by using 0x14 instead of proposed 0x18 in > > > > > > this > > > > > > patch? > > > > > What difference does it make, the entire image is generated > > > > > during > > > > > the > > > > > build anyway ? This patch uses offset 0x1c, but what is the > > > > > reason > > > > > for > > > > > address 0x14 in your proprietary tool, is there one ? > > > > Our A10 header ended at 0x13 today. Hence we are continuing the > > > > code at > > > > 0x14 without any spacing. > > > > > > > > While for 0x1c, should it be 3 nop? > > > Yes, gives enough space were the header grow for whatever reason. > > > Mind > > > you, the NOPs are not executed, the socfpga jumps to 0x1c > > > directly > > > via > > > 0x0c -- Image entry offset > > Ok, I don't have strong objection on this. We can claim that we > > don't > > support use case where we use mkpimage tools from SCOEDS to sign > > SPL > > binary from mainstream. > Which you can, why wouldn't it work ? >
Rethinking on this, yes as the nop shall able to handle this. Just the vice versa won't work since downstream U-Boot already have the entry fixed at 0x14. > What is the benefit of using mkpimage if mkimage does the same thing > though ? Initial thought is for having both tools compatible. But rethinking the makefile will handle this, we just advise user directly use sfp file directly. Thanks Chin Liang _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
