On 08/28/2018 05:43 PM, Dalon L Westergreen wrote: > On Tue, 2018-08-28 at 01:54 +0200, Marek Vasut wrote: >> On 08/28/2018 12:03 AM, Dalon L Westergreen wrote: >> 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>> <mailto:dwest...@gmail.com >> <mailto:dwest...@gmail.com> <mailto:dwest...@gmail.com >> <mailto:dwest...@gmail.com>>> <mailto:dwest...@gmail.com >> <mailto:dwest...@gmail.com> <mailto:dwest...@gmail.com >> <mailto:dwest...@gmail.com>> <mailto: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 >> >> The intel ihex is terrible (sorry), it's really hard to decode. But >> here's some example: >> https://en.wikipedia.org/wiki/Intel_HEX >> >> 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. >> >> This is what objcopy(1) says: >> >> --change-addresses incr >> --adjust-vma incr >> Change the VMA and LMA addresses of all sections, as well as >> the start address, by adding incr. Some object file formats do not >> permit section addresses to be changed >> arbitrarily. Note that this does not relocate the sections; >> if the program expects sections to be loaded at a certain address, and >> this option is used to change the sections such >> that they are loaded at a different address, the program may >> fail. >> >> So I ran make V=1 , to see how the hex file is generated, and this is how: >> aarch64-linux-gnu-objcopy -j .text -j .secure_text -j .secure_data -j >> .rodata -j .data -j .u_boot_list -j .rela.dyn -j .got -j .got.plt -j >> .binman_sym_table -j .text_rest -j .dtb.init.rodata -j .efi_runtime -j >> .efi_runtime_rel -I binary -O ihex --change-addresses 0xffe00000 >> spl/u-boot-spl.bin spl/u-boot-spl.hex >> >> It's generated from u-boot-spl.bin , which is weird. The u-boot.hex is >> generated from u-boot (ELF binary). I think that's what the SPL hex >> should be generated from too, since the ELF binary contains all the >> relocation info. >> >> So a target similar to u-boot.hex should do: >> OBJCOPYFLAGS_$(SPL_BIN).hex = -O ihex >> >> $(obj)/$(SPL_BIN).hex: $(obj)/$(SPL_BIN) FORCE >> $(call if_changed,objcopy) >> >> Does that work for you ? >> > > Actually no, it is weird that it is using SPL_BIN, the intent was to use the > binary with > > the devicetree included. That is the reason for generating from the binary. > I will update > > the patch i sent to use $(SPL_BIN)-dtb.bin which was the intent unless there > is another > > way you would like the hex output to include the dtb?
The DT is also included in the ELF file if you use CONFIG_OF_EMBED iirc, so there really shouldn't be any need to use the .bin . -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
