On Mon, 2018-08-27 at 21:03 +0200, Marek Vasut wrote: > On 08/27/2018 05:30 PM, Dalon L Westergreen wrote: > On Tue, 2018-08-21 at 05:52 +0200, Marek Vasut wrote: > On 08/20/2018 11:04 PM, Dalon L Westergreen wrote: > On Mon, 2018-08-20 at 20:33 +0200, Marek Vasut wrote: > On 08/20/2018 03:54 PM, Dalon Westergreen wrote: > Stratix10 requires a hex image of the spl for boot. The hex > image is added to the FPGA configuration image and loaded to > the processor memory by the configuration engine. > > Signed-off-by: Dalon Westergreen <dwest...@gmail.com > <mailto:dwest...@gmail.com> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com>>> > --- > scripts/Makefile.spl | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl > index 76d08fd92b..c424f87e6e 100644 > --- a/scripts/Makefile.spl > +++ b/scripts/Makefile.spl > @@ -190,6 +190,7 @@ endif > ifdef CONFIG_ARCH_SOCFPGA > ALL-$(CONFIG_TARGET_SOCFPGA_GEN5) += $(obj)/$(SPL_BIN).sfp > ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp > +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/$(SPL_BIN).hex > endif > > ifdef CONFIG_ARCH_SUNXI > @@ -299,6 +300,15 @@ OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j > .start16 -j .resetvec > $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE > $(call if_changed,objcopy) > > +ifdef CONFIG_TARGET_SOCFPGA_STRATIX10 > +OBJCOPYFLAGS_$(SPL_BIN).hex = -I binary -O ihex --change-addresses 0xffe00000 > > Why is this --change-address needed ? This smells like a hack of some > sort ... > > I believe the tool that uses this file expects this offset, that said i have > not > > tried using a hex file without this change address applied. I will try > without > > this, and see what happens. > > You probably need to adjust the link address of the SPL or U-Boot too. > > The link address appears to be correctly set to 0xffe00000 which is the > location of the onchip ram. > > The quartus_cpf tool itself errors out when the --change-address option is > not used. The quartus_cpf > > checks that the address range of the hex is entirely within the onchip ram. > My suggestion would > > be to leave the --change-address option as is. > > So what is _not_ in the onchip RAM then ? Is something sticking out of > the OCRAM , that's why the quartus_cpf fails ? Maybe that's something > you should fix. > Thanks Marek, I'm m not very familiar with the hex format, but there only 2 lines that differ when using the change address option, the first and last, of the hex.
in the file with the change-address option :02000004FFE01B is prepended to the file, and :04000005FFE0000018 is added to the second to last line. It is followed by :00000001FF (end of file). My belief is the change-address is simply specifying the start address of the hex data converted from the binary. This offset is required by the quartus_cpf tool as a form of validation. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
