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 that area.
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.
Regards, Carl-Daniel