experimental splash screen support
laforge at openmoko.org
Tue Feb 20 15:09:40 CET 2007
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
> 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
> 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.)
> 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.
> - 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
> - 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)
- Harald Welte <laforge at openmoko.org> http://openmoko.org/
Software for the world's first truly open Free Software mobile phone
More information about the openmoko-uboot