| Message ID | 20121229203157.0f50ba5e@black |
|---|---|
| State | RFC |
| Headers | show |
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 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
Hi Jeroen, > Hi All, > > 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. > > 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. > > 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? > > Regards, > Jeroen > > proposed patch: > > diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c > index e0cb635..4d0fc3c 100644 > --- a/arch/arm/lib/board.c > +++ b/arch/arm/lib/board.c > @@ -371,9 +371,10 @@ void board_init_f(ulong bootflag) > gd->fb_base = CONFIG_FB_ADDR; > #else > /* reserve memory for LCD display (always full pages) */ > - addr = lcd_setmem(addr); > - gd->fb_base = addr; > + gd->fb_base = lcd_setmem(addr); > #endif /* CONFIG_FB_ADDR */ > + /* always continue placement below the frame buffer to not > overlap */ Good idea. I will test it and let you know.
Dear Lukasz Majewski, In message <20121231153353.2d9a5dda@amdc308.digital.local> you wrote: > > > - addr = lcd_setmem(addr); > > - gd->fb_base = addr; > > + gd->fb_base = lcd_setmem(addr); > > #endif /* CONFIG_FB_ADDR */ > > + /* always continue placement below the frame buffer to not > > overlap */ > > Good idea. I will test it and let you know. 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. Best regards, Wolfgang Denk
On Mon, Dec 31, 2012 at 03:54:25PM +0100, Wolfgang Denk wrote: > Dear Lukasz Majewski, > > In message <20121231153353.2d9a5dda@amdc308.digital.local> you wrote: > > > > > - addr = lcd_setmem(addr); > > > - gd->fb_base = addr; > > > + gd->fb_base = lcd_setmem(addr); > > > #endif /* CONFIG_FB_ADDR */ > > > + /* always continue placement below the frame buffer to not > > > overlap */ > > > > Good idea. I will test it and let you know. > > 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?
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index e0cb635..4d0fc3c 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -371,9 +371,10 @@ void board_init_f(ulong bootflag) gd->fb_base = CONFIG_FB_ADDR; #else /* reserve memory for LCD display (always full pages) */ - addr = lcd_setmem(addr); - gd->fb_base = addr; + gd->fb_base = lcd_setmem(addr); #endif /* CONFIG_FB_ADDR */ + /* always continue placement below the frame buffer to not overlap */ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de