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 <blessyic...@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.stojsavlje...@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 <blessyic...@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.stojsavlje...@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.boec...@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.stojsavlje...@gmail.com] >>>>> *Gesendet:* Montag, 25. Juli 2016 22:08 >>>>> *An:* Alexander Böcken >>>>> *Cc:* coreboot@coreboot.org; york.y...@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@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.boec...@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@coreboot.org >>>> https://www.coreboot.org/mailman/listinfo/coreboot >>>> >>> >>> >> >
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
