[U-Boot] Call for participation in the U-Boot Mini Summit 2014

[Marek Vasut]

On Friday, September 05, 2014 at 05:50:47 PM, Scott Wood wrote:
> On Thu, 2014-09-04 at 17:01 +0200, Marek Vasut wrote:
> > On Wednesday, September 03, 2014 at 06:39:23 PM, Detlev Zundel wrote:
> > > Hi Marek,
> > > 
> > > [...]
> > > 
> > > > I got my talk, "Secure and flexible boot with U-Boot bootloader",
> > > > accepted for the main track it seems. It's mostly about "use fitImage
> > > > and use UBI on NAND" kind of talk, which covers introduction to
> > > > fitImage and storing system components on UBI/UBIFS to prevent
> > > > problems like silent data corruption on modern systems.
> > > 
> > > Excellent!
> > > 
> > > > That being said, I believe I won't be able to cover the fitImage
> > > > verified boot part properly, so I might as well cook a talk for the
> > > > u-boot summit about this advanced topic.
> > > 
> > > We had a talk about that exact topic last year on the main track by
> > > Simon and in the mini summit by Jagan Teki[1].  In what respect will
> > > your talk differ from that?
> > 
> > I believe there is never enough advertising when it comes to fitImage,
> > since we want to get rid of uImage. On the other hand, I see no point in
> > artificially filling the talk slots, so consider my offer only as a
> > backup solution.
> 
> Why do we want to get rid of uImage?

There is no longer much point in uImage other than the size of it's 
implementation. The code which handles the uImage format is smaller
than the fitImage handler, since it doesn't have to deal with all of
the DT stuff.

On the other hand, the fitImage is more flexible -- you can pack in
multiple images , you can select stronger checksum algo than crc32
(which is important), you can sign it. The downside is that not many
people even know of all these options fitImage gives them.

The uImage has been legacy for years now, it's not going away any soon,
but we need to push for stronger adoption of the fitImage format. This
is especially important if you are concerned about things like silent
data corruption of the kernel image or protection against tampering.

Indeed, 'getting rid of uImage' might have been a bit strong wording,
but eventually, uImage should be deprecated.

> It's easier to work with than fitImage.

In which way?

> Or do you just mean get rid of legacy multi-image support?

It worries me we even had something like that.

Best regards,
Marek Vasut