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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A90BC48BE8 for ; Tue, 15 Jun 2021 08:20:08 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 0B9A76141F for ; Tue, 15 Jun 2021 08:20:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B9A76141F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1A7B580092; Tue, 15 Jun 2021 10:20:03 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="Jr3iycUV"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3ECF881249; Tue, 15 Jun 2021 10:20:00 +0200 (CEST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id DB34C80082 for ; Tue, 15 Jun 2021 10:19:56 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ilias.apalodimas@linaro.org Received: by mail-wm1-x331.google.com with SMTP id c84so846014wme.5 for ; Tue, 15 Jun 2021 01:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=xs+3ITm+6kJkfjGOhSQeakLF46jl2xZLmvy5J9fW7Bs=; b=Jr3iycUV0kof7ymeYJ7DP39d8EZKzh4Z76RlXhSIdOk2ecVO1GSQeDyCv1AZpuWo3D CjTdc9OJr3XkpLPx1fopFcKmENq918KHEGYJDgQWejyPap+dSepEVBqZj+Zm1B8MhT5Y kxrncIojE6dugE9JfoFlRaPhReWJk39i9J0U6klrxneUleEhkeEr/boR85gTSeKrgXqH verix64Gg4YH9q372beSK4maYOY3UfcCr1DsGRN3656i9PPOc8Z46I/9DKJQsCL/jV1C 2GjgESkPNl2OdGMm1pqxp1Xv6OjpSdxAVWDGabGUYdqxchs91OVmk9jb4T3jbVUdLjnZ sDHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=xs+3ITm+6kJkfjGOhSQeakLF46jl2xZLmvy5J9fW7Bs=; b=KlymmDJzbQih28Npz/iCnnJ7y6+pbzhn/vTZU9JnlatYvCzoezA24D775dvJRUGZ1J p5dtS/z+prraVu3/QHHkh5yDAzVcVYqoEdCFETyTY8lSBWZbWsoP/9jFaEaJLcS7pp+h La9GVLyI0D4uLAn3limbhLM2RlfHmPZCJXEfBQGDL5sVubXSE6FFKaLYZjtVks+8UH6W GnjIuE5M0y0Ql6qCnm8dUHgXGU7HIM0pJ2bV97ry70BQYOZTAvmTDW9Usj7THgW6id5X 5pDIoZ4+4P1x6IPFazLOo78IptonbLGSPxGQstk9is0w1l6UyHmbHgNf7t/VSI+oO9VZ Mh+Q== X-Gm-Message-State: AOAM5314OQntMyNoEenNlqmYUCuc6cXGWzpJhhsX3bVnFn6meXzP//40 6R2/Tv2NMVr+wqlibSOB9MmnHg== X-Google-Smtp-Source: ABdhPJzydHkXeO8LVmkQHr25WwXdQ5JlYvVuL4R2GocBxHQIhs2tlY8SxjJXAg/9AYeYDeR2HFVdRw== X-Received: by 2002:a05:600c:a04:: with SMTP id z4mr21123337wmp.103.1623745196313; Tue, 15 Jun 2021 01:19:56 -0700 (PDT) Received: from enceladus (ppp-94-66-220-227.home.otenet.gr. [94.66.220.227]) by smtp.gmail.com with ESMTPSA id n1sm15107627wms.18.2021.06.15.01.19.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Jun 2021 01:19:55 -0700 (PDT) Date: Tue, 15 Jun 2021 11:19:53 +0300 From: Ilias Apalodimas To: AKASHI Takahiro , xypron.glpk@gmx.de, masami.hiramatsu@linaro.org, Simon Glass , Mario Six , Michal Simek , Alexander Graf , u-boot@lists.denx.de Subject: Re: [PATCH] efi_loader: FMP cleanups Message-ID: References: <20210614151015.99992-1-ilias.apalodimas@linaro.org> <20210615015101.GA46087@laputa> <20210615044458.GA54329@laputa> <20210615055538.GA56793@laputa> <20210615064023.GA58428@laputa> <20210615071331.GA58885@laputa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210615071331.GA58885@laputa> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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.2 at phobos.denx.de X-Virus-Status: Clean [...] > > > > > Yes. > > > > > We may have different *firmware* for different software components > > > > > and different devices. For example, > > > > > You have firmare like U-Boot binary and default variable storage > > > > > in different partitions. > > > > > On the other hand, you have an extra firmware for a particular > > > > > peripheral, like PCI device or anything else, which comes > > > > > from a 3rd party vendor of the device. > > > > > The former may and can be packed into a single binary in FIT format. > > > > > The latter can be used in a separate RAW format as the timing of > > > > > updating those firmware is likely to be different. > > > > > > > > > > > > > Sure that's a use case. But that's not a specific one, nor something you cant > > > > do without both of them being installed. You can arguably just create a RAW > > > > image for the second firmware and put the info into dfu_alt_info. > > > > > > Why do you stick to a single format? > > > > I think it's the other way around. Why wouldn't you? It's the easiest and > > sanest thing to do when generating capsules. > > I don't know why you think it's the easiest. > "mkeficapsule" can create any format of capsule file. > (This is not true in the current form. but it's quite easy > to enhance this command for this purpose.) Because it's easier from a system maintenance perspective to have to deal with a single capsule format instead of two. > > > > We can reasonably assume that each FMP may > > > have a different format. > > > I think it's a very natural thing. > > > > The FMPs logic in the EFI spec is not tied to 'format', it's tied to 'device' > > and currently both FMPs target the same device. > > the same device? What do you mean by 'same device'? > I probably won't agree. > This depends on the dfu_alt_info. See below > > So my understanding is, that > > in order to use it you need to: > > 1. Create 2 capsules, 1 raw, 1 fmp. > > 2. Set dfu_alt_info -> process RAW capsule. > > What do you mean by "process"? > > > 3. Set dfu_alt_info to something different -> process FIT capsule. > > No. What you need to do is to *add* definition for firmware > in FIT. We can have a single definition of dfu_alt_info > even if we use both FIT and RAW FMPs. Ok that's what I've been asking all along. Do you have an *working* example for that? Set the dfu_alt_info once and be able to update 2 different flash devices on the same system, using 1 capsule as RAW and 1 capsule as FIT. While at the same time populate those 2 different flash devices correctly in the ESRT. > > > and by doing so the ESRTs will use one of the information found in > > dfu_alt_info. > > So what? If they both refer to the same flash, the spec says you shouldn't do that and you have no way of knowing this right now. But if you can define a dfu_alt_info, that exposes 1 flash device handled by the RAW capsule and 1 flash device handled by the FIT capsule, I guess that would be fine. But looking at the dfu entities code, we can add mmc, mtd, nand, ram, sf or virt and the it handles things like 'raw' of a filesystem. How do you point out "this dfu entry is a fit"? > > > > > > > > > > So unless we > > > > have an example of a device that says "This firmware file can only be updated > > > > by a FIT image, while the rest of the firmware is on a FAT filesystem", I don't > > > > see any reason why we need to support that. The changes are not set in stone > > > > anyway. The code was fine before the ESRT got involved. So all my patch > > > > really does is make the current code useful when an ESRT is installed. We can > > > > then break the spec on purpose (yes break it :>) ignore the OsIndications > > > > bit and have fwupd working with U-Boot. This will have an actual impact on > > > > devices and the code usability, since people will start using it. I prefer > > > > this over adding a very cumbersome corner case, that's arguably no one will > > > > ever need. > > > > We can always go back and make them a config option in the future. But unless > > > > we get a use case for it, I'd still prefer having them mutually exclusive, > > > > rather than adding code for an imaginary device (which I really doubt anyone > > > > will ever design). > > > > > > I don't think that the example I gave is a imaginary device. > > > > > > > All of the devices I've tested and seen up to now are working fine with just > > RAW capsules installed and I can't understand why a specific *format* should > > play a role in the capsule creation. > > I don't get your point. > I never said, "a specific format should play a role." > > > FITs are a nice way to get authentication and bundle things without having the > > EFI capsule authentication code, but really apart from that those 2 are doing > > the same thing. > > Yes, but why do we have to have the restriction? > Different capsule files for different firmware/device may > come from different owners of the firmware. No that's a completely moot point imho. If any vendor has a very special firmware he needs to treat in a very special way, he needs to install his own FMP. If we are talking about different firmwares on *different* flash devices, then the final board re-seller should say "all of you individual people send me RAW capsules, or FIT capsules". There still hasn't been a single argument on what you can achieve with a FIT specific image, which you can't with a RAW. So I'll ask again. The fact that you *can* do it doesn't mean it the sane thing to do. > > > [...] > > > > The ESRT code right now uses get_image_info from the FMP code and the FMP code > > > > uses the dfu_alt_info to derive whatever information it needs. Both of these > > > > concepts are trying to provide information about the running firmware. So if > > > > we change that imho both of them should get that info from an abstracted > > > > object (file/c struct in u-boot/whatever). But really I think using FMP to > > > > fill ESRT entries is fine (at least for me). > > > > > > Well, dfu_alt_info can already be seen as abstracted object > > > in terms of FMP. > > > > Yes but it can't handle the ESRT generation properly. So if you change that, > > why leave the FMPs get_image_info, read the information differently? > > Again, I don't get your point. > I've tried to explain this a couple of times. If we manage to answer the dfu_alt_info question above sufficiently, then maybe you will Thanks /Ilias