[XS] Change in coreboot[main]: bootsplash: Increase heap from 1 MB to 4 MB when bootsplash is enabled

[Jonathon Hall (Code Review)]

Attention is currently required from: Felix Singer, Martin L Roth, Nico Huber, Nigel Tao, Paul Menzel.

Jonathon Hall has posted comments on this change by Jonathon Hall. ( https://review.coreboot.org/c/coreboot/+/83476?usp=email )

Change subject: bootsplash: Increase heap from 1 MB to 4 MB when bootsplash is enabled
......................................................................

Patch Set 2:

(2 comments)

Patchset:

PS2:
> I would have to ask "where would we stop?" If next time somebody runs into this […]

Ah I didn't realize this persisted through OS runtime, thanks Nico.

Is there somewhere we could allocate the Wuffs work area outside of the ordinary heap - where we wouldn't have this size limitation and it wouldn't persist through OS runtime?  This work area isn't needed once the bootsplash is shown.

Do we have any infrastructure for allocating other available memory temporarily, or could we add it?  (I can work on it, but I'd appreciate suggestions where to start if you have an idea.)

BTW, in combination with the issue address in patch 83475, this regression results in failure to boot if the bootsplash work area can't be allocated, where those bootsplashes worked on the older decoder.

PS2:
> NB. We should probably try to save the next person to run into this […]

It's not based on the file size, it's based on the image resolution + chroma subsampling, as I understand it.  We would probably need to rely on ImageMagick being available at build time to figure that out.  Or build the Wuffs decoder for the host and run it, maybe.

ImageMagick is already needed at build time if the bootsplash conversion is enabled in Kconfig, but it's not needed otherwise.

Either way this still has the heap cost during OS runtime that you mentioned, which I didn't realize.  If we could use some other memory for the bootsplash, which we likely have, I think it'd address both problems, no static limitation and no runtime cost.