coreboot May 2013

coreboot@coreboot.org

38 participants
91 discussions

Re: [coreboot] Question about STACK_SIZE
by Stefan Reinauer 03 May '13

03 May '13

* 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

1 0

Re: [coreboot] Question about STACK_SIZE
by Aaron Durbin 03 May '13

03 May '13

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

1 0

Re: [coreboot] Question about STACK_SIZE
by ron minnich 03 May '13

03 May '13

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

1 0

Re: [coreboot] Question about STACK_SIZE
by Aaron Durbin 03 May '13

03 May '13

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

1 0

Re: [coreboot] Question about STACK_SIZE
by Marc Jones 03 May '13

03 May '13

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

1 0

Re: [coreboot] Question about STACK_SIZE
by Aaron Durbin 03 May '13

03 May '13

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

1 0

Re: [coreboot] Question about STACK_SIZE
by Marc Jones 03 May '13

03 May '13

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

1 0

Question about STACK_SIZE
by Aaron Durbin 02 May '13

02 May '13

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

1 0

Re: [coreboot] hudson BAR troubles
by Martin Roth 02 May '13

02 May '13

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 >

1 0

GSoC student application period closes Friday, 03.05.2013
by Marc Jones 02 May '13

02 May '13

The deadline for student applications ends 03.05.2013, 19:00 UTC. Note that the UTC time. I recoemmend that you get the something submitted by Thursday. Please visit the wiki for more information: http://www.coreboot.org/GSoC http://www.coreboot.org/GSoC#coreboot_Summer_of_Code_Application Marc -- http://se-eng.com

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2013