[coreboot] Time for a new project

[Stefan Reinauer]

Am 12.04.2008 um 07:14 schrieb Peter Stuge <peter at stuge.se>:

> 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 our algorithms are broken we should  fix them and not try to  
workaround by adding in-memory checksums. A correct input file leads  
to correct output. If we stop assuming that the uncompressed copy is  
our least problem.

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

Absolutely.

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

Or even in the decompression code

>
>>>> 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
>
> -- 
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>