Am 12.04.2008 um 07:14 schrieb Peter Stuge peter@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@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot