[coreboot] [PATCH] v3: print current and wanted LZMA scratchpad size

[Carl-Daniel Hailfinger]

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)

Regards,
Carl-Daniel