Am 12.04.2008 um 08:06 schrieb Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net
:
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.
You want to catch compiler bugs during runtime? Come on let's get serious again and deal with the real world.
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.
Right. Using the lar specified compression algorithm. So?
Keep in mind that we handle segments much differently than xip and blobs already.
Again, LAR does the work. No?
See above. I wouldn't have complained that much if you were right.
Ehem
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).
At some point the entry point to a blob was at the beginning of the file. Adding the flexibility to begin with moved complexity from compile time to run time -- guess what, that was a bad idea.
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.
What problem are you trying to catch?right now this is just artificial
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?
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.
in the real world this is not true.
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 arbitrary memory?
Beause of what?compiler bugs? In that case the miscompiled panic room will not help us.
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.
initram needs an entry point. Storing an entry point in LAR and in SELF is really bad design.
Wrong and right.
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?
They are handled 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?
I hope I listed most of my concerns above.
Regards, Carl-Daniel
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot