This patch fixes the processor name string for Rev F. CPUs. It moves the complete naming functionality to src/cpu/amd/model_fxx/processor_name.c
Signed-off-by: Sven Kapferer skapfere@rumms.uni-mannheim.de ---
The current code sets the processor name string twice for Rev. F CPUs.
In src/cpu/amd/model_fxx/model_fxx_init.c the function amd_set_name_string_f is called first. Several lines later init_processor_name is called which doesn't recognize newer CPUs and actually programs incorrect values, thus overwriting the previously set CPU name. For example, this resulted in identifying an Opteron 2218 as a Turion processor.
This patch removes the amd_set_name_string_f function from src/cpu/amd/model_fxx/model_fxx_init.c and adds support for Rev. F CPUs to src/cpu/amd/model_fxx/processor_name.c as described in the Revision Guide for AMD NPT Family 0Fh Processors, AMD Document ID 33610 Rev 3.00, October 2006.
Regards, - Sven
On Fri, May 04, 2007 at 08:56:20PM +0200, Sven Kapferer wrote:
In src/cpu/amd/model_fxx/model_fxx_init.c the function amd_set_name_string_f is called first. Several lines later init_processor_name is called which doesn't recognize newer CPUs and actually programs incorrect values, thus overwriting the previously set CPU name. For example, this resulted in identifying an Opteron 2218 as a Turion processor.
Confirmed - I have seen that behavior too (X2 cpus being misidentified as Turion when booted with LinuxBIOS).
Thanks, Ward.
* Sven Kapferer skapfere@rumms.uni-mannheim.de [070504 20:56]:
This patch fixes the processor name string for Rev F. CPUs. It moves the complete naming functionality to src/cpu/amd/model_fxx/processor_name.c
Why does REV_F throw out all the old code? Is REV_F always AM2 or newer?
Yes
On 5/4/07, Stefan Reinauer stepan@coresystems.de wrote:
- Sven Kapferer skapfere@rumms.uni-mannheim.de [070504 20:56]:
This patch fixes the processor name string for Rev F. CPUs. It moves the complete naming functionality to src/cpu/amd/model_fxx/processor_name.c
Why does REV_F throw out all the old code? Is REV_F always AM2 or newer?
-- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
yhlu wrote:
Yes
On 5/4/07, Stefan Reinauer stepan@coresystems.de wrote:
- Sven Kapferer skapfere@rumms.uni-mannheim.de [070504 20:56]:
This patch fixes the processor name string for Rev F. CPUs. It moves the complete naming functionality to src/cpu/amd/model_fxx/processor_name.c
Why does REV_F throw out all the old code? Is REV_F always AM2 or newer?
AM2 for Athlons, Socket F (1207) for Opterons and Socket S1g1 for Turions.
Regards, - Sven
Hi Sven,
On Fri, May 04, 2007 at 08:56:20PM +0200, Sven Kapferer wrote:
This patch fixes the processor name string for Rev F. CPUs.
I've just tried this patch on a m57sli-s4 system with an
AMD Athlon 64 X2 3800+(65W) Windsor 2.0GHz 2 x 512KB L2 Cache Socket AM2
and it doesn't help detection for me; the cpu is still listed as a
Mobile AMD Sempron(tm) Processor 3700+
I've attached my cpuinfo output from the proprietary BIOS, and from LB with your patch.
Interestingly enough, the proprietary BIOS gets the model name right, but not the cpu clock frequency (!).
Thoughts?
Thanks, Ward.
* Ward Vandewege ward@gnu.org [070521 21:30]:
I've attached my cpuinfo output from the proprietary BIOS, and from LB with your patch.
Did you set K8_REV_F_SUPPORT=1? Otherwise Sven's patch will not work.
Interestingly enough, the proprietary BIOS gets the model name right, but not the cpu clock frequency (!).
Maybe power now or something?
On Mon, May 21, 2007 at 09:37:28PM +0200, Stefan Reinauer wrote:
- Ward Vandewege ward@gnu.org [070521 21:30]:
I've attached my cpuinfo output from the proprietary BIOS, and from LB with your patch.
Did you set K8_REV_F_SUPPORT=1? Otherwise Sven's patch will not work.
Ah, I did not. I tried adding it to the mainboard Options.lb:
--- Options.lb (revision 2680) +++ Options.lb (working copy) @@ -85,6 +85,7 @@ uses HW_MEM_HOLE_SIZEK uses HW_MEM_HOLE_SIZE_AUTO_INC uses K8_HT_FREQ_1G_SUPPORT +uses K8_REV_F_SUPPORT
uses HT_CHAIN_UNITID_BASE uses HT_CHAIN_END_UNITID_BASE @@ -209,6 +210,9 @@ #Opteron K8 1G HT Support default K8_HT_FREQ_1G_SUPPORT=1
+#Opteron Rev F (DDR2) support +default K8_REV_F_SUPPORT=1 +
But that did not seem to have any effect. Is this the right place?
Interestingly enough, the proprietary BIOS gets the model name right, but not the cpu clock frequency (!).
Maybe power now or something?
Yeah, you're right, that's why that is.
Thanks, Ward.
On Mon, May 21, 2007 at 04:02:07PM -0400, Ward Vandewege wrote:
Ah, I did not. I tried adding it to the mainboard Options.lb:
--- Options.lb (revision 2680) +++ Options.lb (working copy) @@ -85,6 +85,7 @@ uses HW_MEM_HOLE_SIZEK uses HW_MEM_HOLE_SIZE_AUTO_INC uses K8_HT_FREQ_1G_SUPPORT +uses K8_REV_F_SUPPORT
uses HT_CHAIN_UNITID_BASE uses HT_CHAIN_END_UNITID_BASE @@ -209,6 +210,9 @@ #Opteron K8 1G HT Support default K8_HT_FREQ_1G_SUPPORT=1
+#Opteron Rev F (DDR2) support +default K8_REV_F_SUPPORT=1
But that did not seem to have any effect. Is this the right place?
Uhm, never mind that. I was modifying a different source tree than the one I was building :(
It works fine:
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
I'll ack Sven's patch, and submit a patch for the m57sli's Options.lb.
Thanks, Ward.
On Fri, May 04, 2007 at 08:56:20PM +0200, Sven Kapferer wrote:
This patch fixes the processor name string for Rev F. CPUs. It moves the complete naming functionality to src/cpu/amd/model_fxx/processor_name.c
Signed-off-by: Sven Kapferer skapfere@rumms.uni-mannheim.de
Acked-by: Ward Vandewege ward@gnu.org
I've tested this on the m57sli-s4, and it fixes the processor name string (if K8_REV_F_SUPPORT=1 is set in Options.lb).
Thanks, Ward.
* Ward Vandewege ward@gnu.org [070521 22:25]:
On Fri, May 04, 2007 at 08:56:20PM +0200, Sven Kapferer wrote:
This patch fixes the processor name string for Rev F. CPUs. It moves the complete naming functionality to src/cpu/amd/model_fxx/processor_name.c
Signed-off-by: Sven Kapferer skapfere@rumms.uni-mannheim.de
Acked-by: Ward Vandewege ward@gnu.org
I've tested this on the m57sli-s4, and it fixes the processor name string (if K8_REV_F_SUPPORT=1 is set in Options.lb).
Does it make sense to have the code decide during runtime rather than during compile time what to do? REV_F_SUPPORT is somewhat misleading, it should rather say SOCKET_AM2 or SOCKET_WHATEVER_HAS_REV_F_IN_IT to make the decision require less knowledge from people porting boards.
Stefan
Ward Vandewege wrote:
On Fri, May 04, 2007 at 08:56:20PM +0200, Sven Kapferer wrote:
This patch fixes the processor name string for Rev F. CPUs. It moves the complete naming functionality to src/cpu/amd/model_fxx/processor_name.c
Signed-off-by: Sven Kapferer skapfere@rumms.uni-mannheim.de
Acked-by: Ward Vandewege ward@gnu.org
I've tested this on the m57sli-s4, and it fixes the processor name string (if K8_REV_F_SUPPORT=1 is set in Options.lb).
Thanks, Ward.
This is strange, because the compiler option -DK8_REV_F_SUPPORT='1' was already set by including cpu/amd/socket_AM2. I just verified this by compiling the gigabyte board with an svn version that doesn't include your changes to Options.lb
Regards, - Sven
On Tue, May 22, 2007 at 09:15:54AM +0200, Sven Kapferer wrote:
This is strange, because the compiler option -DK8_REV_F_SUPPORT='1' was already set by including cpu/amd/socket_AM2. I just verified this by compiling the gigabyte board with an svn version that doesn't include your changes to Options.lb
Yes, confirmed, YH signalled this too yesterday. My patch is superfluous. Yours should go in though, can someone else review and commit it?
Thanks, Ward.
On Mon, May 21, 2007 at 04:25:45PM -0400, Ward Vandewege wrote:
On Fri, May 04, 2007 at 08:56:20PM +0200, Sven Kapferer wrote:
This patch fixes the processor name string for Rev F. CPUs. It moves the complete naming functionality to src/cpu/amd/model_fxx/processor_name.c
Signed-off-by: Sven Kapferer skapfere@rumms.uni-mannheim.de
Acked-by: Ward Vandewege ward@gnu.org
I've tested this on the m57sli-s4, and it fixes the processor name string.
Can someone commit this please, if there is no objection?
Thanks, Ward.
On Fri, May 25, 2007 at 08:15:06AM -0400, Ward Vandewege wrote:
Can someone commit this please, if there is no objection?
Yep, it's about time. Committed in r2699. Sorry for the delay...
I cannot test the patch, so I hope it doesn't break random stuff ;-) As nobody reported problems so far I think it's ok to commit.
I'll post an additional patch to fix/adapt the copyright header.
Uwe.