Dear Jeroen Hofstee,
please be more careful with the mail addresses in your postings:
repl: bad addresses: mpfj@mimc.co.uk; -- extraneous semi-colon l.majewski@samsung.com; -- extraneous semi-colon u-boot@denx.de -- no such address
In message 20121229203157.0f50ba5e@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 notoverlap */
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