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

login
register
mail settings
Submitter Jeroen Hofstee
Date Dec. 29, 2012, 7:31 p.m.
Message ID <20121229203157.0f50ba5e@black>
Download mbox | patch
Permalink /patch/208682/
State RFC
Headers show

Comments

Jeroen Hofstee - Dec. 29, 2012, 7:31 p.m.
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:

http://lists.denx.de/mailman/listinfo/u-boot
Wolfgang Denk - Dec. 29, 2012, 9:47 p.m.
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
Ɓukasz Majewski - Dec. 31, 2012, 2:33 p.m.
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.
Wolfgang Denk - Dec. 31, 2012, 2:54 p.m.
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
Tom Rini - Jan. 2, 2013, 3:48 p.m.
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?

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 */
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de