[coreboot] Time for a new project
stepan at coresystems.de
Sat Apr 12 20:53:27 CEST 2008
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
>> 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:
>>>> 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?
>> 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
>> overlapping archive members right now. With SELF, a corrupt SELF
> 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
> 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
>> 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
> This is where I'm lost. Please explain what would not work anymore?
> coreboot mailing list
> coreboot at coreboot.org
More information about the coreboot