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/
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/
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
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
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
* 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
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
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
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
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.
Thanks,
Paul
