[U-Boot-Users] [RFC] Splash image
Hello,
I'm planning to review the splash image support and in order to do that my next steps should be:
1) Remove the logo support.
Currently we have two function for a boot screen: CONFIG_SPLASH_SCREEN and CONFIG_LCD_LOGO. I propose to remove logo support since logos must be statically compiled into u-boot and cannot be changed unless rebuild u-boot. On the other side splash images could be loaded at runtime.
2) Rewrite the lcd_display_bitmap() in order to be more portable across several BPP values.
I'd like to have some suggestions from you before starting to modify the code. :)
Thanks in advance,
Rodolfo
"Rodolfo Giometti" giometti@enneenne.com wrote in message news:20070718083012.GE4836@enneenne.com...
I'm planning to review the splash image support and in order to do that my next steps should be:
- Remove the logo support.
As long as it's modular, I agreed because the two functions are nearly identical. It's important to add/remove code to keep the size down. Probably should test for a pointer to a compressed (gzip) image, uncompress, then call the bmp_display.
- Rewrite the lcd_display_bitmap() in order to be more portable
across several BPP values.
Keep it modular; have a bitmap_display(addr, x, y) robust to bpp that is called from an lcd_display_splash_screen(). Account for 24-bit LCDs and files. The bit-per-pixel data structure was a poor-fit with 24-bit, and I didn't even try to support colormapped files on a truecolor display. Great idea because it might save a ton of flash to display an 8bpp image on a 24bpp display.
3. If there's an overall flash savings, it would be nice to support GIF, PNG, or some other format smaller than a BMP. How complex is the parsing, and would it be a net savings on flash?
4. Account for text overlay on splash screen. There are callbacks for bootup progress, and it's nice to lcd_printf() the status to some rectangle on the screen. Even better if it scrolls or clears nicely.
5. Document and improve the videolfb ATAG. I hardcode my framebuffer to the end of RAM, don't tell linux to use that memory, and pass the info to linux. The display still flickers until you remove the re-initialization, but at least Linux won't move and therefore clobber the contents of the framebuffer.
-joey
On Wed, Jul 18, 2007 at 09:40:28AM -0400, Joey Oravec wrote:
"Rodolfo Giometti" giometti@enneenne.com wrote in message news:20070718083012.GE4836@enneenne.com...
I'm planning to review the splash image support and in order to do that my next steps should be:
- Remove the logo support.
As long as it's modular, I agreed because the two functions are nearly identical. It's important to add/remove code to keep the size down. Probably should test for a pointer to a compressed (gzip) image, uncompress, then call the bmp_display.
I think we should remove it definitely... it's just doubled code.
- Rewrite the lcd_display_bitmap() in order to be more portable
across several BPP values.
Keep it modular; have a bitmap_display(addr, x, y) robust to bpp that is called from an lcd_display_splash_screen(). Account for 24-bit LCDs and files. The bit-per-pixel data structure was a poor-fit with 24-bit, and I didn't even try to support colormapped files on a truecolor display. Great idea because it might save a ton of flash to display an 8bpp image on a 24bpp display.
- If there's an overall flash savings, it would be nice to support GIF,
PNG, or some other format smaller than a BMP. How complex is the parsing, and would it be a net savings on flash?
I think we should support just one format for two reasons:
1) Supporting just one format keep the code smallest.
2) We have "convert". :)
- Account for text overlay on splash screen. There are callbacks for bootup
progress, and it's nice to lcd_printf() the status to some rectangle on the screen. Even better if it scrolls or clears nicely.
- Document and improve the videolfb ATAG. I hardcode my framebuffer to the
end of RAM, don't tell linux to use that memory, and pass the info to linux. The display still flickers until you remove the re-initialization, but at least Linux won't move and therefore clobber the contents of the framebuffer.
I dislike this feature. :) IMHO I think it introduces several problems and complications whose can be avoided just defining a boot logo into Linux... however it could be keep into some consideration.
Thanks for your suggestions,
Rodolfo
Rodolfo Giometti wrote:
On Wed, Jul 18, 2007 at 09:40:28AM -0400, Joey Oravec wrote:
"Rodolfo Giometti" giometti@enneenne.com wrote in message news:20070718083012.GE4836@enneenne.com...
I'm planning to review the splash image support and in order to do that my next steps should be:
- Remove the logo support.
As long as it's modular, I agreed because the two functions are nearly identical. It's important to add/remove code to keep the size down. Probably should test for a pointer to a compressed (gzip) image, uncompress, then call the bmp_display.
I think we should remove it definitely... it's just doubled code.
- Rewrite the lcd_display_bitmap() in order to be more portable
across several BPP values.
Keep it modular; have a bitmap_display(addr, x, y) robust to bpp that is called from an lcd_display_splash_screen(). Account for 24-bit LCDs and files. The bit-per-pixel data structure was a poor-fit with 24-bit, and I didn't even try to support colormapped files on a truecolor display. Great idea because it might save a ton of flash to display an 8bpp image on a 24bpp display.
- If there's an overall flash savings, it would be nice to support GIF,
PNG, or some other format smaller than a BMP. How complex is the parsing, and would it be a net savings on flash?
I think we should support just one format for two reasons:
Supporting just one format keep the code smallest.
We have "convert". :)
- Account for text overlay on splash screen. There are callbacks for bootup
progress, and it's nice to lcd_printf() the status to some rectangle on the screen. Even better if it scrolls or clears nicely.
- Document and improve the videolfb ATAG. I hardcode my framebuffer to the
end of RAM, don't tell linux to use that memory, and pass the info to linux. The display still flickers until you remove the re-initialization, but at least Linux won't move and therefore clobber the contents of the framebuffer.
I dislike this feature. :) IMHO I think it introduces several problems and complications whose can be avoided just defining a boot logo into Linux... however it could be keep into some consideration.
Thanks for your suggestions,
Rodolfo
FWIIW, I took a screenshot, saved it as a 16 bit BMP, then converted the BMP as a GIF, JPEG, and a PNG. While very unscientific, this says BMP with gzip is a winner for two reasons: 1) It is similar in compression ratios to PNG and GIF 2) We already know how to gunzip and BMP.
Benchmark: 495410 screenshot-16.bmp
25411 screenshot-16.bmp.gz 25875 screenshot-16.PNG 37727 screenshot-16.GIF 148854 screenshot-16.JPG
(Trivia: I did JPEG because it was there. It is generally a poor choice for splash screens because it has artifacts on sharp transitions, which splash screens tend to have.)
gvb
On Wed, Jul 18, 2007 at 10:31:25AM -0400, Jerry Van Baren wrote:
FWIIW, I took a screenshot, saved it as a 16 bit BMP, then converted the BMP as a GIF, JPEG, and a PNG. While very unscientific, this says BMP with gzip is a winner for two reasons:
- It is similar in compression ratios to PNG and GIF
- We already know how to gunzip and BMP.
Benchmark: 495410 screenshot-16.bmp
25411 screenshot-16.bmp.gz 25875 screenshot-16.PNG 37727 screenshot-16.GIF 148854 screenshot-16.JPG
(Trivia: I did JPEG because it was there. It is generally a poor choice for splash screens because it has artifacts on sharp transitions, which splash screens tend to have.)
This seems good! :)
Rodolfo
Hi Rodolfo,
Rodolfo Giometti wrote:
Hello,
I'm planning to review the splash image support and in order to do that my next steps should be:
- Remove the logo support.
Currently we have two function for a boot screen: CONFIG_SPLASH_SCREEN and CONFIG_LCD_LOGO. I propose to remove logo support since logos must be statically compiled into u-boot and cannot be changed unless rebuild u-boot. On the other side splash images could be loaded at runtime.
- Rewrite the lcd_display_bitmap() in order to be more portable
across several BPP values.
I'd like to have some suggestions from you before starting to modify the code. :)
I already have a big rewrite of the LCD driver, as I already told you some time ago. Till now I did'nt find the time to post it, sorry. Will do so next week. It supports dynamic display configuration via FDT, which requires substantial modification.
Nevertheless, for true-color display (BPP >= 8) we should use "drivers/cfb_console.c". "common/lcd.c" just supports properly monochrome and 8-bit displays with color table. It would make more sense to spend time for a unified display driver in U-Boot. Unfortunately, that's not a trivial task.
Wolfgang.
On Wed, Jul 18, 2007 at 04:47:38PM +0200, Wolfgang Grandegger wrote:
I already have a big rewrite of the LCD driver, as I already told you some time ago. Till now I did'nt find the time to post it, sorry. Will do so next week. It supports dynamic display configuration via FDT, which requires substantial modification.
Great! Can we have a preview? :P
Which modifications are you talking about? In the per-CPU framebuffer code?
Nevertheless, for true-color display (BPP >= 8) we should use "drivers/cfb_console.c". "common/lcd.c" just supports properly monochrome and 8-bit displays with color table. It would make more sense to spend time for a unified display driver in U-Boot. Unfortunately, that's not a trivial task.
I see. Currently I need a splash screen for my custom boards so I have to find a quinck&trick solution! ;)
However I'll do modifications on your new code.
Thanks,
Rodolfo
Rodolfo Giometti wrote:
On Wed, Jul 18, 2007 at 04:47:38PM +0200, Wolfgang Grandegger wrote:
I already have a big rewrite of the LCD driver, as I already told you some time ago. Till now I did'nt find the time to post it, sorry. Will do so next week. It supports dynamic display configuration via FDT, which requires substantial modification.
Great! Can we have a preview? :P
Which modifications are you talking about? In the per-CPU framebuffer code?
In both!
Nevertheless, for true-color display (BPP >= 8) we should use "drivers/cfb_console.c". "common/lcd.c" just supports properly monochrome and 8-bit displays with color table. It would make more sense to spend time for a unified display driver in U-Boot. Unfortunately, that's not a trivial task.
I see. Currently I need a splash screen for my custom boards so I have to find a quinck&trick solution! ;)
What color format do you want to support?
However I'll do modifications on your new code.
OK.
Wolfgang.
On Wed, Jul 18, 2007 at 06:03:54PM +0200, Wolfgang Grandegger wrote:
What color format do you want to support?
16 bpp
Ciao,
Rodolfo
Rodolfo Giometti wrote:
On Wed, Jul 18, 2007 at 06:03:54PM +0200, Wolfgang Grandegger wrote:
What color format do you want to support?
16 bpp
Then use "drivers/cfb_console.c" as it already supports that format. Adapting the interface to pxafb should not be a big deal.
Wolfgang.
On Wed, Jul 18, 2007 at 06:17:12PM +0200, Wolfgang Grandegger wrote:
Rodolfo Giometti wrote:
On Wed, Jul 18, 2007 at 06:03:54PM +0200, Wolfgang Grandegger wrote:
What color format do you want to support?
16 bpp
Then use "drivers/cfb_console.c" as it already supports that format. Adapting the interface to pxafb should not be a big deal.
In order to adapt pxafb support to "drivers/cfb_console.c" I think I should move cpu/pxa/pxafb.c to drivers/pxafb.c adapting the internal functions to use video_hw_init() and video_set_lut(). Is that right?
Thanks,
Rodolfo
Rodolfo Giometti wrote:
On Wed, Jul 18, 2007 at 06:17:12PM +0200, Wolfgang Grandegger wrote:
Rodolfo Giometti wrote:
On Wed, Jul 18, 2007 at 06:03:54PM +0200, Wolfgang Grandegger wrote:
What color format do you want to support?
16 bpp
Then use "drivers/cfb_console.c" as it already supports that format. Adapting the interface to pxafb should not be a big deal.
In order to adapt pxafb support to "drivers/cfb_console.c" I think I should move cpu/pxa/pxafb.c to drivers/pxafb.c adapting the internal functions to use video_hw_init() and video_set_lut(). Is that right?
I think so and drivers is also the correct place for pxafb.c.
Wolfgang.
On Thu, Jul 19, 2007 at 11:47:59AM +0200, Wolfgang Grandegger wrote:
Rodolfo Giometti wrote:
On Wed, Jul 18, 2007 at 06:17:12PM +0200, Wolfgang Grandegger wrote:
Rodolfo Giometti wrote:
On Wed, Jul 18, 2007 at 06:03:54PM +0200, Wolfgang Grandegger wrote:
What color format do you want to support?
16 bpp
Then use "drivers/cfb_console.c" as it already supports that format. Adapting the interface to pxafb should not be a big deal.
In order to adapt pxafb support to "drivers/cfb_console.c" I think I should move cpu/pxa/pxafb.c to drivers/pxafb.c adapting the internal functions to use video_hw_init() and video_set_lut(). Is that right?
I think so and drivers is also the correct place for pxafb.c.
Ok, I'll propose a patch ASAP. However, simply moving the file from cpu/pxa/ to drivers/ shouldn't break any code but modifying it in order to support cfb_console.c will do.
What do you suggest in order to do the right steps? Maybe should I remove lcd.c support before doing my modifications?
Thanks,
Rodolfo
On Thu, Jul 19, 2007 at 11:52:40AM +0200, Rodolfo Giometti wrote:
On Thu, Jul 19, 2007 at 11:47:59AM +0200, Wolfgang Grandegger wrote:
Rodolfo Giometti wrote:
On Wed, Jul 18, 2007 at 06:17:12PM +0200, Wolfgang Grandegger wrote:
Rodolfo Giometti wrote:
On Wed, Jul 18, 2007 at 06:03:54PM +0200, Wolfgang Grandegger wrote:
What color format do you want to support?
16 bpp
Then use "drivers/cfb_console.c" as it already supports that format. Adapting the interface to pxafb should not be a big deal.
In order to adapt pxafb support to "drivers/cfb_console.c" I think I should move cpu/pxa/pxafb.c to drivers/pxafb.c adapting the internal functions to use video_hw_init() and video_set_lut(). Is that right?
I think so and drivers is also the correct place for pxafb.c.
Ok, I'll propose a patch ASAP. However, simply moving the file from cpu/pxa/ to drivers/ shouldn't break any code but modifying it in order to support cfb_console.c will do.
What do you suggest in order to do the right steps? Maybe should I remove lcd.c support before doing my modifications?
Just to gain some time and doing some tests I did the modifications in order to support splash screen into cfb_console for PXAFB.
I noticed that I have to disable some code regarding LCD otherwise there are doubled code execution and several incongruences, see here:
static int bmp_display(ulong addr, int x, int y) { #if defined(CONFIG_LCD) extern int lcd_display_bitmap (ulong, int, int);
return (lcd_display_bitmap (addr, x, y)); #elif defined(CONFIG_VIDEO) extern int video_display_bitmap (ulong, int, int); return (video_display_bitmap (addr, x, y)); #else # error bmp_display() requires CONFIG_LCD or CONFIG_VIDEO #endif }
This code seems OK but if you doesn't define CONFIG_LCD you cannot get framebuffer memory here (lib_arm/board.c):
#ifdef CONFIG_LCD # ifndef PAGE_SIZE # define PAGE_SIZE 4096 # endif /* * reserve memory for LCD display (always full pages) */ /* bss_end is defined in the board-specific linker script */ addr = (_bss_end + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1); size = lcd_setmem (addr); gd->fb_base = addr; #endif /* CONFIG_LCD */
Ok, I can add a defined() but this is not the right solution IMHO.
I wish to remove LCD support at all... are you agree? Any suggestions in order to which steps I should do for better result?
Thanks in advance,
Rodolfo
Rodolfo Giometti wrote:
On Thu, Jul 19, 2007 at 11:52:40AM +0200, Rodolfo Giometti wrote:
On Thu, Jul 19, 2007 at 11:47:59AM +0200, Wolfgang Grandegger wrote:
Rodolfo Giometti wrote:
On Wed, Jul 18, 2007 at 06:17:12PM +0200, Wolfgang Grandegger wrote:
Rodolfo Giometti wrote:
On Wed, Jul 18, 2007 at 06:03:54PM +0200, Wolfgang Grandegger wrote: > What color format do you want to support? 16 bpp
Then use "drivers/cfb_console.c" as it already supports that format. Adapting the interface to pxafb should not be a big deal.
In order to adapt pxafb support to "drivers/cfb_console.c" I think I should move cpu/pxa/pxafb.c to drivers/pxafb.c adapting the internal functions to use video_hw_init() and video_set_lut(). Is that right?
I think so and drivers is also the correct place for pxafb.c.
Ok, I'll propose a patch ASAP. However, simply moving the file from cpu/pxa/ to drivers/ shouldn't break any code but modifying it in order to support cfb_console.c will do.
What do you suggest in order to do the right steps? Maybe should I remove lcd.c support before doing my modifications?
Just to gain some time and doing some tests I did the modifications in order to support splash screen into cfb_console for PXAFB.
I noticed that I have to disable some code regarding LCD otherwise there are doubled code execution and several incongruences, see here:
static int bmp_display(ulong addr, int x, int y) { #if defined(CONFIG_LCD) extern int lcd_display_bitmap (ulong, int, int);
return (lcd_display_bitmap (addr, x, y));#elif defined(CONFIG_VIDEO) extern int video_display_bitmap (ulong, int, int); return (video_display_bitmap (addr, x, y)); #else # error bmp_display() requires CONFIG_LCD or CONFIG_VIDEO #endif }
This code seems OK but if you doesn't define CONFIG_LCD you cannot get framebuffer memory here (lib_arm/board.c):
#ifdef CONFIG_LCD # ifndef PAGE_SIZE # define PAGE_SIZE 4096 # endif /* * reserve memory for LCD display (always full pages) */ /* bss_end is defined in the board-specific linker script */ addr = (_bss_end + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1); size = lcd_setmem (addr); gd->fb_base = addr; #endif /* CONFIG_LCD */
Ok, I can add a defined() but this is not the right solution IMHO.
OK, why not.
I wish to remove LCD support at all... are you agree? Any suggestions in order to which steps I should do for better result?
Well, removing LCD support means that you provide a working alternative. My proposal is to re-write a unified display driver for u-boot-v2 and do _not_ waste too much time with the old drivers.
Wolfgang.
Thanks in advance,
Rodolfo
On Thu, Jul 19, 2007 at 04:41:49PM +0200, Wolfgang Grandegger wrote:
Ok, I can add a defined() but this is not the right solution IMHO.
OK, why not.
I wish to remove LCD support at all... are you agree? Any suggestions in order to which steps I should do for better result?
Well, removing LCD support means that you provide a working alternative. My proposal is to re-write a unified display driver for u-boot-v2 and do _not_ waste too much time with the old drivers.
I agree.
So I wait for your modifications and then try to port my code. :)
Thanks for your suggestions,
Rodolfo
Hi Wolfgang,
it would be fine if you consider my 'add splashimage positioning support' patch I sent to the list about two weeks ago. This allows positioning the splashimage somewhere or even aligned through the splashimage variable.
On Wednesday 18 July 2007 16:47, Wolfgang Grandegger wrote:
I already have a big rewrite of the LCD driver, as I already told you some time ago. Till now I did'nt find the time to post it, sorry. Will do so next week. It supports dynamic display configuration via FDT, which requires substantial modification.
Matthias
Hi Matthias,
Matthias Fuchs wrote:
Hi Wolfgang,
it would be fine if you consider my 'add splashimage positioning support' patch I sent to the list about two weeks ago. This allows positioning the splashimage somewhere or even aligned through the splashimage variable.
OK. But this patch is for cfb_console.c, which I actually do not use or even touch. I'm dealing with "common/lcd.c", which is different in various respects :-(. Hope you now realized the mess. Nevertheless, from my point of view, the patch is fine and can go up-stream, but I'm not the custodian. Rodolfo, have you looked at it?
Wolfgang.
On Wednesday 18 July 2007 16:47, Wolfgang Grandegger wrote:
I already have a big rewrite of the LCD driver, as I already told you some time ago. Till now I did'nt find the time to post it, sorry. Will do so next week. It supports dynamic display configuration via FDT, which requires substantial modification.
Matthias
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
On Thu, Jul 19, 2007 at 10:19:52AM +0200, Wolfgang Grandegger wrote:
Hi Matthias,
Matthias Fuchs wrote:
Hi Wolfgang, it would be fine if you consider my 'add splashimage positioning support' patch I sent to the list about two weeks ago. This allows positioning the splashimage somewhere or even aligned through the splashimage variable.
OK. But this patch is for cfb_console.c, which I actually do not use or even touch. I'm dealing with "common/lcd.c", which is different in various respects :-(. Hope you now realized the mess. Nevertheless, from my point of view, the patch is fine and can go up-stream, but I'm not the custodian. Rodolfo, have you looked at it?
Yes, but I hold it for the following reasons:
1) waiting for your modifications regarding the new video support.
2) "Logo" vs "Splash". I think we should remove the logo support definitely.
3) "common/lcd.c" vs "drivers/cfb_console.c". We should drop one? I vote for lcd.c.
4) Few time to dedicate. :)
However if you consider the patch ok, I'll add it to the u-boot-video repository. But the main task here is to clean the code regarding video support ASAP.
Ciao,
Rodolfo
participants (5)
-
Jerry Van Baren -
Joey Oravec -
Matthias Fuchs -
Rodolfo Giometti -
Wolfgang Grandegger