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

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

[Jeroen Hofstee]

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 */

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

[Jeroen Hofstee]

> 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?

My apologies, I pasted half the patch, the intention is to always
set addr = gd->fb_base. 

This should be the complete one:

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 */
+       addr = gd->fb_base;
 #endif /* CONFIG_LCD */

[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@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..."

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

[Wolfgang Denk]

Dear Jeroen Hofstee,

In message <20121229211050.3249f8b7@black> you wrote:
> 
> My apologies, I pasted half the patch, the intention is to always
> set addr = gd->fb_base. 

No, this is not correct.  If CONFIG_FB_ADDR is set, then it will
usually points to the start address of an on on-chip video memory
region.  There will be no RAM below this aread to relocate U-Boot to, 
i. e. you patch will break a number of systems.

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
Overflow on /dev/null, please empty the bit bucket.

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

[Lukasz Majewski]

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. 

-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group

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

[Wolfgang Denk]

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

-- 
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
You go slow, be gentle. It's no one-way street -- you  know  how  you
feel and that's all. It's how the girl feels too. Don't press. If the
girl feels anything for you at all, you'll know.
	-- Kirk, "Charlie X", stardate 1535.8

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

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130102/92fcb57f/attachment.pgp>

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

[Wolfgang Denk]

Dear Tom,

In message <20130102154854.GC14738@bill-the-cat> you wrote:
> 
> > 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?

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.

Best regards,

Wolfgang Denk

Suggested doc patch:

[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@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 at 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

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

[Wolfgang Denk]

Dear Jeroen,

In message <50E55D24.8000809@myspectrum.nl> you wrote:
> 
> 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 at vger.kernel.org/msg80440.html

Hm...

In any case the code should behave the same in U-Boot and Linux.  If
we can lift this restriction in Linux, then OK.  If not, then the FB
allocation in U-Boot (by lcd_setmem()) should result in the same size
as allocated by Linux.  After all, the allocated size should be a
"resasonable" one ;-)

> > +                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"

OK, will repost.

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
2000 pounds of chinese soup                               = 1 Won Ton

[U-Boot] [PATCH v2] VIDEO: better document the correct use of CONFIG_FB_ADDR

[Wolfgang Denk]

Signed-off-by: Wolfgang Denk <wd@denx.de>
cc: Anatolij Gustschin <agust@denx.de>
---
V2: changed text as suggested by Jeroen Hofstee
    in <50E55D24.8000809@myspectrum.nl>

 README | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

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 place 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.
 
-- 
1.7.11.7

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

[Jeroen Hofstee]

Hi,

On 01/03/2013 11:41 AM, Wolfgang Denk wrote:
> In message <50E55D24.8000809@myspectrum.nl> you wrote:
>> 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 at vger.kernel.org/msg80440.html
> Hm...
>
> In any case the code should behave the same in U-Boot and Linux.  If
> we can lift this restriction in Linux, then OK.  If not, then the FB
> allocation in U-Boot (by lcd_setmem()) should result in the same size
> as allocated by Linux.  After all, the allocated size should be a
> "resasonable" one ;-)

For completeness, removing size = ALIGN(size, SZ_2M); from vram.c
in the linux dss driver and passing the correct vram= works fine.
The frame buffer is then at the same physical address and I regain
15MB of memory. So solved as far as I am concerned till proven that
it really hurts performance.

Motivation for the 2mb alignment is at:
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/035013.html

Regards,
Jeroen

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

[Wolfgang Denk]

Dear Jeroen Hofstee,

In message <50E5C9A2.7090904@myspectrum.nl> you wrote:
> 
> > In any case the code should behave the same in U-Boot and Linux.  If
> > we can lift this restriction in Linux, then OK.  If not, then the FB
> > allocation in U-Boot (by lcd_setmem()) should result in the same size
> > as allocated by Linux.  After all, the allocated size should be a
> > "resasonable" one ;-)
> 
> For completeness, removing size = ALIGN(size, SZ_2M); from vram.c
> in the linux dss driver and passing the correct vram= works fine.

Hm... I'm not sure if this is the right approach, then.  If mainline
Linux insists on such a 2 MB alignment, we shoud  rather teach
lcd_setmem() to follow tha rule, too.  That should solve the problem
as well (and probably more efficiently, especially if other features
like pRAM or shared log buffer reserve high memory as well).


Anatolij, what do you think should be done here?


> The frame buffer is then at the same physical address and I regain
> 15MB of memory. So solved as far as I am concerned till proven that
> it really hurts performance.

I can't grok this, though.  I could understand if you say you saved
up to 2 MB by lifting the 2 MB alignment requirement - but 15 MB?
Please elucidate where this number is coming from.

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
A Perl script is correct if it's halfway readable and  gets  the  job
done before your boss fires you.
                       - L. Wall & R. L. Schwartz, _Programming Perl_

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

[Jeroen Hofstee]

Hi Wolfgang,

On 01/03/2013 09:28 PM, Wolfgang Denk wrote:
>> The frame buffer is then at the same physical address and I regain
>> 15MB of memory. So solved as far as I am concerned till proven that
>> it really hurts performance.
> I can't grok this, though.  I could understand if you say you saved
> up to 2 MB by lifting the 2 MB alignment requirement - but 15 MB?
> Please elucidate where this number is coming from.
>

I had the frame buffer at 16mb before the end of the ram to allow
u-boot, heap etc to relocated itself into the end of the frame buffer
/ ram. Without the CONFIG_FB_ADDR, the frame buffer it is located
at 1mb before the end and u-boot relocates itself before it. So now
linux has 15mb more since the framebuffer is at the 1mb before the
end of ram and not 16mb as it used to be.

Regards,
Jeroen

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

[Jeroen Hofstee]

Hi,

On 01/03/2013 09:28 PM, Wolfgang Denk wrote:
> Hm... I'm not sure if this is the right approach, then.  If mainline
> Linux insists on such a 2 MB alignment, we shoud  rather teach
> lcd_setmem() to follow tha rule, too.  That should solve the problem
> as well (and probably more efficiently, especially if other features
> like pRAM or shared log buffer reserve high memory as well).
>
I just noticed this is already possible since the recently introduced
dcache for lcd.c also adds a CONFIG_LCD_ALIGNMENT. Since I am at
rc2 I had not seen it yet.

Regards,
Jeroen

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

[Wolfgang Denk]

Dear Jeroen,

In message <50E7FB65.9000709@myspectrum.nl> you wrote:
> 
> > Hm... I'm not sure if this is the right approach, then.  If mainline
> > Linux insists on such a 2 MB alignment, we shoud  rather teach
> > lcd_setmem() to follow tha rule, too.  That should solve the problem
> > as well (and probably more efficiently, especially if other features
> > like pRAM or shared log buffer reserve high memory as well).
> >
> I just noticed this is already possible since the recently introduced
> dcache for lcd.c also adds a CONFIG_LCD_ALIGNMENT. Since I am at
> rc2 I had not seen it yet.

Ah, so we have a working solution already in place?  Excellent.

Do you think you have a chance to test if this works for you, too?

Thanks in advance.

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
Carelessly planned projects take three times longer to complete  than
expected.  Carefully  planned  projects  take  four  times  longer to
complete than expected, mostly  because  the  planners  expect  their
planning to reduce the time it takes.

[U-Boot] [PATCH v2] VIDEO: better document the correct use of CONFIG_FB_ADDR

[Anatolij Gustschin]

Hi Wolfgang,

On Thu,  3 Jan 2013 11:43:59 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Signed-off-by: Wolfgang Denk <wd@denx.de>
> cc: Anatolij Gustschin <agust@denx.de>
> ---
> V2: changed text as suggested by Jeroen Hofstee
>     in <50E55D24.8000809@myspectrum.nl>
> 
>  README | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)

applied to u-boot-video/master. Thanks!

Anatolij