mbox series

[RFC,00/13] ARM: dts: DT overlay support infra + some data

Message ID 1523956215-28154-1-git-send-email-t-kristo@ti.com
Headers show
Series ARM: dts: DT overlay support infra + some data | expand

Message

Tero Kristo April 17, 2018, 9:10 a.m. UTC 
Hi,

This series is an attempt to start discussion on the DT overlay build time
support. Basically, one can build DT overlays directly from kernel tree,
and also build FIT images that contain the kernel + devicetree blobs
required for specific configuration that can be booted directly with
u-boot. No runtime support for overlay switching is touched by this
series.

What this series does, is to:

1) add subdir support under arch/arm/boot/dts
2) provide DT overlay build support to kernel tree
3) provide FIT image build support to kernel tree
4) provide a number of DT overlay + FIT image files for some TI SoCs
   to show the reasons why we are doing this, this is only a subset
   of our boards that we would want to use overlays with

Main reason for TI to use DT overlays right now is the rather large
amount of different displays we have around, which can be used with
different boards. With the current approach one needs to write a
separate .dts file for each board + display config, but with overlays,
one can just create a single overlay that would apply to different boards.
There are some other cases like the shown dra71-evm case in this series,
where the gpmc vs. display support is mutually exclusive, as they are
sharing certain pieces of the HW.

The main controversy with this series is most likely where the DT overlay
files should be stored at. Should they still reside with the kernel
tree or someplace else? Also, the FIT image support is probably
controversial, should it be part of the kernel build system like shown
here, or should it be separate? The zImage dependency is pretty annoying
so maybe it should be done somewhere else.

Any comments welcome as this is just an RFC for now, but basically we
would really want a solution to this problem.

-Tero


--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Russell King April 17, 2018, 9:18 a.m. UTC | #1 
Hi,

Please copy me at linux@armlinux.org.uk not rmk@armlinux.org.uk - this
entire series has ended up in my spam folder.

On Tue, Apr 17, 2018 at 12:10:02PM +0300, Tero Kristo wrote:
> Hi,

> 

> This series is an attempt to start discussion on the DT overlay build time

> support. Basically, one can build DT overlays directly from kernel tree,

> and also build FIT images that contain the kernel + devicetree blobs

> required for specific configuration that can be booted directly with

> u-boot. No runtime support for overlay switching is touched by this

> series.

>

> The main controversy with this series is most likely where the DT overlay

> files should be stored at. Should they still reside with the kernel

> tree or someplace else? Also, the FIT image support is probably

> controversial, should it be part of the kernel build system like shown

> here, or should it be separate? The zImage dependency is pretty annoying

> so maybe it should be done somewhere else.


Please, no, do not add any further build targets for special boot loader
formats.  We already deprecate the "uImage" format when building multi-
platform kernels.

The problem is that we either need to pass in parameters like the load
address and dtb path to include in the image, or we need to add to the
kernel build system the load addresses for every platform, and generate
hundreds of images eating up lots of disk space, and adding to the
kernel build time.

When we switched to dtb and multi-platform support, we decided that it
was much better that such bootloader specific stuff be external to the
kernel tree.

-- 
Russell King
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html