* Marc Jones <marcj303(a)gmail.com> [130502 17:15]:
> Hi Aaron,
>
> On Thu, May 2, 2013 at 8:32 AM, Aaron Durbin <adurbin(a)chromium.org> wrote:
> > Hi folks,
> >
> > I am wondering why the ramstage stack size is so large on a lot of boards:
> >
> > $ grep -A 3 -r STACK_SIZE src/* | grep Kconfig | grep default | awk '{
> > print $NF }' | sort | uniq -c | sort -r -n
> > 16 0x10000
> > 2 0x2000
> > 2 0x1000
> > 1 0x20000
> >
> > Is this just an artifact of copy-n-paste? What is driving the
> > requirement for such large stack sizes?
>
> I suspect that it is some copy and paste. Some of the AMD Fam10 and
> Fam15 have large stacks for stacks for each core (which may or maynot
> need to be as large as they are).
>
> Marc
We added code that measures and prints stack usage for each core. I
believe any board with a non-default stack size has these by accident
and it got copied and pasted around.
Can anyone with those boards in question please post information about
the actual stack usage here so we can unify (and possibly fix) this?
Stefan
On Thu, May 2, 2013 at 10:45 AM, ron minnich <rminnich(a)gmail.com> wrote:
> The old requirement was a 17K automatic for lzma. We removed that
> problem a year ago and the stack measuring stuff showed that the
> largest stack size used was well under 4k (in the places we checked)
>
I'm definitely aware of the lzma requirement (and how it was handled
with a 'static' :). I would be curious to know about what the AMD
requirements are, though. It seems excessive to me.
-Aaron
The old requirement was a 17K automatic for lzma. We removed that
problem a year ago and the stack measuring stuff showed that the
largest stack size used was well under 4k (in the places we checked)
I think it's inertia.
ron
On Thu, May 2, 2013 at 10:35 AM, Marc Jones <marcj303(a)gmail.com> wrote:
> On Thu, May 2, 2013 at 9:25 AM, Aaron Durbin <adurbin(a)chromium.org> wrote:
>> On Thu, May 2, 2013 at 10:15 AM, Marc Jones <marcj303(a)gmail.com> wrote:
>>> Hi Aaron,
>>>
>>> On Thu, May 2, 2013 at 8:32 AM, Aaron Durbin <adurbin(a)chromium.org> wrote:
>>>> Hi folks,
>>>>
>>>> I am wondering why the ramstage stack size is so large on a lot of boards:
>>>>
>>>> $ grep -A 3 -r STACK_SIZE src/* | grep Kconfig | grep default | awk '{
>>>> print $NF }' | sort | uniq -c | sort -r -n
>>>> 16 0x10000
>>>> 2 0x2000
>>>> 2 0x1000
>>>> 1 0x20000
>>>>
>>>> Is this just an artifact of copy-n-paste? What is driving the
>>>> requirement for such large stack sizes?
>>>
>>> I suspect that it is some copy and paste. Some of the AMD Fam10 and
>>> Fam15 have large stacks for stacks for each core (which may or maynot
>>> need to be as large as they are).
>>>
>>
>> What do you mean by that? Did you mean the STACK_SIZE variable is
>> being used preallocate stacks for all cores? If so what about the
>> following? I admittedly changed the 2nd one, but that still followed
>> the original intent.
>>
>> http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/lib/stack.c;h…
>> http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/lib/…
>>
>> -Aaron
>
> Sorry, I am wrong about that being the total size.
> The BSP of the AMD code requires a large stack, but those sizes do
> seem excessive.
OK. Thanks for the info. That does make for some huge memory
footprints on the AMD machines with a large number of CONFIG_MAX_CPUS.
I'd be curious to know why the BSP for the AMD code requires so much
while in ramstage.
-Aaron
On Thu, May 2, 2013 at 9:25 AM, Aaron Durbin <adurbin(a)chromium.org> wrote:
> On Thu, May 2, 2013 at 10:15 AM, Marc Jones <marcj303(a)gmail.com> wrote:
>> Hi Aaron,
>>
>> On Thu, May 2, 2013 at 8:32 AM, Aaron Durbin <adurbin(a)chromium.org> wrote:
>>> Hi folks,
>>>
>>> I am wondering why the ramstage stack size is so large on a lot of boards:
>>>
>>> $ grep -A 3 -r STACK_SIZE src/* | grep Kconfig | grep default | awk '{
>>> print $NF }' | sort | uniq -c | sort -r -n
>>> 16 0x10000
>>> 2 0x2000
>>> 2 0x1000
>>> 1 0x20000
>>>
>>> Is this just an artifact of copy-n-paste? What is driving the
>>> requirement for such large stack sizes?
>>
>> I suspect that it is some copy and paste. Some of the AMD Fam10 and
>> Fam15 have large stacks for stacks for each core (which may or maynot
>> need to be as large as they are).
>>
>
> What do you mean by that? Did you mean the STACK_SIZE variable is
> being used preallocate stacks for all cores? If so what about the
> following? I admittedly changed the 2nd one, but that still followed
> the original intent.
>
> http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/lib/stack.c;h…
> http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/lib/…
>
> -Aaron
Sorry, I am wrong about that being the total size.
The BSP of the AMD code requires a large stack, but those sizes do
seem excessive.
Marc
--
http://se-eng.com
On Thu, May 2, 2013 at 10:15 AM, Marc Jones <marcj303(a)gmail.com> wrote:
> Hi Aaron,
>
> On Thu, May 2, 2013 at 8:32 AM, Aaron Durbin <adurbin(a)chromium.org> wrote:
>> Hi folks,
>>
>> I am wondering why the ramstage stack size is so large on a lot of boards:
>>
>> $ grep -A 3 -r STACK_SIZE src/* | grep Kconfig | grep default | awk '{
>> print $NF }' | sort | uniq -c | sort -r -n
>> 16 0x10000
>> 2 0x2000
>> 2 0x1000
>> 1 0x20000
>>
>> Is this just an artifact of copy-n-paste? What is driving the
>> requirement for such large stack sizes?
>
> I suspect that it is some copy and paste. Some of the AMD Fam10 and
> Fam15 have large stacks for stacks for each core (which may or maynot
> need to be as large as they are).
>
What do you mean by that? Did you mean the STACK_SIZE variable is
being used preallocate stacks for all cores? If so what about the
following? I admittedly changed the 2nd one, but that still followed
the original intent.
http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/lib/stack.c;h…http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/lib/…
-Aaron
Hi Aaron,
On Thu, May 2, 2013 at 8:32 AM, Aaron Durbin <adurbin(a)chromium.org> wrote:
> Hi folks,
>
> I am wondering why the ramstage stack size is so large on a lot of boards:
>
> $ grep -A 3 -r STACK_SIZE src/* | grep Kconfig | grep default | awk '{
> print $NF }' | sort | uniq -c | sort -r -n
> 16 0x10000
> 2 0x2000
> 2 0x1000
> 1 0x20000
>
> Is this just an artifact of copy-n-paste? What is driving the
> requirement for such large stack sizes?
I suspect that it is some copy and paste. Some of the AMD Fam10 and
Fam15 have large stacks for stacks for each core (which may or maynot
need to be as large as they are).
Marc
>
> Thanks.
>
> -Aaron
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
--
http://se-eng.com
Hi folks,
I am wondering why the ramstage stack size is so large on a lot of boards:
$ grep -A 3 -r STACK_SIZE src/* | grep Kconfig | grep default | awk '{
print $NF }' | sort | uniq -c | sort -r -n
16 0x10000
2 0x2000
2 0x1000
1 0x20000
Is this just an artifact of copy-n-paste? What is driving the
requirement for such large stack sizes?
Thanks.
-Aaron
On 05/01/2013 02:25 PM, Rudolf Marek wrote:
> Hi all,
>
> I ran into strange problem that flashrom was looping forever in the
> chip probe.
>
> I have the Hudson D3 here:
>
> 00:14.0 SMBus: Advanced Micro Devices [AMD] Hudson SMBus Controller
> (rev 14)
> 00:14.2 Audio device: Advanced Micro Devices [AMD] Hudson Azalia
> Controller (rev 01)
> 00:14.3 ISA bridge: Advanced Micro Devices [AMD] Hudson LPC Bridge
> (rev 11)
> 00:14.4 PCI bridge: Advanced Micro Devices [AMD] Hudson PCI Bridge
> (rev 40)
> 00:14.5 USB controller: Advanced Micro Devices [AMD] Hudson USB OHCI
> Controller (rev 11)
> 00:14.7 SD Host controller: Advanced Micro Devices [AMD] Hudson SD
> Flash Controller
>
> The problem I was seeing is that 14.3 SPI BAR has the SAME address as
> 14.7 SD controller.
>
> Also, there is some special code in hudson.c to protect the SPI BAR
> from changing otherwise IMC firmware dies.
>
> 1) workaround for IMC does not work for me, it gets new address from
> coreboot resource management.
>
> Martin, please can you check?
Hi Rudolph,
I do not think the IMC workaround does what you think it does.... It
isn't meant to prevent the address from changing. The main reason this
workaround is needed is that this bar (naturally) doesn't actually
follow the PCI spec. Bit 1 isn't to enable memory - it's to enable the
spy controller itself. The reason for the workaround was that when the
device memory was getting changed, it was also getting disabled. When
it got disabled at this point, for whatever reason the IMC rom would
crash and stop running (I actually later tried this method of killing
off the IMC, but it seems to be timing dependent - I couldn't kill it
with this method after booting).
>
> 2) even if SD controller 14.7 is "off" in devicetree, the PCI device
> exists.
> I noticed that hudson enable() is empty...
yeah, there's no code in the hudson directory to do ANYTHING with the SD
device right now. I did some work on that this past weekend - I'll try
to wrap it up and push it this weekend.
Each component gets its own enable() function. I liked the way that
SB800 was done, but when the southbridge wrapper was re-architected from
cimx to agesa, this structure was changed... whatever, either way works.
>
> 3) because 1) does not work, the newly allocated BAR by coreboot
> 0xf014fa00 is used for SPI, and because linux is super smart, it
> figures out first free PCI resource and this is also 0xf014fa00!!!
>
> [ 0.215751] pci 0000:00:14.7: >BAR 0: assigned [mem
> 0xf014fa00-0xf014faff 64bit]
>
> And last pitty point is that SD wins over SPI controller ;)
I think I see the bug in my change that's causing this. I think the
problem is that I adjusted the base address before setting the resources
and didn't adjust it back. Because of this there's nothing in the
tables at 0xf014fa00 - The code doing the tables thinks the base address
is at 0xf014fa02, and this messed SOMETHING up. I'll submit a patch.
I'll pester you on IRC about testing this.
Martin
>
> My questions are mostly 1) and 2) any clue about that? The 3) was just
> FYI if you ran ever into same problem. I will do a patch to the f2a85x
> to "on" 14.7 in devicetree. This allocates the BAR in coreboot and
> everything is fine again.
>
> Thanks
> Rudolf
>
