[coreboot] Time for a new project
c-d.hailfinger.devel.2006 at gmx.net
Sat Apr 12 17:06:23 CEST 2008
On 12.04.2008 16:14, Peter Stuge wrote:
> 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.
That could happen.
> If LAR provides a reliable transport then why add another checksum?
Memory corruption during decompression and miscompilation of the
decompression code come to mind.
>> SELF is missing a per-section compression algorithm specifier
> Does it need one? Either the entire SELF is compressed, or not.
Uh, no. The SELF design says that only some SELF segments may be
compressed, others must not be compressed.
> Again, LAR does the work. No?
See above. I wouldn't have complained that much if you were right.
>> 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() ?
Are you willing to copy the lzma header for every lzma-compressed SELF
segment to some reserved place in RAM? Are you willing to rewrite the
decompression code so that it can handle a detached lzma header?
>>>> 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.
raminit needs an entry point, so it has to be SELF (unless you propose
that LAR and SELF both specify an entry point).
>>>> 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.
See my other mail in response to Patrick.
>> 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?
A LAR archive can have multiple SELFs and each of them can reference
arbitrary memory and the LAR parser has no way to check that. A SELF
parser could check that, but then it would have to know about the LAR
structure which is a layering violation.
>>>> 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?
Currently, the ELF-to-LAR parser has a reasonable chance to find out
whether the structure of the ELF is crap. If LAR simply handles a SELF
as opaque object, it will not notice at all if the SELF is crap.
> 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. :)
What? And I trusted its baseball result predictions for 2009 ;-)
> 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.
Are we guaranteed to reach the panic room if the SELF points to
>>> 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.
initram needs an entry point. Storing an entry point in LAR and in SELF
is really bad design.
>> 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?
Hm. I know of no such table yet. What about option ROMs?
>> 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?
I hope I listed most of my concerns above.
More information about the coreboot