[U-Boot] Preserving frame buffer memory between uboot and Linux

[U-Boot] Preserving frame buffer memory between uboot and Linux

[Steven Zedeck]

Hi,
We have a situation when we want to display an image towards the end of
Uboot's execution, before we boot Linux. I have that already.

However, my issue is that while Linux boots it mallocs a new frame buffer
and reinitializes the LCD controller with a new memory address. At the
moment in Uboot the frame buffer is at 0x23F39000. In Linux I see it being
mapped to 0x23980000.

Is there a way to force Linux to use the already-allocated frame buffer
memory so the image doesn't go away?

I am running on an Atmel AT91SAM9RL with Uboot 2008.10 and 2.6.28 Linux.

Thanks in advance,
Steve
-- 
View this message in context: http://www.nabble.com/Preserving-frame-buffer-memory-between-uboot-and-Linux-tp25722060p25722060.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

[U-Boot] Preserving frame buffer memory between uboot and Linux

[Wolfgang Denk]

Dear Steven Zedeck,

In message <25722060.post@talk.nabble.com> you wrote:
> 
> We have a situation when we want to display an image towards the end of
> Uboot's execution, before we boot Linux. I have that already.
> 
> However, my issue is that while Linux boots it mallocs a new frame buffer
> and reinitializes the LCD controller with a new memory address. At the
> moment in Uboot the frame buffer is at 0x23F39000. In Linux I see it being
> mapped to 0x23980000.
> 
> Is there a way to force Linux to use the already-allocated frame buffer
> memory so the image doesn't go away?

In mainline: not, or not yet at least. 

In our linux-2.6-denx repo you can find these commits:

commit 01baab26e52bc66cb1781ab970fba932b592f2ee
Author: Anatolij Gustschin <agust@denx.de>
Date:   Wed May 28 23:45:21 2008 +0200

    Fix to enable console cursor drawing capability if CONFIG_FB_PRE_INIT_FB defined
    
    Background:
      By defining the CONFIG_FB_PRE_INIT_FB option in the
      Linux kernel configuration the framebuffer state
      set by the boot loader before booting the Linux kernel
      will be preserved in order to avoid display flicker and
      splash screen destruction. To ensure this, this option
      also disabled framebuffer console cursor drawing capability
      entirely. This was pretty invasive restriction and didn't
      allow using console cursor drawing later in applications
      which need the visible cursor.
    
      Now this patch is introduced to get rid of this restriction.
      If CONFIG_FB_PRE_INIT_FB is defined in the Linux kernel
      configuration, the framebuffer state will still be preserved
      (as set by the boot loader) and also framebuffer console
      cursor drawing will be disabled. If an application needs
      visible cursor, it should enable cursor drawing by writing
      escape sequence ESC[?25h to the console device.
      E.g. echo -e "\33[?25h" > /dev/tty0
    
    Signed-off-by: Anatolij Gustschin <agust@denx.de>
...
commit 6c3b5cdbc84b43190996124debc8fb29c9bf90ed
Author: Anatolij Gustschin <agust@denx.de>
Date:   Tue Jan 15 00:28:23 2008 +0100

    Add CONFIG_FB_PRE_INIT_FB option
    
    CONFIG_FB_PRE_INIT_FB option allows to inherit
    display controller configuration and framebuffer
    contents from the state set by the bootloader.
    
    Signed-off-by: Anatolij Gustschin <agust@denx.de>

They do exactly what you are looking for. I remember that someone
tried to clean this up and poush it into mainline, but IIRC this
attempt failed because the PTB considered this an exotic requirement
from those insane embedded folks which was not needed on any real
systems.

> I am running on an Atmel AT91SAM9RL with Uboot 2008.10 and 2.6.28 Linux.

Hope this helps.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Four thousand throats may be cut in one night by a running man.
	-- Klingon Soldier, "Day of the Dove", stardate unknown

[U-Boot] Preserving frame buffer memory between uboot and Linux

[Steven Zedeck]

wd wrote:
> 
> Dear Steven Zedeck,
> 
> In message <25722060.post@talk.nabble.com> you wrote:
>> 
>> We have a situation when we want to display an image towards the end of
>> Uboot's execution, before we boot Linux. I have that already.
>> 
>> However, my issue is that while Linux boots it mallocs a new frame buffer
>> and reinitializes the LCD controller with a new memory address. At the
>> moment in Uboot the frame buffer is at 0x23F39000. In Linux I see it
>> being
>> mapped to 0x23980000.
>> 
>> Is there a way to force Linux to use the already-allocated frame buffer
>> memory so the image doesn't go away?
> 
> In mainline: not, or not yet at least. 
> 
> In our linux-2.6-denx repo you can find these commits:
> 
> commit 01baab26e52bc66cb1781ab970fba932b592f2ee
> Author: Anatolij Gustschin <agust@denx.de>
> Date:   Wed May 28 23:45:21 2008 +0200
> 
>     Fix to enable console cursor drawing capability if
> CONFIG_FB_PRE_INIT_FB defined
>     
>     Background:
>       By defining the CONFIG_FB_PRE_INIT_FB option in the
>       Linux kernel configuration the framebuffer state
>       set by the boot loader before booting the Linux kernel
>       will be preserved in order to avoid display flicker and
>       splash screen destruction. To ensure this, this option
>       also disabled framebuffer console cursor drawing capability
>       entirely. This was pretty invasive restriction and didn't
>       allow using console cursor drawing later in applications
>       which need the visible cursor.
>     
>       Now this patch is introduced to get rid of this restriction.
>       If CONFIG_FB_PRE_INIT_FB is defined in the Linux kernel
>       configuration, the framebuffer state will still be preserved
>       (as set by the boot loader) and also framebuffer console
>       cursor drawing will be disabled. If an application needs
>       visible cursor, it should enable cursor drawing by writing
>       escape sequence ESC[?25h to the console device.
>       E.g. echo -e "\33[?25h" > /dev/tty0
>     
>     Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ...
> commit 6c3b5cdbc84b43190996124debc8fb29c9bf90ed
> Author: Anatolij Gustschin <agust@denx.de>
> Date:   Tue Jan 15 00:28:23 2008 +0100
> 
>     Add CONFIG_FB_PRE_INIT_FB option
>     
>     CONFIG_FB_PRE_INIT_FB option allows to inherit
>     display controller configuration and framebuffer
>     contents from the state set by the bootloader.
>     
>     Signed-off-by: Anatolij Gustschin <agust@denx.de>
> 
> They do exactly what you are looking for. I remember that someone
> tried to clean this up and poush it into mainline, but IIRC this
> attempt failed because the PTB considered this an exotic requirement
> from those insane embedded folks which was not needed on any real
> systems.
> 
>> I am running on an Atmel AT91SAM9RL with Uboot 2008.10 and 2.6.28 Linux.
> 
> Hope this helps.
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Four thousand throats may be cut in one night by a running man.
> 	-- Klingon Soldier, "Day of the Dove", stardate unknown
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 

Wolfgang,
Thanks for the reply. I did a search on our entire Linux code base for
CONFIG_FB_PRE_INIT_FB and it only appears in one file
drivers/video/mb862xx/mb862xxfb.c

I don't understand how to set this variable in my specific configuration
file.

I did, however, see this in atmel_lcdfb.c:
map = platform_get_resource(pdev, IORESOURCE_MEM,1);
if (map)
{
   /* use a pre-allocated memory buffer (/
.
.
.
   /* Don't clear the frame buffer -- someone may have set up a splash
image. */

.
.

}

Isn't this what I need to be concerned about? If so, what do I need to do un
Uboot to make this take effect?

Thanks,
Steve

-- 
View this message in context: http://www.nabble.com/Preserving-frame-buffer-memory-between-uboot-and-Linux-tp25722060p25751508.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

[U-Boot] Preserving frame buffer memory between uboot and Linux

[Wolfgang Denk]

Dear Steven Zedeck,

In message <25751508.post@talk.nabble.com> you wrote:
> 

[Full quote deleted]

It was probably not necessary to quote my full message, including
signature and everything. Please see
http://www.netmeister.org/news/learn2quote.html

> I don't understand how to set this variable in my specific configuration
> file.

Check where U-Boot allocates the FB (should be top of RAM, but the ARM
implementation of U-Boot does so many things wrong), and figure a way
to pass this to the kernel.

> I did, however, see this in atmel_lcdfb.c:
> map = platform_get_resource(pdev, IORESOURCE_MEM,1);
> if (map)
> {
>    /* use a pre-allocated memory buffer (/

I have no idea how this is implemented for AT91, for example,m how
the boot loader communicates the FB address to Linux.

> Isn't this what I need to be concerned about? If so, what do I need to do un
> Uboot to make this take effect?

Well, check who wrote that driver resp. who is to (git-) blame for
that code, and ask him how this is supposed to work.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Memories of you remind me of you.                   - Karl Lehenbauer