Skip to contentSkip to conversation

RPi: enable building a device-tree-enabled kernel (branch yem/rpi-dt)

PATCH Superseded Yann E. MORIN 3 participants 19 messages Jan 1, 2015

v1 of 3 Superseded Latest is v3 →

lore
Share & tools
lore
#0 lore raw

cover RPi: enable building a device-tree-enabled kernel (branch yem/rpi-dt)

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
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#1 lore raw

PATCH 1/7 package/rpi-firmware: bump version

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

---
 package/rpi-firmware/rpi-firmware.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
package/rpi-firmware/rpi-firmware.mk +1 -1
index 033ff33..7ebd38c 100644
@@ -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
Signature · 1 line
1.9.1
#2 lore raw

PATCH 1/7 package/rpi-firmware: bump version

Dear Yann E. MORIN,

Quoted 7 lines · Yann E. MORIN

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

---
 package/rpi-firmware/rpi-firmware.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#3 lore raw

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

In reply to 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.

---
 linux/Config.in |  8 ++++++++
 linux/linux.mk  | 12 +++++++++++-
 2 files changed, 19 insertions(+), 1 deletion(-)
linux/Config.in +8 -0
index ba4b574..6d994ee 100644
@@ -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
linux/linux.mk +11 -1
index 8256641..9b1f19b 100644
@@ -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
Signature · 1 line
1.9.1
#4 lore raw

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

Dear Yann E. MORIN,

Quoted 9 lines · 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.

Quoted 7 lines

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.

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#5 lore raw

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

Thomas, All,

On 2015-01-01 22:24 +0100, Thomas Petazzoni spake thusly:

Quoted 18 lines · Yann E. MORIN
Quoted 9 lines

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.

Quoted 7 lines

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.

Quoted 7 lines

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#6 lore raw

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

Dear Yann E. MORIN,

Quoted 6 lines · Yann E. MORIN

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.

Quoted 9 lines

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#7 lore raw

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

Thomas, All,

On 2015-01-01 22:51 +0100, Thomas Petazzoni spake thusly:

Quoted 10 lines · Yann E. MORIN
Quoted 7 lines

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.

Quoted 8 lines
Quoted 8 lines

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?

Quoted 7 lines
Quoted 1 line

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#8 lore raw

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

Dear Yann E. MORIN,

Quoted 11 lines · Yann E. MORIN

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#9 lore raw

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

Thomas, All,

On 2015-01-01 23:17 +0100, Thomas Petazzoni spake thusly:

Quoted 16 lines

Dear Yann E. MORIN,

Quoted 11 lines · Yann E. MORIN

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.

Quoted 5 lines

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.

Quoted 2 lines

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#10 lore raw

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

In reply to Thomas Petazzoni
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hi,

Quoted 15 lines

Dear Yann E. MORIN,

Quoted 11 lines · Yann E. MORIN

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.

Quoted 8 lines

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.

Signature · 1 line
Bye, Peter Korsgaard
#11 lore raw

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

Peter, Thomas, All,

On 2015-01-02 00:15 +0100, Peter Korsgaard spake thusly:

Quoted 22 lines
Quoted 21 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Dear Yann E. MORIN,

Quoted 11 lines · Yann E. MORIN

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.

Quoted 5 lines
Quoted 2 lines

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#12 lore raw

PATCH 3/7 docs/manual: document LIBFOO_INSTALL_IMAGES

In reply to Yann E. MORIN

Document it as are LIBFOO_INSTALL_STAGING and LIBFOO_INSTALL_TARGET.

---
 docs/manual/adding-packages-generic.txt | 5 +++++
 1 file changed, 5 insertions(+)
docs/manual/adding-packages-generic.txt +5 -0
index f20c9de..e80fc33 100644
@@ -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
Signature · 1 line
1.9.1
#13 lore raw

PATCH 3/7 docs/manual: document LIBFOO_INSTALL_IMAGES

Dear Yann E. MORIN,

Quoted 3 lines · Yann E. MORIN

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#14 lore raw

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

In reply to Yann E. MORIN

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

---
 package/rpi-firmware/rpi-firmware.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
package/rpi-firmware/rpi-firmware.mk +3 -1
index 7ebd38c..571a546 100644
@@ -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
Signature · 1 line
1.9.1
#15 lore raw

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

Dear Yann E. MORIN,

Quoted 7 lines · Yann E. MORIN

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

---
 package/rpi-firmware/rpi-firmware.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Applied, thanks!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#16 lore raw

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

In reply to 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
---
 package/rpi-firmware/mkknlimg        | 204 +++++++++++++++++++++++++++++++++++
 package/rpi-firmware/rpi-firmware.mk |  10 ++
 2 files changed, 214 insertions(+)
 create mode 100755 package/rpi-firmware/mkknlimg
package/rpi-firmware/mkknlimg new file +204 -0
new file mode 100755
index 0000000..7288925
@@ -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'));
+}
package/rpi-firmware/rpi-firmware.mk +10 -0
index 571a546..eb835ee 100644
@@ -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))
Signature · 1 line
1.9.1
#17 lore raw

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

In reply to 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.

---
 package/rpi-firmware/Config.in       | 11 +++++++++++
 package/rpi-firmware/rpi-firmware.mk | 13 +++++++++++++
 2 files changed, 24 insertions(+)
package/rpi-firmware/Config.in +11 -0
index cd45be4..b708579 100644
@@ -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
package/rpi-firmware/rpi-firmware.mk +13 -0
index eb835ee..dedfbc5 100644
@@ -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
Signature · 1 line
1.9.1
#18 lore raw

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

In reply to 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.

---
 package/rpi-firmware/rpi-firmware.mk | 12 ++++++++++++
 1 file changed, 12 insertions(+)
package/rpi-firmware/rpi-firmware.mk +12 -0
index dedfbc5..7a35e99 100644
@@ -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
Signature · 1 line
1.9.1