All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Zedeck <saz@proliphix.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Preserving frame buffer memory between uboot and Linux
Date: Mon, 5 Oct 2009 07:09:52 -0700 (PDT)	[thread overview]
Message-ID: <25751508.post@talk.nabble.com> (raw)
In-Reply-To: <20091002220952.01285832E408@gemini.denx.de>




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.

  reply	other threads:[~2009-10-05 14:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-02 20:48 [U-Boot] Preserving frame buffer memory between uboot and Linux Steven Zedeck
2009-10-02 22:09 ` Wolfgang Denk
2009-10-05 14:09   ` Steven Zedeck [this message]
2009-10-05 14:15     ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=25751508.post@talk.nabble.com \
    --to=saz@proliphix.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.