Jordan Crouse wrote:
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.
Full ack. If the code can make an optimal decision, there is absolutely no reason to create a bload-interface around it for a flexibility that noone is ever going to use. We have this in v2 in so many places, one of them is the image building/size logic in the device tree description file Config.lb (calculating fallback/normal offsets etc) This has caused so many headaches, and has actively scared people away from the project.
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.
Yes. All we need to know about the VSA binary is its start address in the lar. There is no need whatsoever to add any extra code for it, except maybe making the build process aware of the fact that it needs to pack the vsa blob into the lar.
Stefan