Dear Stefano Babic, In message <4ccfd2fb.6060...@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 -- 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: w...@denx.de Philosophy: A route of many roads leading from nowhere to nothing. - Ambrose Bierce _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot