[coreboot] [RFC] coreboot image marker

[Jordan Crouse]

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