[coreboot] Microcode problem with Braswell CPU

Tue Jul 26 10:48:11 CEST 2016

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/20160726/a95d7328/attachment.html>