experimental splash screen support

[Harald Welte]

On Tue, Feb 20, 2007 at 04:24:47AM -0300, Werner Almesberger wrote:
> Let's see if anyone has found this list yet ;-)

I 'found' it, but had some misconfigured imap sync script for that
mailbox.

> We use gzip'ed BMP images with a palette and 8 index bits per pixel. If
> you look carefully, you can see the dithering, and the colors are also
> not quite as rich as when using the full 16 bit data, but at least this
> is quick and saves space. (Some 16 kB vs. 600 kB for 640x480x16.)

I think we have to work with eight bit here.  We can't really afford too
much flash space and even additional delays.  If the image quality
on-screen is not enough, we go back to the designer and ask him to keep
8bit in mind.

> u-boot already has support for gzip and BMP. However, when unzipping,
> it wants to keep everything in memory at once, so I had to increase the
> heap from 128 kB to 400 kB. I've even tried 512 kB, but there I hit
> something that didn't want to be disturbed. I still have to check what
> this was, and if it may cause trouble with 400 kB, too.

mh, maybe we should modify that the gunzipped data goes directly into
the framebuffer? oh, wait, it's bitmap ;)

Can you do some size experiments on raw framebuffer images, compressed
with gzip?  If that gives us sufficient results, it might be an
alternative.

> u-boot's splash image support assumes that the image is in regular
> memory (RAM or NOR Flash). Since ours is in NAND, I've changed the
> mechanism such that, if the environment variable "splashimage" is not a
> valid number, u-boot simply executes it as a command. There we can load
> the data from Flash, and display it. (I've enabled the "bmp" command
> for this.)

ok.

> Now, I think it would be good to have an indication when we're
> actually about to boot the kernel. Fortunately, this is easy to do.
> We can just load another image and display it as part of "bootcmd".

Firstly, I don't think that this is particularly important.  Secondly, I
think it can be done by redefining the palette in a way that some
(currently blacked out) colour suddenly appears on-screen.

> One problem is that bootcmd is now getting so long that we exceed the
> maximum number of command line arguments. So I've increased them from
> 16 to 64.

mh, will have to look at that.

> In order to save space, I've made the new image an update of the old
> one, and I'm just loading the new part (Tux, the obvious choice).

ok, will check it out.

> In order to avoid having to do NAND offset calculations, I treat the
> two images as a contiguous data block. This also helps to avoid
> additional complications if bad blocks get in the way. Since we don't
> have a useful way of handling sizes, I just use the sizes my images
> have, and add a bit of slack. If using something entirely different,
> all this changes.

we could introduce two separate partitions, if we wanted.  Also, I think
the good old palette adjustment trick would do the job.

> I've just lumped all changes related to this into a single patch.
> In truth, that should be about four distinct pieces. I'll pry this
> apart later. For now, it suits me to have everything in one place.

sure.

> - decide whether we really want a second image, and if yes, what it
>   should look like. Good old tux isn't too ugly, but it could at least
>   use some sort of halo.

I would either stay with one, or do the palette trick.

> - see how things are with full 16 bit. Slow, probably.

I wouldn't even go there.

> - decide whether the grainy 8 bit image is good enough, and, if not,
>   what to do

That's a 'beyond phase 1' topic.

> - confirm that HWSWP is how the kernel expects it 

ok.

> - check that the display doesn't light up before the splash screeen
>   image is shown (it does that when booting from JTAG, but that's
>   expected, since everything is already powered up)

ok.

-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone