[Buildroot] [PATCH 0/7] RPi: enable building a device-tree-enabled kernel (branch yem/rpi-dt)

[Buildroot] [PATCH 0/7] RPi: enable building a device-tree-enabled kernel (branch yem/rpi-dt)

[Yann E. MORIN]

Hello All!

Recently, the Raspberry Pi fork of the kernel has gained support
for the device tree.

This series is an attempt at making it smoothly available in Buildroot:

  - allow Buildroot to build a DT kernel without necessarily building
    the DTB (the DTB can be hard-coded on a board, for example, or the
    bootloader will provide it, either dynamically built at runtime,
    or bundled in the bootloader sources);

  - bump rpi-firmware, and use different versions depending on
    whether we are using a DT kernel or not; install the DTBs when
    needed.

It is to be moted that the device tree support on the Raspberry Pi is
not trivially similar to how all other boards behave.


====
First, the bootloader needs to know if the kernel has DT support or not,
so it looks for a magic DTOK footer (a header at the end); if this header
is present, DT support is assumed, and the bootloader loads the DTB.

This is not very much like what is done on other boards...

====
Second, the bootloader knows what model of the RPi it boots on, and is
thus capable of loading the correct DTB. This is nice, because it means
that a single firmware will work on all RPI models, auto magically.

This requires the kernel image has the footer appended, of course.


===
Third, if the kernel does not have a DTOK footer, it is possible to
force-load a DTB, by adding a directive in the config.txt file (the
configuration of the bootloader).

In this case, the bootloader will force-load that file as a DTB before
booting the kernel.

But we loose the autodetection of the model we are running on, and
it is not longer possible to run the same firmware on all models.


===
Eventually, there is a not-so-simple perl script that is provided in
a separate RPi repository. Since this repository is rather huge, we
just copied that script and bundled it in Buildroot.

Notes: I've upstreamed a fix for that perl script, that has been
accepted. Round-trip: 2 hours! Yeah! :-)


===
This has been tested to work great with the currently-latest cset on
the rpi-3.18.y branch, at:
    https://github.com/raspberrypi/linux/tree/rpi-3.18.y
    5fdce56c57f419a8f8a57a6c5b90d63deabca713

Since this is not their stable branch, that specific commit may disapear
any time; just use the latest commit on rpi-3.18.y .

Regards,
Yann E. MORIN.


The following changes since commit b7e7b417fa1210a7f9c4e76ee747238981dcd012:

  wpa_supplicant: fix indentation and change file permissions (2015-01-01 11:31:14 +0100)

are available in the git repository at:

  git://git.busybox.net/~ymorin/git/buildroot yem/rpi-dt

for you to fetch changes up to 0c0f5c97634b438044f09c32bdc42edcd878feb0:

  package/rpi-firmware: append the DTOK footer for DT-aware kernel (2015-01-01 18:33:20 +0100)

----------------------------------------------------------------
Yann E. MORIN (7):
      package/rpi-firmware: bump version
      linux: add option to rely on a bootloader-provided DTB
      docs/manual: document LIBFOO_INSTALL_IMAGES
      package/rpi-firmware: only install images
      package/rpi-firmware: add DT-aware marking script
      package/rpi-firmware: install DTB blobs
      package/rpi-firmware: append the DTOK footer for DT-aware kernel

 docs/manual/adding-packages-generic.txt |   5 +
 linux/Config.in                         |   8 ++
 linux/linux.mk                          |  12 +-
 package/rpi-firmware/Config.in          |  11 ++
 package/rpi-firmware/mkknlimg           | 204 ++++++++++++++++++++++++++++++++
 package/rpi-firmware/rpi-firmware.mk    |  41 ++++++-
 6 files changed, 278 insertions(+), 3 deletions(-)
 create mode 100755 package/rpi-firmware/mkknlimg

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 1/7] package/rpi-firmware: bump version

[Yann E. MORIN]

Too many changes to list, but lots of fixes and enhancements all over
the place...

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 package/rpi-firmware/rpi-firmware.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/rpi-firmware/rpi-firmware.mk b/package/rpi-firmware/rpi-firmware.mk
index 033ff33..7ebd38c 100644
--- a/package/rpi-firmware/rpi-firmware.mk
+++ b/package/rpi-firmware/rpi-firmware.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-RPI_FIRMWARE_VERSION = 53162d55fa557e60453c0652aa00fa3daf4ed618
+RPI_FIRMWARE_VERSION = 393dcc0e76f18f6ac1b67ba45d36058410670034
 RPI_FIRMWARE_SITE = $(call github,raspberrypi,firmware,$(RPI_FIRMWARE_VERSION))
 RPI_FIRMWARE_LICENSE = BSD-3c
 RPI_FIRMWARE_LICENSE_FILES = boot/LICENCE.broadcom
-- 
1.9.1

[Buildroot] [PATCH 1/7] package/rpi-firmware: bump version

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Thu,  1 Jan 2015 21:23:47 +0100, Yann E. MORIN wrote:
> Too many changes to list, but lots of fixes and enhancements all over
> the place...
> 
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> ---
>  package/rpi-firmware/rpi-firmware.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2/7] linux: add option to rely on a bootloader-provided DTB

[Yann E. MORIN]

On some platforms (e.g. the Raspberry Pi), the DTB is already bundled
with the bootloader, and installed with it. On some other platforms, the
DTB might even be stored on the device itself (which is the ultimate
goal of the DTB).

So far, when we build a kernel with DT support, we forcibly want a to
also build the DTB blob, which goes against the situations described
above.

Add a new option in the DT choice, to specify the DTB will be provided
by the bootloader or the device itself.

This also means we must be a little bit more selective when we check the
validity of the DTS name at build time.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 linux/Config.in |  8 ++++++++
 linux/linux.mk  | 12 +++++++++++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/linux/Config.in b/linux/Config.in
index ba4b574..6d994ee 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -313,6 +313,14 @@ config BR2_LINUX_KERNEL_USE_CUSTOM_DTS
 	  Use a custom device tree file, i.e, a device
 	  tree file that does not belong to the kernel
 	  source tree.
+
+config BR2_LINUX_KERNEL_USE_EXTERNAL_DTS
+	bool "Use a bootloader-provided device tree blob"
+	help
+	  Say 'y' here if your device tree blob is already
+	  bundled by the bootloader, or already present on
+	  the board.
+
 endchoice
 
 config BR2_LINUX_KERNEL_INTREE_DTS_NAME
diff --git a/linux/linux.mk b/linux/linux.mk
index 8256641..9b1f19b 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -59,16 +59,20 @@ LINUX_MAKE_FLAGS = \
 # going to be installed in the target filesystem.
 LINUX_VERSION_PROBED = $(shell $(MAKE) $(LINUX_MAKE_FLAGS) -C $(LINUX_DIR) --no-print-directory -s kernelrelease)
 
+ifeq ($(BR2_LINUX_KERNEL_DTS_SUPPORT),y)
+
 ifeq ($(BR2_LINUX_KERNEL_USE_INTREE_DTS),y)
 KERNEL_DTS_NAME = $(call qstrip,$(BR2_LINUX_KERNEL_INTREE_DTS_NAME))
 else ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM_DTS),y)
 KERNEL_DTS_NAME = $(basename $(notdir $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH))))
 endif
 
-ifeq ($(BR2_LINUX_KERNEL_DTS_SUPPORT)$(KERNEL_DTS_NAME),y)
+ifeq ($(BR2_LINUX_KERNEL_USE_INTREE_DTS)$(BR2_LINUX_KERNEL_USE_CUSTOM_DTS),y)
+ifeq ($(KERNEL_DTS_NAME),)
 $(error No kernel device tree source specified, check your \
 BR2_LINUX_KERNEL_USE_INTREE_DTS / BR2_LINUX_KERNEL_USE_CUSTOM_DTS settings)
 endif
+endif
 
 ifeq ($(BR2_LINUX_KERNEL_APPENDED_DTB),y)
 ifneq ($(words $(KERNEL_DTS_NAME)),1)
@@ -79,6 +83,8 @@ endif
 
 KERNEL_DTBS = $(addsuffix .dtb,$(KERNEL_DTS_NAME))
 
+endif # BR2_LINUX_KERNEL_DTS_SUPPORT == y
+
 ifeq ($(BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM),y)
 LINUX_IMAGE_NAME = $(call qstrip,$(BR2_LINUX_KERNEL_IMAGE_NAME))
 LINUX_TARGET_NAME = $(call qstrip,$(BR2_LINUX_KERNEL_IMAGE_TARGET_NAME))
@@ -212,12 +218,15 @@ define LINUX_CONFIGURE_CMDS
 		$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY,$(@D)/.config)
 		$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY_SMACK,$(@D)/.config)
 		$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY_NETWORK,$(@D)/.config))
+	$(if $(BR2_LINUX_KERNEL_DTS_SUPPORT),
+		$(call KCONFIG_ENABLE_OPT,CONFIG_USE_OF,$(@D)/.config))
 	$(if $(BR2_LINUX_KERNEL_APPENDED_DTB),
 		$(call KCONFIG_ENABLE_OPT,CONFIG_ARM_APPENDED_DTB,$(@D)/.config))
 	yes '' | $(TARGET_MAKE_ENV) $(MAKE1) $(LINUX_MAKE_FLAGS) -C $(@D) oldconfig
 endef
 
 ifeq ($(BR2_LINUX_KERNEL_DTS_SUPPORT),y)
+ifeq ($(BR2_LINUX_KERNEL_USE_EXTERNAL_DTS),)
 ifeq ($(BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT),)
 define LINUX_BUILD_DTB
 	$(TARGET_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(KERNEL_DTBS)
@@ -238,6 +247,7 @@ define LINUX_INSTALL_DTB_TARGET
 endef
 endif
 endif
+endif
 
 ifeq ($(BR2_LINUX_KERNEL_APPENDED_DTB),y)
 # dtbs moved from arch/$ARCH/boot to arch/$ARCH/boot/dts since 3.8-rc1
-- 
1.9.1

[Buildroot] [PATCH 2/7] linux: add option to rely on a bootloader-provided DTB

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Thu,  1 Jan 2015 21:23:48 +0100, Yann E. MORIN wrote:
> On some platforms (e.g. the Raspberry Pi), the DTB is already bundled
> with the bootloader, and installed with it. On some other platforms, the
> DTB might even be stored on the device itself (which is the ultimate
> goal of the DTB).
> 
> So far, when we build a kernel with DT support, we forcibly want a to
> also build the DTB blob, which goes against the situations described
> above.
> 
> Add a new option in the DT choice, to specify the DTB will be provided
> by the bootloader or the device itself.
> 
> This also means we must be a little bit more selective when we check the
> validity of the DTS name at build time.
> 
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

I don't really see the point of this. If you don't want to build a DTB,
then don't tell Buildroot that you want to build a DTB, and that's it.
Why would we want such a patch?

Enabling CONFIG_OF should be done by the platform defconfig. It really
is tied to how the platform is supported in the Linux kernel, and is
not something that Buildroot should touch IMO.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2/7] linux: add option to rely on a bootloader-provided DTB

[Yann E. MORIN]

Thomas, All,

On 2015-01-01 22:24 +0100, Thomas Petazzoni spake thusly:
> On Thu,  1 Jan 2015 21:23:48 +0100, Yann E. MORIN wrote:
> > On some platforms (e.g. the Raspberry Pi), the DTB is already bundled
> > with the bootloader, and installed with it. On some other platforms, the
> > DTB might even be stored on the device itself (which is the ultimate
> > goal of the DTB).
> > 
> > So far, when we build a kernel with DT support, we forcibly want a to
> > also build the DTB blob, which goes against the situations described
> > above.
> > 
> > Add a new option in the DT choice, to specify the DTB will be provided
> > by the bootloader or the device itself.
> > 
> > This also means we must be a little bit more selective when we check the
> > validity of the DTS name at build time.
> > 
> > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> I don't really see the point of this. If you don't want to build a DTB,
> then don't tell Buildroot that you want to build a DTB, and that's it.
> Why would we want such a patch?
> 
> Enabling CONFIG_OF should be done by the platform defconfig. It really
> is tied to how the platform is supported in the Linux kernel, and is
> not something that Buildroot should touch IMO.

Fact is, the prompt reads:

    [*] Device tree support

So, I take that as "build a kernel with support for the device tree",
not as "build a DTB".

But Now I think of it, this patch is doing two things:

  - enable USE_OF when that option is enabled,

  - add support for bootloader- or board-provided DTB.

Maybe that should be split up in two, then?

Or do you still want that option to mean "build a DTB" ?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 2/7] linux: add option to rely on a bootloader-provided DTB

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Thu, 1 Jan 2015 22:44:35 +0100, Yann E. MORIN wrote:

> Fact is, the prompt reads:
> 
>     [*] Device tree support
> 
> So, I take that as "build a kernel with support for the device tree",
> not as "build a DTB".

Right, the prompt may not be the most appropriate one.

> But Now I think of it, this patch is doing two things:
> 
>   - enable USE_OF when that option is enabled,
> 
>   - add support for bootloader- or board-provided DTB.
> 
> Maybe that should be split up in two, then?
> 
> Or do you still want that option to mean "build a DTB" ?

Yes, I believe the prompt should be changed. I really don't see the
point of adding a new entry in the choice to simply mean "do nothing".

And also, enabling CONFIG_OF should be done by the defconfig of the
platform, not by Buildroot.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2/7] linux: add option to rely on a bootloader-provided DTB

[Yann E. MORIN]

Thomas, All,

On 2015-01-01 22:51 +0100, Thomas Petazzoni spake thusly:
> On Thu, 1 Jan 2015 22:44:35 +0100, Yann E. MORIN wrote:
> 
> > Fact is, the prompt reads:
> > 
> >     [*] Device tree support
> > 
> > So, I take that as "build a kernel with support for the device tree",
> > not as "build a DTB".
> 
> Right, the prompt may not be the most appropriate one.

OK.

> > But Now I think of it, this patch is doing two things:
> > 
> >   - enable USE_OF when that option is enabled,
> > 
> >   - add support for bootloader- or board-provided DTB.
> > 
> > Maybe that should be split up in two, then?
> > 
> > Or do you still want that option to mean "build a DTB" ?
> 
> Yes, I believe the prompt should be changed. I really don't see the
> point of adding a new entry in the choice to simply mean "do nothing".
> 
> And also, enabling CONFIG_OF should be done by the defconfig of the
> platform, not by Buildroot.

OK, thanks for the position statement.

However, I beg to disagree on that last part: I think we should have
this as an option in Buildroot.

The reason is that some platforms can be built with or without support
for the device tree. The Raspberry Pi is but one such platform; there
are others. Their defconfig do not always enable USE_OF by default, it
must be a volunteer selection from the user.

In that case, your opinion is to delegate to the user the responsibility
to enable that on his own, right? So, it would no longer be possible to
use in-tree defconfigs for those boards, for example.

But as a starter, I'll rename the prompt, so it is no longer ambiguous.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 2/7] linux: add option to rely on a bootloader-provided DTB

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Thu, 1 Jan 2015 22:58:45 +0100, Yann E. MORIN wrote:

> However, I beg to disagree on that last part: I think we should have
> this as an option in Buildroot.
> 
> The reason is that some platforms can be built with or without support
> for the device tree. The Raspberry Pi is but one such platform; there
> are others. Their defconfig do not always enable USE_OF by default, it
> must be a volunteer selection from the user.
> 
> In that case, your opinion is to delegate to the user the responsibility
> to enable that on his own, right? So, it would no longer be possible to
> use in-tree defconfigs for those boards, for example.

Well, to me this is a slippery slope. There are gazillions of kernel
options that do platform-specific stuff. So far, we really tried hard
to limit how much Buildroot modifies the kernel options, and tried to
limit that to cases related to userspace components enabled by the user
that really need some feature in the kernel.

Let's see what Peter thinks about this, he might very well have a
different opinion on this.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2/7] linux: add option to rely on a bootloader-provided DTB

[Yann E. MORIN]

Thomas, All,

On 2015-01-01 23:17 +0100, Thomas Petazzoni spake thusly:
> Dear Yann E. MORIN,
> 
> On Thu, 1 Jan 2015 22:58:45 +0100, Yann E. MORIN wrote:
> 
> > However, I beg to disagree on that last part: I think we should have
> > this as an option in Buildroot.
> > 
> > The reason is that some platforms can be built with or without support
> > for the device tree. The Raspberry Pi is but one such platform; there
> > are others. Their defconfig do not always enable USE_OF by default, it
> > must be a volunteer selection from the user.
> > 
> > In that case, your opinion is to delegate to the user the responsibility
> > to enable that on his own, right? So, it would no longer be possible to
> > use in-tree defconfigs for those boards, for example.
> 
> Well, to me this is a slippery slope. There are gazillions of kernel
> options that do platform-specific stuff. So far, we really tried hard
> to limit how much Buildroot modifies the kernel options, and tried to
> limit that to cases related to userspace components enabled by the user
> that really need some feature in the kernel.

Ok, it all makes sense. I agree, we should be pretty conservative about
what we're doing there.

> Let's see what Peter thinks about this, he might very well have a
> different opinion on this.

Yup.

In the meantime, I'll rewrite the rest of the series to take this into
consideration. It's a few pretty trivial changes. Adding what I wanted
can very well be done later if Peter sees it fit to have.

The big remaining issue I can anyway work around outside Buildroot,
since in my case I do provide the Linux defconfig file, so I'm
prefectly OK with ditching this for now.

Thank you! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 2/7] linux: add option to rely on a bootloader-provided DTB

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 > Dear Yann E. MORIN,
 > On Thu, 1 Jan 2015 22:58:45 +0100, Yann E. MORIN wrote:

 >> However, I beg to disagree on that last part: I think we should have
 >> this as an option in Buildroot.
 >> 
 >> The reason is that some platforms can be built with or without support
 >> for the device tree. The Raspberry Pi is but one such platform; there
 >> are others. Their defconfig do not always enable USE_OF by default, it
 >> must be a volunteer selection from the user.
 >> 
 >> In that case, your opinion is to delegate to the user the responsibility
 >> to enable that on his own, right? So, it would no longer be possible to
 >> use in-tree defconfigs for those boards, for example.

 > Well, to me this is a slippery slope. There are gazillions of kernel
 > options that do platform-specific stuff. So far, we really tried hard
 > to limit how much Buildroot modifies the kernel options, and tried to
 > limit that to cases related to userspace components enabled by the user
 > that really need some feature in the kernel.

 > Let's see what Peter thinks about this, he might very well have a
 > different opinion on this.

I must say I'm with Thomas on this one. Let's not fiddle with the kernel
.config unless we really _HAVE_ to.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2/7] linux: add option to rely on a bootloader-provided DTB

[Yann E. MORIN]

Peter, Thomas, All,

On 2015-01-02 00:15 +0100, Peter Korsgaard spake thusly:
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>  > Dear Yann E. MORIN,
>  > On Thu, 1 Jan 2015 22:58:45 +0100, Yann E. MORIN wrote:
> 
>  >> However, I beg to disagree on that last part: I think we should have
>  >> this as an option in Buildroot.
>  >> 
>  >> The reason is that some platforms can be built with or without support
>  >> for the device tree. The Raspberry Pi is but one such platform; there
>  >> are others. Their defconfig do not always enable USE_OF by default, it
>  >> must be a volunteer selection from the user.
>  >> 
>  >> In that case, your opinion is to delegate to the user the responsibility
>  >> to enable that on his own, right? So, it would no longer be possible to
>  >> use in-tree defconfigs for those boards, for example.
> 
>  > Well, to me this is a slippery slope. There are gazillions of kernel
>  > options that do platform-specific stuff. So far, we really tried hard
>  > to limit how much Buildroot modifies the kernel options, and tried to
>  > limit that to cases related to userspace components enabled by the user
>  > that really need some feature in the kernel.
> 
>  > Let's see what Peter thinks about this, he might very well have a
>  > different opinion on this.
> 
> I must say I'm with Thomas on this one. Let's not fiddle with the kernel
> .config unless we really _HAVE_ to.

OK, marked as Rejected in Patchwork, dropped from my tree.

Thamks! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 3/7] docs/manual: document LIBFOO_INSTALL_IMAGES

[Yann E. MORIN]

Document it as are LIBFOO_INSTALL_STAGING and LIBFOO_INSTALL_TARGET.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 docs/manual/adding-packages-generic.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/docs/manual/adding-packages-generic.txt b/docs/manual/adding-packages-generic.txt
index f20c9de..e80fc33 100644
--- a/docs/manual/adding-packages-generic.txt
+++ b/docs/manual/adding-packages-generic.txt
@@ -317,6 +317,11 @@ information is (assuming the package name is +libfoo+) :
   variables are executed to install the package into the target
   directory.
 
+* +LIBFOOR_INSTALL_IMAGES+ can be set to +YES+ or +NO+ (default). If
+  set to +YES+, then the commands in the +LIBFOO_INSTALL_IMAGES_CMDS+
+  variable are executed to install the package into the images
+  directory.
+
 * +LIBFOO_CONFIG_SCRIPTS+ lists the names of the files in
   '$(STAGING_DIR)/usr/bin' that need some special fixing to make them
   cross-compiling friendly. Multiple file names separated by space can
-- 
1.9.1

[Buildroot] [PATCH 3/7] docs/manual: document LIBFOO_INSTALL_IMAGES

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Thu,  1 Jan 2015 21:23:49 +0100, Yann E. MORIN wrote:
> Document it as are LIBFOO_INSTALL_STAGING and LIBFOO_INSTALL_TARGET.

> +* +LIBFOOR_INSTALL_IMAGES+ can be set to +YES+ or +NO+ (default). If

LIBFOOR -> LIBFOO.

Committed with this fixed, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 4/7] package/rpi-firmware: only install images

[Yann E. MORIN]

The rpi-firmware only installs images files, so it should use
_INSTALL_IMAGES_CMDS and not _INSTALL_TARGET_CMDS.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 package/rpi-firmware/rpi-firmware.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/package/rpi-firmware/rpi-firmware.mk b/package/rpi-firmware/rpi-firmware.mk
index 7ebd38c..571a546 100644
--- a/package/rpi-firmware/rpi-firmware.mk
+++ b/package/rpi-firmware/rpi-firmware.mk
@@ -8,8 +8,10 @@ RPI_FIRMWARE_VERSION = 393dcc0e76f18f6ac1b67ba45d36058410670034
 RPI_FIRMWARE_SITE = $(call github,raspberrypi,firmware,$(RPI_FIRMWARE_VERSION))
 RPI_FIRMWARE_LICENSE = BSD-3c
 RPI_FIRMWARE_LICENSE_FILES = boot/LICENCE.broadcom
+RPI_FIRMWARE_INSTALL_TARGET = NO
+RPI_FIRMWARE_INSTALL_IMAGES = YES
 
-define RPI_FIRMWARE_INSTALL_TARGET_CMDS
+define RPI_FIRMWARE_INSTALL_IMAGES_CMDS
 	$(INSTALL) -D -m 0644 $(@D)/boot/bootcode.bin $(BINARIES_DIR)/rpi-firmware/bootcode.bin
 	$(INSTALL) -D -m 0644 $(@D)/boot/start$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).elf $(BINARIES_DIR)/rpi-firmware/start.elf
 	$(INSTALL) -D -m 0644 $(@D)/boot/fixup$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).dat $(BINARIES_DIR)/rpi-firmware/fixup.dat
-- 
1.9.1

[Buildroot] [PATCH 4/7] package/rpi-firmware: only install images

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Thu,  1 Jan 2015 21:23:50 +0100, Yann E. MORIN wrote:
> The rpi-firmware only installs images files, so it should use
> _INSTALL_IMAGES_CMDS and not _INSTALL_TARGET_CMDS.
> 
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> ---
>  package/rpi-firmware/rpi-firmware.mk | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Applied, thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 5/7] package/rpi-firmware: add DT-aware marking script

[Yann E. MORIN]

The Raspberry Pi can boot a kernel with device tree support. But at the
same time, the RPi folks wante to keep the old-fashioned, ATAG-based way
of booting (don't ask...).

So, the bootloader needs to know whether the kernel it is loading has DT
support or not. For that, it looks at the end of the kernel image for a
magic footer. If found, it loads a device tree and sets the registers
appropriately so that the kernel finds the DTB. If not found, it loads
the kernel with the traditional ATAGS.

Where it becomes a bit tricky, is that the DTB is different for models
A/B and A+/B+ (that is A and B use the same DTB, while the A+ and B+ use
a second DTB). The bootloader is capable to load the correct DTB from a
specially named file. That is:
  - on A/B, it loads bcm2708-rpi-b.dtb
  - on A+/B+, it loads bcm2708-rpi-b-plus.dtb

If the DTB is differently named, the bootloader won't find it, will not
load any DTB at all, and revert to booting with ATAGS.

It is possible to specify what DTB to load, by adding an new config
option 'device_tree=file.dtb' in config.txt, but then the firmware on
the SDcard is no longer bootable on both the original models and the
Plus models.

So, add a script that appends the appropriate footer to the kernel
image. The script is vampirised from the RPi's tools repository, but a
new package is *not* added just for that script: the whole repository is
300+ MiB, and a checkout is 600+ MiB; it is not pertinent to add this as
a new package for a script that weights a few KiB...

Install that script as a host utility, too.

Notes: lots of information is available in this thread on the RPi forums:
    http://www.raspberrypi.org/forums/viewtopic.php?f=29&t=93015

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 package/rpi-firmware/mkknlimg        | 204 +++++++++++++++++++++++++++++++++++
 package/rpi-firmware/rpi-firmware.mk |  10 ++
 2 files changed, 214 insertions(+)
 create mode 100755 package/rpi-firmware/mkknlimg

diff --git a/package/rpi-firmware/mkknlimg b/package/rpi-firmware/mkknlimg
new file mode 100755
index 0000000..7288925
--- /dev/null
+++ b/package/rpi-firmware/mkknlimg
@@ -0,0 +1,204 @@
+#!/usr/bin/env perl
+#
+# Originaly from: https://github.com/raspberrypi/tools/blob/master/mkimage/mkknlimg
+# Original cset : bcd5ced1366e4904199f0fa1ed0511a085203913
+
+use strict;
+use integer;
+
+my $trailer_magic = 'RPTL';
+
+my $tmpfile1 = "/tmp/mkknlimg_$$.1";
+my $tmpfile2 = "/tmp/mkknlimg_$$.2";
+
+my $dtok = 0;
+
+while ($ARGV[0] =~ /^-/)
+{
+    my $arg = shift(@ARGV);
+    if ($arg eq '--dtok')
+    {
+	$dtok = 1;
+    }
+    else
+    {
+	print ("* unknown option '$arg'\n");
+	usage();
+    }
+}
+
+usage() if (@ARGV != 2);
+
+my $kernel_file = $ARGV[0];
+my $out_file = $ARGV[1];
+
+my @wanted_config_lines =
+(
+	'CONFIG_BCM2708_DT'
+);
+
+my @wanted_strings =
+(
+	'brcm,bcm2708',
+	'brcm,bcm2708-pinctrl',
+	'of_find_property'
+);
+
+my $res = try_extract($kernel_file, $tmpfile1);
+
+$res = try_decompress('\037\213\010', 'xy',    'gunzip',
+		      $kernel_file, $tmpfile1, $tmpfile2) if (!$res);
+$res = try_decompress('\3757zXZ\000', 'abcde', 'unxz --single-stream',
+		      $kernel_file, $tmpfile1, $tmpfile2) if (!$res);
+$res = try_decompress('BZh',          'xy',    'bunzip2',
+		      $kernel_file, $tmpfile1, $tmpfile2) if (!$res);
+$res = try_decompress('\135\0\0\0',   'xxx',   'unlzma',
+		      $kernel_file, $tmpfile1, $tmpfile2) if (!$res);
+$res = try_decompress('\211\114\132', 'xy',    'lzop -d',
+		      $kernel_file, $tmpfile1, $tmpfile2) if (!$res);
+exit(1) if (!$res);
+
+my @atoms;
+
+print("Version: $res->{''}\n");
+
+if (!$dtok)
+{
+    if (!config_bool($res, 'brcm,bcm2708'))
+    {
+	print ("* this doesn't look like a Raspberry Pi kernel\n");
+	exit(1);
+    }
+
+    $dtok ||= config_bool($res, 'CONFIG_BCM2708_DT');
+    $dtok ||= config_bool($res, 'brcm,bcm2708-pinctrl');
+}
+
+printf("DT: %s\n", $dtok ? "y" : "n");
+
+push @atoms, [ $trailer_magic, pack('V', 0) ];
+push @atoms, [ 'KVer', $res->{''} ];
+push @atoms, [ 'DTOK', pack('V', $dtok) ];
+
+my $trailer = pack_trailer(\@atoms);
+$atoms[0]->[1] = pack('V', length($trailer));
+
+$trailer = pack_trailer(\@atoms);
+
+die "* Failed to open '$kernel_file'\n" if (!open(my $ifh, '<', $kernel_file));
+die "* Failed to create '$out_file'\n" if (!open(my $ofh, '>', $out_file));
+
+my $copybuf;
+my $total_len = 0;
+while (1)
+{
+	my $bytes = sysread($ifh, $copybuf, 64*1024);
+	last if (!$bytes);
+	syswrite($ofh, $copybuf, $bytes);
+	$total_len += $bytes;
+}
+
+# Pad to word-alignment
+syswrite($ofh, "\x000\x000\x000", (-$total_len & 0x3));
+syswrite($ofh, $trailer);
+close($ifh);
+close($ofh);
+
+exit(0);
+
+END {
+	unlink($tmpfile1) if ($tmpfile1);
+	unlink($tmpfile2) if ($tmpfile2);
+}
+
+
+sub usage
+{
+	print ("Usage: mkknlimg [--dtok] <vmlinux|zImage|bzImage> <outfile>\n");
+	exit(1);
+}
+
+sub try_extract
+{
+	my ($knl, $tmp) = @_;
+
+	my $ver = `strings "$knl" | grep -a "^Linux version"`;
+
+	return undef if (!$ver);
+
+	chomp($ver);
+
+	my $res = { ''=>$ver };
+	my $string_pattern = '^('.join('|', @wanted_strings).')$';
+
+	my @matches = `strings \"$knl\" | grep -E \"$string_pattern\"`;
+	foreach my $match (@matches)
+	{
+	    chomp($match);
+	    $res->{$match} = 1;
+	}
+
+	my $config_pattern = '^('.join('|', @wanted_config_lines).')=(.*)$';
+	my $cf1 = 'IKCFG_ST\037\213\010';
+	my $cf2 = '0123456789';
+
+	my $pos = `tr "$cf1\n$cf2" "\n$cf2=" < "$knl" | grep -abo "^$cf2"`;
+	if ($pos)
+	{
+		$pos =~ s/:.*[\r\n]*$//s;
+		$pos += 8;
+		my $err = (system("tail -c+$pos \"$knl\" | zcat > $tmp 2> /dev/null") >> 8);
+		if (($err == 0) || ($err == 2))
+		{
+			if (open(my $fh, '<', $tmp))
+			{
+				while (my $line = <$fh>)
+				{
+					chomp($line);
+					$res->{$1} = $2 if ($line =~ /$config_pattern/);
+				}
+
+				close($fh);
+			}
+		}
+	}
+
+	return $res;
+}
+
+
+sub try_decompress
+{
+	my ($magic, $subst, $zcat, $knl, $tmp1, $tmp2) = @_;
+
+	my $pos = `tr "$magic\n$subst" "\n$subst=" < "$knl" | grep -abo "^$subst" |tail -n 1`;
+	if ($pos)
+	{
+		$pos =~ s/:.*[\r\n]*$//s;
+		my $cmd = "tail -c+$pos \"$knl\" | $zcat > $tmp2 2> /dev/null";
+		my $err = (system($cmd) >> 8);
+		return undef if (($err != 0) && ($err != 2));
+
+		return try_extract($tmp2, $tmp1);
+	}
+
+	return undef;
+}
+
+sub pack_trailer
+{
+	my ($atoms) = @_;
+	my $trailer = pack('VV', 0, 0);
+	for (my $i = $#$atoms; $i>=0; $i--)
+	{
+		my $atom = $atoms->[$i];
+		$trailer .= pack('a*x!4Va4', $atom->[1], length($atom->[1]), $atom->[0]);
+	}
+	return $trailer;
+}
+
+sub config_bool
+{
+	my ($configs, $wanted) = @_;
+	return (($configs->{$wanted} eq 'y') || ($configs->{$wanted} eq '1'));
+}
diff --git a/package/rpi-firmware/rpi-firmware.mk b/package/rpi-firmware/rpi-firmware.mk
index 571a546..eb835ee 100644
--- a/package/rpi-firmware/rpi-firmware.mk
+++ b/package/rpi-firmware/rpi-firmware.mk
@@ -19,4 +19,14 @@ define RPI_FIRMWARE_INSTALL_IMAGES_CMDS
 	$(INSTALL) -D -m 0644 package/rpi-firmware/cmdline.txt $(BINARIES_DIR)/rpi-firmware/cmdline.txt
 endef
 
+# We have no host sources to get, since we already
+# bundle the script we want to install.
+HOST_RPI_FIRMWARE_SOURCE =
+HOST_RPI_FIRMWARE_DEPENDENCIES =
+
+define HOST_RPI_FIRMWARE_INSTALL_CMDS
+	$(INSTALL) -D -m 0755 package/rpi-firmware/mkknlimg $(HOST_DIR)/usr/bin/mkknlimg
+endef
+
 $(eval $(generic-package))
+$(eval $(host-generic-package))
-- 
1.9.1

[Buildroot] [PATCH 6/7] package/rpi-firmware: install DTB blobs

[Yann E. MORIN]

If we compile a DT-aware kernel, or the user wants them, install the DTB
blobs:
  - standard DTBs for standalon A/B and A+/B+ models;
  - overlay DTBs for the 'hats' addon boards.

The only configurations allowed are:
  - no kernel enabled                 :  prompt the user
  - kernel enabled without DT support :  hide the prompt
  - kernel enabled with DT support    :  show the prompt, force the option

Install the DTBs as per the traditional layout expected by all RPi
users, that is:
  - base DTBs alongside the other boot files;
  - overlay DTBs in a sub-directory.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 package/rpi-firmware/Config.in       | 11 +++++++++++
 package/rpi-firmware/rpi-firmware.mk | 13 +++++++++++++
 2 files changed, 24 insertions(+)

diff --git a/package/rpi-firmware/Config.in b/package/rpi-firmware/Config.in
index cd45be4..b708579 100644
--- a/package/rpi-firmware/Config.in
+++ b/package/rpi-firmware/Config.in
@@ -1,6 +1,7 @@
 config BR2_PACKAGE_RPI_FIRMWARE
 	bool "rpi-firmware"
 	depends on BR2_arm
+	select BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DBS if BR2_LINUX_KERNEL_DTS_SUPPORT
 	help
 	  RaspberryPi Firmware
 	  Pre-compiled binaries of the current bootloader and GPU firmware
@@ -45,4 +46,14 @@ config BR2_PACKAGE_RPI_FIRMWARE_BOOT
 	default "_x"    if BR2_PACKAGE_RPI_FIRMWARE_X
 	default "_cd"   if BR2_PACKAGE_RPI_FIRMWARE_CD
 
+config BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DBS
+	bool "Install DTB blobs"
+	depends on !BR2_LINUX_KERNEL || BR2_LINUX_KERNEL_DTS_SUPPORT
+	help
+	  Say 'y' here if you want to boot your kernel that has support
+	  for the device tree.
+
+	  If Buildroot will also build a kernel, this is automatically
+	  selected.
+
 endif # BR2_PACKAGE_RPI_FIRMWARE
diff --git a/package/rpi-firmware/rpi-firmware.mk b/package/rpi-firmware/rpi-firmware.mk
index eb835ee..dedfbc5 100644
--- a/package/rpi-firmware/rpi-firmware.mk
+++ b/package/rpi-firmware/rpi-firmware.mk
@@ -11,6 +11,19 @@ RPI_FIRMWARE_LICENSE_FILES = boot/LICENCE.broadcom
 RPI_FIRMWARE_INSTALL_TARGET = NO
 RPI_FIRMWARE_INSTALL_IMAGES = YES
 
+ifeq ($(BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DBS),y)
+RPI_FIRMWARE_DEPENDENCIES += host-rpi-firmware
+# Override the version in this case.
+RPI_FIRMWARE_VERSION = 09627457b9e15bf4ea4e6751d3c173a3fb65df07
+define RPI_FIRMWARE_INSTALL_DTB
+	$(INSTALL) -D -m 0644 $(@D)/boot/bcm2708-rpi-b.dtb $(BINARIES_DIR)/rpi-firmware/bcm2708-rpi-b.dtb
+	$(INSTALL) -D -m 0644 $(@D)/boot/bcm2708-rpi-b-plus.dtb $(BINARIES_DIR)/rpi-firmware/bcm2708-rpi-b-plus.dtb
+	for ovldtb in  $(@D)/boot/overlays/*.dtb; do \
+		$(INSTALL) -D -m 0644 $${ovldtb} $(BINARIES_DIR)/rpi-firmware/overlays/$${ovldtb##*/} || exit 1; \
+	done
+endef
+endif
+
 define RPI_FIRMWARE_INSTALL_IMAGES_CMDS
 	$(INSTALL) -D -m 0644 $(@D)/boot/bootcode.bin $(BINARIES_DIR)/rpi-firmware/bootcode.bin
 	$(INSTALL) -D -m 0644 $(@D)/boot/start$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).elf $(BINARIES_DIR)/rpi-firmware/start.elf
-- 
1.9.1

[Buildroot] [PATCH 7/7] package/rpi-firmware: append the DTOK footer for DT-aware kernel

[Yann E. MORIN]

When building a DT-aware kernel, we need to append a footer that tells
the bootloader that the kernel has DT support.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 package/rpi-firmware/rpi-firmware.mk | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/package/rpi-firmware/rpi-firmware.mk b/package/rpi-firmware/rpi-firmware.mk
index dedfbc5..7a35e99 100644
--- a/package/rpi-firmware/rpi-firmware.mk
+++ b/package/rpi-firmware/rpi-firmware.mk
@@ -22,6 +22,16 @@ define RPI_FIRMWARE_INSTALL_DTB
 		$(INSTALL) -D -m 0644 $${ovldtb} $(BINARIES_DIR)/rpi-firmware/overlays/$${ovldtb##*/} || exit 1; \
 	done
 endef
+
+ifeq ($(BR2_LINUX_KERNEL),y)
+RPI_FIRMWARE_DEPENDENCIES += linux
+define RPI_FIRMWARE_KERNEL_APPEND_DTOK_FOOTER
+	$(HOST_DIR)/usr/bin/mkknlimg --dtok \
+		$(BINARIES_DIR)/$(notdir $(LINUX_IMAGE_PATH)) \
+		$(BINARIES_DIR)/$(notdir $(LINUX_IMAGE_PATH)).dtok
+endef
+endif
+
 endif
 
 define RPI_FIRMWARE_INSTALL_IMAGES_CMDS
@@ -30,6 +40,8 @@ define RPI_FIRMWARE_INSTALL_IMAGES_CMDS
 	$(INSTALL) -D -m 0644 $(@D)/boot/fixup$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).dat $(BINARIES_DIR)/rpi-firmware/fixup.dat
 	$(INSTALL) -D -m 0644 package/rpi-firmware/config.txt $(BINARIES_DIR)/rpi-firmware/config.txt
 	$(INSTALL) -D -m 0644 package/rpi-firmware/cmdline.txt $(BINARIES_DIR)/rpi-firmware/cmdline.txt
+	$(RPI_FIRMWARE_INSTALL_DTB)
+	$(RPI_FIRMWARE_KERNEL_APPEND_DTOK_FOOTER)
 endef
 
 # We have no host sources to get, since we already
-- 
1.9.1