[coreboot] Microcode problem with Braswell CPU

Zoran Stojsavljevic zoran.stojsavljevic at gmail.com
Tue Jul 26 09:27:40 CEST 2016


Hello Alex,

I am not actively working for INTEL anymore (as my Linkedin profile
suggests). For couple more months, my written agreement with them will come
to the end, since we have some agreement in place for quite a while. I'll
update my profile with the end date accordingly, when time comes. Here and
everywhere else on the net, I speak only out of my IT experience/myself, so
this has nothing to do with INTEL. In other words, opinions I write here
are strictly mine, based on open net, open source, white paper documents
and public data from INTEL, AMD and other companies.

There are other INTEL people watching this thread, so they might expedite
your IPS/Sales Force case #. Good luck with that.

ATOM released wise, I was not too much involved with BSW (much more with
BYT), so I have no idea if this what support suggested is correct, but it
is (at least) worth trying.

Please, do note the following:
http://www.anandtech.com/show/9806/intel-introduces-new-braswell-stepping-with-j3060-j3160-and-j3710

Namely (excerpt from the article): *The Braswell update is a new stepping
which adjusts the power consumption of the cores, raising the frequency,
raising the TDP of the Pentium variants for a larger product separation,
and renaming both the processor itself and the HD Graphics implementation.
This change is referred to in the documentation as moving from the
C-stepping to the D-stepping, which typically co-incides with a change in
the way these processors are made (adjusted metal layer arrangement or
lithography mask update).*

Not sure how many D steppings are out there, you should ask/verify with
support.

I myself now inspected ./src/include/console/post_codes.h, and there is no
0x52 post code per say. This is why I asked several times PED FSP team to
update/document non existent FSP post codes, so you all Coreboot-ers can
have more clear picture what is going on with FSP boot, stages wise. :-)

Considering the latest you wrote, there are two files you also need to
inspect:
src/cpu/intel/microcode/microcode.c
src/include/cpu/intel/microcode.h

Sincerely hope (some of) this helps,
Zoran

On Tue, Jul 26, 2016 at 8:04 AM, Alexander Böcken <
Alexander.Boecken at junger-audio.com> wrote:

> Hi Zoran,
>
>
>
> thanks for checking back. I’m still on the issue (next to some other
> things), but haven’t made any progress yet. I also opened up a case at
> Intel Premier Support and tried to follow their suggestions (Case 00053422).
>
>
>
> Anyway, I know the post_codes.h file. It defines POST_FSP_TEMP_RAM_INIT
> (0x90) which is the post code shown by coreboot just before it calls
> TempRamInit. Then TempRamInit shows 0x52. Intel suggested that this is a
> microcode problem (i.e. the microcode doesn’t match the CPU stepping or
> platform), however, I’m pretty sure that this is not the case. At least
> I’ve taken a look at the CPUID signature (which is 0x406C4) and the
> microcode header signature (which is 0x406C4). I also compared the platform
> ID bits from MSR 0x17 (which are 000, i.e. 1 << 000 = 1) with  the platform
> ID field of the microcode (which is also 1). The microcode update
> facilities are documented in Intel’s System Programming Guide (#325384).
>
>
>
> I’m currently checking if coreboot is able to update the microcode while
> still in bootblock. There is a call to intel_update_microcode_from_cbfs()
> in /src/soc/intel/braswell/bootblock/bootblock.c. Maybe, there is something
> sticking out…
>
>
>
> Regards,
>
> Alex
>
>
>
> *Von:* Zoran Stojsavljevic [mailto:zoran.stojsavljevic at gmail.com]
> *Gesendet:* Montag, 25. Juli 2016 22:08
> *An:* Alexander Böcken
> *Cc:* coreboot at coreboot.org; york.yang at intel.com
> *Betreff:* Re: [coreboot] Microcode problem with Braswell CPU
>
>
>
> Hello Alex,
>
>
>
> It is awhile... Opportunity just did struck (suddenly/plotzlich), so I am
> back!
>
>
>
> While lurking around in Coreboot, trying to solve some "Mystery of digital
> Orga.ni.sms", I ran into very interesting file:
>
> ./src/include/console/post_codes.h
>
>
>
> Coreboot tree I am using: [zoran at localhost coreboot-09.06.2016]$ git
> describe<CR>
>
> 4.4-455-g538b324
>
>
>
> Maybe, it is worth looking into it. You tell us?
>
>
>
> Zoran
>
>
>
> On Tue, May 3, 2016 at 10:28 AM, Alexander Böcken <
> Alexander.Boecken at junger-audio.com> wrote:
>
> Hello Zoran,
>
> again, thanks for your clues to this problem. I don't think post code 0x52
> is about memory configuration. The post code appears when I call
> TempRamInit which is supposed to enable Cache-as-RAM. Real memory is
> initialized at a later call to FspMemoryInit. coreboot supplies the
> location of the microcode and a cachable region to TempRamInit.
> Additionally, there are some settings that can be applied to the FSP image
> with Intel's Binary Configuration Tool. I don't know if these are used
> during TempRamInit, but I'll try and fiddle around with them.
>
> I agree, it would be helpful to have a list of post codes that can be
> output by FSP. Otherwise it's all speculation as what is wrong.
>
> Regards,
> Alex
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160726/8634be48/attachment-0001.html>


More information about the coreboot mailing list