[U-Boot] [PATCH 0/2] 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(-)
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
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.
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.
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.
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@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.
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@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.
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@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@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.
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@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@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.
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@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com> <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@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 ?
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@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com> <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@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 asthe 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?
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@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com> <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com>> <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com> <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@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 asthe 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 .
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@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com> <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com>> <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com> <mailto:dwesterg@gmail.com mailto:dwesterg@gmail.com <mailto:dwesterg@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 asthe 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?
participants (3)
-
Dalon L Westergreen -
Dalon Westergreen -
Marek Vasut