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