Sorry for entering late here. Here are my questions:
How does l-m-c know about the boot partition convention? Is the fact that omap wants a dos partition with some files on it but i.MX just needs the raw bits at a fixed location on the card embedded in l-m-c? If a new platform pops up with a completely different convention does l-m-c need to be modified or could we put a script in the hwpack to do that?
For map you could call a script with an argument pointing to the blown out hwpack and and second argument pointing at the mounted boot partition. For mx first argument is the same second is a pointer to raw device. So the hwpack would need a field to say if the scipt needs a raw device or mounted dos partition and.. another field with the script name.
Is this over engineering?
Sorry for the noise, John
On Wed, Jan 19, 2011 at 9:58 AM, Loïc Minier loic.minier@linaro.org wrote:
On Wed, Jan 19, 2011, James Westby wrote:
Right, but what would they do? That's my point.
If you really want to push Andoid in to v2 then we can write code to identify/specify image type, then defer Android/linux_image combination with a specific error message.
The point of a format specifier is such that l-i-t won't try to act on things that are added after that version was released. If the old code won't do the wrong thing then we don't need a format bump.
That's exactly my point: have the next version of the code try to do the right thing. Maybe I actually have broken expectations: I expect l-i-t would reject hwpacks with unknown fields. That's the failure I'm trying to avoid if we know we're going to introduce a linux_image field and that it can be safely ignored.
It's a bit like when Debian introduced Breaks, by adding support to dpkg to simply treat the field in a dumb way, and then adding full support the next cycle, as to allow using old dpkg for upgrades.
-- Loïc Minier
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev