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

[Wolfgang Denk]

Dear Jeroen Hofstee,

please be more careful with the mail addresses in your postings:

repl: bad addresses:
	mpfj at mimc.co.uk; -- extraneous semi-colon
	l.majewski at samsung.com; -- extraneous semi-colon
	u-boot at denx.de -- no such address


In message <20121229203157.0f50ba5e at black> you wrote:
> 
> Currently CONFIG_FB_ADDR can be set to specify the location of the
> frame buffer. Since Linux places the frame buffer at the end of the
> RAM, it is nice to place it at the same position so the u-boot to
> linux transition can be made flicker free, by preserving the
> frame buffer. However u-boot and it's heap prefer to locate themselves
> at the end of the RAM as well and there is nothing which prevents them
> to overlap.

This is not as it is intended.  Please see the example "typical memory
configuration" in section "Memory Management" of the top level README
file.  Also, if you check "arch/arm/lib/board.c" (lines 336 ff), you
can see that we allocate to down, starting at the end of RAM, in the
following order:

- shared kernel log buffer
- protected RAM
- TLB table
- frame buffer
- U-Boot code, data & bss

Assuming we have no shared log buffer nor protected RAM, only the TLB
table is in the way (whch should actually be moded down, right above
the U-Boot bss segment.

> While this can be set/calculated manually, it would be nicer if the
> relocation would never take place to the region occupied by the
> frame buffer. A simple way to do so is to locate u-boot before the
> frame buffer, like it is already done when the frame buffer address is
> not set.

There should never be such an overlapping  If there is, then this is a
bug that should be fixed, to match the documented memory map mentioned
above.

> Currently there are 2 boards using the CONFIG_FB_ADDR and CONFIG_LCD
> on arm (trats, mimc200). Would it cause any problem to relocate
> u-boot below the frame buffer on these boards?

I think this is a misunderstanding here.  If you define
CONFIG_FB_ADDR, this means that the FB memory is not part of the
system RAM and/or shall not be allocated automatically for specific
reasons.  Normally you would use this with systems where the graphics
controller provides his own video meory, i. e. where the actual GB
storage is not part of the system RAM.

If there are boards that define CONFIG_FB_ADDR to an address ranges
that is part of the system RAM, these are either broken, or they try
to implement very special, board-specific features.  In this case the
board maintainers should be contacted to comment.

>         /* reserve memory for LCD display (always full pages) */
> -       addr = lcd_setmem(addr);
> -       gd->fb_base = addr;
> +       gd->fb_base = lcd_setmem(addr);

Doing this, you are not upating "addr", which means it will still
point to the end of RAM, i. e. now you intentionally place the frame
buffer in the same memory region as the U-Boot code, data & bss;
this cannot be correct.

>  #endif /* CONFIG_FB_ADDR */
> +       /* always continue placement below the frame buffer to not
> overlap */

White space corrupted patch.  And comment does not match code.

If my guess that you misinterpret the meaning of CONFIG_FB_ADDR, then
I fail to understand what you see wrong in the existing code.

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
"How is this place run - is it an anarchy?"
"No, I wouldn't say so; it is not that well organised..."