[U-Boot-Users] U-Boot Memory Allocation for Framebuffer?

[U-Boot-Users] U-Boot Memory Allocation for Framebuffer?

[Michael Bendzick]

Himba-

I had actually noticed the that size from size = lcd_setmem wasn't getting
used, and adjusted my own code to deal with that, it's just that I decided
to paste from CVS instead of my own code for some reason.

#ifdef CONFIG_LCD
	/*
	 * reserve memory for LCD display (always full pages)
	 */
	/* bss_end is defined in the board-specific linker script */
	addr = (_bss_end + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1);
	addr = lcd_setmem (addr);
	gd->fb_base = addr;
#endif /* CONFIG_LCD */

...is what I actually was using, which matched lib_ppc/board.c...

	/* round down to next 4 kB limit */
	addr &= ~(4096 - 1);

#ifdef CONFIG_LCD
	/* reserve memory for LCD display (always full pages) */
	addr = lcd_setmem (addr);
	gd->fb_base = addr;
#endif /* CONFIG_LCD */

In any case, I will give things a try with using the framebuffer at
0x110a2000.

-Michael Bendzick

-----Original Message-----
From: himba [mailto:himba at siol.net]
Sent: Tuesday, July 27, 2004 2:09 PM
To: Michael Bendzick
Cc: U-Boot-Users (E-mail)
Subject: Re: [U-Boot-Users] U-Boot Memory Allocation for Framebuffer?


Michael Bendzick wrote:
> I'm doing some development on a LCD framebuffer for the OMAP 1510
Innovator
> board (ARM925T CPU), and am encountering some difficulties with code
flying
> off to strange places.
> 
> I'm theorizing that the code flies off because memory is not properly
> allocated for the framebuffer.  I'm basing all of my new U-Boot related
code
> on cpu/mpc8xx/lcd.c, and adding LCD code from the OMAP kernel to get a
final
> product.
> 
> I make use of this code from lib_arm/board.c:
> 
> #ifdef CONFIG_LCD
> 	/*
> 	 * reserve memory for LCD display (always full pages)
> 	 */
> 	/* bss_end is defined in the board-specific linker script */
> 	addr = (_bss_end + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1);
> 	size = lcd_setmem (addr);
> 	gd->fb_base = addr;
> #endif /* CONFIG_LCD */
> 
> I have a lcd_setmem function that works fine, but I don't think the memory
> map gets properly initialized once it knows how much framebuffer memory is
> needed.
> 

If you look at the lcd_setmem() function in cpu/pxa/pxafb.c you
can see that it does nothing worth calling it - maybe just for
information that we are "reserving" FB mem. It just calculates the
size, prints it out and does nothing else on that chunk. Also note
that returned value by lcd_setmem() is not being used anywhere, for 
that matter. For my pxa255 arm target board I commented out call to
lcd_setmem().

HTH,
himba

[U-Boot-Users] U-Boot Memory Allocation for Framebuffer?

[himba]

Michael Bendzick wrote:
>
> #ifdef CONFIG_LCD
> 	/* reserve memory for LCD display (always full pages) */
> 	addr = lcd_setmem (addr);
> 	gd->fb_base = addr;
> #endif /* CONFIG_LCD */
> 

I tried taht too, till I started reading the source in more
detail, as this particular tweak hanged my board, since fb
that was allocated overwrote u-boot code that is there as
you pointed out in your first mail.

> In any case, I will give things a try with using the framebuffer at
> 0x110a2000.
> 

I'm affraid that's the only viable option you have ;)


regards,
himba

[U-Boot-Users] U-Boot Memory Allocation for Framebuffer?

[Michael Bendzick]

I'm doing some development on a LCD framebuffer for the OMAP 1510 Innovator
board (ARM925T CPU), and am encountering some difficulties with code flying
off to strange places.

I'm theorizing that the code flies off because memory is not properly
allocated for the framebuffer.  I'm basing all of my new U-Boot related code
on cpu/mpc8xx/lcd.c, and adding LCD code from the OMAP kernel to get a final
product.

I make use of this code from lib_arm/board.c:

#ifdef CONFIG_LCD
	/*
	 * reserve memory for LCD display (always full pages)
	 */
	/* bss_end is defined in the board-specific linker script */
	addr = (_bss_end + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1);
	size = lcd_setmem (addr);
	gd->fb_base = addr;
#endif /* CONFIG_LCD */

I have a lcd_setmem function that works fine, but I don't think the memory
map gets properly initialized once it knows how much framebuffer memory is
needed.

As the board initializes, "U-Boot code: 11080000 -> 1109D7B0  BSS: ->
110A1DA0" is printed, and the call lcd_setmem(0x110a2000) happens.
lcd_setmem wants to reserve the size 0x13000, which causes 'addr' in the
above code block to be 1108f000, and that is the location of the
framebuffer.

With the framebuffer occupying 1108f000 to 110A2000, that leaves only
1108000 to 1108f000 for U-Boot.  Taking a look at disassembly of the binary,
there is definitely valid code in the framebuffer range.

I'm wondering how the code block above, which also appears in roughly the
same form in lib_ppc/board.c, is supposed to grab a block of free memory for
the framebuffer.  Do I need to just allocate uchar
framebuffer[col*row*depth+palette] and point the framebuffer address to that
instead?  Something else?

Thanks,

-Michael Bendzick
Systems and Software Engineering
Logic Product Development
michael.b at logicpd.com
612-436-5122
www.logicpd.com

[U-Boot-Users] U-Boot Memory Allocation for Framebuffer?

[himba]

Michael Bendzick wrote:
> I'm doing some development on a LCD framebuffer for the OMAP 1510 Innovator
> board (ARM925T CPU), and am encountering some difficulties with code flying
> off to strange places.
> 
> I'm theorizing that the code flies off because memory is not properly
> allocated for the framebuffer.  I'm basing all of my new U-Boot related code
> on cpu/mpc8xx/lcd.c, and adding LCD code from the OMAP kernel to get a final
> product.
> 
> I make use of this code from lib_arm/board.c:
> 
> #ifdef CONFIG_LCD
> 	/*
> 	 * reserve memory for LCD display (always full pages)
> 	 */
> 	/* bss_end is defined in the board-specific linker script */
> 	addr = (_bss_end + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1);
> 	size = lcd_setmem (addr);
> 	gd->fb_base = addr;
> #endif /* CONFIG_LCD */
> 
> I have a lcd_setmem function that works fine, but I don't think the memory
> map gets properly initialized once it knows how much framebuffer memory is
> needed.
> 

If you look at the lcd_setmem() function in cpu/pxa/pxafb.c you
can see that it does nothing worth calling it - maybe just for
information that we are "reserving" FB mem. It just calculates the
size, prints it out and does nothing else on that chunk. Also note
that returned value by lcd_setmem() is not being used anywhere, for 
that matter. For my pxa255 arm target board I commented out call to
lcd_setmem().

> As the board initializes, "U-Boot code: 11080000 -> 1109D7B0  BSS: ->
> 110A1DA0" is printed, and the call lcd_setmem(0x110a2000) happens.
> lcd_setmem wants to reserve the size 0x13000, which causes 'addr' in the
> above code block to be 1108f000, and that is the location of the
> framebuffer.
> 
> With the framebuffer occupying 1108f000 to 110A2000, that leaves only
> 1108000 to 1108f000 for U-Boot.  Taking a look at disassembly of the binary,
> there is definitely valid code in the framebuffer range.
> 

When it prints out, it prints out the wrong value. Actually FB starts
at passed address - 0x110a2000 in your case (which is page aligned
location after _bss_end). Memory in size = fb_size + page_size is then
used for:
          *  FB
          *  DMA descriptors
          *  palette

in that order.

> I'm wondering how the code block above, which also appears in roughly the
> same form in lib_ppc/board.c, is supposed to grab a block of free memory for
> the framebuffer.  Do I need to just allocate uchar
> framebuffer[col*row*depth+palette] and point the framebuffer address to that
> instead?  Something else?
> 

I don't know how the ppc deals with it, but above works for me - I'm
also memcpy'ing fb and palette allocated by u-boot later in linux, so
I can confirm that locations on FB and palette are correct.

HTH,
himba

[U-Boot-Users] U-Boot Memory Allocation for Framebuffer?

[Wolfgang Denk]

In message <31ADFA827355984B9E2A161514595B561C330E@lpdsrv04.logicpd.com> you wrote:
> I'm doing some development on a LCD framebuffer for the OMAP 1510 Innovator
> board (ARM925T CPU), and am encountering some difficulties with code flying
> off to strange places.
> 
> I'm theorizing that the code flies off because memory is not properly
> allocated for the framebuffer.  I'm basing all of my new U-Boot related code
> on cpu/mpc8xx/lcd.c, and adding LCD code from the OMAP kernel to get a final
> product.

It is not a good idea to use the PPC code as a model as it  is  based
on  a  different  memory  map.  It  may  not work on ARM - on PPC, we
actually compute the relocation address depeding on how  much  memory
we need to reserve. All this is missing for ARM.

> I'm wondering how the code block above, which also appears in roughly the
> same form in lib_ppc/board.c, is supposed to grab a block of free memory for
> the framebuffer.  Do I need to just allocate uchar

It does not gram anything. It is just a copy of  PPC  code  which  is
used in a completely different context on PPC.

> framebuffer[col*row*depth+palette] and point the framebuffer address to that
> instead?  Something else?

Either you simply make sure not to use  the  framebuffer  area  which
follows  the  BSS  segment,  or  (more  complicated)  you fix the ARM
implementation and implement real relocation as  done  for  PPC.  I'd
prefer  to  see  (2)  because  this  is  long  overdue,  but  I could
understand if you chose the simple route.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Life sucks, but death doesn't put out at all...."   - Thomas J. Kopp