Le 20/04/2016 23:03, Tom Rini a écrit :
On Wed, Apr 20, 2016 at 03:49:58PM -0400, Denys Dmytriyenko wrote:
On Wed, Apr 20, 2016 at 03:50:36PM +0200, Yannick Gicquel wrote:
This introduces a new uboot-sign.class to support U-Boot verified boot.
This part delivers the new class file, with related environment variables, and
a basic prepend to do_install task which performs the concatenation of the
u-boot-nodtb.bin and the device tree blob. The 'cat' command used
overrides the u-boot.bin in both DEPLOYDIR & build dir to propagate the
changes in later tasks (do_install, do_package, etc.)
Signed-off-by: Yannick Gicquel <[email protected]>
---
meta/classes/uboot-sign.bbclass | 59 ++++++++++++++++++++++++++++++++++++++
meta/recipes-bsp/u-boot/u-boot.inc | 2 +-
2 files changed, 60 insertions(+), 1 deletion(-)
create mode 100644 meta/classes/uboot-sign.bbclass
diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
new file mode 100644
index 0000000..63a5181
--- /dev/null
+++ b/meta/classes/uboot-sign.bbclass
@@ -0,0 +1,59 @@
+# This file is part of U-Boot verified boot support and is intended to be
+# inherited from u-boot recipe and from kernel-fitimage.bbclass.
+#
+# The signature procedure requires the user to generate an RSA key and
+# certificate in a directory and to define the following variable:
+#
+# UBOOT_SIGN_KEYDIR = "/keys/directory"
+# UBOOT_SIGN_KEYNAME = "dev" # keys name in keydir (eg. "dev.crt", "dev.key")
+# UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
+# UBOOT_SIGN_ENABLE = "1"
+#
+# As verified boot depends on fitImage generation, following is also required:
+#
+# KERNEL_CLASSES ?= " kernel-fitimage "
+# KERNEL_IMAGETYPE ?= "fitImage"
+#
+# The signature support is limited to the use of CONFIG_OF_SEPARATE in U-Boot.
+#
+# The tasks sequence is as below, using DEPLOY_IMAGE_DIR as common place to
+# treat the device tree blob:
+#
+# u-boot:do_deploy -> virtual/kernel:do_assemble_fitimage -> u-boot:do_install
+#
+# For more details on signature process, please refer to U-boot documentation.
+
+# Signature activation.
+UBOOT_SIGN_ENABLE ?= "0"
+
+# Default value for deployment filenames.
+UBOOT_DTB_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.dtb"
+UBOOT_DTB_BINARY ?= "u-boot.dtb"
+UBOOT_DTB_SYMLINK ?= "u-boot-${MACHINE}.dtb"
+UBOOT_NODTB_IMAGE ?= "u-boot-nodtb-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
+UBOOT_NODTB_BINARY ?= "u-boot-nodtb.${UBOOT_SUFFIX}"
+UBOOT_NODTB_SYMLINK ?= "u-boot-nodtb-${MACHINE}.${UBOOT_SUFFIX}"
+
+#
+# Following is relevant only for u-boot recipes:
+#
+
+do_install_prepend_pn-u-boot () {
Why _pn-u-boot here? What if I have my own version of u-boot recipe?
Oh good point, maybe this should be class-target instead of pn-u-boot
(here and elsewhere) ?
Hi Tom, Denys, all,
I initially though that any custom u-boot recipes declares a 'PROVIDE +=
"u-boot"' and the bitbake "_pn-" syntax will append functions to u-boot
recipes only. Unfortunately, i just checked and confirmed the appends
functions are not called anymore when the u-boot recipe is not named
"u-boot".
Using "class-target" is an interesting idea, but it looks like the
kernel recipe is also part of this class (at least on my setup), thus it
may not be reliable enough.
What about using the "PREFERRED_PROVIDER_u-boot" variable instead of
static 'u-boot' string in the relevant places ?
A "do_install_prepend_pn-${PREFERRED_PROVIDER_u-boot}" is not valid, but
it can be performed by adding tasks in the python function at EOF.
Something like:
-do_deploy_append_pn-u-boot () {
+do_before_uboot_deploy () {
[snip]
python() {
if d.getVar('PN', True) == d.getVar('PREFERRED_PROVIDER_u-boot', True):
bb.build.addtask('do_before_uboot_deploy', None, 'do_deploy', d)
}
Off course, it requires few changes in other places, but I hope you'll
see the idea ? What do you think ?
Best regards,
Yannick
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
