public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Danny van Dyk <kugelfang@gentoo.org>
To: linux-kernel@vger.kernel.org
Subject: [RFC] Microcode Update Driver for AMD K8 CPUs
Date: Sun, 15 Aug 2004 17:48:48 +0200	[thread overview]
Message-ID: <411F85E0.70707@gentoo.org> (raw)

Hi @ all!

[First of all, please CC me on all responses as I am not subscribed to 
lkml. Thanx in advance.]

I recently found some piece of code [1] to perform a microcode update on 
AMD's K8 CPUs. It included some update blocks hardcoded into the module.

gregkh pointed out that this is no good style and that the module should 
rather use /dev/microcode to provide the kernel with the latest ucode block.


Therefore I rewrote the module to do it similar to the i386 Intel 
microcode update code. The update block gets written to /dev/microcode. 
The k8_ucode_write() function does nothing but copying the data from 
userspace to kernelspace, using means to avoid multiple concurrent 
writes. After that, the userspace application performs the 
K8_IOCTL_UCODE_UPDATE ioctl(). This starts the update process for each 
cpu, checking that the update block is valid and checks for all cpus if 
their cpuid matches the header's cpuid.

You will find the latest version of the module here [2]. Further it 
_should_ now be SMP safe; should meaning that I had no chance/no 
hardware to test it on.


However, I still experience one bug concerning the first update to be 
performed after loading the module:

The module holds a pointer to a 960 bytes large buffer, holding the 
actual update block. This buffer gets memset'ed with the pattern 
0xA0A0A0A0. When the module's write operation gets used the first time, 
copy_from_user _definitely_ returns 0, telling me that all the 960 bytes 
have been written to the buffer. On the other side, when performing the 
ioctl to start the update, the module tells me that the signature is not 
0x00aaaaaa as expected for a valid update, but rather the same pattern 
which was written into the empty buffer at the beginning. Even stranger 
is, that the same thing then works for all the following calls to the 
update application. Have I misunderstood the copy_from_user() function 
and its return value ? Or is that a bug ?


The process of updating the microcode is rather simple - at least 
compared to the things the i386 driver does. To start it, you need
a block of 960 bytes containing the update block (I extracted 2 blocks 
from the bios update for my ASUS K8V MoBo). This block consists of a 64 
byte long header and a 896 byte long data block. The header contains - 
among other things - the signature 0x00AAAAAA and a 32bit checksum. That 
checksum gets computed by just makeing a sum of all words in the data block.
Performing a msr call with the adress of this updata block in edx:eax 
and the magic 0xC0010020 in ecx starts the actual update.


Please tell me what you think about this. Ah, and Greg mentioned some 
problems with my coding style. Would someone please tell me what I did 
wrong ? ;-)

Danny

[1] 
http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=2527&Thread=1&entryID=35446&roomID=11
[2] http://dev.gentoo.org/~kugelfang/k8-ucode/

-- 
Danny van Dyk
Gentoo/AMD64 Developer
kugelfang@gentoo.org

             reply	other threads:[~2004-08-15 15:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-15 15:48 Danny van Dyk [this message]
     [not found] <2tvqK-3rv-7@gated-at.bofh.it>
2004-08-15 20:58 ` [RFC] Microcode Update Driver for AMD K8 CPUs Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2004-08-16  1:24 richard.brunner
2004-08-16 12:57 ` Danny van Dyk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=411F85E0.70707@gentoo.org \
    --to=kugelfang@gentoo.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox