Re: [coreboot] Microcode problem with Braswell CPU

[cheng yichen]

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 23:11 GMT+08:00 cheng yichen :
> 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 <
> [e-mail]>:
> > > 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 
> > 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 <
> > > [e-mail]>:
> > > > 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-wi...
> > > >
> > > > 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 <
> > > > [e-mail]> 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:[e-mail]]
> > > > > *Gesendet:* Montag, 25. Juli 2016 22:08
> > > > > *An:* Alexander Böcken
> > > > > *Cc:* [e-mail]; [e-mail]
> > > > > *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@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 <
> > > > > [e-mail]> 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