[coreboot] v3 patch rm elfboot

[Stefan Reinauer]

* Myles Watson <mylesgw at gmail.com> [080215 20:56]:
> >  Elfboot still uses bootblock space if it is disabled in Kconfig? That's
> >  definitely something we need to fix. That space is tight.
> 
> PAYLOAD_NONE doesn't mean no elfboot.  Elfboot is included always so
> that if someone adds an ELF to the lar later it will still work.  My
> contention is that we should make people preparse the ELF when adding
> it to the lar, so that v3 doesn't have to understand ELF.  That
> doesn't mean that lar shouldn't.  Just the opposite.

I am talking about CONFIG_PAYLOAD_PREPARSE_ELF, not at all about
CONFIG_PAYLOAD_NONE.

> >  Please don't just remove this code. If you don't like to compile it in,
> >  create a config option to disable it. (There is such a config option
> >  already, so I really don't see the gain)
> 
> I didn't see one.

One might say CONFIG_PAYLOAD_PREPARSE_ELF implicates that the ELF
parsing is ommitted in coreboot. I agree that that's misleading. Alle
the ELF preparsing pretty much messed up the code to begin with.

> >  Because with this patch it is no longer possible to unpack a lar.
> 
> v3 doesn't unpack a lar.  lar unpacks them.

C'mon. lar is part of v3, and lar can not unpack lar files without
loosing information anymore. This is broken, and it breaks all of the v3
concept. If people want a config option to choose a broken concept,
well, go ahead. But please leave a method in for the rest of us who need
to rely on a safe and reliable method.

I don't think it is appropriate talking about dropping ELF support from
coreboot as long as the lar handling is as broken as it currently is.
Regardless whether that happens in our code under lib/ or under util/

> >  Or we forget about lars having the feature to be unpacked. Not sure that
> >  its ever needed, except when you want to migrate a payload from one
> >  image to another one.
> 
> This is a lar problem, not a v3 problem.
 
You keep repeating this like a mantra. Would you mind explaining the
difference? I don't care what part is broken. I just don't think it is
sane to drop working code while the broken code doing something similar
is not fixed.

Sorry. 

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866