New on blogs.coreboot.org: [GSOC] Panic Room, week #4/5/6

[Julius Werner]

Hi Antonello,

On Fri, Jul 22, 2016 at 3:02 AM, WordPress 
wrote:
> Since my last post I mainly kept focusing on the region_device API, I
> attempted to go through with my week #3 plan to continue the phasing out of
> rdev_mmap_full() from the selfload code (described in previous post).
>
> I think I overestimated what I could accomplish regarding that project, I
> tried to modify the current lzma API used inside to coreboot to make it
> possible to easily load each chunk of data from memory/chip and decompress
> it gradually.
> Theoretically it shouldn’t be too difficult, in practice the decompression
> code is particularly nasty and it seems it is a customised version of the
> LZMA SDK code.
> I, not so quickly, realised that I didn’t have the time to delve into
> that, so I momentarily dropped the idea. (It could be a nice project to do
> after the GSOC ends.)
>
> Just wanted to point out that we recently added LZ4 compression as an

alternative to LZMA which has the nice property that it can decompress
in-place (meaning you read it into the end of the buffer reserved for the
decompressed binary, and then just run the decompression function with
overlapping input and output buffers). This would allow you to solve your
problem by just doing a single big rdev_readat(), but without needing
additional memory anywhere.

On the systems I looked at, LZ4 and LZMA are almost equally effective
anyway. What little LZ4 lacks in compression ratio is roughly made up with
faster decompression speed when you look at total boot time. Maybe it's
time we just get rid of LZMA completely and then we can rewrite all the
decompression things with the assumption that they support in-place.