Archived from groups: alt.comp.periphs.mainboard.asus (
More info?)
"Paul" <nospam@needed.com> wrote in message
news:nospam-0109042305440001@192.168.1.177...
> In article <tivZc.542828$Gx4.155564@bgtnsc04-news.ops.worldnet.att.net>,
> "Ron Reaugh" <rondashreaugh@att.net> wrote:
>
> Answers inline:
>
> First of all, it should be pretty obvious I don't know very much about
> this topic.
Way more than I do and more than anyone else that has stepped forward so
far.
>Otherwise I would have "spilled the beans" by now.
> I believe in a previous search, I couldn't find any Intel docs on
> the subject, and that is how it should be anyway
Less knowledge
> in the hands of hackers, means less problems for end users.
I figured that angle but MS+Intel have now brought the issue front and
center.
> > Ok so during BIOS init a Intel CPU has encrypted microcode loaded into
the
> > CPU. That microcode depends on exactly which CPU model is present.
> >
> All I can remember, is someone suggesting you could blindly load
> one 2KB segment after another, and microcode segments that didn't
> match would be ignored. Based on the fact that the Intel utility
> returns a "CPU_version" field, that corresponds to the revision
> level of the microcode, in fact proves there is more to the
> interface than complete blindness. It does imply, that if the BIOS
> loads revision "N", the update.sys could check the Windows bundled
> revision and load it, if the revision is a later one. I have no
> idea as to exactly when the processor stops accepting candidates for
> "final microcode".
>
> > Does that microcode load happen during Ctl-Alt-Del?
> >
> > Does that microcode load happen during reset button or only at power-up
> > time?
> My guess would be that, while a reset wouldn't necessarily wipe
> out the microstore, a prudent BIOS algorithm would be to reload it.
>
> >
> > Does which microcode version page?/module? gets loaded also depend on
CPU
> > stepping?
> No concrete documentation - just a lot of unsubstantiated guesses.
> A typical Asus BIOS has (8) 2KB microcode segments, so any algorithm
> you can think of is feasible. I have seen BIOS with more than that.
>
> >
> > Does the BIOS that one flashes to the mobo contain all the possible CPU
> > microcode pages?/modules? for all the possible CPUs and all the
steppings
> > that the particular motherboard can handle OR does it depend on what CPU
is
> > in the mobo's socket when the BIOS is flashed?
> The microcode segments provided should be cumulative, unless the flash
> EEPROM is running out of space. I think the practice is to nuke the
> motherboard logo, to make room, if new code takes too much space.
> As you use later BIOS releases, the microcode file in the BIOS should
> grow.
>
> >
> > Depending on the answer, might it be a requirement to flash a mobo BIOS
> > each time the CPU is changed and/or might that imply that there are a
whole
> > bunch of different microcode pages?/modules? within the BIOS and
accounting
> > for much of its size?
> Microcode takes a tiny portion of the BIOS. The revision of BIOS required,
> should only have to be high enough, to get microcode when the processor
> is introduced. If you purchase a processor that was just recently
> introduced by Intel, then flashing the BIOS can be necessary just to get
> code to deal with the new processor - for example, the bug where a
> 3.2GHz Prescott is recognized as a 2.8GHz, requires code to read the
> platform bit and set up the processor some how, based on that bit. That
> is not microcode, but a difference in processor interface itself. So,
> getting that piece of code is one part of the solution, and the
> microcode in that case, was introduced before that bug was known
> and fixed.
>
> I have seen BIOS, with two microcode segments for the same family
> code, but different revision levels. Either that is a packaging error,
> or implies there is some finer granularity in the microcode than I
> know about. When that happens, generally it only happens for one
> particular family code, and not all of them, which suggests it could
> be clumsy packaging.
>
> >
> > With respect to the SP2+Prescott+865/875 issue the reason for the
ambiguity
> > about whether CPU revision=7 or =8 is needed has been apparently
answered.
> > =7 is sufficient for Prescotts of a given set of steppings and =8 is
> > sufficent for other steppings of Prescott CPUs. =9 microcode is
present in
> > some BIOSs.
>
> Considering the number of processors out there, isn't it time
> Microsoft issued their own info, as to exactly what is required ?
Somebody obviously needs to. The Prescott+865/875+SP2 issue was known by
mid-June and likely much earlier but the mobo mfgs seem to have been caught
by surprise as did MS so appear. That's the part I can't figure.
> Experimenting one processor type at a time, is a lot of unnecessary
> work. Has Microsoft admitted to the problem, or is the Cari
> "community" entry in the KB
I am unaware of any MS KB articles on this issue.
> the only evidence that the problem is
> known ?
Cari is a connected MVP apparently. It was very curious in that the
carefully worded extreme minimum was posted in the microsoft.public.....
NGs AND they never answered most all my questions...ergo I end up here
bugging you as no one else is talkin. My opening post here on this issue
was also posted to a number of other NGs and basically your answer is the
only one with any content.
Cari's posts(thread) did point to some Web forums where Cari did post a more
complete version of what MS & Intel had said in an email(still minimal). So
to that extent MS has recognized the issue. MS has NOT admitted that the
real bug is apparently in their SP2 version of update.sys as they only talk
about deficient mobo BIOS microcode but also quietly mention that renaming
update.sys fixes the issue for Prescotts regardless of microcode version and
then even more quietly mentioning that if you want to use SP1's update.sys
that works too.
Since Cari's posts another MS MVP(cquirke
(http://cquirke.mvps.org/sp2intel.htm)) has some threads on the issue
including some details about the stepping vs microcode needed for
Prescott+SP2. None respond to follow-up questions. It was fairly clear
that Cari was at her peter principle limit on the issue but cquirke either
has a fast learning curve and good learning resources OR already had a
considerable knowledge in this arena.
> While we are on the topic of microcode, I notice that my tool set
> doesn't work properly with the new P5AD2 board with 1MB flash chip.
> So, it will be a little difficult to provide this info for the
> latest 915/925 boards. A guess would be that the microcode file
> format in the new BIOS has changed again. Here is a previous
> effort to document it:
>
>
http://groups.google.com/groups?threadm=f1b266c9.0302161254.26380e62%40posting.google.com
>
> Paul
Facebook
Twitter
Instagram