[U-Boot] [PATCH] kbuild: get back DTB at the top directory
Commit 6ab6b2af deleted ./u-boot.dtb because it was a copy of dts/dt.dtb.
But Simon suggested to keep u-boot.dtb at the top directory because it is a build output.
After discussions, we agreed on revival of ./u-boot.dtb.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com Cc: Simon Glass sjg@chromium.org Cc: Tom Rini trini@ti.com ---
Hello Simon,
In our discussions, I memtioned to post version 4 of "dts: re-write dts/Makefile more simply with Kbuild".
But, before that, version 3 has been applied.
Anyway, I promised to get back ./u-boot.dtb, so I'm posting this patch.
To avoid a conflict with other patches, this patch is rebased on "Follow-up for Kbuild series: more misc targets and short logs" series. (And using Kbuild style to display short log)
BTW, another question hit me when I was writing this patch. Please let me ask you a little more questions.
I guess the reason why you want device tree at the top directory is Sandbox. Is this right? If so, I am 100% convinced and I'd like to suggest to modify
ALL-$(CONFIG_OF_SEPARATE) += u-boot.dtb u-boot-dtb.bin
to
ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb.bin ALL-$(CONFIG_OF_HOSTFILE) += u-boot.dtb
Is this better? For CONFIG_OF_SEPARATE, I think there is no opportunity to use u-boot.dtb because we have u-boot-dtb.bin.
Makefile | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile index b91381c..db263ef 100644 --- a/Makefile +++ b/Makefile @@ -720,7 +720,7 @@ ALL-$(CONFIG_RAMBOOT_PBL) += u-boot.pbl ALL-$(CONFIG_SPL) += spl/u-boot-spl.bin ALL-$(CONFIG_SPL_FRAMEWORK) += u-boot.img ALL-$(CONFIG_TPL) += tpl/u-boot-tpl.bin -ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb.bin +ALL-$(CONFIG_OF_SEPARATE) += u-boot.dtb u-boot-dtb.bin ifneq ($(CONFIG_SPL_TARGET),) ALL-$(CONFIG_SPL) += $(CONFIG_SPL_TARGET:"%"=%) endif @@ -766,6 +766,12 @@ dtbs dts/dt.dtb: checkdtc u-boot u-boot-dtb.bin: u-boot.bin dts/dt.dtb FORCE $(call if_changed,cat)
+quiet_cmd_copy = COPY $@ + cmd_copy = cp $< $@ + +u-boot.dtb: dts/dt.dtb + $(call cmd,copy) + OBJCOPYFLAGS_u-boot.hex := -O ihex
OBJCOPYFLAGS_u-boot.srec := -O srec
On 20 February 2014 22:34, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Commit 6ab6b2af deleted ./u-boot.dtb because it was a copy of dts/dt.dtb.
But Simon suggested to keep u-boot.dtb at the top directory because it is a build output.
After discussions, we agreed on revival of ./u-boot.dtb.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com Cc: Simon Glass sjg@chromium.org Cc: Tom Rini trini@ti.com
Acked-by: Simon Glass sjg@chromium.org
Hello Simon,
In our discussions, I memtioned to post version 4 of "dts: re-write dts/Makefile more simply with Kbuild".
But, before that, version 3 has been applied.
Anyway, I promised to get back ./u-boot.dtb, so I'm posting this patch.
To avoid a conflict with other patches, this patch is rebased on "Follow-up for Kbuild series: more misc targets and short logs" series. (And using Kbuild style to display short log)
BTW, another question hit me when I was writing this patch. Please let me ask you a little more questions.
I guess the reason why you want device tree at the top directory is Sandbox. Is this right? If so, I am 100% convinced and I'd like to suggest to modify
ALL-$(CONFIG_OF_SEPARATE) += u-boot.dtb u-boot-dtb.binto
ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb.bin ALL-$(CONFIG_OF_HOSTFILE) += u-boot.dtbIs this better? For CONFIG_OF_SEPARATE, I think there is no opportunity to use u-boot.dtb because we have u-boot-dtb.bin.
Well some build systems may take the u-boot.dtb and package it up with U-Boot in a different way. Also they may look inside this file to find out things about the board they are targeting. For example, you might imagine a flash program which gets flash programming parameters from this file so it knows how to flash the board.
I don't consider something in the dts/ directory to be a build product really. I suspect one day we might support multiple .dtb files in U-Boot and select between them based on a setting or a hardware feature, and in that case perhaps everything will be put in a FIT, but we are not there yet.
But for now I see the .dtb file as a first-class build product just like the main U-Boot binary.
Regards, Simon
Hello Simon,
Well some build systems may take the u-boot.dtb and package it up with U-Boot in a different way. Also they may look inside this file to find out things about the board they are targeting. For example, you might imagine a flash program which gets flash programming parameters from this file so it knows how to flash the board.
I don't consider something in the dts/ directory to be a build product really. I suspect one day we might support multiple .dtb files in U-Boot and select between them based on a setting or a hardware feature, and in that case perhaps everything will be put in a FIT, but we are not there yet.
But for now I see the .dtb file as a first-class build product just like the main U-Boot binary.
Then, I agreed to include this version to the main line. Thanks for your answering.
I confirmed this patch can apply on commit 1674df60 + Follow-up for Kbuild series v2.
Best Regards Masahiro Yamada
On Fri, Feb 21, 2014 at 03:34:30PM +0900, Masahiro Yamada wrote:
Commit 6ab6b2af deleted ./u-boot.dtb because it was a copy of dts/dt.dtb.
But Simon suggested to keep u-boot.dtb at the top directory because it is a build output.
After discussions, we agreed on revival of ./u-boot.dtb.
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com Cc: Simon Glass sjg@chromium.org Cc: Tom Rini trini@ti.com Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
participants (3)
-
Masahiro Yamada -
Simon Glass -
Tom Rini