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 < [email protected]>: > 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 < > [email protected]> 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:[email protected]] >> *Gesendet:* Montag, 25. Juli 2016 22:08 >> *An:* Alexander Böcken >> *Cc:* [email protected]; [email protected] >> *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 < >> [email protected]> 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: [email protected] > https://www.coreboot.org/mailman/listinfo/coreboot >
-- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
