[coreboot] Time for a new project

[Stefan Reinauer]

Am 12.04.2008 um 04:16 schrieb Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net 
 >:

> 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.

Yes, on purpose. Because LAR takes care of that for the whole file. We  
don't want duplicate information in SELF.

> SELF is missing a per-section compression algorithm specifier and if  
> you
> introduce one...

Short answer: Not needed. The LAR compression type is good enough.  
Using different compression algorithms within a SELF is a bad idea  
anyways.


> you have a compression algorithm specifier both in LAR
> and in SELF. If you remove it from LAR, you have no way to store
> compressed data in a LAR directly. You can work around that by  
> wrapping
> every file with a SELF header, but then SELF becomes a generic file
> container and violates your statement that "SELF is the container for
> executable files".
>
>>> There's also an obvious speed penalty for SELF (guess why).
>> The opposite. There's a speed win because we do less work in lar  
>> walks.
>
> Sorry, you misunderstood. The obvious speed penalty comes from  
> unaligned
> accesses. Some architectures can't even handle unaligned accesses at  
> all.

And they will not happen more often than now.

>
>
>>> 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?

Those are blobs. In a few years everyone will be happy we got rid of  
the current misconception, so no need to explain anything.

>
>
>>> A LAR parser can't figure out if the archive is corrupt.
>> Plain wrong. There's checksums in the lar, and that wont change. Even
>> here you will see a reasonable speed-up because you don't have to  
>> load
>> 3 segments to memory before you find the 4th being corrupted.
>
> 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
> 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.
>

Wrong. The SELF header is checksummed, too. If the SELF is not  
consistent don't load any of it.

>>> 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. SELF
>>> completely destroys that feature.
>> Not at all - The opposite: It makes lar finally more solid again. The
>> feature of checksumming (could have) worked nicely with the very  
>> first
>> version of lar that I wrote. Just the actual checking was not in  
>> place
>> as it is a minor issue when you can't even boot.
>
> 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.
>

Yes and by this simplify the code in all cases. It removes all the  
special cases that we handle now and instead replaces them with a sane  
solution.


>>> We might as well kill LAR completely
>>> and move to SELF only (and then SELF slowly will become a bad
>>> reinvention of LAR).
>> You are seriously misunderstanding the concepts of LAR and SELF.  
>> While
>> 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.
>
> The bootblock and initram are executable files. They should be  
> contained
> in SELF as well (and that means you should be able to state that the
> code is XIP). Tables which should be loaded to a given address in  
> memory
> are by definition NOT code, yet you have to supply a load address
> (something that will only be available to SELF), so SELF is in no way
> "the" container for executable files, but a container for files which
> need at least part of them loaded to a given address.
>
>> When writing software, one should think about the problem that is
>> going to be solved. The reason for unpacking segments was to get rid
>> of the ELF loader and being able to streamload code. This has nothing
>> to do with anything I designed LAR for and the fact that the
>> implementation was married into LAR was obviously a foul hack.
>
> I agree that the current LAR implementation and design is a
> one-size-fits-all compromise.

Just that it doesn't fit, because the concept is broken.

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

Wrong.

> I'm all for revising an existing design as long as the new design is
> better or equal in all aspects. LAR+SELF probably can be beaten into
> shape, but it won't resemble the current proposal.
>
> Regards,
> Carl-Daniel
>