[U-Boot] [RFC]: always relocate u-boot before the framebuffer

[Jeroen Hofstee]

Hello Tom, Wolfgang,

On 01/02/2013 09:17 PM, Wolfgang Denk wrote:
> Dear Tom,
>
> In message <20130102154854.GC14738 at 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 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.
>   
Maybe it is clearer as "U-boot will then place the frame buffer at ... 
instead of reserving"

Regards,
Jeroen