socfpga: cleanup files generated for spl

PATCH Superseded Dalon Westergreen 3 participants 13 messages Aug 20, 2018 – Aug 28, 2018 Kbuild

Share & tools

Dalon Westergreen

author

2018-08-20 13:54 UTC #0 lore raw

cover socfpga: cleanup files generated for spl

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(-)

Signature · 1 line

2.17.1

Dalon Westergreen

author

2018-08-20 13:54 UTC #1 lore raw

PATCH 1/2 spl: socfpga: only gen5 devices and arria10 require sfp image

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 <[email protected]>

---
 scripts/Makefile.spl | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

scripts/Makefile.spl +2 -1

index 252f13826d..76d08fd92b 100644
@@ -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

Signature · 1 line

2.17.1

Dalon Westergreen

author

2018-08-20 13:54 UTC #2 lore raw

PATCH 2/2 spl: socfpga: stratix10: add hex file output for spl image

In reply to 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 <[email protected]>

---
 scripts/Makefile.spl | 10 ++++++++++
 1 file changed, 10 insertions(+)

scripts/Makefile.spl +10 -0

index 76d08fd92b..c424f87e6e 100644
@@ -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.

Signature · 1 line

2.17.1

Marek Vasut

2018-08-20 18:33 UTC #3 lore raw

PATCH 2/2 spl: socfpga: stratix10: add hex file output for spl image

Quoted 22 lines · 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 <[email protected]>
---
 scripts/Makefile.spl | 10 ++++++++++
 1 file changed, 10 insertions(+)
scripts/Makefile.spl +1 -0
index 76d08fd92b..c424f87e6e 100644
@@ -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

scripts/Makefile.spl OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j .start16 -j .resetvec · line 304

Quoted 5 lines

scripts/Makefile.spl +2 -0

@@ -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 ...

Quoted 11 lines

scripts/Makefile.spl +7 -0

+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.

Signature · 2 lines

Best regards,
Marek Vasut

Dalon L Westergreen

2018-08-20 21:04 UTC #4 lore raw

PATCH 2/2 spl: socfpga: stratix10: add hex file output for spl image

Quoted 29 lines · 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 <[email protected]>

---
 scripts/Makefile.spl | 10 ++++++++++
 1 file changed, 10 insertions(+)

scripts/Makefile.spl +3 -0

index 76d08fd92b..c424f87e6e 100644
@@ -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

Quoted 3 lines

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.

Quoted 15 lines

scripts/Makefile.spl +7 -0

+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.

Marek Vasut

2018-08-21 03:52 UTC #5 lore raw

PATCH 2/2 spl: socfpga: stratix10: add hex file output for spl image

Quoted 30 lines · Dalon L Westergreen

Quoted 29 lines · 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 <dwesterg at gmail.com <mailto:[email protected]>>
---
 scripts/Makefile.spl | 10 ++++++++++
 1 file changed, 10 insertions(+)
scripts/Makefile.spl +3 -0
index 76d08fd92b..c424f87e6e 100644
@@ -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
 

Quoted 8 lines

Quoted 3 lines
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.

Signature · 2 lines

Best regards,
Marek Vasut

Dalon L Westergreen

2018-08-27 15:30 UTC #6 lore raw

PATCH 2/2 spl: socfpga: stratix10: add hex file output for spl image

Quoted 34 lines · 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 <dwesterg at gmail.com <mailto:[email protected]>>
---
 scripts/Makefile.spl | 10 ++++++++++
 1 file changed, 10 insertions(+)
scripts/Makefile.spl +3 -0
index 76d08fd92b..c424f87e6e 100644
@@ -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 ...

Quoted 8 lines

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.

Marek Vasut

2018-08-27 19:03 UTC #7 lore raw

PATCH 2/2 spl: socfpga: stratix10: add hex file output for spl image

Quoted 45 lines · Dalon L Westergreen

Quoted 34 lines · 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 <dwesterg at gmail.com <mailto:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>>>
---
 scripts/Makefile.spl | 10 ++++++++++
 1 file changed, 10 insertions(+)
scripts/Makefile.spl +3 -0
index 76d08fd92b..c424f87e6e 100644
@@ -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 ...
Quoted 8 lines
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.

Quoted 5 lines

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.

Signature · 2 lines

Best regards,
Marek Vasut

Dalon L Westergreen

2018-08-27 22:03 UTC #8 lore raw

PATCH 2/2 spl: socfpga: stratix10: add hex file output for spl image

Quoted 48 lines · 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 <dwesterg at gmail.com <mailto:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>>>
---
 scripts/Makefile.spl | 10 ++++++++++
 1 file changed, 10 insertions(+)
scripts/Makefile.spl +3 -0
index 76d08fd92b..c424f87e6e 100644
@@ -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

Quoted 8 lines

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.

Marek Vasut

2018-08-27 23:54 UTC #9 lore raw

PATCH 2/2 spl: socfpga: stratix10: add hex file output for spl image

Quoted 51 lines · Dalon L Westergreen

Quoted 50 lines · 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 <dwesterg at gmail.com <mailto:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>> <mailto:dwesterg at gmail.com <mailto:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>>>>
---
 scripts/Makefile.spl | 10 ++++++++++
 1 file changed, 10 insertions(+)
scripts/Makefile.spl +3 -0
index 76d08fd92b..c424f87e6e 100644
@@ -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

Quoted 7 lines

Quoted 6 lines
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

Quoted 5 lines

but there only 2 lines that differ when
using the change address option, the first and last, of the hex.

Quoted 8 lines

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 ?

Signature · 2 lines

Best regards,
Marek Vasut

Dalon L Westergreen

2018-08-28 15:43 UTC #10 lore raw

PATCH 2/2 spl: socfpga: stratix10: add hex file output for spl image

Quoted 103 lines · 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:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>> <mailto:dwesterg at gmail.com <mailto:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>>>>
---
 scripts/Makefile.spl | 10 ++++++++++
 1 file changed, 10 insertions(+)
scripts/Makefile.spl +3 -0
index 76d08fd92b..c424f87e6e 100644
@@ -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.

Quoted 8 lines

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?

Marek Vasut

2018-08-28 15:51 UTC #11 lore raw

PATCH 2/2 spl: socfpga: stratix10: add hex file output for spl image

Quoted 115 lines · Dalon L Westergreen

Quoted 103 lines · 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:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>> <mailto:dwesterg at gmail.com <mailto:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>>> <mailto:dwesterg at gmail.com <mailto:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>> <mailto:dwesterg at gmail.com <mailto:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>>>>>
---
 scripts/Makefile.spl | 10 ++++++++++
 1 file changed, 10 insertions(+)
scripts/Makefile.spl +3 -0
index 76d08fd92b..c424f87e6e 100644
@@ -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.
Quoted 8 lines
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

Quoted 5 lines

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 .

Signature · 2 lines

Best regards,
Marek Vasut

Dalon L Westergreen

2018-08-28 15:55 UTC #12 lore raw

PATCH 2/2 spl: socfpga: stratix10: add hex file output for spl image

Quoted 118 lines · 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 <dwesterg at gmail.com <mailto:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>> <mailto:dwesterg at gmail.com <mailto:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>>> <mailto:dwesterg at gmail.com <mailto:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>> <mailto:dwesterg at gmail.com <mailto:[email protected]> <mailto:dwesterg at gmail.com <mailto:[email protected]>>>>>
---
 scripts/Makefile.spl | 10 ++++++++++
 1 file changed, 10 insertions(+)
scripts/Makefile.spl +3 -0
index 76d08fd92b..c424f87e6e 100644
@@ -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

Quoted 9 lines

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?