[coreboot] Embedding VSA in a LAR

Jordan Crouse jordan.crouse at amd.com
Wed Jan 23 16:56:14 CET 2008

On 23/01/08 02:33 +0100, Carl-Daniel Hailfinger wrote:
> Besides the obvious stuff (storing the VSA as a file in the LAR) there
> are two points to solve which are rather interesting:
> - Entry point specification
> - Load address specification
> Both are not trivial because we get both specifications above from an
> ELF header. The VSA is not an ELF file, so we have to specify entry
> point and load address by hand.
> The following patch allows us to specify LAR entries like
> "entry=33:blobs/vsa" which then have entry point addr 33.
> This can be extended to a loadaddr= parameter.


Seriously, why are we making this so difficult?  All Geode code needs
the VSA.  _Only_ Geode code needs the VSA.  All Geode code will put
the code in the same place and load it the same way.  All the code 
really needs from the LAR is a blob.  find_blob('blobs/vsa') - thats it.
The code will know where to put it, and what to do with it.    Your method
takes that knowledge out of the hands of the code and puts it in the hands
of the user.  That is a recipe for disaster.

I admit, I was the original LAR abuser - I took it from a simple command
line option to a long list of options and flags, so its slightly hypocritical
for me to complain now.  But I think that we need to be careful to consider
the practical aspects of what we are doing.  We need to make things easier
for the person building the ROM; regardless of if they use a tool or 
roll it by hand.  Forcing the user to understand complex information
like load addresses and such (which even _we_ will forget and have to
look up on the wiki) is not productive.  It is double plus not productive
when the information we are asking them to provide is already static and
well known.

Lets go back to basics on this one - put the blob in the LAR (easy to do),
and then the code will know how to use it.  Done and done.


More information about the coreboot mailing list