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 wd@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 wd@denx.de cc: Anatolij Gustschin agust@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.