Attention is currently required from: Felix Singer, Jonathon Hall, Martin L Roth, Nigel Tao, Paul Menzel.
Nico Huber 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:
It's not based on the file size, it's based on the image resolution + chroma subsampling, as I under […]
I guess I was thinking about the resolution (file(1) should be able to print it?). Using the exact same Wuffs code for the calculation would be more accurate ofc.
PS2:
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.)
In general, we have at least the <4GiB address space and all the DRAM available therein. I'm not aware of any infrastructure, I guess technically you could look into `bootmem` and pick your spot.
IMO, the thing is however, coreboot is not designed for this, and probably shouldn't be. Something that isn't needed on S3 resume? that's a payload thing. And AIUI, historically display init was only added in coreboot because the payloads couldn't do it. I do understand the issue, though, that you want to show something before a huge payload has been slowly loaded. I guess if I wanted to do something in this direction, I'd try to create a graphics stage/ payload-shim.
For now, I suggest we keep the `if`, just move things to `src/Kconfig` as Felix suggested.