Hello Tom, Wolfgang,
On 01/02/2013 09:17 PM, Wolfgang Denk wrote:
Dear Tom,
In message 20130102154854.GC14738@bill-the-cat you wrote:
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 did read the document. Especially "Then system will reserve the frame buffer address to defined address instead of lcd_setmem" is a bit misleading, given that nothing is "reserved" it is just assumed to be free.
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.
I encountered this issue on a omap board / dss. Currently the amount of video ram is passed with a vram= argument to linux and allocated at the end of the ram. This is 16Mb by default I have CONFIG_FB_ADDR set to end of RAM minus that. U-boot then relocates _into_ my frame buffer and all goes well since I have a small lcd and only use the first 500k or so.
So the intention was to fix that while preserving the frame buffer and I don't want linux to steal so much memory. The minimum amount of memory the dss accepts is 2MB though (for reason unknown to me). Without the fb address set U-boot will allocate it at 1MB before the end of the ram, since it does not have the 2MB minimum. With the fb address set to -2MB u-boot will allocate itself over it, hence the patch, do actually reserve the frame buffer (well in the most simplistic way, by placing everything before it).
As Wolfgang suggested, maybe I shouldn't point at U-boot but blame linux and get rid of the 2MB alignment. I haven't checked yet, but I don't see why that should not work. So this is resolved for my case (thanks for the suggestion) for now until I meet
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg80440.html
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 specificaddress for frame buffer.Then system will reserve the frame buffer address todefined address instead of lcd_setmem (this functiongrabs the memory for frame buffer by panel's size).
Define CONFIG_FB_ADDR if you want to use specificaddress for frame buffer. This is typically the casewhen using a graphics controller has separate videomemory. U-Boot will then reserve the frame buffer atthe given address instead of dynamically reserving itin system RAM by calling lcd_setmem(), which grabsthe memory for the frame buffer depending on theconfigured panel size.Please see board_init_f function.
Maybe it is clearer as "U-boot will then place the frame buffer at ... instead of reserving"
Regards, Jeroen