[U-Boot-Users] How can I reserve memory for LCD framebuffer on ARM-based board?

Hello, I'm working on support for LCD framebuffer on S3C24[14]0 ARM-based SoCs in u-boot. I faced the problem that existing code in lib_arm/board.c uses memory just behind .bss for framebuffer and don't even tries to ensure that there are enough memory (yes, my hardware uses system memory for framebuffer). What can I do to reserve enough memory? Should I somehow relocate .bss (and code)? or should I reserve memory under u-boot code? (that is what lcd_setmem() expects as far as I can understand)
Thanks in advance, Ilya.

In message loom.20060506T115123-50@post.gmane.org you wrote:
I'm working on support for LCD framebuffer on S3C24[14]0 ARM-based SoCs in u-boot. I faced the problem that existing code in lib_arm/board.c uses memory just behind .bss for framebuffer and don't even tries to ensure that there are enough memory (yes, my hardware uses system memory for framebuffer).
Why do you think that reserving memory above the BSS segmet was a problem?
And "don't even tries to ensure that there are enough memory" - well, it is obviously the responsibility of the person porting U-Boot to a specific board to come up with a valid memory map.
What exactly is your problem?
What can I do to reserve enough memory? Should I somehow relocate .bss (and code)? or should I reserve memory under u-boot code? (that is what lcd_setmem() expects as far as I can understand)
Oops? I don't understand. The existing code works fine on a couple of boards. What's your specific problem? What exactly makes you think you cannot to the same?
Best regards,
Wolfgang Denk

Wolfgang Denk <wd <at> denx.de> writes:
Why do you think that reserving memory above the BSS segmet was a problem?
And "don't even tries to ensure that there are enough memory" - well, it is obviously the responsibility of the person porting U-Boot to a specific board to come up with a valid memory map.
To be more precise I just try to ask where exactly I should make changes to reserve memory for framebuffer?
Oops? I don't understand. The existing code works fine on a couple of boards. What's your specific problem? What exactly makes you think you cannot to the same?
Existing code works fine, but writers of lib_arm/board.c and common/lcd.c for sure were thinking about different things... Code from lib_arm/board.c: size = lcd_setmem (addr); gd->fb_base = addr;
But lcd_setmem(addr) returns not size of framebuffer but addr - size and reports of reserving framebuffer at addr - size. This don't make things broken but obviously is some kind of misunderstanding...
This makes me think that somewhere (obviously not on ARM boards) we reserve framebuffer below u-boot code, so second question is why not to do this everywhere?
With best regards, Ilya.
participants (2)
-
Ilya Yanok
-
Wolfgang Denk