On Sat, Feb 26, 2011 at 03:53:43AM +0200, Alex G. wrote:
On 02/26/2011 03:39 AM, xdrudis wrote:
This patch tries to fix compilation when you select EXPERT in make
menuconfig.
HT Frequencies are multiples of 200MHz AFAIK, so there are no 300MHz and
500MHz. I'm not sure why the build
xdrudis wrote:
HT Frequencies are multiples of 200MHz AFAIK, so there are no
300MHz and 500MHz.
..
Oh! You may well be right. All others are multiples of 200 MHz .
Then we should maybe remove 2 #elif in the following code. But I
wonder whether the break in the progression of values
On Sat, Feb 26, 2011 at 04:01:56AM +0200, Alex G. wrote:
On 02/26/2011 03:38 AM, xdrudis wrote:
This is the patch for option B.
You may not be able to test it without my next patch. At least for me
selectiong EXPERT in make menuconfig breaks the build. Next patch fixes it.
I
On Sat, Feb 26, 2011 at 07:17:46PM +0100, Peter Stuge wrote:
xdrudis wrote:
HT Frequencies are multiples of 200MHz AFAIK, so there are no
300MHz and 500MHz.
..
Oh! You may well be right. All others are multiples of 200 MHz .
Then we should maybe remove 2 #elif in the following code.
On Sat, Feb 26, 2011 at 11:22:17PM +0200, Alex G. wrote:
I look at the microcode as simply DIP switches used to configure the IRQ
line on the hardware. If the manual (microcode updates) gives me
erroneous information, then I put the switches back to their initial
position (factory microcode).
The 500MHz and 300MHz are valid HT frequencies
Table 59. Link Frequency Bit Field Encoding
[FreqExt, Link Frequency] Transmitter Clock Frequency
Encoding(MHz)
0_ 200 (default)
0_0001
On 02/27/2011 12:46 AM, xdrudis wrote:
On Sat, Feb 26, 2011 at 11:22:17PM +0200, Alex G. wrote:
I look at the microcode as simply DIP switches used to configure the IRQ
line on the hardware. If the manual (microcode updates) gives me
erroneous information, then I put the switches back to
xdrudis wrote:
This is the patch for option B.
Thanks!
Make patching cpu microcode optional (for experts).
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
Acked-by: Peter Stuge pe...@stuge.se
Committed as r6385 with some whitespace changes and reworded the help
message to try to
This is the patch for option B.
You may not be able to test it without my next patch. At least for me
selectiong EXPERT in make menuconfig breaks the build. Next patch fixes it.
Make patching cpu microcode optional (for experts).
It's been requested to not link update_microcode.c in that case,
This patch tries to fix compilation when you select EXPERT in make menuconfig.
If I select Expert mode in make menuconfig I couldn't compile because
it complained of 2 missing configuration constants. I hope this is
the right solution, but haven't really checked that the related code
in
On 02/26/2011 03:39 AM, xdrudis wrote:
This patch tries to fix compilation when you select EXPERT in make menuconfig.
HT Frequencies are multiples of 200MHz AFAIK, so there are no 300MHz and
500MHz. I'm not sure why the build breaks, and why this fixes it, but I
don't think this is the right
On 02/26/2011 03:38 AM, xdrudis wrote:
This is the patch for option B.
You may not be able to test it without my next patch. At least for me
selectiong EXPERT in make menuconfig breaks the build. Next patch fixes it.
I don't like the wording for the help option. It creates the
On 02/23/2011 03:51 PM, Xavi Drudis Ferran wrote:
Pompous ?
Yes. This is an option for experienced users, and people too smart for
they own sake (pozitive connotation), that value their freedom more than
practicality. They will go to an extra effort to ensure that. Therefore,
considering the
Alex G. wrote:
Is the 'adding a line in Kconfig' option hassle free enough for you?
I just don't see a way to make it obscure enough it menuconfig, but I
won't object if you do find one.
Don't we have an experts option that will enable further options?
//Peter
--
coreboot mailing list:
On Mon, Feb 21, 2011 at 08:44:35AM -0600, Scott Duplichan wrote:
This really isn't relevant, but microcode patch source code
certainly exists, as does source code for the main microcode
that the patch modifies. A microcode assembler converts the
source code into binary form.
I think it's
On 02/22/2011 02:47 AM, Peter Stuge wrote:
Xavi Drudis Ferran wrote:
Does everyone prefer to have it not include update_microcode.c and
change romstage.c in those boards that call update_microcode(...) ?
At least I like this better. It makes it clear what effect this
option has for
On Mon 21/02/11 03:58 , Stefan Reinauer stefan.reina...@coreboot.org wrote:
On 2/19/11 12:45 PM, xdrudis wrote:
On Fri, Feb 18, 2011 at 10:19:31AM -0500, Ward Vandewege wrote:
Hi Xavi,
On Wed, Feb 16, 2011 at 02:45:02PM +0100, Xavi Drudis Ferran
wrote:
Should I send a patch
I've suggested it and got 2 expressions of interest and negative
reaction, so I did it.
Sorry, I meant and no negative reaction.
I'd just add that it's just an option, and I've made the default to update
microcode,
liek it did before, so it has no effect unless you explicity unselect it.
Xavi Drudis Ferran wrote:
Does everyone prefer to have it not include update_microcode.c and
change romstage.c in those boards that call update_microcode(...) ?
At least I like this better. It makes it clear what effect this
option has for mainboard code.
//Peter
--
coreboot mailing list:
On 2/19/11 12:45 PM, xdrudis wrote:
On Fri, Feb 18, 2011 at 10:19:31AM -0500, Ward Vandewege wrote:
Hi Xavi,
On Wed, Feb 16, 2011 at 02:45:02PM +0100, Xavi Drudis Ferran wrote:
Should I send a patch making a Kconfig option to not upgrade microcode
for fam10? Is there any interest
On Fri, Feb 18, 2011 at 10:19:31AM -0500, Ward Vandewege wrote:
Hi Xavi,
On Wed, Feb 16, 2011 at 02:45:02PM +0100, Xavi Drudis Ferran wrote:
Should I send a patch making a Kconfig option to not upgrade microcode for
fam10? Is there any interest in that ?
Yes, please. I would test and
21 matches
Mail list logo
