[patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[Tigran Aivazian]

Second attempt -- the first one got lost due to some local mail client
problems...

---------- Forwarded message ----------
Date: Fri, 1 Dec 2000 11:43:10 +0000 (GMT)
From: Tigran Aivazian <tigran@veritas.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: [patch-2.4.0-test12-pre3] microcode update for P4

Hi Linus,

Here is the patch to microcode update driver to support the new P4
CPU.

Regards,
Tigran

diff -urN -X dontdiff linux/arch/i386/kernel/microcode.c ucode/arch/i386/kernel/microcode.c
--- linux/arch/i386/kernel/microcode.c	Mon Oct 30 22:44:29 2000
+++ ucode/arch/i386/kernel/microcode.c	Fri Dec  1 09:45:47 2000
@@ -4,13 +4,13 @@
  *	Copyright (C) 2000 Tigran Aivazian
  *
  *	This driver allows to upgrade microcode on Intel processors
- *	belonging to P6 family - PentiumPro, Pentium II, 
- *	Pentium III, Xeon etc.
+ *	belonging to IA-32 family - PentiumPro, Pentium II, 
+ *	Pentium III, Xeon, Pentium 4, etc.
  *
- *	Reference: Section 8.10 of Volume III, Intel Pentium III Manual, 
- *	Order Number 243192 or free download from:
+ *	Reference: Section 8.10 of Volume III, Intel Pentium 4 Manual, 
+ *	Order Number 245472 or free download from:
  *		
- *	http://developer.intel.com/design/pentiumii/manuals/243192.htm
+ *	http://developer.intel.com/design/pentium4/manuals/245472.htm
  *
  *	For more information, go to http://www.urbanmyth.org/microcode
  *
@@ -44,6 +44,9 @@
  *		to be 0 on my machine which is why it worked even when I
  *		disabled update by the BIOS)
  *		Thanks to Eric W. Biederman <ebiederman@lnxi.com> for the fix.
+ *	1.08	01 Dec 2000, Richard Schaal <richard.schaal@intel.com> and
+ *			     Tigran Aivazian <tigran@veritas.com>
+ *		Intel P4 processor support.
  */
 
 #include <linux/init.h>
@@ -58,12 +61,20 @@
 #include <asm/uaccess.h>
 #include <asm/processor.h>
 
-#define MICROCODE_VERSION 	"1.07"
+#define MICROCODE_VERSION 	"1.08"
 
-MODULE_DESCRIPTION("Intel CPU (P6) microcode update driver");
+MODULE_DESCRIPTION("Intel CPU (IA-32) microcode update driver");
 MODULE_AUTHOR("Tigran Aivazian <tigran@veritas.com>");
 EXPORT_NO_SYMBOLS;
 
+#define MICRO_DEBUG 0
+
+#if MICRO_DEBUG
+#define Dprintk(x...) printk(##x)
+#else
+#define Dprintk(x...)
+#endif
+
 /* VFS interface */
 static int microcode_open(struct inode *, struct file *);
 static ssize_t microcode_read(struct file *, char *, size_t, loff_t *);
@@ -114,7 +125,10 @@
 		printk(KERN_ERR "microcode: failed to devfs_register()\n");
 		return -EINVAL;
 	}
-	printk(KERN_INFO "P6 Microcode Update Driver v%s\n", MICROCODE_VERSION);
+	printk(KERN_INFO 
+		"IA-32 Microcode Update Driver: v%s <tigran@veritas.com>\n", 
+		MICROCODE_VERSION);
+
 	return 0;
 }
 
@@ -124,12 +138,12 @@
 	devfs_unregister(devfs_handle);
 	if (mc_applied)
 		kfree(mc_applied);
-	printk(KERN_INFO "P6 Microcode Update Driver v%s unregistered\n", 
+	printk(KERN_INFO "IA-32 Microcode Update Driver v%s unregistered\n", 
 			MICROCODE_VERSION);
 }
 
-module_init(microcode_init);
-module_exit(microcode_exit);
+module_init(microcode_init)
+module_exit(microcode_exit)
 
 static int microcode_open(struct inode *unused1, struct file *unused2)
 {
@@ -177,16 +191,18 @@
 
 	req->err = 1; /* assume the worst */
 
-	if (c->x86_vendor != X86_VENDOR_INTEL || c->x86 != 6){
-		printk(KERN_ERR "microcode: CPU%d not an Intel P6\n", cpu_num);
+	if (c->x86_vendor != X86_VENDOR_INTEL || c->x86 < 6 ||
+		test_bit(X86_FEATURE_IA64, &c->x86_capability)){
+		printk(KERN_ERR "microcode: CPU%d not a capable Intel processor\n", cpu_num);
 		return;
 	}
 
 	sig = c->x86_mask + (c->x86_model<<4) + (c->x86<<8);
 
-	if (c->x86_model >= 5) {
-		/* get processor flags from BBL_CR_OVRD MSR (0x17) */
-		rdmsr(0x17, val[0], val[1]);
+	if ((c->x86_model >= 5) || (c->x86 > 6))
+		{
+		/* get processor flags from MSR 0x17 */
+		rdmsr(IA32_PLATFORM_ID, val[0], val[1]);
 		pf = 1 << ((val[1] >> 18) & 7);
 	}
 
@@ -195,13 +211,32 @@
 		    microcode[i].ldrver == 1 && microcode[i].hdrver == 1) {
 
 			found=1;
-			wrmsr(0x8B, 0, 0);
+
+			Dprintk("Microcode\n");
+			Dprintk("   Header Revision %d\n",microcode[i].hdrver);
+			Dprintk("   Date %x/%x/%x\n",
+				((microcode[i].date >> 24 ) & 0xff),
+				((microcode[i].date >> 16 ) & 0xff),
+				(microcode[i].date & 0xFFFF));
+			Dprintk("   Type %x Family %x Model %x Stepping %x\n",
+				((microcode[i].sig >> 12) & 0x3),
+				((microcode[i].sig >> 8) & 0xf),
+				((microcode[i].sig >> 4) & 0xf),
+				((microcode[i].sig & 0xf)));
+			Dprintk("   Checksum %x\n",microcode[i].cksum);
+			Dprintk("   Loader Revision %x\n",microcode[i].ldrver);
+			Dprintk("   Processor Flags %x\n\n",microcode[i].pf);
+
+			/* trick, to work even if there was no prior update by the BIOS */
+			wrmsr(IA32_UCODE_REV, 0, 0);
 			__asm__ __volatile__ ("cpuid" : : : "ax", "bx", "cx", "dx");
-			rdmsr(0x8B, val[0], rev);
+
+			/* get current (on-cpu) revision into rev (ignore val[0]) */
+			rdmsr(IA32_UCODE_REV, val[0], rev);
 			if (microcode[i].rev < rev) {
 				printk(KERN_ERR 
 					"microcode: CPU%d not 'upgrading' to earlier revision"
-					" %d (current=%d)\n", cpu_num, microcode[i].rev, rev);
+					" %x (current=%x)\n", cpu_num, microcode[i].rev, rev);
 			} else if (microcode[i].rev == rev) {
 				printk(KERN_ERR
 					"microcode: CPU%d already up-to-date (revision %d)\n",
@@ -219,9 +254,14 @@
 					break;
 				}
 
-				wrmsr(0x79, (unsigned int)(m->bits), 0);
+				/* write microcode via MSR 0x79 */
+				wrmsr(IA32_UCODE_WRITE, (unsigned int)(m->bits), 0);
+
+				/* serialize */
 				__asm__ __volatile__ ("cpuid" : : : "ax", "bx", "cx", "dx");
-				rdmsr(0x8B, val[0], val[1]);
+
+				/* get the current revision from MSR 0x8B */
+				rdmsr(IA32_UCODE_REV, val[0], val[1]);
 
 				req->err = 0;
 				req->slot = i;
@@ -267,8 +307,8 @@
 		mc_applied = kmalloc(smp_num_cpus*sizeof(struct microcode),
 				GFP_KERNEL);
 		if (!mc_applied) {
-			printk(KERN_ERR "microcode: out of memory for saved microcode\n");
 			up_write(&microcode_rwsem);
+			printk(KERN_ERR "microcode: out of memory for saved microcode\n");
 			return -ENOMEM;
 		}
 	}
diff -urN -X dontdiff linux/include/asm-i386/msr.h ucode/include/asm-i386/msr.h
--- linux/include/asm-i386/msr.h	Thu Oct  7 18:17:09 1999
+++ ucode/include/asm-i386/msr.h	Fri Dec  1 09:38:59 2000
@@ -30,3 +30,7 @@
 			  : "=a" (low), "=d" (high) \
 			  : "c" (counter))
 
+/* symbolic names for some interesting MSRs */
+#define IA32_PLATFORM_ID	0x17
+#define IA32_UCODE_WRITE	0x79
+#define IA32_UCODE_REV		0x8B


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.21.0012011150490.877-100000@penguin.homenet>
By author:    Tigran Aivazian <tigran@veritas.com>
In newsgroup: linux.dev.kernel
>
> Second attempt -- the first one got lost due to some local mail client
> problems...
> 
> Hi Linus,
> 
> Here is the patch to microcode update driver to support the new P4
> CPU.
> 
> --- linux/include/asm-i386/msr.h	Thu Oct  7 18:17:09 1999
> +++ ucode/include/asm-i386/msr.h	Fri Dec  1 09:38:59 2000
> @@ -30,3 +30,7 @@
>  			  : "=a" (low), "=d" (high) \
>  			  : "c" (counter))
>  
> +/* symbolic names for some interesting MSRs */
> +#define IA32_PLATFORM_ID	0x17
> +#define IA32_UCODE_WRITE	0x79
> +#define IA32_UCODE_REV		0x8B
> 

Please call these MSR_* instead, "IA32_*" isn't very descriptive,
besides, the preferred prefix in existing locations in the Linux
kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE.  I think there
are standard symbolic names for most MSRs in volume 3 of the Intel
processor manuals; I would suggest we use those.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[Alan Cox]

> Please call these MSR_* instead, "IA32_*" isn't very descriptive,
> besides, the preferred prefix in existing locations in the Linux
> kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE.  I think there

I think I agree with Tigran's naming. These are IA32 registers not X86 ones ;)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[Tigran Aivazian]

On 1 Dec 2000, H. Peter Anvin wrote:
> > +/* symbolic names for some interesting MSRs */
> > +#define IA32_PLATFORM_ID	0x17
> > +#define IA32_UCODE_WRITE	0x79
> > +#define IA32_UCODE_REV		0x8B
> > 
> 
> Please call these MSR_* instead, "IA32_*" isn't very descriptive,
> besides, the preferred prefix in existing locations in the Linux
> kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE.  I think there
> are standard symbolic names for most MSRs in volume 3 of the Intel
> processor manuals; I would suggest we use those.
                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~

which is exactly what I did. The old name for 0x17 was something like
BBL_CR_OVRD which had absolutely no meaning (or no meaning that I could
discern) so in the past I use just the number 0x17. Now (see P4 manuals,
already on developer.intel.com) they renamed to a very meaningful
IA32_PLATFORM_ID so I used that one. It is more important to match the
naming of the original specs than to be consistent with other naming used
in the kernel. To prove this point I suggest you look at NFSv2/NFSv3
naming used in the Linux kernel -- it matches rfc1094/rfc1813 which I
liked very much because it simplified reading kernel code (I assume
everyone first studies the specs and then reads Linux implementation).

Now that was about 0x17. As for 0x79 and 0x8B I made up my own names using
the Intel's one for 0x17 as a guideline. So they "look just like" as if
they were from the manual too ;) (and they are meaningful, which is a
bonus)

I am also glad Alan agrees with me.

Regards,
Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[H. Peter Anvin]

Alan Cox wrote:
> 
> > Please call these MSR_* instead, "IA32_*" isn't very descriptive,
> > besides, the preferred prefix in existing locations in the Linux
> > kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE.  I think there
> 
> I think I agree with Tigran's naming. These are IA32 registers not X86 ones ;)

They are MSRs, most of all.  His naming didn't reflect that, and quite
frankly, I'd much rather use the names (all starting with MSR_) that the
Intel documentation uses.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[H. Peter Anvin]

Tigran Aivazian wrote:
> 
> On Sat, 2 Dec 2000, H. Peter Anvin wrote:
> 
> > Alan Cox wrote:
> > >
> > > > Please call these MSR_* instead, "IA32_*" isn't very descriptive,
> > > > besides, the preferred prefix in existing locations in the Linux
> > > > kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE.  I think there
> > >
> > > I think I agree with Tigran's naming. These are IA32 registers not X86 ones ;)
> >
> > They are MSRs, most of all.  His naming didn't reflect that, and quite
> > frankly, I'd much rather use the names (all starting with MSR_) that the
> > Intel documentation uses.
> >
> 
> Peter,
> 
> you probably missed the message I sent to you earlier. I have already
> explained that I did use the names which Intel documentation uses. You may
> have an old (Pentium III) version of the manual but the current
> (P4) is already available (albeit a preliminary) and that is what I used
> as a guidance.
> 
> It makes sense to check the facts before stating the same wrong statement
> twice.
> 

OK, fair enough.  Let me make a new statement then: I suggest we preface
these with MSR_ anyway so we can tell what they really are.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[H. Peter Anvin]

Tigran Aivazian wrote:
> 
> On Sat, 2 Dec 2000, H. Peter Anvin wrote:
> >
> > OK, fair enough.  Let me make a new statement then: I suggest we preface
> > these with MSR_ anyway so we can tell what they really are.
> >
> 
> That is much better. Actually, I accept your suggestion. (because I have
> just found a few more cleanups to be done in the code but they were not
> worth a patch on their own but together with the above it is worth
> remaking the patch).
> 
> So, unless Linus already applied it I will resend a new one to him
> shortly.
> 
> Regards,
> Tigran
> 
> PS. Btw, the proof of my statement is found at:
> 
> http://developer.intel.com/design/pentium4/manuals/245472.htm
> 
> and download the PDF, then read the section 8.11.1 on page 8-32.

I believe you :)  Pardon me now, I have a foot to get unstuck from this
here mouth of mine...

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[H. Peter Anvin]

Tigran Aivazian wrote:
> 
> On Sat, 2 Dec 2000, Tigran Aivazian wrote:
> 
> > On Sat, 2 Dec 2000, H. Peter Anvin wrote:
> > >
> > > OK, fair enough.  Let me make a new statement then: I suggest we preface
> > > these with MSR_ anyway so we can tell what they really are.
> > >
> >
> > That is much better. Actually, I accept your suggestion.
> 
> on the other hand -- that makes them much longer and it is always obvious
> from the context what they are, i.e.:
> 
> a) if they appear in the code then it is unlikely they are outside of
> rdmsr()/wrmsr() which makes their meaning obvious.
> 
> b) if they are in the header, the name of the header asm/msr.h and the
> comment above their definition explains what they are.
> 
> I don't know -- if people really think MSR_ is needed then it can be
> done.
> 
> I think my intuitive IA32_ naming was adequate but if you really believe
> we should prefix it with MSR_ then so be it.
> 

I really think so... after all, it might be obvious when you use them in
the correct context, but it definitely isn't obvious when you're using
them in the wrong context.  I am also worried about namespace collisions
doing back things.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

[patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[Tigran Aivazian]

Second attempt. The linux-kernel list is broken at the moment (reported
fault to postmaster already) so some messages get lost at random:


---------- Forwarded message ----------
Date: Sat, 2 Dec 2000 21:49:21 +0000 (GMT)
From: Tigran Aivazian <tigran@veritas.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org

diff -urN -X dontdiff linux/CREDITS ucode/CREDITS
--- linux/CREDITS	Fri Dec  1 15:44:03 2000
+++ ucode/CREDITS	Fri Dec  1 15:47:23 2000
@@ -41,7 +41,7 @@
 E: tigran@veritas.com
 W: http://www.ocston.org/~tigran
 D: BFS filesystem
-D: Intel P6 CPU microcode update support
+D: Intel IA32 CPU microcode update support
 D: Various kernel patches
 S: United Kingdom
 
diff -urN -X dontdiff linux/Documentation/Changes ucode/Documentation/Changes
--- linux/Documentation/Changes	Thu Oct 26 21:49:15 2000
+++ ucode/Documentation/Changes	Fri Dec  1 15:47:23 2000
@@ -185,10 +185,10 @@
 kernel source.  Pay attention when you recompile your kernel ;-).
 Also, be sure to upgrade to the latest pcmcia-cs release.
 
-Intel P6 microcode
-------------------
+Intel IA32 microcode
+--------------------
 
-A driver has been added to allow updating of Intel P6 microcode,
+A driver has been added to allow updating of Intel IA32 microcode,
 accessible as both a devfs regular file and as a normal (misc)
 character device.  If you are not using devfs you may need to:
 
@@ -198,6 +198,13 @@
 
 as root before you can use this.  You'll probably also want to
 get the user-space microcode_ctl utility to use with this.
+
+If you have compiled the driver as a module you may need to add
+the following line:
+
+alias char-major-10-184 microcode
+
+to your /etc/modules.conf file.
 
 Networking
 ==========
diff -urN -X dontdiff linux/Documentation/Configure.help ucode/Documentation/Configure.help
--- linux/Documentation/Configure.help	Fri Dec  1 15:44:03 2000
+++ ucode/Documentation/Configure.help	Fri Dec  1 15:47:23 2000
@@ -13427,13 +13427,13 @@
   Toshiba Linux utilities website at:
   http://www.buzzard.org.uk/toshiba/
 
-/dev/cpu/microcode - Intel P6 CPU microcode support
+/dev/cpu/microcode - Intel IA32 CPU microcode support
 CONFIG_MICROCODE
   If you say Y here and also to "/dev file system support" in the
   'File systems' section, you will be able to update the microcode on
-  Intel processors in the P6 family, e.g. Pentium Pro, Pentium II,
-  Pentium III, Xeon etc. You will obviously need the actual microcode
-  binary data itself which is not shipped with the Linux kernel.
+  Intel processors in the IA32 family, e.g. Pentium Pro, Pentium II,
+  Pentium III, Pentium 4, Xeon etc. You will obviously need the actual 
+  microcode binary data itself which is not shipped with the Linux kernel.
 
   For latest news and information on obtaining all the required
   ingredients for this driver, check:
@@ -13442,7 +13442,9 @@
   This driver is also available as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want).
   The module will be called microcode.o. If you want to compile it as
-  a module, say M here and read Documentation/modules.txt.
+  a module, say M here and read Documentation/modules.txt. If you use
+  modprobe or kmod you may also want to add the line
+  'alias char-major-10-184 microcode' to your /etc/modules.conf file.
 
 /dev/cpu/*/msr - Model-specific register support
 CONFIG_X86_MSR
diff -urN -X dontdiff linux/Documentation/ioctl-number.txt ucode/Documentation/ioctl-number.txt
--- linux/Documentation/ioctl-number.txt	Mon Jun 19 20:56:07 2000
+++ ucode/Documentation/ioctl-number.txt	Fri Dec  1 15:47:23 2000
@@ -74,8 +74,8 @@
 0x22	all	scsi/sg.h
 '1'	00-1F	<linux/timepps.h>	PPS kit from Ulrich Windl
 					<ftp://ftp.de.kernel.org/pub/linux/daemons/ntp/PPS/>
-'6'	00-10	<asm-i386/processor.h>	Intel P6 microcode update driver
-					<tigran@veritas.com>
+'6'	00-10	<asm-i386/processor.h>	Intel IA32 microcode update driver
+					<mailto:tigran@veritas.com>
 '8'	all				SNP8023 advanced NIC card
 					<mailto:mcr@solidum.com>
 'A'	00-1F	linux/apm_bios.h
diff -urN -X dontdiff linux/MAINTAINERS ucode/MAINTAINERS
--- linux/MAINTAINERS	Fri Dec  1 15:44:04 2000
+++ ucode/MAINTAINERS	Fri Dec  1 15:47:23 2000
@@ -633,7 +633,7 @@
 W:	http://sourceforge.net/projects/gkernel/
 S:	Maintained
 
-INTEL P6 MICROCODE UPDATE SUPPORT
+INTEL IA32 MICROCODE UPDATE SUPPORT
 P:	Tigran Aivazian
 M:	tigran@veritas.com
 S:	Maintained
diff -urN -X dontdiff linux/arch/i386/kernel/microcode.c ucode/arch/i386/kernel/microcode.c
--- linux/arch/i386/kernel/microcode.c	Mon Oct 30 22:44:29 2000
+++ ucode/arch/i386/kernel/microcode.c	Sat Dec  2 20:46:49 2000
@@ -4,13 +4,13 @@
  *	Copyright (C) 2000 Tigran Aivazian
  *
  *	This driver allows to upgrade microcode on Intel processors
- *	belonging to P6 family - PentiumPro, Pentium II, 
- *	Pentium III, Xeon etc.
+ *	belonging to IA-32 family - PentiumPro, Pentium II, 
+ *	Pentium III, Xeon, Pentium 4, etc.
  *
- *	Reference: Section 8.10 of Volume III, Intel Pentium III Manual, 
- *	Order Number 243192 or free download from:
+ *	Reference: Section 8.10 of Volume III, Intel Pentium 4 Manual, 
+ *	Order Number 245472 or free download from:
  *		
- *	http://developer.intel.com/design/pentiumii/manuals/243192.htm
+ *	http://developer.intel.com/design/pentium4/manuals/245472.htm
  *
  *	For more information, go to http://www.urbanmyth.org/microcode
  *
@@ -44,6 +44,9 @@
  *		to be 0 on my machine which is why it worked even when I
  *		disabled update by the BIOS)
  *		Thanks to Eric W. Biederman <ebiederman@lnxi.com> for the fix.
+ *	1.08	01 Dec 2000, Richard Schaal <richard.schaal@intel.com> and
+ *			     Tigran Aivazian <tigran@veritas.com>
+ *		Intel P4 processor support.
  */
 
 #include <linux/init.h>
@@ -58,12 +61,20 @@
 #include <asm/uaccess.h>
 #include <asm/processor.h>
 
-#define MICROCODE_VERSION 	"1.07"
+#define MICROCODE_VERSION 	"1.08"
 
-MODULE_DESCRIPTION("Intel CPU (P6) microcode update driver");
+MODULE_DESCRIPTION("Intel CPU (IA-32) microcode update driver");
 MODULE_AUTHOR("Tigran Aivazian <tigran@veritas.com>");
 EXPORT_NO_SYMBOLS;
 
+#define MICRO_DEBUG 0
+
+#if MICRO_DEBUG
+#define Dprintk(x...) printk(##x)
+#else
+#define Dprintk(x...)
+#endif
+
 /* VFS interface */
 static int microcode_open(struct inode *, struct file *);
 static ssize_t microcode_read(struct file *, char *, size_t, loff_t *);
@@ -99,23 +110,27 @@
 
 static int __init microcode_init(void)
 {
-	int error = 0;
+	int error;
 
-	if (misc_register(&microcode_dev) < 0) {
+	error = misc_register(&microcode_dev);
+	if (error)
 		printk(KERN_WARNING 
 			"microcode: can't misc_register on minor=%d\n",
 			MICROCODE_MINOR);
-		error = 1;
-	}
+
 	devfs_handle = devfs_register(NULL, "cpu/microcode",
 			DEVFS_FL_DEFAULT, 0, 0, S_IFREG | S_IRUSR | S_IWUSR, 
 			&microcode_fops, NULL);
 	if (devfs_handle == NULL && error) {
 		printk(KERN_ERR "microcode: failed to devfs_register()\n");
-		return -EINVAL;
+		goto out;
 	}
-	printk(KERN_INFO "P6 Microcode Update Driver v%s\n", MICROCODE_VERSION);
-	return 0;
+	printk(KERN_INFO 
+		"IA-32 Microcode Update Driver: v%s <tigran@veritas.com>\n", 
+		MICROCODE_VERSION);
+
+out:
+	return error;
 }
 
 static void __exit microcode_exit(void)
@@ -124,12 +139,12 @@
 	devfs_unregister(devfs_handle);
 	if (mc_applied)
 		kfree(mc_applied);
-	printk(KERN_INFO "P6 Microcode Update Driver v%s unregistered\n", 
+	printk(KERN_INFO "IA-32 Microcode Update Driver v%s unregistered\n", 
 			MICROCODE_VERSION);
 }
 
-module_init(microcode_init);
-module_exit(microcode_exit);
+module_init(microcode_init)
+module_exit(microcode_exit)
 
 static int microcode_open(struct inode *unused1, struct file *unused2)
 {
@@ -177,16 +192,17 @@
 
 	req->err = 1; /* assume the worst */
 
-	if (c->x86_vendor != X86_VENDOR_INTEL || c->x86 != 6){
-		printk(KERN_ERR "microcode: CPU%d not an Intel P6\n", cpu_num);
+	if (c->x86_vendor != X86_VENDOR_INTEL || c->x86 < 6 ||
+		test_bit(X86_FEATURE_IA64, &c->x86_capability)){
+		printk(KERN_ERR "microcode: CPU%d not a capable Intel processor\n", cpu_num);
 		return;
 	}
 
 	sig = c->x86_mask + (c->x86_model<<4) + (c->x86<<8);
 
-	if (c->x86_model >= 5) {
-		/* get processor flags from BBL_CR_OVRD MSR (0x17) */
-		rdmsr(0x17, val[0], val[1]);
+	if ((c->x86_model >= 5) || (c->x86 > 6)) {
+		/* get processor flags from MSR 0x17 */
+		rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
 		pf = 1 << ((val[1] >> 18) & 7);
 	}
 
@@ -195,9 +211,28 @@
 		    microcode[i].ldrver == 1 && microcode[i].hdrver == 1) {
 
 			found=1;
-			wrmsr(0x8B, 0, 0);
+
+			Dprintk("Microcode\n");
+			Dprintk("   Header Revision %d\n",microcode[i].hdrver);
+			Dprintk("   Date %x/%x/%x\n",
+				((microcode[i].date >> 24 ) & 0xff),
+				((microcode[i].date >> 16 ) & 0xff),
+				(microcode[i].date & 0xFFFF));
+			Dprintk("   Type %x Family %x Model %x Stepping %x\n",
+				((microcode[i].sig >> 12) & 0x3),
+				((microcode[i].sig >> 8) & 0xf),
+				((microcode[i].sig >> 4) & 0xf),
+				((microcode[i].sig & 0xf)));
+			Dprintk("   Checksum %x\n",microcode[i].cksum);
+			Dprintk("   Loader Revision %x\n",microcode[i].ldrver);
+			Dprintk("   Processor Flags %x\n\n",microcode[i].pf);
+
+			/* trick, to work even if there was no prior update by the BIOS */
+			wrmsr(MSR_IA32_UCODE_REV, 0, 0);
 			__asm__ __volatile__ ("cpuid" : : : "ax", "bx", "cx", "dx");
-			rdmsr(0x8B, val[0], rev);
+
+			/* get current (on-cpu) revision into rev (ignore val[0]) */
+			rdmsr(MSR_IA32_UCODE_REV, val[0], rev);
 			if (microcode[i].rev < rev) {
 				printk(KERN_ERR 
 					"microcode: CPU%d not 'upgrading' to earlier revision"
@@ -219,9 +254,14 @@
 					break;
 				}
 
-				wrmsr(0x79, (unsigned int)(m->bits), 0);
+				/* write microcode via MSR 0x79 */
+				wrmsr(MSR_IA32_UCODE_WRITE, (unsigned int)(m->bits), 0);
+
+				/* serialize */
 				__asm__ __volatile__ ("cpuid" : : : "ax", "bx", "cx", "dx");
-				rdmsr(0x8B, val[0], val[1]);
+
+				/* get the current revision from MSR 0x8B */
+				rdmsr(MSR_IA32_UCODE_REV, val[0], val[1]);
 
 				req->err = 0;
 				req->slot = i;
@@ -267,8 +307,8 @@
 		mc_applied = kmalloc(smp_num_cpus*sizeof(struct microcode),
 				GFP_KERNEL);
 		if (!mc_applied) {
-			printk(KERN_ERR "microcode: out of memory for saved microcode\n");
 			up_write(&microcode_rwsem);
+			printk(KERN_ERR "microcode: out of memory for saved microcode\n");
 			return -ENOMEM;
 		}
 	}
diff -urN -X dontdiff linux/include/asm-i386/msr.h ucode/include/asm-i386/msr.h
--- linux/include/asm-i386/msr.h	Thu Oct  7 18:17:09 1999
+++ ucode/include/asm-i386/msr.h	Sat Dec  2 20:18:07 2000
@@ -30,3 +30,7 @@
 			  : "=a" (low), "=d" (high) \
 			  : "c" (counter))
 
+/* symbolic names for some interesting MSRs */
+#define MSR_IA32_PLATFORM_ID	0x17
+#define MSR_IA32_UCODE_WRITE	0x79
+#define MSR_IA32_UCODE_REV	0x8B
diff -urN -X dontdiff linux/include/asm-i386/processor.h ucode/include/asm-i386/processor.h
--- linux/include/asm-i386/processor.h	Sun Nov 19 04:56:59 2000
+++ ucode/include/asm-i386/processor.h	Fri Dec  1 15:50:01 2000
@@ -464,7 +464,8 @@
 	unsigned int bits[500];
 };
 
-#define MICROCODE_IOCFREE	_IO('6',0) /* because it is for P6 */
+/* '6' because it used to be for P6 only (but now covers P4 as well) */
+#define MICROCODE_IOCFREE	_IO('6',0)
 
 /* REP NOP (PAUSE) is a good thing to insert into busy-wait loops. */
 extern inline void rep_nop(void)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[Matti Aarnio]

On Sat, Dec 02, 2000 at 10:11:28PM +0000, Tigran Aivazian wrote:
> Second attempt. The linux-kernel list is broken at the moment (reported
> fault to postmaster already) so some messages get lost at random:

   Tigran has local problems with his outgoing email.
   Nothing to do with vger.kernel.org.

   His email didn't make it out from his machine to some ISP outgoing relay.
   Looks like he dialed using ISP2, but the relay he used was at ISP1.
   Quite naturally that fails.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

[Tigran Aivazian]

On Sun, 3 Dec 2000, Matti Aarnio wrote:

> On Sat, Dec 02, 2000 at 10:11:28PM +0000, Tigran Aivazian wrote:
> > Second attempt. The linux-kernel list is broken at the moment (reported
> > fault to postmaster already) so some messages get lost at random:
> 
>    Tigran has local problems with his outgoing email.
>    Nothing to do with vger.kernel.org.
> 
>    His email didn't make it out from his machine to some ISP outgoing relay.
>    Looks like he dialed using ISP2, but the relay he used was at ISP1.
>    Quite naturally that fails.

Yes, Matti is right. Although there are no ISP1 and ISP2. There is just
ISP1 (btconnect.com) and it is broken, i.e. the smtp server which sendmail
discovers is wrong. So I manually set pine(1) to use mail.btconnect.com
and that works.

Regards,
Tigran





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/