From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Thu, 19 Mar 2020 10:55:01 +0200
Subject: [RFC 13/14] tools: add mkeficapsule command for UEFI capsule
 update test
In-Reply-To: <20200318013237.GR13880@linaro.org>
References: <20200317021247.5849-1-takahiro.akashi@linaro.org>
 <20200317021247.5849-14-takahiro.akashi@linaro.org>
 <2befee04-ac36-dc3e-b969-46c94bab87c7@gmx.de>
 <20200318013237.GR13880@linaro.org>
Message-ID: <20200319085501.GA141034@apalos.home>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Wed, Mar 18, 2020 at 10:32:38AM +0900, AKASHI Takahiro wrote:
> On Tue, Mar 17, 2020 at 08:58:55AM +0100, Heinrich Schuchardt wrote:
> > On 3/17/20 3:12 AM, AKASHI Takahiro wrote:
> > > This is a utility mainly for test purpose.
> > >    mkeficapsule -f: create a FIT image firmware capsule
> > 
> > The UEFI spec defines a capsule format and how to invoke it by placing
> > the file in the right directory before reboot. Why do we need a FIT
> > image firmware capsule?
> 
> ??? I don't get your point.
> 
> A capsule is just a wrapper that can hold any kind (or format) of
> binary data. In fact, an associated capsule driver should know
> how the data should correctly be handled on U-Boot.
> 
> So if you provide your own driver (more specifically, "firmware
> management protocol" for firmware update), you can encapsulate
> any firmware in your proprietary format.
> 
> In this RFC, I provide a *sample* driver for a single FIT image
> in patch#9.

FWIW I think Takahiro's approach is fine here. FIT has been around for a couple
of years so why not use it? As Takahiro pointed out, this is by no means
restrictive.

Regards
/Ilias