[coreboot] [PATCH] v3: print current and wanted LZMA scratchpad size
c-d.hailfinger.devel.2006 at gmx.net
Fri May 23 22:00:33 CEST 2008
On 23.05.2008 21:45, Myles Watson wrote:
> On Fri, May 23, 2008 at 1:32 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> On 23.05.2008 21:25, Myles Watson wrote:
>>> On Fri, May 23, 2008 at 1:22 PM, Carl-Daniel Hailfinger
>>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>>> Print current and wanted LZMA scratchpad size in the decompression
>>>> routine. That allows people to either adjust compression parameters
>>>> or scratchpad size.
>>>> Having a similar check during build time would be nice.
>>>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>>> Index: LinuxBIOSv3-tmp/lib/lzma.c
>>>> --- LinuxBIOSv3-tmp/lib/lzma.c (Revision 682)
>>>> +++ LinuxBIOSv3-tmp/lib/lzma.c (Arbeitskopie)
>>>> @@ -14,6 +14,7 @@
>>>> #include "string.h"
>>>> #include "console.h"
>>>> +#define LZMA_SCRATCHPAD_SIZE 15980
>>> What's the reason for 15980? What's the downside to increasing it further?
>> It's the value I picked during OLPC early bringup, based on compression
>> efficiency measurements correlated with stack requirements. It seemed to
>> be the sweet spot on Geode back then. Besides that, v3 relies on the
>> stack not to outgrow 32k IIRC, otherwise stack and printk buffer will
>> corrupt each other.
> I don't know enough about the state of v3 at the point of
> decompression, but it seems like if you could allocate the buffer on
> the heap instead of the stack, it would make this better. I also
> think that it should be an error, not a warning if it can't decompress
> the next stage.
>> Right now the patch is a no-op except for the better error message.
> Yes. I just thought it might be worth fixing the problem at the same
> time if it was simple enough.
> Acked-by: Myles Watson <mylesgw at gmail.com>
Thanks, r684 and r685 (fixup of a compilation breakage typo in r684)
More information about the coreboot