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

[Dalon L Westergreen]

On Tue, 2018-08-28 at 17:51 +0200, Marek Vasut wrote:
> 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    >    >>    >    
> ---
>  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 0xffe0
> 
> 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 0xffe0 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 :0204FFE01B is prepended to 
> the file, and 
> 
> :0405FFE018 is added to the second to last line.  It is followed by 
> :0001FF (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 0xffe0
> 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:
> 

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

[Marek Vasut]

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 >  > > >  > >> >  > > >  > 
>> ---
>>  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 
>> 0xffe0
>>
>> 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 0xffe0 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 :0204FFE01B is prepended to 
>> the file, and 
>>
>> :0405FFE018 is added to the second to last line.  It is followed by 
>> :0001FF (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 0xffe0
>> 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 

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

[Dalon L Westergreen]

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    >     ---
>  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 0xffe0
> 
> 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 0xffe0 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 :0204FFE01B is prepended to 
> the file, and 
> 
> :0405FFE018 is added to the second to last line.  It is followed by 
> :0001FF (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 0xffe0
> 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 

Re: [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 >  > > >  > > ---
>>  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 
>> 0xffe0
>>
>> 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 0xffe0 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 :0204FFE01B is prepended to 
> the file, and 
> 
> :0405FFE018 is added to the second to last line.  It is followed by 
> :0001FF (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 0xffe0
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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Dalon L Westergreen]

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    >>
> ---
>  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 0xffe0
> 
> 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 0xffe0 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 :0204FFE01B is prepended to the 
file, and 
:0405FFE018 is added to the second to last line.  It is followed by 
:0001FF (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

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

[Marek Vasut]

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 >  > >>
>> ---
>>  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 
>> 0xffe0
>>
>> 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 0xffe0 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.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Dalon L Westergreen]

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  >
> ---
>  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 0xffe0
> 
> 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 0xffe0 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.  


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Marek Vasut]

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 > >
>> ---
>>  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 
>> 0xffe0
>>
>> 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.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Dalon L Westergreen]

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 
> ---
>  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 0xffe0
> 
> 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.
> 
> +else
> +OBJCOPYFLAGS_$(SPL_BIN).hex = -I binary -O ihex
> +endif
> +
> +$(obj)/$(SPL_BIN).hex: $(obj)/$(SPL_BIN).bin FORCE
> + $(call if_changed,objcopy)
> +
>  LDFLAGS_$(SPL_BIN) += -T u-boot-spl.lds $(LDFLAGS_FINAL)
>  
>  # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
> 
> 
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Marek Vasut]

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 
> ---
>  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 0xffe0

Why is this --change-address needed ? This smells like a hack of some
sort ...

> +else
> +OBJCOPYFLAGS_$(SPL_BIN).hex = -I binary -O ihex
> +endif
> +
> +$(obj)/$(SPL_BIN).hex: $(obj)/$(SPL_BIN).bin FORCE
> + $(call if_changed,objcopy)
> +
>  LDFLAGS_$(SPL_BIN) += -T u-boot-spl.lds $(LDFLAGS_FINAL)
>  
>  # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Dalon Westergreen]

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 
---
 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 0xffe0
+else
+OBJCOPYFLAGS_$(SPL_BIN).hex = -I binary -O ihex
+endif
+
+$(obj)/$(SPL_BIN).hex: $(obj)/$(SPL_BIN).bin FORCE
+   $(call if_changed,objcopy)
+
 LDFLAGS_$(SPL_BIN) += -T u-boot-spl.lds $(LDFLAGS_FINAL)
 
 # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot