[coreboot] [PATCH] more Kconfig default fixes

[Carl-Daniel Hailfinger]

On 10.10.2009 23:55, Myles Watson wrote:
>> Myles Watson schrieb:
>>     
>>> Fix AP_CODE_IN_CAR (only selected for two boards), STACK_SIZE, and
>>>       
>> HEAP_SIZE.
>>     
>>
>> One thing though: We're using lzma per default now if we're using
>> compression. This means each board needs at _least_ a stack size of
>> 0x8000.
> Why does LZMA use so much memory from the stack?  Couldn't we convert it to
> use heap so that it is easier to tell when you run out?  I guess that would
> make it dependent on a malloc call?
>   

Yes, the malloc dependency is what originally caused me to use the stack
instead.


>> Those boards with STACK_SIZE being 0x2000 or 0x8000 are definitely
>> broken (and if they boot, they do by accident)
>>     
>
> So since it's broken with Kconfig and newconfig, how can we decide what the
> correct stack size should be?
>
> What's the downside of a large stack?
>   

If you make the stack too large and you have multiple cores in CAR at
the same time, the CAR size is too small for all stacks.

> What breakage should occur, heap corruption?
> Should we check before LZMA how much stack is left?
>   

The best choice would be to make sure no AP ever uses LZMA.
Let me explain. If one AP uses LZMA, it's very likely due to
decompressing some CBFS member. If one AP does that, it is very likely
all of them are doing it, probably even at the same time (at least we
had that problem in the past). LZMA decompression uses the destination
buffer as scratch pad which means if you are decompressing the same file
to the same destination on different cores, you are likely to get
garbage there in the meantime or even at the end. Plus, decompressing
one file once per AP is totally wasteful. Nobody wants that.
Two ways to solve this:
1. Have the first AP decompress the CBFS member it wants to run and
block all other APs until decompression is complete (but you still need
a big stack for that first AP).
2. Have the BSP decompress the CBFS member the APs want to run, then
start the APs. Big benefit here is you can avoid locking and the stack
of APs can stay small.


Regards,
Carl-Daniel

-- 
Developer quote of the week: 
"We are juggling too many chainsaws and flaming arrows and tigers."