RPi: enable building a device-tree-enabled kernel (branch yem/rpi-dt)
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. | '------------------------------^-------^------------------^--------------------'
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
@@ -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
Thomas Petazzoni
AppliedPATCH 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...
Signed-off-by "Yann E. MORIN" <[email protected]>--- 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
PATCH 2/7 linux: add option to rely on a bootloader-provided DTB
In reply to Yann E. MORINOn 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
@@ -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
@@ -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
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.
Signed-off-by "Yann E. MORIN" <[email protected]>
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
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.
Signed-off-by "Yann E. MORIN" <[email protected]>
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_OFshould 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. | '------------------------------^-------^------------------^--------------------'
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_OFwhen 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
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_OFwhen 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_OFshould 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. | '------------------------------^-------^------------------^--------------------'
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_OFby 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
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_OFby 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. | '------------------------------^-------^------------------^--------------------'
PATCH 2/7 linux: add option to rely on a bootloader-provided DTB
In reply to Thomas PetazzoniQuoted 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_OFby 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
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_OFby 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. | '------------------------------^-------^------------------^--------------------'
PATCH 3/7 docs/manual: document LIBFOO_INSTALL_IMAGES
In reply to Yann E. MORINDocument 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
@@ -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
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_STAGINGandLIBFOO_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
PATCH 4/7 package/rpi-firmware: only install images
In reply to Yann E. MORINThe 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
@@ -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
Thomas Petazzoni
AppliedPATCH 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_CMDSand not_INSTALL_TARGET_CMDS.Signed-off-by "Yann E. MORIN" <[email protected]>--- 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
PATCH 5/7 package/rpi-firmware: add DT-aware marking script
In reply to Yann E. MORINThe 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
@@ -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
@@ -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
PATCH 6/7 package/rpi-firmware: install DTB blobs
In reply to Yann E. MORINIf 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
@@ -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
@@ -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
PATCH 7/7 package/rpi-firmware: append the DTOK footer for DT-aware kernel
In reply to Yann E. MORINWhen 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
@@ -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