From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EB4FBC433FE for ; Mon, 24 Jan 2022 10:42:17 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id BBA0680F81; Mon, 24 Jan 2022 11:42:15 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=prevas.dk Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=prevas.dk header.i=@prevas.dk header.b="anWwXzHW"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6178880FE1; Mon, 24 Jan 2022 11:42:13 +0100 (CET) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on071a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::71a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 8F4C280646 for ; Mon, 24 Jan 2022 11:42:09 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=prevas.dk Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=rasmus.villemoes@prevas.dk ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XGdtuGIR+PTiz8rymfkAPialbPozUfk/vBTO84Z1R4JBuFqK5eFtfgVkChgfbo0PyThtiOf331FVxRdOy9fPX9ilNVTwdvWBdMk3Hfj+P6TB6XAnSTip4Cl/Au5bKq4BkhRarHVzPCLcESzwrl2hTR+IorCluzDu8hBwJk7MSVo9Nuxr8/GUB2VYhPsfvcBjXyA1BYe/5akwkjmrPxkI94VMBhLZFqtCWTILuviPfmAY0+Dq/+vJ8k3dQoe1jmS48KrD5bGJyDB/m6nAnHc6+eirRnN1Kk0SZ1sToKO0geiM6C9l4kIJJ6MhUDQrhewztxfcPfPcbYNnsbLEbvdjpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=y2VodGfAI4jNX4hFtSalznfx0TOsqbc2z00TBdtS6Og=; b=OFjsuPSQryG0e+VIrv/qX5dwzoFw4fusgaLLZa+ATz4s+roL5/ng5X6IWs7dOWLclRTjuYE8YjZNozF7MacHHOMy7f3rwV++01EuJnfMVo0WvqWxzW12DkE8ZTmVkI0TxFiCQNg5iWr4QNHUPKvdTsf2ddUTA3p45f+MAA9xIMZrT3Nj57lXIr9zQQ6rSCKJaXmjxduZ+yKBgQRwuk8Ug/urRHROufyoFPGfsEnVZJqHeNM2MUZzI9xwdk3rDMG15kLINBihD9/IK7Jc8iVz0UYmOl6TJUCwtb8nIeuVh8BSrwkg6itD+Y/s/A+hqDtPjFj18nBbbG7xbJCr0XHnIg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prevas.dk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y2VodGfAI4jNX4hFtSalznfx0TOsqbc2z00TBdtS6Og=; b=anWwXzHW9F8KXvtn+FVqjFnUuzEu+RGuCfRHu2fmH6ScV0kR8XISK8hKEZMZhWr/m/hIlYf7hsmFNSm43hpAESDbyyublRbZcI7bSvdxWK+FyoEFIImyoYXcmy8qnFr/Ud//MkJUkvbL3YAE2HgSbdJR1yco4zChz7TL8Gp5GFQ= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=prevas.dk; Received: from DU0PR10MB5266.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:34a::22) by DB9PR10MB4862.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:2c5::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.8; Mon, 24 Jan 2022 10:42:07 +0000 Received: from DU0PR10MB5266.EURPRD10.PROD.OUTLOOK.COM ([fe80::608f:51b:ced9:9c8f]) by DU0PR10MB5266.EURPRD10.PROD.OUTLOOK.COM ([fe80::608f:51b:ced9:9c8f%7]) with mapi id 15.20.4909.017; Mon, 24 Jan 2022 10:42:07 +0000 Subject: Re: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES To: Simon Glass Cc: U-Boot Mailing List , Alex Kiernan , Roman Kopytin , Masahiro Yamada References: <20210928085651.619892-1-rasmus.villemoes@prevas.dk> <918b92c8-c553-5d09-d385-ae90bf296c3f@prevas.dk> From: Rasmus Villemoes Message-ID: <13fc4f99-6980-57e4-33bd-6e164b114e6a@prevas.dk> Date: Mon, 24 Jan 2022 11:42:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR0P281CA0046.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:48::23) To DU0PR10MB5266.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:34a::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d56819c8-3a96-4bb1-3a91-08d9df262b22 X-MS-TrafficTypeDiagnostic: DB9PR10MB4862:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:425; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gV1yjSSC2MrPhab5ZOtiJw/Mg2Q/2d7g60R9TXRGkjJDoXGdG7wKlORQ7eU5ZMHG+Ei2Oa+ri44nZ4hwHTvRHrZmadRNFyiLSYICrNOmQibnYHtJc98119TkplktglbAaxr9CnkbErES4lDC2H3RKFRnMtcSRj0lGCAPJFGEr80naqtgIp4/h2MBP+RLLCab5q5vvolxIFDoUx4Zb25DYTAswvE+fF4c+EgTVeOH+d/Nt+JnoLWlWFfp40m0/5Pd3p0bUO2D3lJjpsMnAdibGtMoepKvirvYdJ2ZqkuNkri4fx+1d+tIEp4NTjaN55SFDYdhehNxL1kOwJsKh+B/yJujduc5NUxfB0h8qqXImWqiCOXfnhDzgnrwKIzH3EYPaaHwBRCaY5z4k5tLwIh0ON+E6pJ8+o0J5ihOw10qy1tJ6D3WAVtKIv+zIG4U2sIyYqsFSgUAxWybCuWN32WkRPR6R7cLLecZkGR/93XVxi/9krv+xUvPniIAXGUfFqNxo9hBqZtcNeIHRmFt4cLNQcYmY9rOgXDRxMRlEmDZqjApj4Z+jMFPmcHnHArQStrhoxTZL//2VCpVHY8auZv5RSYqQlzlxzH2KjsdPoDrnr2yODXRvGhuzcxM6+NCUai2LYgFJTeIyODP4xEPvapxTg+q3gXsqVdvsnvcTrlZZTxFLADr09jCkPUxNOTjB8I0Q5oA3HRN1olDVUR2I/9PZLP77gRAXqox29K3L4azbJ2VGhH08XAIVk5gnADSsdzwR/yNOOGFMX1mVQxMInfzhEQqSZsuOttbOiN9pJRYtsenicFlkFCL/Ih9wtiEQQqLpP1+i04tPQoctm+i6PX36gU2J8sfhlhRY+GXtki6bVg= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0PR10MB5266.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(966005)(31696002)(6512007)(86362001)(5660300002)(52116002)(66476007)(66946007)(38100700002)(38350700002)(66556008)(6506007)(30864003)(186003)(44832011)(508600001)(4326008)(8676002)(2616005)(6916009)(6666004)(31686004)(2906002)(8976002)(316002)(8936002)(26005)(36756003)(54906003)(83380400001)(6486002)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cXU3OER1MDBLeHhNVm93bUJxVzVac3NGTnJwVmJsaWpHQjhqZ2xNbm52RnV2?= =?utf-8?B?MzBKR3ExTThCWm5oL2h6a0hOeWRyOE9UY1dhUDBSOGlLSzh5TEhvUjJKc1lt?= =?utf-8?B?Slo2VmM1Qi82L0JJZ0tsRHA4ejFYWi9nRnZ3bGRrOFdKRDFhZzZXdmEwQmNy?= =?utf-8?B?c0VuSms2SW9acW83MmltNFk5TkYrOUN1cUw0SWhXakJMaHJMWVd4cmJ6NktI?= =?utf-8?B?bnFnb2VZQUdPRk0xYnM1RVY5UG5tTHlsVitOT1RTWHY4ejhMRWNIRUQrSEpL?= =?utf-8?B?UmVLWDRLbXEyTXNSYzlia2R2RXpWQ0J1NWpSUlVTYmE5eERBM3Q0anpVYUpY?= =?utf-8?B?akdxd0FHMG9iZ1I3Nmt5Ynp0Vk1jSkcvNXhQbFVMTVpoOXdzeXBCWlVyckVp?= =?utf-8?B?RXlubUJqNTBmZVJqeThLMnd1ZzcxSVU4eTIwcHZhY0lSdERGVDNRMUhDeE9o?= =?utf-8?B?QU1IYkJNbXRVbEFDdnlhM3ovTXpBRGt2SHZBc2g2YlU0MkQ3cWlDYmo1RUUy?= =?utf-8?B?UFJ5em5mTHBCL2x4MjVSQU5XSDFYc2s4bGkwZVo1ZEVjTVVvNDJQVmxIVm14?= =?utf-8?B?ZWlhU2dJNHBEZWhUSVE1a0pUd1JDSVdXdDBBNHRteW95Y0YxWFhNUVJYdXVV?= =?utf-8?B?OEsrVi9uMTNoajAzMzcweU9UcjVHOWxLaHNwQi9USzU1WDhyWVJVOVJjc0Ur?= =?utf-8?B?UW9hZFZKOU4vT2FPZ0ZaUlpKM2k1OVlrMXJhQ2dtRTVkKzhuZW1semtJS2ZM?= =?utf-8?B?S3o1dndJWFJmUFRoekNqV1lSL0xnQVVRTHFpTE1KcjNreHFUY0RSenlNWVNw?= =?utf-8?B?QkY5VEQ2a1JuQk9hVUFoclgxS3VwdWJNZFRGUithcTN3b3g5QzF3Mkthbklx?= =?utf-8?B?MVJCRTlTQUFxQjdHVUhzZG4xTFZGeEFNdjZwZmJtSzRWa1R1dmJ1SHRtTk1W?= =?utf-8?B?aFEwT1o1VXdOQ2dWWStST2FGczlESXkzOWl2Y29OdkdwbWdYMGN6Z2thYmI2?= =?utf-8?B?cDN2WjRXL3Z1WXplRjdqNkE3OTRsMHNVNExQdHEzNDFFdXVsZnl3ZnVoeTUv?= =?utf-8?B?bjZhT1hyNGhBcGg4Ti83TkpFREdNVm16MVpkRUhSbmVqODBJSzVEdWd3Nm1v?= =?utf-8?B?TE1aVm9abE5sQ3dpaDVBbmo3bzFVOFMycnM3dmh4VS9laTBvam14T3hrMVAy?= =?utf-8?B?RllRTmdsQXFSY2hyRStBV2lPK0dZTVkydXFMVm1MQm9UbThoTXMyVnloTkkr?= =?utf-8?B?TEpDNGREU2ZPKytJMmI0amVuY0ExeURBL1pBeE5XSVBxL1oxajJtSWhNZ1RO?= =?utf-8?B?NFJxTUtwNnVwVWUwMDZhZjhNWXIyakZZMUNqODg3aDA5YTVwczU0RWFyNGMx?= =?utf-8?B?SXVualRaWHRkMmxjVWpYS0x3RFZKT1BEVHZMNFhaNFJMQTZGcWVocWxHbk1X?= =?utf-8?B?RzVPeml1Z210dzRJYk9JbWg2VC9ic2ZVRDNNcWdPeTd6cUtqbkZXd2hWTVd3?= =?utf-8?B?V1Zyd2hsSjE5dkgxTmV1ZDl2VjVnV2FHSTg1elo0YmxJcXBvQXRVejkzenZO?= =?utf-8?B?TU1LVVcxNXpGemoyR01ZRXVyd1U3OEphbVJKcXFVd0RtRmw1MlQ0UnNabTVY?= =?utf-8?B?a01xVFFNU01NcEw2bDBFcHdpNDZNWEI3SFVZV0dWcTJHZGJJbEp0emlWRnk1?= =?utf-8?B?YXRlc2lEdGUrWkhGblVVRHFKTXY3TGpMSzJ5SFhQNUtsY0ZsaW80MUdDMmRR?= =?utf-8?B?bjRlT3IzOE9DRW5tb3ZZWUdPWVYvVUsyWnNCVXVFMHFiQ3loTjJqYUtZemll?= =?utf-8?B?bHlWaTltTWxxSWprN3pxTUhYOHFCRVdJVHRYN1RJMGwrUmo0a0ZXZmpMVU5m?= =?utf-8?B?dW8xZTY5d212OE1URkhyVVM3aTh0MnUySjhDR0t6WFhRcW8yWU1ldm9IczBO?= =?utf-8?B?NG42dnpNQWhaYytrRnpFQWZoU1NVbXBPdGowSExwVDFpZllLTUJrY1loVEI5?= =?utf-8?B?MUZKY3BOeVVHalFKbEVqaGcvVzNBTmVqU1dGMDB4TTA2V1JwSFUvMFNiRitK?= =?utf-8?B?VVdMK25wRHZSdWsvMzN0TUpBa3hWc2NIZHRuWURTcWY0Vjd5RGxFczA4aisx?= =?utf-8?B?a3hITGdtNy83UlhtK3BRbTF4SlNZbldLTWg3a3h3Y0MreEhlSnM5QTJMSlZr?= =?utf-8?B?UjJNT3BCKzFOMlZVcTlEWHVDT1c2ZzcxSTRNOG9za1pYcVFmVUFLMW9kNXAx?= =?utf-8?B?NEhRMERFTkc0OUoxNmNwcjhhenNBPT0=?= X-OriginatorOrg: prevas.dk X-MS-Exchange-CrossTenant-Network-Message-Id: d56819c8-3a96-4bb1-3a91-08d9df262b22 X-MS-Exchange-CrossTenant-AuthSource: DU0PR10MB5266.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jan 2022 10:42:07.7237 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d350cf71-778d-4780-88f5-071a4cb1ed61 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ExBeICQuxbwP97+Z7hMRl09E4INJIOf3dVANB4Ydfg+7Z2pDVb52nSMknBwpXsPbeI7WK3pkhdGxF4/qMcqhuSspabH0UFWSGvPxtPn4SFw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR10MB4862 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean On 14/01/2022 17.51, Simon Glass wrote: > Hi Rasmus, > > On Tue, 26 Oct 2021 at 02:08, Rasmus Villemoes > wrote: >> >> On 26/10/2021 03.28, Simon Glass wrote: >>> Hi Rasmus, >>> >>> On Tue, 28 Sept 2021 at 02:57, Rasmus Villemoes >>> wrote: >>>> >>>> The build system already automatically looks for and includes an >>>> in-tree *-u-boot.dtsi when building the control .dtb. However, there >>>> are some things that are awkward to maintain in such an in-tree file, >>>> most notably the metadata associated to public keys used for verified >>>> boot. >>>> >>>> The only "official" API to get that metadata into the .dtb is via >>>> mkimage, as a side effect of building an actual signed image. But >>>> there are multiple problems with that. First of all, the final U-Boot >>>> (be it U-Boot proper or an SPL) image is built based on a binary >>>> image, the .dtb, and possibly some other binary artifacts. So >>>> modifying the .dtb after the build requires the meta-buildsystem >>>> (Yocto, buildroot, whatnot) to know about and repeat some of the steps >>>> that are already known to and handled by U-Boot's build system, >>>> resulting in needless duplication of code. It's also somewhat annoying >>>> and inconsistent to have a .dtb file in the build folder which is not >>>> generated by the command listed in the corresponding .cmd file (that >>>> of course applies to any generated file). >>>> >>>> So the contents of the /signature node really needs to be baked into >>>> the .dtb file when it is first created, which means providing the >>>> relevant data in the form of a .dtsi file. One could in theory put >>>> that data into the *-u-boot.dtsi file, but it's more convenient to be >>>> able to provide it externally: For example, when developing for a >>>> customer, it's common to use a set of dummy keys for development, >>>> while the consultants do not (and should not) have access to the >>>> actual keys used in production. For such a setup, it's easier if the >>>> keys used are chosen via the meta-buildsystem and the path(s) patched >>>> in during the configure step. And of course, nothing prevents anybody >>>> from having DEVICE_TREE_INCLUDES point at files maintained in git, or >>>> for that matter from including the public key metadata in the >>>> *-u-boot.dtsi directly and ignore this feature. >>>> >>>> There are other uses for this, e.g. in combination with ENV_IMPORT_FDT >>>> it can be used for providing the contents of the /config/environment >>>> node, so I don't want to tie this exclusively to use for verified >>>> boot. >>>> >>>> Signed-off-by: Rasmus Villemoes >>>> --- >>>> >>>> Getting the public key metadata into .dtsi form can be done with a >>>> little scripting (roughly 'mkimage -K' of a dummy image followed by >>>> 'dtc -I dtb -O dts'). I have a script that does that, along with >>>> options to set 'required' and 'required-mode' properties, include >>>> u-boot,dm-spl properties in case one wants to check U-Boot proper from >>>> SPL with the verified boot mechanism, etc. I'm happy to share that >>>> script if this gets accepted, but it's moot if this is rejected. >>>> >>>> I have previously tried to get an fdt_add_pubkey tool accepted [1,2] >>>> to disentangle the kernel and u-boot builds (or u-boot and SPL builds >>>> for that matter!), but as I've since realized, that isn't quite enough >>>> - the above points re modifying the .dtb after it is created but >>>> before that is used to create further build artifacts still >>>> stand. However, such a tool could still be useful for creating the >>>> .dtsi info without the private keys being present, and my key2dtsi.sh >>>> script could easily be modified to use a tool like that should it ever >>>> appear. >>>> >>>> [1] https://lore.kernel.org/u-boot/20200211094818.14219-3-rasmus.villemoes@prevas.dk/ >>>> [2] https://lore.kernel.org/u-boot/2184f1e6dd6247e48133c76205feeabe@kaspersky.com/ >>>> >>>> dts/Kconfig | 9 +++++++++ >>>> scripts/Makefile.lib | 2 ++ >>>> 2 files changed, 11 insertions(+) >>> >>> Reviewed-by: Simon Glass >>> >>> I suggest adding this to the documentation somewhere in doc/develop/devicetree/ >> >> Will do. >> >>> Getting the key into the U-Boot .dtb is normally done with mkimage, as >>> you say. I don't really understand why this approach is easier. >> >> I think I explained that in the commit message, but let me try with a >> more concrete example. I'm building, using Yocto as the umbrella build >> system, for a SOC that needs an SPL + U-Boot proper. >> >> So I have a U-Boot recipe that handles the configuration and >> compilation. That's mostly a matter of "make foo_defconfig" followed by >> "make ${UBOOT_TARGETS}" where UBOOT_TARGETS is something set in the >> machine config. That results in two artifacts, say SPL and u-boot.itb >> (the names don't really matter) that are almost ready to be written to >> whatever storage is used for them. Most likely, the SPL binary is built >> from a u-boot-spl-nodtb.bin and a spl.dtb and perhaps there's some >> SOC-specific header in front of it all that the hardware/firmware needs, >> those details are hidden by U-Boot's build system invoking the right >> flavour of mkimage with the right parameters. If I really want to know, >> I can look in spl/.SPL.cmd to see just how it was made [unless it's >> binman creating a flash.bin, because then it's just black magic]. But I >> usually don't need to. >> >> Enter verified boot. SPL needs to verify U-Boot, and U-Boot must in turn >> verify the kernel. I can easily, as a post-compile step, create a signed >> version of u-boot.itb. But the -K option is rather useless here, because >> SPL has already been built. So if I were to only add the corresponding >> public key to SPL's dtb after/while signing U-Boot proper, I'd have to >> manually repeat the step(s) needed to create SPL in the first place. Not >> to mention that the .dtb living inside u-boot.itb doesn't have the >> public key needed for verifying the kernel, so I'd _actually_ first have >> to repeat whatever steps were done to create u-boot.itb, after using >> mkimage to sign some dummy image just to use the -K option to modify >> u-boot.dtb. It's really cumbersome. >> >> So part of the problem is this "you can only get the public keys in the >> form required inside the .dtb as a side-effect of signing an image". I >> believe that's a fundamental design mistake, hence my attempt at >> creating the fdt_add_pubkey tool. But even with that available, adding >> the pubkey info into an already-compiled .dtb isn't really enough, >> because the .dtb gets built as part of a normal "make". Hence the need >> for a way to ensure the pubkey info gets baked into that .dtb during the >> build. >> >> Yes, I then need to prepare proper .dtsi files. But since key generation >> is a mostly one-time/manual thing, that easily goes along with the >> instructions (or script) that generates those, and for every foo.crt, >> I'll just have that directory also contain a foo.dtsi, which I can then >> point at during do_configure. >> >>> Also, is there any interest in using binman? >> >> Not really. I mean, it's fine if U-Boot internally uses that, and I can >> just take the final output and use that. But as long as binman doesn't >> play nice with Kbuild and e.g. tells the commands that were used to >> create a given binary, and pollutes the build dir with stuff that's not >> removed by "make clean", I'm not very enthusiastic about adding more >> uses myself. >> >> Also, this: >> >> BINMAN all >> Image 'main-section' is missing external blobs and is non-functional: >> blob-ext@3 >> >> Some images are invalid >> $ echo $? >> 0 >> >> Really? When building manually, perhaps the developer sees that warning >> (unless there were other non-BINMAN targets that make decided to build >> later, making the above scroll away...), but it's not very useful in >> some CI scenario where artifacts get deployed automatically to a test >> system after a successful build. Recovering boards with a broken >> bootloader easily costs many man-hours, plus the time to figure out >> what's wrong. > > I still think binman is the best solution here. The points you are > raising are annoyances that can be resolved. > > We could return a non-zero value from binman when external blobs are > missing; we'd just need to use a special value (we use 101 for > buildman) and update the CI to detect and ignore that. Eh, does make(1) exit with a code that depends on the exit code from a failing target? What if multiple targets failed to build? Unless one can quote chapter-and-verse from make documentation, I don't think that's a particularly robust solution. > Normally people use a separate output directory from the source > directory, which is why the 'pollution' is not normally a big problem. Well, build systems like Yocto do set up a separate build dir, but that's not really important, as I rarely look inside ${S} nor ${B} - but when doing my own tinkering, I almost always build in the source tree, simply because that's a lot faster for quick experiments. So I'd wish all binman's temporary files were stowed away in some .binman_tmp dir in the top build dir (whether that's the source dir or an out-of-tree dir). Commits like 824204e42 are a strong indication that the current state of things is broken and doesn't scale. > But it is possible to resolve that problem and it has been discussed > on the mailing list. It's just that no one has done it yet. > > In what way does binman play badly with Kbuild? My main grievance is that when binman is merely a thin wrapper around some external tool (often mkimage or one of its derivates), there's no ..cmd file generated allowing me to see just what command was run to generate . Another thing is that I can't do "make ". > I'd really suggest changing the mindset to separating build from > packaging, perhaps by having a separate yocto package/recipe that puts > the firmware together, adds the signature, etc. Oh, I couldn't agree more, and in fact I've already done that for all the kernels I build; Yocto's kernel-fitimage.bbclass is simply too inflexible to use directly from the kernel recipe, so I just build an Image (or Image.gz) in the kernel recipe, then have a separate kernel-fit.bb recipe for actually assembling the different FIT images I need (often one for normal use and another for bootstrapping, but possibly more). But I really can't see how binman helps in any way or form - in fact, it obscures the process of creating such a separate recipe, exactly because I can't extract the necessary magic invocation of mkimage that is needed to wrap SPL in the header format expected by the hardware. And the thing about "adding the signature" - yes, indeed, _signing_ can and should be done after building. But that is not at all what this started with, this is about embedding the metadata that U-Boot (or SPL) will need for _verifying_ during the build itself - when the private key may not even be available. Again, I think that it's a fundamental design bug that generating and adding that metadata in the form needed by U-Boot can only be done as a side effect of signing some unrelated image. Rasmus