coreboot May 2013

coreboot@coreboot.org

38 participants
91 discussions

Tree broken: ASUS M4A785T-M and PC Engines ALIX.1C fail to build
by Paul Menzel 12 May '13

12 May '13

Dear coreboot folks, since yesterday the tree is broken [1] due to merging the following commits [2][3] without their dependencies as they were not pushed as a branch [4]. commit b8b3e8bff32ee7dddcacec11e015f6683783eb2f Author: Denis 'GNUtoo' Carikli <GNUtoo(a)no-log.org> Date: Thu May 9 16:14:59 2013 +0200 Asus M4A785T-M: Add CMOS defaults. commit f90071faeee3358748d0c8d31e46721b53241e28 Author: Denis 'GNUtoo' Carikli <GNUtoo(a)no-log.org> Date: Thu May 9 23:35:18 2013 +0200 PC Engines ALIX.1C: Add CMOS defaults. The following two boards fail to build [1]. board.i386/asus/m4a785t-m board.i386/pcengines/alix1c Could the two commits be reverted as it does not look like that [4] is going to be approved soon. Thanks, Paul [1] http://qa.coreboot.org/job/coreboot-gerrit/6251/ [2] http://review.coreboot.org/#/c/3224/ [3] http://review.coreboot.org/#/c/3229/ [4] http://review.coreboot.org/#/c/3223/

2 1

How to set different defaults for Kconfig values like `CONFIG_USBDEBUG_DEFAULT_PORT`
by Paul Menzel 11 May '13

11 May '13

Dear coreboot folks, looking at how to split up the patch for the Lenovo X201 southbridge support [1], commit 92ba16cf9fabcf478c225dff687ae717666b502d Author: Vladimir Serbinenko <phcoder(a)gmail.com> Date: Sun Mar 31 22:22:10 2013 +0200 intel/bd82x6x: Support mobile 5 southbridge I stumbled over `CONFIG_USBDEBUG_DEFAULT_PORT`. $ git describe 4.0-3936-g92ba16c $ git grep -A3 USBDEBUG_DEFAULT_PORT src/console/Kconfig:config USBDEBUG_DEFAULT_PORT src/console/Kconfig- int "Default USB port to use as Debug Port" src/console/Kconfig- default 1 src/console/Kconfig- depends on USBDEBUG && !SOUTHBRIDGE_INTEL_I82801GX && !SOUTHBRIDGE_AMD_SB600 -- src/console/console.c: enable_usbdebug(CONFIG_USBDEBUG_DEFAULT_PORT); src/console/console.c- early_usbdebug_init(); src/console/console.c-#endif src/console/console.c-#if CONFIG_CONSOLE_SERIAL -- src/southbridge/amd/sb600/Kconfig:config USBDEBUG_DEFAULT_PORT src/southbridge/amd/sb600/Kconfig- int src/southbridge/amd/sb600/Kconfig- default 0 src/southbridge/amd/sb600/Kconfig- -- src/southbridge/intel/bd82x6x/Kconfig:config USBDEBUG_DEFAULT_PORT src/southbridge/intel/bd82x6x/Kconfig- int src/southbridge/intel/bd82x6x/Kconfig- default 2 src/southbridge/intel/bd82x6x/Kconfig- -- src/southbridge/intel/i82801gx/Kconfig:config USBDEBUG_DEFAULT_PORT src/southbridge/intel/i82801gx/Kconfig- int src/southbridge/intel/i82801gx/Kconfig- default 1 src/southbridge/intel/i82801gx/Kconfig- -- src/southbridge/intel/i82801ix/Kconfig:config USBDEBUG_DEFAULT_PORT src/southbridge/intel/i82801ix/Kconfig- int src/southbridge/intel/i82801ix/Kconfig- default 1 src/southbridge/intel/i82801ix/Kconfig- 1. Is there an easier way to handle this? I assume the complexity is due to the fact, that boards have different defaults? Is default default 1 default 0 if SOUTHBRIDGE_AMD_SB600 a shorter alternative? 2. The other thing is probably under what menu item this option is displayed at. If under Console or Chipset. Do you have other suggestions? Shall I prepare a commit to change the code as suggested above? Thanks, Paul [1] http://review.coreboot.org/#/c/2995/

1 0

Proposal on cheap test rig for the distributed firmware test environment
by Ayush Sagar 11 May '13

11 May '13

Hello. I'm Ayush from India and I have applied to coreboot for GSoc 2013. My proposal is on developing a cheap test rig for the distributed firmware test environment and I have gone through the material on Distributed Test Environment given in GSoc ideas page. I wish to know how many firmware test servers are being used and how many systems under test are present in total. Are they in the same office? And what type of flash chips would you want the test-rig to be able to program? Do you need support for parallel, LPC, FWH flash? Please suggest improvements in my GSoc proposal if possible: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/ayush350…<http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/ayush350…> Thanks

1 0

Re: [coreboot] DDR fails on F2A85-M
by Rudolf Marek 10 May '13

10 May '13

Hi all, > I am using CONFIG_BOARD_ASUS_F2A85_M_DDR3_VOLT_150 There seems to be a problem in the code logic, Paul should know more. Maybe playing with the SMBus write and set voltage to 165 might help? > I uncommented the #define IDSOPT_IDS_ENABLED in > src/mainboard/asus/f2a85-m/OptionsIds.h and captured the serial output. > > What do you think I should pursue first, option A or B: Unfortunately I don't know. Hope some AGESA expert will step in. I'm AFK for the weekend so I can't help more. Have a look to the mainboard manual, i think dimm labeled A1 is in fact the second channel and not the first one. Please give a try in other slots too. Sorry for the short answer, I travel soonish AFK. Thanks Rudolf

1 0

Re: [coreboot] DDR fails on F2A85-M
by David Hubbard 10 May '13

10 May '13

Hi Rudolf, Paul, I pulled the version from http://review.coreboot.org/#/c/3200/ but my F2A85-M still halts in the same place: ASSERTION FAILED: file 'src/vendorcode/amd/agesa/f15tn/Proc/Mem/Main/mmExcludeDimm.c', line 263 I am using CONFIG_BOARD_ASUS_F2A85_M_DDR3_VOLT_150 I uncommented the #define IDSOPT_IDS_ENABLED in src/mainboard/asus/f2a85-m/OptionsIds.h and captured the serial output. What do you think I should pursue first, option A or B: Option A is where AGESA says: > MemClkFreq changed: 333 MHz -> 800 MHzMemFInitTableDrive [0000000000000001] Start MemFInitTableDrive End > > No Rtt entries > > * ERROR Event: 04063500 Data: 0, 0, 0, 0 > > Disable DCT0 due to unsupported DIMM configuration > Memclk Freq: 800 > RdPtr: 6 It sounds like AGESA needs a table with Rtt entries? Option B is where AGESA says: > Going into training stage 2. Complete training at DDR667 is done. If DDR3-667 works but AGESA fails at DDR3-1600, is it possible to go back to DDR3-667 or try an intermediate speed, say DDR3-1333 ? I put a sample log at https://gist.github.com/davidhubbard/5552910 Here are some things I did: 1. cold boot after removing AC power for ~30 s 2. try the other DIMM in slot A1 (still just a single DIMM in the machine) 3. hit the reset switch a couple of times The manufacturer page for the memory says: [1] Non-ECC Tested Speed DDR3-2133 MHz Tested Latency 11-11-11-30 2N Tested Voltage 1.5 -1.6V SPD Speed 1600 MHz SPD Voltage 1.5V Some useful snippets from the log: MemoryClockSelect : 800 AmdMemAuto: Start MEM PARAMS: BottomIo : 00E0 MemHoleRemap : 1 LimitBelow1TB : 1 UserTimingMode : 0 MemClockValue : 800 BankIntlv : 1 NodeIntlv : 0 ChannelIntlv : 1 EccFeature : 0 PowerDown : 1 OnLineSpare : 0 Parity : 0 BankSwizzle : 1 MemClr : 1 UmaMode : 1 UmaSize : 8192 MemRestoreCtl : 0 SaveMemContextCtl : 0 ExternalVrefCtl : 0 ForceTrainMode : 2 Node0: 1.5V -> 800MHz MemClkFreq: 333 MHz MemClkFreq changed: 333 MHz -> 800 MHz [1] http://www.gskill.com/products.php?index=397 [2] this is the same product: http://www.newegg.com/Product/Product.aspx?Item=N82E16820231468

1 0

Re: [coreboot] Intel: How to share `tsc_freq.c` to select `UDELAY_TSC`
by Stefan Reinauer 10 May '13

10 May '13

* Aaron Durbin <adurbin(a)chromium.org> [130509 00:02]: > >> > Am Mittwoch, den 08.05.2013, 08:18 -0500 schrieb Aaron Durbin: > >> The reason udelay was put in northbridge was for SMM if I am not > >> mistaken. How similar are the implementations? > > > > Of `udelay.c`? Besides the register differences it is the same. Sandy > > Bridge (and Haswell) define `fsb` to 100 MHz, where i945 and i5000 use > > 400 MHz and divide it by four later on. i945 and i5000 don't have a constant TSC but need to take the FSB frequency into regard. Not sure about Mobile 4 series. Sandybridge/Ivybridge/Haswell have a fixed frequency TSC. > > As no code has been written yet, I do not know. But judging from the > > three `udelay.c` files I looked at, they should be. > > The delay_tsc.c could be used as the basis for all of these > implementations. I was confusing myself thinking each of these cpus > had the implementation. Not the northbridge. Apparently the gm45 and > i945 serve as the basis for all the memory controller for most of > those cpus. > > So the current intel northbridge chipsets with a delay implementation are: > src/northbridge/intel/gm45 > src/northbridge/intel/i945 > src/northbridge/intel/sandybridge > The gm45 and i945 use the Intel Core architecture with the quad pumped > FSB. Uses msrs 0x198 and MSR_FSB_FREQ. Note that the gm45 has a > ns100delay() function for raminit. The gm45 uses delay.c for romstage > as well as SMM while i945 just uses udelay.c for SMM. The code originally went in on i945 and the reason was that certain delay operations were required to not create any front side bus traffic (interesting, huh?) or random corruption could happen. Of course it is almost impossible to get to that information, and even telling you the mere fact might force me into killing you. Whether this was an issue with any other chipset / CPU after the i945 generation? I don't know. I am happy that haswell was cleaned up to not have that mess. Sandybridge/Ivybridge should/could probably be cleaned up as well. > Sandybridge's udelay for romstage and smm can be converted like > haswell. As for having a seemingly-duplicate copy of a file for > determining tsc freq doesn't bother me all that much. It's small and > self contained. Sometimes components seem very similar. Duplicating code because it happens to be similar hardware (but maybe not, in ways you will never actually know) is not the worst thing that can happen. And if it allows a clean API, we should not worry much. This is not the IOCC or contest for the shortest program, but a matter of how to create a maintainable code base that covers nearly 300 mainboards with a fast paced development team that moves on to the next set of boards every couple of months. Stefan

1 0

Re: [coreboot] Intel: How to share `tsc_freq.c` to select `UDELAY_TSC`
by Peter Stuge 09 May '13

09 May '13

ron minnich wrote: > >> Given that the platforms work, and most of them are obsolete, > >> it's hard to see the virtue in this change. > > > > I disagree. > > Are you going to test every one of the 19 platforms that we're talking > about changing? That's unrelated to seeing virtue, but no, I'm not going to test them all. If I do review I will however do very careful review, as usual. > And if you can't test it, you need to think hard about what you're doing. Absolutely. I actually hold this true for *all* software no matter what. Most developers I see code from think a lot less hard. > > Code reuse where reuse makes sense is one of several things that > > separate coreboot from commercial firmware products, and a very > > worthy goal indeed. > > Well, yes, and I had something to do with that, you may recall :-) Yes of course! > I'm not arguing against reuse. You are arguing against refactoring existing code for increased reuse. > One way is to unify new platforms going forward, and not touch old > ones that can't be tested. Much too conservative. You're essentially arguing against each and every item on http://www.coreboot.org/Infrastructure_Projects > I've had people break things before while 'cleaning it up' and it's not fun. Of course, it's important to be careful with all changes to all code. > far, far harder to work out than the stuff you run into at the > kernel level, and it's best to keep that in mind. All of us have this in mind, already. //Peter

1 0

Re: [coreboot] Intel: How to share `tsc_freq.c` to select `UDELAY_TSC`
by Paul Menzel 09 May '13

09 May '13

Am Mittwoch, den 08.05.2013, 09:07 -0500 schrieb Aaron Durbin: > On Wed, May 8, 2013 at 8:50 AM, Paul Menzel wrote: > > Am Mittwoch, den 08.05.2013, 08:18 -0500 schrieb Aaron Durbin: > > > >> I think what you'll find is that determining this is cpu specific. > > > > understood. > > > >> I'm fairly sure it's not worth trying to generalize it. The > >> implementations are already associated with the chipset/cpu code. Why > >> move them? > > > > Because there would be a lot of copies. 19 if I am not mistaken. > > > > $ ls src/cpu/intel/ > > car model_65x model_f2x socket_mFCPGA478 > > ep80579 model_67x model_f3x socket_mPGA478 > > fit model_68x model_f4x socket_mPGA479M > > haswell model_69x slot_1 socket_mPGA603 > > hyperthreading model_6bx slot_2 socket_mPGA604 > > Kconfig model_6dx socket_441 socket_PGA370 > > Makefile.inc model_6ex socket_BGA956 socket_rPGA989 > > microcode model_6fx socket_FC_PGA370 speedstep > > model_1067x model_6xx socket_LGA771 thermal_monitoring > > model_106cx model_f0x socket_LGA775 turbo > > model_206ax model_f1x socket_mFCBGA479A989 > > > > I guess that is also the reason, why `udelay.c` was put into the > > northbridge code beforehand? > > The reason udelay was put in northbridge was for SMM if I am not > mistaken. How similar are the implementations? Of `udelay.c`? Besides the register differences it is the same. Sandy Bridge (and Haswell) define `fsb` to 100 MHz, where i945 and i5000 use 400 MHz and divide it by four later on. > > For example the `udelay.c` in Sandy Bridge could use the `tsc_freq.c` > > from Haswell. > > I know sandy/ivy and haswell are the same (they happen to use the same > blck). But are all the other ones? And is it 19 copies of the *same* > code? As no code has been written yet, I do not know. But judging from the three `udelay.c` files I looked at, they should be. > What you would be getting rid of is 19 copies of the udelay > logic. Not necessarily the tsc frequency implementation. I was talking > about the latter w.r.t. keeping that code (tsc freq) associated w/ the > chipset/cpu. We can definitely cleanup the tsc udelay copies though. I am still wondering why originally four `udelay.c` were enough and now it has to be done for each CPU model. I think a lot of the CPU models are similar in the TSC regard. Not sure, what I am missing. But let’s rephrase my question then. Assume the code is the same. Where should this file be put at? Thanks, Paul

2 1

Re: [coreboot] Intel: How to share `tsc_freq.c` to select `UDELAY_TSC`
by Peter Stuge 09 May '13

09 May '13

ron minnich wrote: > Given that the platforms work, and most of them are obsolete, it's > hard to see the virtue in this change. I disagree. > It adds the risk of failure for what seems an academic gain in > cleanliness. Code reuse where reuse makes sense is one of several things that separate coreboot from commercial firmware products, and a very worthy goal indeed. Emphasis on makes sense, as always. Ron, I'm surprised that you are arguing against cleaning up code while at the same time saying that the code is too old to care about. If there are almost 20 copies of identical code then that is merely silly copypasting which we should be happy that Paul wants to clean up. As Aaron mentioned it might be one level too deep to unify the TSC code right now, but perhaps there can be some successful unification of some of the copies, and/or compile-time parameterization of the code such that there is less copies of the same code needed, if only some parameters change. It's certainly worth looking into further, with an open mind. //Peter

2 1

Re: [coreboot] Intel: How to share `tsc_freq.c` to select `UDELAY_TSC`
by Paul Menzel 09 May '13

09 May '13

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