<br><br><div class="gmail_quote">On Sat, Oct 10, 2009 at 5:02 PM, Carl-Daniel Hailfinger <span dir="ltr"><<a href="mailto:c-d.hailfinger.devel.2006@gmx.net">c-d.hailfinger.devel.2006@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On 11.10.2009 00:28, Myles Watson wrote:<br>
> On Sat, Oct 10, 2009 at 4:18 PM, Carl-Daniel Hailfinger<br>
> <<a href="mailto:c-d.hailfinger.devel.2006@gmx.net">c-d.hailfinger.devel.2006@gmx.net</a>> wrote:<br>
><br>
>> On 10.10.2009 23:55, Myles Watson wrote:<br>
>><br>
>>>> One thing though: We're using lzma per default now if we're using<br>
>>>> compression. This means each board needs at _least_ a stack size of<br>
>>>> 0x8000.<br>
>>>><br>
>> Yes, the malloc dependency is what originally caused me to use the stack<br>
>> instead.<br></div></blockquote><div>Maybe we ought to revisit it, then, since malloc already checks if it is running out of memory.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> But we could check the position on the stack compared to the top of<br>
> the stack before running LZMA, right?<br>
<br>
</div>That's hideously complicated. On AMD Fam10, each AP gets its own<br>
mini-stack at another location. The code for a stack checker is in v3<br>
and even for the no-SMP case it is really fragile. Add multiple stack<br>
sizes and multiple stack locations to it and the code will have to be<br>
marked "Do not touch even if you think you understand it".<br>
But yes, it can be done.<br></blockquote><div>I just meant compare against the top of all stacks (or the bottom of the heap.)  Any checking is better than none.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>>>>> Those boards with STACK_SIZE being 0x2000 or 0x8000 are definitely<br>
>>>> broken (and if they boot, they do by accident)<br>
>>> So since it's broken with Kconfig and newconfig, how can we decide what the<br>
>>> correct stack size should be?<br></div></blockquote><div>Ping.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">

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