experimental splash screen support

[Werner Almesberger]

Let's see if anyone has found this list yet ;-)

I've just checked in a first try at splash screen support. The design
is as follows:

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.)

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.

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.)

Note that this is somewhat risky, since we're still deep in device
bringup, so trying to do too much from "splashimage" may cause
surprises. (This also needs to be linked with the factory reset mode.)
Nevertheless, it works for the intended purpose, and this also allows
us to try other schemes, such as loading a full 16 bit image directly
into the framebuffer. So far, so good.

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".
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.

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).

The tools to generate the images are in SVN,
developers/werner/splash/
They're still very unpolished. Usage is described in README, along
with a complete splash screen setup walk-through.

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.

The u-boot patch is in SVN,
trunk/src/target/u-boot/patches/uboot-s3c2410-splash.patch

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.

Open issues, besides things mentioned above:

- 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.

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

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

- confirm that HWSWP is how the kernel expects it 

- 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)

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina     werner at almesberger.net /
/_http://www.almesberger.net/____________________________________________/