* [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.