[coreboot] Microcode problem with Braswell CPU

Zoran Stojsavljevic zoran.stojsavljevic at gmail.com
Wed Jul 27 05:10:48 CEST 2016


Hello Cheng,

What I am getting from your emails and the net is the following:
CPUID 0x406C3 => 6 - Family, C - Model, Stepping - 3 (Si = C0)

Following the article I have posted before:
http://www.anandtech.com/show/9806/intel-introduces-new-braswell-stepping-with-j3060-j3160-and-j3710
 :
It is obvious that INTEL introduced new stepping Dx. In other words, CPUID
0x406C4 is stepping Dx (not sure which number x is for stepping 4).

Certainly you have to have different MCUs for the different stepping.

Now, I see the following from your last email:
2. In Coreboot I use microcode  version M01406C440A   N3060/N3160/x5-e800.
version M01406C3363 for N3150.

Here, you are correct, your N3150 is stepping C0, CPUID 0x406C3, MCU 0x363
N3060/N3160/x5-e800, they are all stepping Dx, CPUID 0x406C4, MCU 0x40A

Only N3060 boots, and this is the lowest class (celeron) sku, maybe here
there is a crucial difference why other skus do not boot.

*Other things to be of significant importance is how many channels and
which DDR3 memory you are using on your boards?*
*POST 0x52 (maybe?) suggests problems with MRC?!*

Best Regards,
Zoran

On Tue, Jul 26, 2016 at 5:11 PM, cheng yichen <blessyichen at gmail.com> wrote:

> HI Zoran
>
> 1Cherry Hill CRB CPU is N3150(cpuid is 406c3)
> 2.in coreboot I use microcode  version M01406C440A   N3060/N3160/x5-e800.
> version M01406C3363 for N3150.
>
>
> 2016-07-26 22:29 GMT+08:00 Zoran Stojsavljevic <
> zoran.stojsavljevic at gmail.com>:
>
>>  > The issue can't be duplicated in cherryhill CRB.
>>
>> Hello Cheng,
>>
>> What BSW SoC type (N3xxx), which CPUID, and which stepping do you have in
>> Cherry Hill CRB (IOTG one, seems N3060)? And also what MCU do you have
>> there??
>>
>> Stepping is (at this point in time) very important (since you have to
>> have correct MCU matching stepping)... I am not saying that this will
>> anyhow solve the problem?!
>>
>> You can back-port IOTG BIOS, and read BIOS System Information page to
>> find these info. And you (also, for sure) could open in Sales Force case
>> #.... It will certainly put more
>> pressure on INTEL IOTG support, so they'll try to cope with the situation
>> (although two different GEOs)... .. .
>>
>> Zoran
>>
>> On Tue, Jul 26, 2016 at 10:48 AM, cheng yichen <blessyichen at gmail.com>
>> wrote:
>>
>>> Hi all
>>> I have the same issue and still can't solve it. I test those CPUs in my
>>> mainboard and only N3060 is workable with FSP.
>>> I confuse why the same cpuid have different result. The issue can't be
>>> duplicated in cherryhill CRB.
>>>
>>>
>>>
>>>
>>> N3060(cpuid:406C4)  :  boot successfully
>>> N3160(cpuid:406C4) :  hang up in check point 0x52
>>> N3150(cpuid:406C3) :  hang up in check point 0x52
>>> x5-e8000(cpuid:406c4): hang up in check point 0x52
>>>
>>> 2016-07-26 15:27 GMT+08:00 Zoran Stojsavljevic <
>>> zoran.stojsavljevic at gmail.com>:
>>>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> coreboot mailing list: coreboot at coreboot.org
>>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160727/671720c4/attachment.html>


More information about the coreboot mailing list