Dear Stefano Babic,
In message 4CCFD2FB.6060000@denx.de you wrote:
Why cannot you determine the exact amount needed at runtime?
Agree, we can do it, and it is better - I do not think we need really to change dinamically (I mean, in the same u-boot session) the LCD connected to the framebuffer, reason that requires to reserve the maximum amount of memory.
Right. If we keep in mind the possibility to share the frame buffer with Linux (to allow for a flicker-free display of a splash screen loaded very early in U-Boot) we should stick with the memory map we have: pRAM on top, frame buffer below, U-Boot code below, etc. That means that size changes for the frame buffer (like for pRAM) take only effect after a reset.
We could introduce a weak function, that a board maintainer can decide to implement or not. This maintains the compatibility with the most drivers where vpanel is static initialized.
In which way is this board dependent?
Best regards,
Wolfgang Denk