[coreboot] [PATCH] more Kconfig default fixes

[Myles Watson]

On Sat, Oct 10, 2009 at 5:02 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 11.10.2009 00:28, Myles Watson wrote:
> > On Sat, Oct 10, 2009 at 4:18 PM, Carl-Daniel Hailfinger
> > <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> >
> >> On 10.10.2009 23:55, Myles Watson wrote:
> >>
> >>>> 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.
> >>>>
> >> Yes, the malloc dependency is what originally caused me to use the stack
> >> instead.
>
Maybe we ought to revisit it, then, since malloc already checks if it is
running out of memory.


> > But we could check the position on the stack compared to the top of
> > the stack before running LZMA, right?
>
> That's hideously complicated. On AMD Fam10, each AP gets its own
> mini-stack at another location. The code for a stack checker is in v3
> and even for the no-SMP case it is really fragile. Add multiple stack
> sizes and multiple stack locations to it and the code will have to be
> marked "Do not touch even if you think you understand it".
> But yes, it can be done.
>
I just meant compare against the top of all stacks (or the bottom of the
heap.)  Any checking is better than none.


> >>>> 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?
>
Ping.


> > It seems like the safest way would be to serialize AP startup and have
> > (at most) two stacks.
> >
>
> That's a good idea as well, but I'm not sure our current infrastructure
> can handle that. And how would the second and subsequent APs realize
> that earlier incarnations already decompressed the CBFS member? All
> those ROM accesses are wasting lots of time, so we only want to do them
> once.

All I'm looking for is the shortest path to "not-broken".  I'm open to
suggestions.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20091012/d68d3d31/attachment.html>