[coreboot] Time for a new project

[Peter Stuge]

On Sat, Apr 12, 2008 at 01:16:00PM +0200, Carl-Daniel Hailfinger wrote:
> On 12.04.2008 10:28, Stefan Reinauer wrote:
> > Carl-Daniel Hailfinger wrote:
> >> NAK. This design is so unfinished it is not even funny. Hint: Certain
> >> fields in the LAR header are there for a reason (guess which).
> >
> > Yes, and because that concept is so incredibly broken beyond belief,
> > we fixed it up at the summit. Those completely archive-unrelated
> > fields which just sneaked into lar because we did not do our reviews
> > thoroughly enough will finally go away again. Way to go.
> 
> SELF is missing a checksum for each uncompressed segment.

Is that really needed? That means we expect the decompression to
fail silently.

If LAR provides a reliable transport then why add another checksum?


> SELF is missing a per-section compression algorithm specifier

Does it need one? Either the entire SELF is compressed, or not.
Again, LAR does the work. No?


> Sorry, you misunderstood. The obvious speed penalty comes from
> unaligned accesses. Some architectures can't even handle unaligned
> accesses at all.

Can't this be solved generically in code like in memcpy_helper() ?


> >> The concept of PIC is missing completely.
> > Because it is not needed.
> 
> So you propose to handle some executable code (bootblock, raminit)
> just with LAR and not with SELF? How are you going to explain that
> concept a few years down the road?

KISS. Since the early LAR files are simple binaries they don't need
to be SELF.


> >> A LAR parser can't figure out if the archive is corrupt.
> > Plain wrong. There's checksums in the lar, and that wont change.
> 
> Wrong. Checksums say nothing about corrupt internal SELF structure.
> The LAR parser has the ability (well, at least in theory) to check for
> overlapping archive members right now. With SELF, a corrupt SELF header

First of all, how would it end up corrupt? It must then be corrupt
upon SELF creation, because if it changed in LAR, the LAR checksum
would not match anymore.


> can reference arbitrary places in the archive and a pure LAR parser
> can't find that out because it does not parse SELF by design.

Why does this matter, in practise? More than one SELF will never be
up in the air. And so what if it references locations in the LAR?


> >> Ron once stated the ability to figure out whether the ROM is
> >> corrupt before you flash it is one of the key features of LAR.
> 
> And since a pure LAR parser does not understand SELF, you need a
> combined SELF+LAR parser to know whether the ROM has a chance to
> boot.

What would be checked in the SELF? Isn't it good enough that there is
a SELF with the right name?

I think it is impossible to reliably determine boot success ahead of
time. Only trying to boot will show the actual outcome, especially
since we want to reflash individual LAR files. I guess I disagree
with Ron's statement. LAR is very nice, but it can't predict the
future. :)

Instead the coreboot panic room will be the key feature in this
domain. The fact that you don't just get beeps from a speaker but
an actual way into your system regardless.


> > LAR is an archiver of arbitrary(!) files, SELF is the container
> > for executable files. Mixing these two up was the biggest mistake
> > in the history of the young LAR, making things irreversible and
> > fragile.

Word.


> The bootblock and initram are executable files. They should be
> contained in SELF as well

I don't think that is neccessary.


> Tables which should be loaded to a given address in memory are by
> definition NOT code, yet you have to supply a load address

Hm, what kind of tables? What would this be that is just copied from
LAR using some generic code rather than code that knows about the
neccessary adress already?


> Unfortunately, the current SELF+LAR proposal is not able to keep
> the design simple and still perform all tasks we currently use LAR
> for.

This is where I'm lost. Please explain what would not work anymore?


//Peter