Beagle Board Graphic

Hi all,

Can anyone tell me how to remove the Beagle Board banner graphic that
appears when the unit is booting? I want to change it to a banner with
our product branding instead.

Also, how do I change the timer that starts when the Beagle Board
first boots so that it is 1 second instead of 10?

Many thanks!
Chris

Don't take my word as fact, but I believe it's part of u-boot. I
updated u-boot to a newer version and the Beagle Board banner no
longer shows.

However, I have no idea how you would add a custom banner to it.

Yup… the Beagle logo is displayed by U-Boot. Easiest way is to download the U-Boot src and build it, make sure its working and then add the Beagle splash patch:

U-Boot src:
http://elinux.org/BeagleBoard#U-Boot

There is a link to the splash patch from there. To change the picture take a look at the code, its basically reading a const (called something like logo_header??) directly into the video memory.

Oh, and if you want to create a new logo.h (presumably) the easiest way is to use GIMP and export the image to a C header file (.h).

Personally I would like to see a way of reading a splash from MMC or from a known offset within U-Boot and/or NAND. I might have a play to make the whole custom splash thing a little easier…

I'd vote for that! It would be a great deal easier if you just change
a file and/or the commands given to U-Boot to change the logo.

It shouldn’t be too tricky (not the first time I’ve said that and ended up regretting it :).

I’ve got the U-boot code and can build it… just haven’t changed any code yet… I’m thinking along the following lines if anyone has any comments:

  • add a new UBoot command “splash”. if no options are provided it searches itself to see if an image is embedded. optional argument is the memory offset to read image data from (potentially also including arguments for image width/height/background color). Splash image can then be easily loaded from MMC.

  • provide a linux userspace tool that takes a u-boot.bin and embeds a splash image into it.

  • embedding of image is nothing more than copying the image metadata (width, height, background colour) and image data onto the end of the U-Boot image file.

  • embedded image data would need to include a searchable string so that U-Boot can locate it during runtime (something like ::UBOOTSPLASH**UBOOTSPLASH::slight_smile:

I might even look at image decoders so the raw image data could be PNG/JPG rather than RGB raw… :wink:

any comments, or shall I just add it to my “to do” list…? :slight_smile:

Or any other media that UBoot understands - which is why I like this
idea.

I don't know that I'd get too worried about image parsers - and I
certainly wouldn't think about JPG as a format, as most logo/splash
pages would look ugly at JPG, not to mention the patent issues.

At most I'd stick to PNG, but I think saying that the image is
something dirt simple is probably best.

Just been looking at the cost/benefit of using an image decoder… Whatever I use would need to be open and make the code bloat worth the image size reduction. (Including code bloat for people that don’t want a splash screen)

Standard linux JPG libs are approx 170k - no doubt that size would be significantly reduced as all I would need is basic decode functionality.

  • Current BB logo is approx 410k of raw uncompressed data.
  • GZIPped BB logo is approx 100k.
  • 80% quality JPEG is approx 20k (barely noticeable artefacts)
  • 93% quality JPEG, no obvious artefacts, approx 35k

Image data size reduction is good, but code bloat might be a bit bigger than expected…

PNG libraries appears to be much the same size as JPG.
GIF libraries are 32k… hmm, now what was the latest on GIF format woes… :] perhaps not!

I’ll poke around, but I’m sure there’s a GPL / free-as-in-beer “mini” library out there somewhere…

i did a run-length encoded version. there is significant size savings.

Could something like miniLZO be useful? Or maybe UCL (used in UPX
executable files compressor)?

Many executable file compressors have really small and simple LZ-based
decoders (typically just a few hundreds of bytes of code).

Siarhei Siamashka <siarhei.siamashka@gmail.com> writes:

A good point. Additionally, there is such a thing as "lossy
LZ-compression" to evaluate if the best possible size reduction is
wanted: http://membled.com/work/apps/lossy_png/

Good luck.

Hm.
I'm more into Arjan van de Ven's camp. Arjan stated last LPC that he
wanted "to make boot fast".
Having a splash screen does not contribute to this.
Please allow a way to switch it off!

FM

Introduction of a splash screen won’t delay the current boot process by more than a couple of microseconds… (honest!) I’m flattered you assume my code would be merged… not putting myself down… but a lot of my code lives quite happily as a user applied patch :slight_smile:

I think the delay depends a lot on the size of the bitmap and the way
it is decompressed.
I recall that rendering a 640x480 jpeg on a 108 Mhz cpu took about 1
second (and this was heavily optimised code).
Then again if you use RLE things are probably a lot faster (no
transformation, dequantisation etc which is there in jpg).;

FM

Sorry, I wasn’t being clear. I meant the couple of microseconds delay would be to check if a splash screen was embedded into the U-Boot image or not. If an image is found then the delay clearly depends on the CPU / image size and image type.

I agree - how about something like this:

1) A tool which runs on the developer's machine, that takes an input
file in one of some set of formats (e.g. PNG, JPG, GIF) and outputs an
RGB file compressed with a compressor already in UBOOT. Ideally you
could embed size data and possibly even video parameters (to make
setting up a logo on boot even easier).
2) A UBoot command to load and decompress such a compressed image into
RAM.
3) A UBoot command to display the image.

That way you minimize the code in UBoot and yet can handle all sorts
of image files.

I’ve been playing around today and have got a number of "proof-of-concept"s working. Ugly, but working… :slight_smile:

I also noticed that U-Boot has a “splashscreen” environment variable which appears to be disabled for OMAP boards. This probably just needs someone to teach U-Boot about the framebuffer and then the built-in commands and console out will probably work- I’ll see if I can work that out tomorrow.

Not sure I like the existing support though which is just BMP files :frowning:
Really the only thing missing is a decompress command which no doubt would be useful for booting kernels…

Anyway… more playing tomorrow…

Hi All,

Sorry to side track here - moving back to the original question.

I have re-built uboot using both git sources outlined in the site
below.
http://elinux.org/BeagleBoard#U-Boot

I did not apply any patches or anything. However the beagleboard image
is still there when I boot.
I have replaced u-boot.bin on the MMC card and erased the nand - just
to be sure - but the picture remains.
The uboot version has changed so I am pretty sure that it is updated.

Is there another file somewhere I need to update? or is there
something obvious that I have missed?

Many thanks,
Chris

I’m pretty sure that once I compiled U-Boot from the denx git repo the logo disappeared… Its possible something has worked its way upstream. My Beagle is at home (no doubt making a mess of my carpets) but I can check later on…