From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dalon L Westergreen <dalon.westergreen@linux.intel.com>
Date: Mon, 27 Aug 2018 15:03:33 -0700
Subject: [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file
 output for spl image
In-Reply-To: <de02a5d1-6e67-9769-39f9-86174c19835b@denx.de>
References: <20180820135420.19080-1-dwesterg@gmail.com>
 <20180820135420.19080-3-dwesterg@gmail.com>
 <84cfe09f-9448-8d4b-9fb3-92d2a485ba58@denx.de>
 <6dedb6e1eeaa0f673a78156652acee8cd3bbb130.camel@linux.intel.com>
 <82031e24-5001-de59-acff-956a090d2a3c@denx.de>
 <5299700a6843152d37fbd8fd734a791e95334216.camel@linux.intel.com>
 <de02a5d1-6e67-9769-39f9-86174c19835b@denx.de>
Message-ID: <79ab79bf359139e7e73d62bbe52c8c924b8aaeaa.camel@linux.intel.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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