Dear Tom,

In message <20130102154854.GC14738@bill-the-cat> you wrote:
> 
> > Please see my responses.  This is definitely NOT a good idea, it will
> > break most (all?) boards that use CONFIG_FB_ADDR in the way it was
> > intended for.
> 
> I think this means we've got people not understanding what the variable
> IS for.  And at the high level, the idea of "lets transition from U-Boot
> to Linux without a flicker" is good.  So, what is the variables we
> should be using for this, today?  Or do we need to add and document
> more?  Or are we all just failing to RTFM here?

I think the key problem is insufficient documentation of what
CONFIG_FB_ADDR is intended for (i. e. graphics controllers with
external video RAM).  Eventualy a patch as attached might help?

The idea of "lets transition from U-Boot to Linux without a flicker"
is as old as PPCBoot (i. e. even predates U-Boot).  The standard
mechanism as implemented should work out of the box, assuming that
both U-Boot and Linux use the same configuration of the graphics
controller (resulting in the same size of the needed frame buffer
memory).  And if they use different configurations, you won't be able
to pass a pre-initialized frame buffer ayway.

The problem Jeroen ran into is/was caused by the fct that U-Boot and
Linux computed different sizes for the frame buffer.  I think this is
either a bug, or a difference in the configuration, but Jeroen did not
reply to my question for the reason for this difference yet.

Best regards,

Wolfgang Denk

Suggested doc patch:

>From ede2e170bd6c4b4ab6a3b7752400eb8afe0fdec9 Mon Sep 17 00:00:00 2001
From: Wolfgang Denk <w...@denx.de>
Date: Wed, 2 Jan 2013 21:10:29 +0100
Subject: [PATCH] VIDEO: better document the correct use of CONFIG_FB_ADDR

Signed-off-by: Wolfgang Denk <w...@denx.de>
cc: Anatolij Gustschin <ag...@denx.de>
---
 README | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/README b/README
index 78f40df..f84108e 100644
--- a/README
+++ b/README
@@ -2695,11 +2695,14 @@ FIT uImage format:
 - Frame Buffer Address:
                CONFIG_FB_ADDR
 
-               Define CONFIG_FB_ADDR if you want to use specific
-               address for frame buffer.
-               Then system will reserve the frame buffer address to
-               defined address instead of lcd_setmem (this function
-               grabs the memory for frame buffer by panel's size).
+                Define CONFIG_FB_ADDR if you want to use specific
+                address for frame buffer.  This is typically the case
+                when using a graphics controller has separate video
+                memory.  U-Boot will then reserve the frame buffer at
+                the given address instead of dynamically reserving it
+                in system RAM by calling lcd_setmem(), which grabs
+                the memory for the frame buffer depending on the
+                configured panel size.
 
                Please see board_init_f function.
 
-- 
1.7.11.7


-- 
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: w...@denx.de
The shortest unit of time in the multiverse is the News York  Second,
defined  as  the  period  of  time between the traffic lights turning
green and the cab behind you honking.
                                - Terry Pratchett, _Lords and Ladies_
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to