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.
Nak.
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.
Thanks, Jordan