coreboot July 2016

coreboot@coreboot.org

47 participants
135 discussions

Re: [coreboot] kexec of Xen hypervisor from a Linux payload
by Trammell Hudson 26 Jul '16

26 Jul '16

On Mon, Jul 25, 2016 at 02:42:11PM +0200, Zoran Stojsavljevic wrote: > [...] > *Probably some module required for your baremetal fedora is missing > in initramfs. First of all, remove "quiet" option to receive more > details. If that's about missing module, you can regenerate initramfs: The system boots fine under coreboot+seabios, so I'm fairly certain it isn't an initrd problem. There are no modules at all in the kernel that I've embedded as the coreboot payload. Even without quiet there is no output after the "kexec_core: Starting new kernel" message. I did find this note from 2008 that mentioned a similar issue regarding xen, kexec and coreboot: http://ward.vandewege.net/blog/2008/08/kexecing-into-a-xen-kernel/ # The no-real-mode option stops Xen from doing some bios # calls, and it also tells it to ignore the e820 bios table. # Note that you need to pass no-real-mode as the first xen # command line argument, otherwise it won’t work. # # And somehow that solves the problem for Xen 3.1.3 and 3.1.4, # both under qemu + coreboot and qemu + bochs. Kexec’ing into # Xen 3.1.2 triple-faults qemu under qemu + coreboot, but # works fine under qemu + bochs. That smells like a coreboot # bug. I’ll try on real hardware tomorrow to see if this bug # is specific to our qemu port, or a more general coreboot # problem. To be continued.. "no-real-mode" does not affect my results on real hardware. I'm still seeing what looks like a triple fault, leading to coreboot being restarted. At least it gets back to the prompt in less than a second... -- Trammell

2 5

Re: [coreboot] Microcode problem with Braswell CPU
by cheng yichen 26 Jul '16

26 Jul '16

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 <blessyichen(a)gmail.com>: > 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(a)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(a)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(a)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-w… >>>> >>>> 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(a)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@gmail.com] >>>>> *Gesendet:* Montag, 25. Juli 2016 22:08 >>>>> *An:* Alexander Böcken >>>>> *Cc:* coreboot(a)coreboot.org; york.yang(a)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.Boecken(a)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(a)coreboot.org >>>> https://www.coreboot.org/mailman/listinfo/coreboot >>>> >>> >>> >> >

1 0

Re: [coreboot] What is the best way to treat warnings reported by checkpatch.pl
by Vadim Bendebury 26 Jul '16

26 Jul '16

I am not sure if this happened in coreboot upstream: on some other projects checkpatch.pl was recently updated to the latest Linux kernel version, and some more stupid warnings/errors started popping out. There is a fine controlling checkpatch.pl behavior, .checkpatch.conf in the coreboot root directory. That file can be modified to quiet down checkpatch.pl complaints which are not applicable to coreboot. --vb On Mon, Jul 25, 2016 at 11:46 PM, Zeh, Werner <werner.zeh(a)siemens.com> wrote: > Hi community. > > > > I recently ran into a blocked commit due to warnings reported by > checkpatch.pl. > > In this particular case I wanted to add the “ATSR” structure to the DMAR > tables. To do that, I need to define a new structure > > which reflects the per specification needed layout of this table entry. > > I did that in the same style how other structures are defined in the same > file (src/arch/x86/include/arch/acpi.h): > > > > typedef struct dmar_atsr_entry { > > u16 type; > > u16 length; > > u8 flags; > > u8 reserved; > > u16 segment; > > } __attribute__ ((packed)) dmar_atsr_entry_t; > > > > This change resulted in two warnings caused by util/lint/checkpatch.pl > when I was trying to do a git commit: > > > > WARNING: do not add new typedefs > > #34: FILE: src/arch/x86/include/arch/acpi.h:288: > > +typedef struct dmar_atsr_entry { > > > > WARNING: __packed is preferred over __attribute__((packed)) > > #40: FILE: src/arch/x86/include/arch/acpi.h:294: > > +} __attribute__ ((packed)) dmar_atsr_entry_t; > > > > So the first warning tells me that I should not use “typedef” in my code. > > > > The second one tells me not to use __attribute__ ((packed) but instead > __packed! > > If one take a closer look to the coreboot tree, one will not find a macro > definition called __packed at all. > > > > After a short discussion on IRC with Stefan it was clear that although we > have this checkpatch.pl script in the tree and the git hook “pre-commit” > > activates it, the script does not perfectly match current coreboot coding > style. > > > > So in the end there needs to be a change somewhere: > > 1. We can adapt the script to match current coreboot coding style > > 2. We can start to refactor the coreboot tree to match the demands of > checkpatch.pl > > 3. We can align only new patches to the demands of the script > > 4. We can show warnings from the script but prevent them from > aborting the git commit > > > > While 1. would be the best, straight forward approach for the project, it > might cause high effort for a person who knows the code base very well. > > 2. will lead to a lot of changes in the tree while the reason/goal is > still questionable (at least to me). > > 3. will lead to different code style all over the tree (even in the same > file) and in the end will result in fragmented code. I personally would not > like it. > > 4. can be a short term solution while we are seeking for the best way to > deal with this issue. > > > > There may be other ways to go, too, which I have overseen now. > > > > I just want to start this discussion officially as this is not the first > time I ran into issues with checkpatch.pl. > > What do you think about it, what would be the best way to handle this case? > > > > Your ideas and thoughts are appreciated. > > > > Werner > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Microcode problem with Braswell CPU
by Zoran Stojsavljevic 26 Jul '16

26 Jul '16

> 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(a)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(a)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-w… >> >> 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(a)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@gmail.com] >>> *Gesendet:* Montag, 25. Juli 2016 22:08 >>> *An:* Alexander Böcken >>> *Cc:* coreboot(a)coreboot.org; york.yang(a)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.Boecken(a)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(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > >

1 0

Re: [coreboot] Microcode problem with Braswell CPU
by cheng yichen 26 Jul '16

26 Jul '16

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(a)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-w… > > 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(a)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@gmail.com] >> *Gesendet:* Montag, 25. Juli 2016 22:08 >> *An:* Alexander Böcken >> *Cc:* coreboot(a)coreboot.org; york.yang(a)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.Boecken(a)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(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Support for USB auto switching in Intel FSP
by Naveed Ghori 26 Jul '16

26 Jul '16

Hi all, I wanted to know if anyone had gotten the Intel FSP to work with auto mode. It does not work for me in Seabios. I have not tried EDKII yet. However I believe the FSP is not setup for it anyway out of the box. Any help appreciated. Naveed Ghori Naveed Ghori | Lead Firmware & Driver Engineer DTI Group Ltd | Transit Security & Surveillance 31 Affleck Road, Perth Airport, Western Australia 6105, AU P +61 8 9373 2905,151 | F +61 8 9479 1190 | naveed.ghori(a)dti.com.au Visit our website www.dti.com.au<http://www.dti.com.au> The information contained in this email is confidential. If you receive this email in error, please inform DTI Group Ltd via the above contact details. If you are not the intended recipient, you may not use or disclose the information contained in this email or attachments.

1 0

Re: [coreboot] Where is the first instrucion?
by Anthony Martin 26 Jul '16

26 Jul '16

Tony Marchini <amarchini(a)RTD.com> once said: > I would like to start with, Do not disassemble copyrighted firmware and > CERTAINLY don't post your results to a public forum. Oh no! The corporate copyright bogeyman's gonna get ya! Keep learning, Rafael. Disassemble everything. Cheers, Anthony

2 1

Re: [coreboot] Microcode problem with Braswell CPU
by Alexander Böcken 26 Jul '16

26 Jul '16

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@gmail.com] Gesendet: Montag, 25. Juli 2016 22:08 An: Alexander Böcken Cc: coreboot(a)coreboot.org; york.yang(a)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.Boecken(a)junger-audio.com<mailto:Alexander.Boecken@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

2 1

What is the best way to treat warnings reported by checkpatch.pl
by Zeh, Werner 26 Jul '16

26 Jul '16

Hi community. I recently ran into a blocked commit due to warnings reported by checkpatch.pl. In this particular case I wanted to add the "ATSR" structure to the DMAR tables. To do that, I need to define a new structure which reflects the per specification needed layout of this table entry. I did that in the same style how other structures are defined in the same file (src/arch/x86/include/arch/acpi.h): typedef struct dmar_atsr_entry { u16 type; u16 length; u8 flags; u8 reserved; u16 segment; } __attribute__ ((packed)) dmar_atsr_entry_t; This change resulted in two warnings caused by util/lint/checkpatch.pl when I was trying to do a git commit: WARNING: do not add new typedefs #34: FILE: src/arch/x86/include/arch/acpi.h:288: +typedef struct dmar_atsr_entry { WARNING: __packed is preferred over __attribute__((packed)) #40: FILE: src/arch/x86/include/arch/acpi.h:294: +} __attribute__ ((packed)) dmar_atsr_entry_t; So the first warning tells me that I should not use "typedef" in my code. The second one tells me not to use __attribute__ ((packed) but instead __packed! If one take a closer look to the coreboot tree, one will not find a macro definition called __packed at all. After a short discussion on IRC with Stefan it was clear that although we have this checkpatch.pl script in the tree and the git hook "pre-commit" activates it, the script does not perfectly match current coreboot coding style. So in the end there needs to be a change somewhere: 1. We can adapt the script to match current coreboot coding style 2. We can start to refactor the coreboot tree to match the demands of checkpatch.pl 3. We can align only new patches to the demands of the script 4. We can show warnings from the script but prevent them from aborting the git commit While 1. would be the best, straight forward approach for the project, it might cause high effort for a person who knows the code base very well. 2. will lead to a lot of changes in the tree while the reason/goal is still questionable (at least to me). 3. will lead to different code style all over the tree (even in the same file) and in the end will result in fragmented code. I personally would not like it. 4. can be a short term solution while we are seeking for the best way to deal with this issue. There may be other ways to go, too, which I have overseen now. I just want to start this discussion officially as this is not the first time I ran into issues with checkpatch.pl. What do you think about it, what would be the best way to handle this case? Your ideas and thoughts are appreciated. Werner

1 0

Re: [coreboot] Where is the first instrucion?
by Rafael Machado 26 Jul '16

26 Jul '16

Hi Anthony, thanks for the advise and for the explanation. You are totally right about posting firmware code on the forum. Rafael Em seg, 25 de jul de 2016 15:59, Tony Marchini <amarchini(a)rtd.com> escreveu: > I would like to start with, Do not disassemble copyrighted firmware and > CERTAINLY don't post your results to a public forum. > > That said, the di in this case is being used as a return instruction in a > piece of BIOS that clearly doesn't have the memory enabled yet. No memory, > no stack. No stack then no call /ret instructions. Here they set the return > point and put it in the di register and then "call" the function. The > instruction after the jp di is another function. > > Anthony A. Marchini > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

← Newer
1
2
3
4
5
6
7
8
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2016