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.
That might have been the original goal, but its just simply not the case in reality. Having to put the bootblock in a fixed position completely destroys the theory of a pure archive. And Ron has requested that we be able to support LAR components in fixed locations within the ROM, which will further emphasis the need for a fully formed ROM from the word go.
And really, this isn't a bad thing - the logical output of the coreboot build is a valid ROM (i.e - properly organized bits that can be directly written to the hardware without further modification). LAR still plays an important part here because both coreboot and the userland utilities desperately need a filesystem like organization within the ROM.
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.
There are a number of problems with that approach - one, it doesn't work with v2, which was an important feature of Carl-Daniel's design. Two, it ends up wasting (eraseblock - sizeof(lar header file)) bytes on every ROM. Thirdly, coreboot and the LAR utilities would still have to know the size of the ROM and the location of the first LAR entry, so information has to be written to the bootblock regardless. The bootblock is valuable here because it is in a known fixed location, and both coreboot and the LAR utility can easily communicate with one another through it.
I think it is important to keep the non-structure of larballs.
Can you explain why in more detail? Do you have some examples?
Jordan