[U-Boot] [PATCH v3] Add 16bpp BMP support

Haavard Skinnemoen haavard.skinnemoen at atmel.com
Mon Feb 23 11:26:24 CET 2009


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


More information about the U-Boot mailing list