* [Buildroot] [Proposal] Build RPi dtbo overlays instead of just copying
@ 2017-01-18 19:32 Scott Ellis
2017-01-19 2:09 ` Thomas Petazzoni
0 siblings, 1 reply; 3+ messages in thread
From: Scott Ellis @ 2017-01-18 19:32 UTC (permalink / raw)
To: buildroot
Currently RPi dtbo overlays come from the rpi-firmware package and are
just copies of the binaries built upstream.
The source for the dtbos are in the same github.com/raspberrypi/linux
tree that Buildroot is using for the kernel and the main board dtb.
I'm suggesting the overlay dtbos should be in sync with the kernel
and the main dtb we are using and get built at the same time.
The particular problem I want to solve is to allow my modifications
to overlays or addition of new overlays both via standard kernel patches
get built and installed into the image.
I have a patch for this that I am already using.
I understand this is an RPi specific change to linux.mk, so I'm asking
first whether it is of interest and worthwhile submitting a patch.
It currently looks like this in my tree
diff --git a/linux/Config.in b/linux/Config.in
index f19dce1..7f0cb9d 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -383,6 +383,13 @@ config BR2_LINUX_KERNEL_CUSTOM_DTS_PATH
endif
+config BR2_LINUX_KERNEL_DTS_OVERLAYS_SUPPORT
+ bool "Build Device Tree Overlays"
+ depends on BR2_LINUX_KERNEL_DTS_SUPPORT
+ help
+ Build in-tree device tree overlays.
+ Currently supports Raspberry Pi kernels.
+
config BR2_LINUX_KERNEL_INSTALL_TARGET
bool "Install kernel image to /boot in target"
depends on !BR2_TARGET_ROOTFS_INITRAMFS
diff --git a/linux/linux.mk b/linux/linux.mk
index 7f4432e..f270e6e 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -309,6 +309,13 @@ define LINUX_INSTALL_DTB
endef
endif # BR2_LINUX_KERNEL_APPENDED_DTB
endif # BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT
+
+ifeq ($(BR2_LINUX_KERNEL_DTS_OVERLAYS_SUPPORT),y)
+define LINUX_INSTALL_DTB_OVERLAYS
+ cp $(KERNEL_ARCH_PATH)/boot/dts/overlays/*.dtbo $(1)
+endef
+endif # BR2_LINUX_KERNEL_DTS_OVERLAYS
+
endif # BR2_LINUX_KERNEL_DTS_SUPPORT
ifeq ($(BR2_LINUX_KERNEL_APPENDED_DTB),y)
@@ -350,6 +357,10 @@ define LINUX_BUILD_CMDS
@if grep -q "CONFIG_MODULES=y" $(@D)/.config; then \
$(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) modules ; \
fi
+ $(if $(BR2_LINUX_KERNEL_DTS_OVERLAYS_SUPPORT),
+ $(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) dtbs ; \
+ )
+
$(LINUX_BUILD_DTB)
$(LINUX_APPEND_DTB)
endef
@@ -373,6 +384,8 @@ ifeq ($(BR2_LINUX_KERNEL_INSTALL_TARGET),y)
define LINUX_INSTALL_KERNEL_IMAGE_TO_TARGET
$(call LINUX_INSTALL_IMAGE,$(TARGET_DIR)/boot)
$(call LINUX_INSTALL_DTB,$(TARGET_DIR)/boot)
+ mkdir -p $(TARGET_DIR)/boot/overlays
+ $(call LINUX_INSTALL_DTB_OVERLAYS,$(TARGET_DIR)/boot/overlays)
endef
endif
@@ -390,6 +403,8 @@ endef
define LINUX_INSTALL_IMAGES_CMDS
$(call LINUX_INSTALL_IMAGE,$(BINARIES_DIR))
$(call LINUX_INSTALL_DTB,$(BINARIES_DIR))
+ mkdir -p $(BINARIES_DIR)/rpi-firmware/overlays
+ $(call LINUX_INSTALL_DTB_OVERLAYS,$(BINARIES_DIR)/rpi-firmware/overlays)
endef
ifeq ($(BR2_STRIP_strip),y)
And something like this to prevent the rpi-firmware package from clobbering
the dtbos just built
diff --git a/package/rpi-firmware/rpi-firmware.mk b/package/rpi-firmware/rpi-firmware.mk
index f71991e..94ceb3b 100644
--- a/package/rpi-firmware/rpi-firmware.mk
+++ b/package/rpi-firmware/rpi-firmware.mk
@@ -21,6 +21,7 @@ define RPI_FIRMWARE_INSTALL_DTB
endef
endif
+ifneq ($(BR2_LINUX_KERNEL_DTS_OVERLAYS_SUPPORT),y)
ifeq ($(BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTB_OVERLAYS),y)
define RPI_FIRMWARE_INSTALL_DTB_OVERLAYS
for ovldtb in $(@D)/boot/overlays/*.dtbo; do \
@@ -28,6 +29,7 @@ define RPI_FIRMWARE_INSTALL_DTB_OVERLAYS
done
endef
endif
+endif # BR2_LINUX_KERNEL_DTS_OVERLAYS_SUPPORT
ifeq ($(BR2_PACKAGE_RPI_FIRMWARE_INSTALL_VCDBG),y)
define RPI_FIRMWARE_INSTALL_TARGET_CMDS
Probably better would be if the new BR2_LINUX_KERNEL_DTS_OVERLAYS_SUPPORT
and the existing BR2_PACKAGE_RPI_FIRMWARE_DTB_OVERLAYS vars were mutually
exclusive in the configuration. I can fix this.
At any rate, is this worth pursuing?
Best regards,
Scott
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [Buildroot] [Proposal] Build RPi dtbo overlays instead of just copying
2017-01-18 19:32 [Buildroot] [Proposal] Build RPi dtbo overlays instead of just copying Scott Ellis
@ 2017-01-19 2:09 ` Thomas Petazzoni
2017-01-19 21:31 ` Scott Ellis
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Petazzoni @ 2017-01-19 2:09 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 18 Jan 2017 14:32:46 -0500 (EST), Scott Ellis wrote:
> Currently RPi dtbo overlays come from the rpi-firmware package and are
> just copies of the binaries built upstream.
>
> The source for the dtbos are in the same github.com/raspberrypi/linux
> tree that Buildroot is using for the kernel and the main board dtb.
Indeed.
> I'm suggesting the overlay dtbos should be in sync with the kernel
> and the main dtb we are using and get built at the same time.
>
> The particular problem I want to solve is to allow my modifications
> to overlays or addition of new overlays both via standard kernel patches
> get built and installed into the image.
Makes sense.
> I understand this is an RPi specific change to linux.mk, so I'm asking
> first whether it is of interest and worthwhile submitting a patch.
Indeed the below is too RPi specific in my opinion. If we want to merge
a solution, it has to be more generic, which is difficult to achieve
because there are no overlays in the upstream Linux kernel so there is
nothing that shows what should be the "standard" way of
storing/building overlays.
> +ifeq ($(BR2_LINUX_KERNEL_DTS_OVERLAYS_SUPPORT),y)
> +define LINUX_INSTALL_DTB_OVERLAYS
> + cp $(KERNEL_ARCH_PATH)/boot/dts/overlays/*.dtbo $(1)
Perhaps the location where the .dtbo are produced should be
configurable, since it's not a standardized behavior that they end up
in arch/ARCH/boot/dts/overlays/ ?
> ifeq ($(BR2_LINUX_KERNEL_APPENDED_DTB),y)
> @@ -350,6 +357,10 @@ define LINUX_BUILD_CMDS
> @if grep -q "CONFIG_MODULES=y" $(@D)/.config; then \
> $(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) modules ; \
> fi
> + $(if $(BR2_LINUX_KERNEL_DTS_OVERLAYS_SUPPORT),
> + $(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) dtbs ; \
> + )
I'm not sure how to handle that one. It doesn't relate only to overlay
support, but also to regular Device Trees. It is actually going to
build all Device Trees that are enabled for the currently selected
kernel configuration.
BTW, if there is a make rule for .dtbo, have you tried simply adding
your list of .dtbo of interest to BR2_LINUX_KERNEL_USE_INTREE_DTS ?
> @@ -390,6 +403,8 @@ endef
> define LINUX_INSTALL_IMAGES_CMDS
> $(call LINUX_INSTALL_IMAGE,$(BINARIES_DIR))
> $(call LINUX_INSTALL_DTB,$(BINARIES_DIR))
> + mkdir -p $(BINARIES_DIR)/rpi-firmware/overlays
> + $(call LINUX_INSTALL_DTB_OVERLAYS,$(BINARIES_DIR)/rpi-firmware/overlays)
This rpi-firmware reference is clearly too RPi specific to be in
linux.mk.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Buildroot] [Proposal] Build RPi dtbo overlays instead of just copying
2017-01-19 2:09 ` Thomas Petazzoni
@ 2017-01-19 21:31 ` Scott Ellis
0 siblings, 0 replies; 3+ messages in thread
From: Scott Ellis @ 2017-01-19 21:31 UTC (permalink / raw)
To: buildroot
> BTW, if there is a make rule for .dtbo, have you tried simply adding
> your list of .dtbo of interest to BR2_LINUX_KERNEL_USE_INTREE_DTS ?
>
Its a little awkward, but I think it will work.
I had to add the 'overlays/' path to the dts name for the kernel
build to see it
For example
BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2710-rpi-3-b overlays/pwm-with-clk-overlay"
This is the same thing you have to do manually if you don't use the
'make dtbs' target.
scott at fractal:~/rpi/linux$ make pwm-with-clk.dtbo
make: *** No rule to make target 'pwm-with-clk.dtbo'. Stop.
scott at fractal:~/rpi/linux$ make pwm-with-clk-overlay.dtbo
make: *** No rule to make target 'pwm-with-clk-overlay.dtbo'. Stop.
scott at fractal:~/rpi/linux$ make overlays/pwm-with-clk.dtbo
make: *** No rule to make target 'overlays/pwm-with-clk.dtbo'. Stop.
scott at fractal:~/rpi/linux$ make overlays/pwm-with-clk-overlay.dtbo
make: *** No rule to make target 'overlays/pwm-with-clk-overlay.dtbo'. Stop.
scott at fractal:~/rpi/linux$ make overlays/pwm-with-clk-overlay.dtb
...
DTC arch/arm/boot/dts/overlays/pwm-with-clk-overlay.dtb
The overlay that's generated has the name 'pwm-with-clk-overlay.dtb'
So it still has to be renamed for the RPi to use it as an overlay
pwm-with-clk-overlay.dtb -> pwm-with-clk.dtbo
And it has to be copied to the boot partition 'overlays/' directory.
But this can all be handled in a post-xxx script.
Unless there is a better suggestion, I'll play around with doing
it this way instead.
Thanks.
Best regards,
Scott
"Thomas Petazzoni" <thomas.petazzoni@free-electrons.com> said:
> Hello,
>
> On Wed, 18 Jan 2017 14:32:46 -0500 (EST), Scott Ellis wrote:
>> Currently RPi dtbo overlays come from the rpi-firmware package and are
>> just copies of the binaries built upstream.
>>
>> The source for the dtbos are in the same github.com/raspberrypi/linux
>> tree that Buildroot is using for the kernel and the main board dtb.
>
> Indeed.
>
>> I'm suggesting the overlay dtbos should be in sync with the kernel
>> and the main dtb we are using and get built at the same time.
>>
>> The particular problem I want to solve is to allow my modifications
>> to overlays or addition of new overlays both via standard kernel patches
>> get built and installed into the image.
>
> Makes sense.
>
>> I understand this is an RPi specific change to linux.mk, so I'm asking
>> first whether it is of interest and worthwhile submitting a patch.
>
> Indeed the below is too RPi specific in my opinion. If we want to merge
> a solution, it has to be more generic, which is difficult to achieve
> because there are no overlays in the upstream Linux kernel so there is
> nothing that shows what should be the "standard" way of
> storing/building overlays.
>
>> +ifeq ($(BR2_LINUX_KERNEL_DTS_OVERLAYS_SUPPORT),y)
>> +define LINUX_INSTALL_DTB_OVERLAYS
>> + cp $(KERNEL_ARCH_PATH)/boot/dts/overlays/*.dtbo $(1)
>
> Perhaps the location where the .dtbo are produced should be
> configurable, since it's not a standardized behavior that they end up
> in arch/ARCH/boot/dts/overlays/ ?
>
>> ifeq ($(BR2_LINUX_KERNEL_APPENDED_DTB),y)
>> @@ -350,6 +357,10 @@ define LINUX_BUILD_CMDS
>> @if grep -q "CONFIG_MODULES=y" $(@D)/.config; then \
>> $(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) modules ;
>> \
>> fi
>> + $(if $(BR2_LINUX_KERNEL_DTS_OVERLAYS_SUPPORT),
>> + $(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) dtbs ;
>> \
>> + )
>
> I'm not sure how to handle that one. It doesn't relate only to overlay
> support, but also to regular Device Trees. It is actually going to
> build all Device Trees that are enabled for the currently selected
> kernel configuration.
>
> BTW, if there is a make rule for .dtbo, have you tried simply adding
> your list of .dtbo of interest to BR2_LINUX_KERNEL_USE_INTREE_DTS ?
>
>> @@ -390,6 +403,8 @@ endef
>> define LINUX_INSTALL_IMAGES_CMDS
>> $(call LINUX_INSTALL_IMAGE,$(BINARIES_DIR))
>> $(call LINUX_INSTALL_DTB,$(BINARIES_DIR))
>> + mkdir -p $(BINARIES_DIR)/rpi-firmware/overlays
>> + $(call LINUX_INSTALL_DTB_OVERLAYS,$(BINARIES_DIR)/rpi-firmware/overlays)
>
> This rpi-firmware reference is clearly too RPi specific to be in
> linux.mk.
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-01-19 21:31 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-18 19:32 [Buildroot] [Proposal] Build RPi dtbo overlays instead of just copying Scott Ellis
2017-01-19 2:09 ` Thomas Petazzoni
2017-01-19 21:31 ` Scott Ellis
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.