: always relocate u-boot before the framebuffer

RFC In review Jeroen Hofstee 6 participants 17 messages Dec 29, 2012 – Jan 14, 2013 Arm (32-bit)

lore

Share & tools

lore

Jeroen Hofstee

author

2012-12-29 19:31 UTC #0 lore raw

RFC 1/1 : always relocate u-boot before the framebuffer

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:

arch/arm/lib/board.c +2 -2

index e0cb635..4d0fc3c 100644
@@ -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 */

Jeroen Hofstee

author

2012-12-29 20:10 UTC #1 lore raw

RFC 1/1 : always relocate u-boot before the framebuffer

Quoted 15 lines

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.

Quoted 3 lines

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:

arch/arm/lib/board.c +2 -2

index e0cb635..4d0fc3c 100644
@@ -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 */

Wolfgang Denk

2012-12-29 21:50 UTC #2 lore raw

Dear Jeroen Hofstee,

Quoted 3 lines · 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

Signature · 4 lines

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.

Wolfgang Denk

2012-12-29 21:47 UTC #3 lore raw

In reply to Jeroen Hofstee

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

Quoted 8 lines · 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.

Quoted 5 lines

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.

Quoted 3 lines

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.

arch/arm/lib/board.c void board_init_f(ulong bootflag) · line 374

Quoted 4 lines

        /* reserve memory for LCD display (always full pages) */

arch/arm/lib/board.c +1 -2

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

Quoted 3 lines

#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

Signature · 5 lines

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

Lukasz Majewski

2012-12-31 14:33 UTC #4 lore raw

In reply to Jeroen Hofstee

Hi Jeroen,

Quoted 38 lines

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:
arch/arm/lib/board.c +2 -2
index e0cb635..4d0fc3c 100644
@@ -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

Quoted 1 line

overlap */

Good idea. I will test it and let you know.

Signature · 5 lines

Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group

Wolfgang Denk

2012-12-31 14:54 UTC #5 lore raw

Dear Lukasz Majewski,

Quoted 9 lines · In message <[email protected]> you wrote:

Quoted 7 lines

arch/arm/lib/board.c +2 -2

-       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

Signature · 7 lines

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

Tom Rini

2013-01-02 15:48 UTC #6 lore raw

Quoted 11 lines · Wolfgang Denk

Dear Lukasz Majewski,
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 7 lines
arch/arm/lib/board.c +2 -2
-       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 */

Quoted 5 lines

Quoted 1 line
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?

Signature · 8 lines

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>

Wolfgang Denk

2013-01-02 20:17 UTC #7 lore raw

Dear Tom,

Quoted 10 lines · In message <20130102154854.GC14738@bill-the-cat> you wrote:

Quoted 4 lines
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:

Jeroen Hofstee

2013-01-03 10:27 UTC #8 lore raw

Hello Tom, Wolfgang,

Quoted 8 lines · Wolfgang Denk

Dear Tom,
Quoted 5 lines · 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.

Quoted 12 lines

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.

Quoted 5 lines

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

Quoted 14 lines

README +1 -5

index 78f40df..f84108e 100644
@@ -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

README FIT uImage format: · line 2708

Quoted 10 lines

README +7 -0

+                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

Wolfgang Denk

2013-01-03 10:41 UTC #9 lore raw

Dear Jeroen,

Quoted 11 lines · In message <[email protected]> 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).

Quoted 6 lines

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 ;-)

Quoted 9 lines

(quoted diff) +8 -0

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

Quoted 4 lines

Quoted 2 lines
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

Signature · 4 lines

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

Jeroen Hofstee

2013-01-03 18:10 UTC #10 lore raw

Hi,

Quoted 6 lines · Wolfgang Denk

Quoted 5 lines · In message <[email protected]> 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

Quoted 8 lines

Quoted 1 line
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

Wolfgang Denk

2013-01-03 20:28 UTC #11 lore raw

Dear Jeroen Hofstee,

Quoted 9 lines · In message <[email protected]> you wrote:

Quoted 6 lines
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?

Quoted 3 lines

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

Signature · 6 lines

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_

Jeroen Hofstee

2013-01-04 20:29 UTC #12 lore raw

Hi Wolfgang,

Quoted 7 lines · Wolfgang Denk

Quoted 3 lines
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

Jeroen Hofstee

2013-01-05 10:07 UTC #13 lore raw

In reply to Wolfgang Denk

Hi,

Quoted 6 lines · Wolfgang Denk

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

Wolfgang Denk

2013-01-05 19:18 UTC #14 lore raw

Dear Jeroen,

Quoted 10 lines · In message <[email protected]> you wrote:

Quoted 7 lines
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

Signature · 7 lines

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.

Wolfgang Denk

2013-01-03 10:43 UTC #15 lore raw

PATCH v2 1/1 VIDEO: better document the correct use of CONFIG_FB_ADDR

In reply to Wolfgang Denk

Signed-off-by Wolfgang Denk <[email protected]>

cc Anatolij Gustschin <[email protected]>

---
V2: changed text as suggested by Jeroen Hofstee

    in <[email protected]>

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

README +8 -5

index 78f40df..f84108e 100644
@@ -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.

Signature · 1 line

1.7.11.7

Anatolij Gustschin

2013-01-14 19:29 UTC #16 lore raw

PATCH v2 1/1 VIDEO: better document the correct use of CONFIG_FB_ADDR

Hi Wolfgang,

Quoted 8 lines · On Thu, 3 Jan 2013 11:43:59 +0100 Wolfgang Denk <[email protected]> wrote:

Signed-off-by Wolfgang Denk <[email protected]>
cc Anatolij Gustschin <[email protected]>
---
V2: changed text as suggested by Jeroen Hofstee
    in <[email protected]>
 README | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

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

Anatolij