[U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image

[Marek Vasut]

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 <dwesterg at gmail.com <mailto:dwesterg at gmail.com> <mailto:dwesterg at gmail.com <mailto:dwesterg at gmail.com>> <mailto:dwesterg at gmail.com <mailto:dwesterg at gmail.com> <mailto:dwesterg at gmail.com <mailto:dwesterg at 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 ?

-- 
Best regards,
Marek Vasut