[coreboot] [RFC] coreboot image marker
c-d.hailfinger.devel.2006 at gmx.net
Sun Dec 7 12:38:57 CET 2008
On 07.12.2008 03:42, Peter Stuge wrote:
> Jordan Crouse wrote:
>> LAR desperately needs this - a master header would solve problems
>> in multiple fields at once.
> It goes directly against one original design goal of lar that I
> consider to be essential (the larball is a series of independent
> files) and I do not understand all the benefits.
> This lar feature comes from the desire to support the use case of
> replacing single files in the lar in flash without any modifications
> being needed in any other part of the flash chip.
> One way to preserve that goal while still providing the information
> you desire would be to store any master header in a separate file in
> the lar.
Storing the LAR size in the boot block is irrelevant for the LAR
utility, but absolutely essential for booting. There's no other way to
find out where to start scanning for LAR members. (In theory, we could
start scanning at 4G-16M, but I doubt anybody wants to wait for up to 16
million accesses before the first LAR member is found.
By the way, for future boards (especially GA-M57SLI) in v3 we will need
another header field: Mappable size. It is pointless to scan memory
where a chip is not mapped even if the chip would theoretically occupy
> I think it is important to keep the non-structure of larballs.
As long as the boot process can easily determine all the info it needs,
that is OK with me.
More information about the coreboot