[U-Boot-Users] [RFC] Splash image

[U-Boot-Users] [RFC] Splash image

[Rodolfo Giometti]

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

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] [RFC] Splash image

[Joey Oravec]

"Rodolfo Giometti" <giometti@enneenne.com> wrote in message 
news:20070718083012.GE4836 at enneenne.com...
> 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.

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.

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

[U-Boot-Users] [RFC] Splash image

[Rodolfo Giometti]

On Wed, Jul 18, 2007 at 09:40:28AM -0400, Joey Oravec wrote:
> "Rodolfo Giometti" <giometti@enneenne.com> wrote in message 
> news:20070718083012.GE4836 at enneenne.com...
> > 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.
> 
> 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.

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

I think we should support just one format for two reasons:

1) Supporting just one format keep the code smallest.

2) We have "convert". :)

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

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

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] [RFC] Splash image

[Jerry Van Baren]

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 at enneenne.com...
>>> 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.
>> 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.
> 
>>> 2) 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?
> 
> I think we should support just one format for two reasons:
> 
> 1) Supporting just one format keep the code smallest.
> 
> 2) We have "convert". :)
> 
>> 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.
> 
> 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

[U-Boot-Users] [RFC] Splash image

[Rodolfo Giometti]

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

This seems good! :)

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] [RFC] Splash image

[Wolfgang Grandegger]

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

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.

[U-Boot-Users] [RFC] Splash image

[Rodolfo Giometti]

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

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] [RFC] Splash image

[Wolfgang Grandegger]

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.

[U-Boot-Users] [RFC] Splash image

[Rodolfo Giometti]

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

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] [RFC] Splash image

[Wolfgang Grandegger]

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.

[U-Boot-Users] [RFC] Splash image

[Rodolfo Giometti]

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

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] [RFC] Splash image

[Wolfgang Grandegger]

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.

[U-Boot-Users] [RFC] Splash image

[Rodolfo Giometti]

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

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] [RFC] Splash image

[Rodolfo Giometti]

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

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] [RFC] Splash image

[Wolfgang Grandegger]

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
> 

[U-Boot-Users] [RFC] Splash image

[Rodolfo Giometti]

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

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] [RFC] Splash image

[Matthias Fuchs]

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

[U-Boot-Users] [RFC] Splash image

[Wolfgang Grandegger]

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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 
> 

[U-Boot-Users] [RFC] Splash image

[Rodolfo Giometti]

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

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] [RFC] Splash image

[Wolfgang Grandegger]

Joey Oravec wrote:
> "Wolfgang Grandegger" <wg@grandegger.com> wrote in message
> news:<469F334F.6040003@grandegger.com>...
>>> 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.
> 
> That doesn't seem like a great move. The drivers folder is just a collection
> of garbage which is board specific anyway right now.

Well, yes, that's a to-do for u-boot-v2. In another mail to the list I 
already suggested _not_ to waste too much time with the old video 
drivers but concentrate the effort on a unified driver for u-boot-v2.

> Where may I download your patches? I have not seen your changes yet, and I
> would like to see if this is completely PXA specific or if any of that is
> reusable for AT91, MPC, or other hardware.

I'm going to post it next week. The dynamic display configuration is 
implemented for the MPC823, other stuff is useful for PXA as well, like 
splash image rotation.

> It makes sense to have a framebuffer.c in drivers which is common to every
> chip, every framebuffer, and everything that you could ever want to program.
> It also makes sense to have some support code in common that opens BMP
> files, draws something upon the frame buffer, etc. Finally it makes sense to
> have CPU specific code that initializes the registers, DMA, and everything
> for the specific chip.

Yes, we have something like that already, e.g. driver/cfb_console.c. 
Unfortunately, it does not support monochrome displays. Furthermore 
there is "common/lcd.c" mainly for the FB of the MPC823 and PXA 
supporting monochrome and 8-bit with color-map display.

> I will take a look at the code but I'm a little worried based on what I've
> read so far. This sounds like the changes may be very specific to one CPU or
> one board and not a general driver framework.

The patch will add more features to "common/lcd.c" but it will 
definitely not improve the general driver framework.

Wolfgang.