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

Tue Aug 28 15:51:31 UTC 2018

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 <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>>> <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 <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 ?
>>
> 
> 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