c-d.hailfinger.devel.2006 at gmx.net
Sun Jun 21 01:04:17 CEST 2009
On 20.06.2009 20:08, Ward Vandewege wrote:
> On Sat, Jun 20, 2009 at 10:13:04AM -0700, ron minnich wrote:
>> That is fine. That's a simple and straightforward change. How about we
>> start with that. But let's not do THAT change until we fix ward's
>> problem, and this has nothing to do with Ward's problem.
> Sorry for opening this can of worms ;)
> So, Stepan thinks that perhaps the stack is too small for the lzma
> decompression. I'm going to test next week with a 32KB stack (right now its
> at the default 8KB).
Wait a second. We have two different possible problems to consider.
1. Every core which uses LZMA decompression needs at least 24k stack.
2. AP stacks are a lot smaller than the BSP stack by design, so even if
you have a 24k stack for the BSP, it is unlikely you have sufficient
stack size for the APs.
Can you test with 32k BSP stack size, but uncompressed AP code and
default AP stack size? Unless CBFS code has some internal design/code
limitations (and I didn't see any regarding the stack), the lzma stack
requirements should not show up on APs for uncompressed AP code.
> This might solve booting, but I'll still have APs and
> BSP talking all at once, which I'm also seeing on K10.
That's the locking problem which we can fix separately.
More information about the coreboot