* [U-Boot] [PATCH 0/2] socfpga: cleanup files generated for spl
@ 2018-08-20 13:54 Dalon Westergreen
2018-08-20 13:54 ` [U-Boot] [PATCH 1/2] spl: socfpga: only gen5 devices and arria10 require sfp image Dalon Westergreen
2018-08-20 13:54 ` [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image Dalon Westergreen
0 siblings, 2 replies; 13+ messages in thread
From: Dalon Westergreen @ 2018-08-20 13:54 UTC (permalink / raw)
To: u-boot
These patches add a hex output of the spl image for Stratix10
devices, and remove the sfp mkimage output for Stratix10 devices.
In Stratix10, the spl image is added to the initial FPGA configuration
bitstream. A hex file is needed to do this.
Dalon Westergreen (2):
spl: socfpga: only gen5 devices and arria10 require sfp image
spl: socfpga: stratix10: add hex file output for spl image
scripts/Makefile.spl | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
--
2.17.1
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 1/2] spl: socfpga: only gen5 devices and arria10 require sfp image
2018-08-20 13:54 [U-Boot] [PATCH 0/2] socfpga: cleanup files generated for spl Dalon Westergreen
@ 2018-08-20 13:54 ` Dalon Westergreen
2018-08-20 13:54 ` [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image Dalon Westergreen
1 sibling, 0 replies; 13+ messages in thread
From: Dalon Westergreen @ 2018-08-20 13:54 UTC (permalink / raw)
To: u-boot
Only the Cyclone5/Arria5 and Arria10 devices require the sfp
formated image for booting. This path ensures that the file is
only generated for those devices.
Signed-off-by: Dalon Westergreen <dwesterg@gmail.com>
---
scripts/Makefile.spl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 252f13826d..76d08fd92b 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -188,7 +188,8 @@ ALL-y += $(obj)/$(BOARD)-spl.bin
endif
ifdef CONFIG_ARCH_SOCFPGA
-ALL-y += $(obj)/$(SPL_BIN).sfp
+ALL-$(CONFIG_TARGET_SOCFPGA_GEN5) += $(obj)/$(SPL_BIN).sfp
+ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp
endif
ifdef CONFIG_ARCH_SUNXI
--
2.17.1
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
2018-08-20 13:54 [U-Boot] [PATCH 0/2] socfpga: cleanup files generated for spl Dalon Westergreen
2018-08-20 13:54 ` [U-Boot] [PATCH 1/2] spl: socfpga: only gen5 devices and arria10 require sfp image Dalon Westergreen
@ 2018-08-20 13:54 ` Dalon Westergreen
2018-08-20 18:33 ` Marek Vasut
1 sibling, 1 reply; 13+ messages in thread
From: Dalon Westergreen @ 2018-08-20 13:54 UTC (permalink / raw)
To: u-boot
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@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
+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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
2018-08-20 13:54 ` [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image Dalon Westergreen
@ 2018-08-20 18:33 ` Marek Vasut
2018-08-20 21:04 ` Dalon L Westergreen
0 siblings, 1 reply; 13+ messages in thread
From: Marek Vasut @ 2018-08-20 18:33 UTC (permalink / raw)
To: u-boot
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@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 ...
> +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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
2018-08-20 18:33 ` Marek Vasut
@ 2018-08-20 21:04 ` Dalon L Westergreen
2018-08-21 3:52 ` Marek Vasut
0 siblings, 1 reply; 13+ messages in thread
From: Dalon L Westergreen @ 2018-08-20 21:04 UTC (permalink / raw)
To: u-boot
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@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.
>
> +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.
>
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
2018-08-20 21:04 ` Dalon L Westergreen
@ 2018-08-21 3:52 ` Marek Vasut
2018-08-27 15:30 ` Dalon L Westergreen
0 siblings, 1 reply; 13+ messages in thread
From: Marek Vasut @ 2018-08-21 3:52 UTC (permalink / raw)
To: u-boot
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>>
>> ---
>> 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.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
2018-08-21 3:52 ` Marek Vasut
@ 2018-08-27 15:30 ` Dalon L Westergreen
2018-08-27 19:03 ` Marek Vasut
0 siblings, 1 reply; 13+ messages in thread
From: Dalon L Westergreen @ 2018-08-27 15:30 UTC (permalink / raw)
To: u-boot
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>>
> ---
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
2018-08-27 15:30 ` Dalon L Westergreen
@ 2018-08-27 19:03 ` Marek Vasut
2018-08-27 22:03 ` Dalon L Westergreen
0 siblings, 1 reply; 13+ messages in thread
From: Marek Vasut @ 2018-08-27 19:03 UTC (permalink / raw)
To: u-boot
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.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
2018-08-27 19:03 ` Marek Vasut
@ 2018-08-27 22:03 ` Dalon L Westergreen
2018-08-27 23:54 ` Marek Vasut
0 siblings, 1 reply; 13+ messages in thread
From: Dalon L Westergreen @ 2018-08-27 22:03 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
2018-08-27 22:03 ` Dalon L Westergreen
@ 2018-08-27 23:54 ` Marek Vasut
2018-08-28 15:43 ` Dalon L Westergreen
0 siblings, 1 reply; 13+ messages in thread
From: Marek Vasut @ 2018-08-27 23:54 UTC (permalink / raw)
To: u-boot
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@gmail.com> <mailto:dwesterg at gmail.com <mailto:dwesterg@gmail.com>> <mailto: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
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
2018-08-27 23:54 ` Marek Vasut
@ 2018-08-28 15:43 ` Dalon L Westergreen
2018-08-28 15:51 ` Marek Vasut
0 siblings, 1 reply; 13+ messages in thread
From: Dalon L Westergreen @ 2018-08-28 15:43 UTC (permalink / raw)
To: u-boot
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@gmail.com> <mailto:dwesterg at gmail.com <mailto:dwesterg@gmail.com>> <mailto: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
>
> 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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
2018-08-28 15:43 ` Dalon L Westergreen
@ 2018-08-28 15:51 ` Marek Vasut
2018-08-28 15:55 ` Dalon L Westergreen
0 siblings, 1 reply; 13+ messages in thread
From: Marek Vasut @ 2018-08-28 15:51 UTC (permalink / raw)
To: u-boot
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@gmail.com> <mailto:dwesterg at gmail.com <mailto:dwesterg@gmail.com>> <mailto:dwesterg at gmail.com <mailto:dwesterg@gmail.com> <mailto:dwesterg at gmail.com <mailto:dwesterg@gmail.com>>> <mailto:dwesterg at gmail.com <mailto:dwesterg@gmail.com> <mailto:dwesterg at gmail.com <mailto:dwesterg@gmail.com>> <mailto: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
>>
>> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
2018-08-28 15:51 ` Marek Vasut
@ 2018-08-28 15:55 ` Dalon L Westergreen
0 siblings, 0 replies; 13+ messages in thread
From: Dalon L Westergreen @ 2018-08-28 15:55 UTC (permalink / raw)
To: u-boot
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 <dwesterg at gmail.com <mailto:dwesterg@gmail.com> <mailto:dwesterg at gmail.com <mailto:dwesterg@gmail.com>> <mailto:dwesterg at gmail.com <mailto:dwesterg@gmail.com> <mailto:dwesterg at gmail.com <mailto:dwesterg@gmail.com>>> <mailto:dwesterg at gmail.com <mailto:dwesterg@gmail.com> <mailto:dwesterg at gmail.com <mailto:dwesterg@gmail.com>> <mailto: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
>
> 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 .
>
Thanks, i will give that a shot. Does that affect uboot as well as uboot-spl?
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2018-08-28 15:55 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-20 13:54 [U-Boot] [PATCH 0/2] socfpga: cleanup files generated for spl Dalon Westergreen
2018-08-20 13:54 ` [U-Boot] [PATCH 1/2] spl: socfpga: only gen5 devices and arria10 require sfp image Dalon Westergreen
2018-08-20 13:54 ` [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image Dalon Westergreen
2018-08-20 18:33 ` Marek Vasut
2018-08-20 21:04 ` Dalon L Westergreen
2018-08-21 3:52 ` Marek Vasut
2018-08-27 15:30 ` Dalon L Westergreen
2018-08-27 19:03 ` Marek Vasut
2018-08-27 22:03 ` Dalon L Westergreen
2018-08-27 23:54 ` Marek Vasut
2018-08-28 15:43 ` Dalon L Westergreen
2018-08-28 15:51 ` Marek Vasut
2018-08-28 15:55 ` Dalon L Westergreen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.