Mark Jackson wrote:
Haavard Skinnemoen wrote:
Mark Jackson wrote:
We do NOT want to do everything that is possible, but only what is reasonable.
Exactly ... otherwise where do you stop ? JPG, GIF, TIFF, PNG, etc ? We're *only* meant to be showing a simply boot up image (not view lots of different sized photos or movies !!), in a very controlled environment (i.e. no "user" options ... just what the designers want / require).
Why not do it even simpler? Drop BMP and generate an image matching the native format of the LCD controller at compile time :-)
Not sure if you're serious, but that'd reduce some of the functionality I was expecting to use.
Well, it was just a thought that struck me, so I'm not going to claim I considered all the pros and cons.
My splashimage is stored in a particular, separate flash partition, and I'm intending to allow end-users to change the boot logo (via a userspace app ?) to customise / personalise the unit as they require (e.g. their own company logo).
You can still do this if the userspace app knows how to generate an image in the correct format -- I'm not arguing against storing the image in a separate flash partition or anything like that. I just think it might be possible to reduce the run-time size and complexity of u-boot by being more strict about the image format.
You could also add support for PNG, JPEG and any format you want to the userspace app -- this will probably be much easier than adding similar support to u-boot itself.
Hard-coding the image would render this impossible.
Of course. But hard-coding the image _format_ isn't the same thing. In a way, we're already using a hard-coded image format, but it's one that is easy to generate for the host, not one that's easy to display by the target.
Haavard