coreboot September 2016

coreboot@coreboot.org

51 participants
82 discussions

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 30 Sep '16

30 Sep '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1363355: (SIZEOF_MISMATCH) /src/drivers/intel/fsp2_0/upd_display.c: 37 in fspm_display_arch_params() /src/drivers/intel/fsp2_0/upd_display.c: 40 in fspm_display_arch_params() ________________________________________________________________________________________________________ *** CID 1363355: (SIZEOF_MISMATCH) /src/drivers/intel/fsp2_0/upd_display.c: 37 in fspm_display_arch_params() 31 { 32 /* Display the architectural parameters for MemoryInit */ 33 printk(BIOS_SPEW, "Architectural UPD values for MemoryInit at: 0x%p\n", 34 new); 35 fsp_display_upd_value("Revision", sizeof(old->Revision), 36 old->Revision, new->Revision); >>> CID 1363355: (SIZEOF_MISMATCH) >>> Passing argument "old->NvsBufferPtr" of type "void * const" and argument "4UL /* sizeof (old->NvsBufferPtr) */" to function "fsp_display_upd_value" is suspicious. 37 fsp_display_upd_value("NvsBufferPtr", sizeof(old->NvsBufferPtr), 38 (uintptr_t)old->NvsBufferPtr, 39 (uintptr_t)new->NvsBufferPtr); 40 fsp_display_upd_value("StackBase", sizeof(old->StackBase), 41 (uintptr_t)old->StackBase, 42 (uintptr_t)new->StackBase); /src/drivers/intel/fsp2_0/upd_display.c: 40 in fspm_display_arch_params() 34 new); 35 fsp_display_upd_value("Revision", sizeof(old->Revision), 36 old->Revision, new->Revision); 37 fsp_display_upd_value("NvsBufferPtr", sizeof(old->NvsBufferPtr), 38 (uintptr_t)old->NvsBufferPtr, 39 (uintptr_t)new->NvsBufferPtr); >>> CID 1363355: (SIZEOF_MISMATCH) >>> Passing argument "old->StackBase" of type "void * const" and argument "4UL /* sizeof (old->StackBase) */" to function "fsp_display_upd_value" is suspicious. 40 fsp_display_upd_value("StackBase", sizeof(old->StackBase), 41 (uintptr_t)old->StackBase, 42 (uintptr_t)new->StackBase); 43 fsp_display_upd_value("StackSize", sizeof(old->StackSize), 44 old->StackSize, new->StackSize); 45 fsp_display_upd_value("BootLoaderTolumSize", ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] where to put info about linux payload and kgpe-d16
by Paul Menzel 30 Sep '16

30 Sep '16

Dear Ron, Am Donnerstag, den 29.09.2016, 20:09 +0000 schrieb ron minnich: > I'd lke to track some things I'm learning about linux paylaod on kgpe-d16 > > I'm thinking of keep track of > working linux ref and a working .config > working coreboot ref and a working .config > > I'm not quite sure where in the wiki this belongs; ideas anyone? If it’s really ASUS KGPE-D16 related, that as a subpage of the board page. If not, that means, if it’s also related to for example QEMU, I’d create a page *Linux Payload* or so. > reon Did you change your name? :P Thanks, Paul

2 1

where to put info about linux payload and kgpe-d16
by ron minnich 29 Sep '16

29 Sep '16

I'd lke to track some things I'm learning about linux paylaod on kgpe-d16 I'm thinking of keep track of working linux ref and a working .config working coreboot ref and a working .config I'm not quite sure where in the wiki this belongs; ideas anyone? reon

1 0

Upcoming coreboot release v4.5 - Targeting mid-October.
by Martin Roth 29 Sep '16

29 Sep '16

Hi Everyone, We're coming up on our next coreboot release. We'd like to get the release done around the middle of October, but if there are issues in flight, we can delay it a bit. The release will absolutely happen before end of the month. If anyone is working on major changes that will affect all of coreboot, I'd request that they hold off until after the release so we have time to stabilize before the release. Please test platforms that you're interested in now, and as we get closer to the release. I'll create a list of validated platforms to include in the release notes, so if you want your favorite platform listed as having been tested in the release notes, please test it now, and post it to the board_status tracker. I'll release updated documentation for running board_status in the next few days. We've got a number of outstanding issues right now, both on the coreboot issue tracker, and in coverity. Please take a moment to look over these issues and if there are any in an area that you think you can fix, please take a swing at them. - https://ticket.coreboot.org/projects/coreboot - https://scan.coverity.com/projects/coreboot?tab=overview Martin

1 0

linux as payload on KGPE-D16
by ron minnich 29 Sep '16

29 Sep '16

things got better with the CL I submitted yesterday, but further on in 4.x more things break on the KGPE-D16 I'll keep you posted. 4.x has been very painful so far. ron

1 0

Re: [coreboot] Support for Gigabyte ga-ma78gm-us2h?
by Alberto Simón Francés 28 Sep '16

28 Sep '16

Thanks a lot for the help, but now I don't even get to the black screen. Whenever I flash coreboot and reboot the computer, after a few seconds of black-screen the backup BIOS complains about a checksum fail from the main bios chip and resets the contents to the original BIOS. I have a few ideas to try tonight, so I'll try that. Hopefully I'll be able to achieve something. Cheers, Alberto 2016-09-28 15:10 GMT-03:00 Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com>: > *"Приветствую!* > *Если я правильно понял, то у меня была схожая проблема, когда я пытался > запустить coreboot на Asus m4a785-m. Я потратил 2 месяца на ее решение, а > решение оказалось простым.* > *Проблема в вызовах printk() до инициализации консоли. Видимо > переполняется кэш процессора."* > > Translation for the above is the following (maybe this also can help): > > Hello, > > If I correctly understand, I had very similar problem, when I > struggled/tried to bring up Coreboot on Asus m4a785-m. I lost two months > for solution finding, and solution appeared to be simplistic. > Problem is by calling printk() before console init. Apparently CPU cache > is overloading. > > (love Russian language, could not resist)! > > Zoran > > On Wed, Sep 28, 2016 at 5:54 PM, Alexey Borovikov via coreboot < > coreboot(a)coreboot.org> wrote: > >> Hi! >> May be the problems in call printk() before console_init(). Two way: >> 1. To comment printk in function which call before console_init. >> 2. Call console_init first in function cache_as_ram_main. >> May be this help. >> >> /* >> Приветствую! >> Если я правильно понял, то у меня была схожая проблема, когда я пытался >> запустить coreboot на Asus m4a785-m. Я потратил 2 месяца на ее решение, а >> решение оказалось простым. >> Проблема в вызовах printk() до инициализации консоли. Видимо >> переполняется кэш процессора. >> Для решения два пути: >> 1. Закомментировать все вызовы printk до вызова console_init >> 2. Попробовать вызвать console_init как можно раньше в функции >> cache_as_ram_main (файл romstage.c). >> Возможно это поможет. >> */ >> >> >> *From:* Alberto Simón Francés <alberto(a)simon.ph> >> *Sent:* Sunday, September 25, 2016 6:07 PM >> *To:* coreboot(a)coreboot.org >> *Subject:* [coreboot] Support for Gigabyte ga-ma78gm-us2h? >> >> >> Hello, >> >> I've been trying to make this board boot and I haven't had much success. >> Sometimes I've been able to get it to POST, but it's not something that >> happens consistently. Since I can't find much info other than it being >> listed, I'm asking here to see if by any chance there's something that I'm >> missing, because I feel like I'm just trying random things to see what >> sticks. >> >> Thankfully the board has dual bios, so it's easy to go back if I mess >> something up. Please, help. >> >> Best regards, >> Albert >> >> ------------------------------ >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > >

1 0

Re: [coreboot] Support for Gigabyte ga-ma78gm-us2h?
by Alexey Borovikov 28 Sep '16

28 Sep '16

Hi! May be the problems in call printk() before console_init(). Two way: 1. To comment printk in function which call before console_init. 2. Call console_init first in function cache_as_ram_main. May be this help. /* Приветствую! Если я правильно понял, то у меня была схожая проблема, когда я пытался запустить coreboot на Asus m4a785-m. Я потратил 2 месяца на ее решение, а решение оказалось простым. Проблема в вызовах printk() до инициализации консоли. Видимо переполняется кэш процессора. Для решения два пути: 1. Закомментировать все вызовы printk до вызова console_init 2. Попробовать вызвать console_init как можно раньше в функции cache_as_ram_main (файл romstage.c). Возможно это поможет. */ From: Alberto Simón Francés Sent: Sunday, September 25, 2016 6:07 PM To: coreboot(a)coreboot.org Subject: [coreboot] Support for Gigabyte ga-ma78gm-us2h? Hello, I've been trying to make this board boot and I haven't had much success. Sometimes I've been able to get it to POST, but it's not something that happens consistently. Since I can't find much info other than it being listed, I'm asking here to see if by any chance there's something that I'm missing, because I feel like I'm just trying random things to see what sticks. Thankfully the board has dual bios, so it's easy to go back if I mess something up. Please, help. Best regards, Albert -------------------------------------------------------------------------------- -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

2 1

Re: [coreboot] Debugging MRC issues with FPS
by Marshall Dawson 27 Sep '16

27 Sep '16

Hi Adolfo, I would try increasing the value of DebugOutputLevel in the UPD region, if you have a serial console. (See fsp_vpd.h.) For a quick experiment, I would jam this into chipset_fsp_util.c ConfigureDefaultUpdData(), although the proper place for it is romstage_fsp_rt_buffer_callback() in your mainboard directory. I'm not certain whether Intel has compiled in the debug information, but I suspect it's still there. Thanks, Marshall On Mon, Sep 26, 2016 at 4:23 PM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > Hello Stephanie, > > With all due respect, you do realize that Coreboot.org is on your side, > INTEL embedded side of the business, correct? Coreboot.org is trying to > help debugging these issues, because in the past there were several > attempts to determine INTEL FSP MRC problems. And number of Coreboot.org > developers on different INTEL platforms ran on undocumented POST FSP codes. > We had here these discussions in the past. > > I do not see any obstacles why INTEL should NOT post (in public domain) > FSP POST codes, well documented. > > Stephanie, you do realize setbacks in business cases, considering > competition: AMD and ARM? > > Please, could you reconsider your/INTEL decision?! > > Thank you, > Zoran > > On Tue, Sep 27, 2016 at 12:09 AM, Wang, Stephanie < > stephanie.wang(a)intel.com> wrote: > >> Hello >> >> Thank you for your interest in Intel® FSP! coreboot.org is not the >> right forum for FSP questions. Intel has no plan to post FSP binary or MRC >> post code to coreboot.org. Please take this question to Intel IPS. >> >> Thanks >> >> Stephanie >> >> >> >> >> >> *From:* Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] >> *Sent:* Sunday, September 25, 2016 11:48 AM >> *To:* Adolfo Sanchez <adolfo_sm_cr(a)hotmail.com> >> *Cc:* coreboot(a)coreboot.org; Yang, York <york.yang(a)intel.com>; Wang, >> Stephanie <stephanie.wang(a)intel.com>; Mahesh, Divya < >> divya.mahesh(a)intel.com> >> *Subject:* Re: [coreboot] Debugging MRC issues with FPS >> >> >> >> Hello Adolfo (you are somehow known to me, isn't it that you are working >> for INTEL Inside support, or maybe not)!? What does it mean _cr in your >> email address (Costa Rica, isn't it)?! ;-) >> >> >> >> Let us ask this very relevant people in INTEL Inside, who MANDATORY >> should know info you are asking, since they are responsible, aren't they >> (INTEL insider is asking for FSP POST codes Coreboot outsiders, which will >> again ask much more relevant INTEL Insiders)??? IN -> OUT -> IN schema. >> Shouldn't it be: IN -> IN schema ONLY??? :-)) >> >> >> >> Verrückt (Deutsche Sprache)?! :LOL: >> >> _______ >> >> >> >> Hello Stephanie, >> >> >> >> You realize how this all strange is (the context)? *BTW, we, Coreboot >> members... We should once forever know these POST codes are (you hide >> inside FSPs - probably reminiscence of BIOS MRC post codes, or you tell us >> all?!)? Could you, please, make this as public info to INTEL Outside?* >> >> >> >> Divya, >> >> >> >> Could you, please, arrange what I am (in *RED*) asking for (INTEL Inside >> and INTEL Outside)? You do realize why I am asking this, correct???💡 >> >> >> >> (don't touch/blame Adolfo... You should ask many questions somewhere >> else... You know exactly where!) >> >> >> >> Thank you, >> >> Zoran Stojsavljevic, independent FREE contributor >> >> >> >> On Sun, Sep 25, 2016 at 5:55 PM, Adolfo Sanchez <adolfo_sm_cr(a)hotmail.com> >> wrote: >> >> Hello >> >> >> >> I would like to know the best way to get information about a Failure >> related with Memory Initialization when using FPS. >> >> Specially when the FSPmemoryinit is being called but then the system >> hangs. POST Code 0x50 >> >> What flags can be enable to get more information? >> >> >> >> Best Regards, >> >> Adolfo Sanchez >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> >> >> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Debugging MRC issues with FPS
by Zoran Stojsavljevic 27 Sep '16

27 Sep '16

Hello Stephanie, With all due respect, you do realize that Coreboot.org is on your side, INTEL embedded side of the business, correct? Coreboot.org is trying to help debugging these issues, because in the past there were several attempts to determine INTEL FSP MRC problems. And number of Coreboot.org developers on different INTEL platforms ran on undocumented POST FSP codes. We had here these discussions in the past. I do not see any obstacles why INTEL should NOT post (in public domain) FSP POST codes, well documented. Stephanie, you do realize setbacks in business cases, considering competition: AMD and ARM? Please, could you reconsider your/INTEL decision?! Thank you, Zoran On Tue, Sep 27, 2016 at 12:09 AM, Wang, Stephanie <stephanie.wang(a)intel.com> wrote: > Hello > > Thank you for your interest in Intel® FSP! coreboot.org is not the right > forum for FSP questions. Intel has no plan to post FSP binary or MRC post > code to coreboot.org. Please take this question to Intel IPS. > > Thanks > > Stephanie > > > > > > *From:* Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] > *Sent:* Sunday, September 25, 2016 11:48 AM > *To:* Adolfo Sanchez <adolfo_sm_cr(a)hotmail.com> > *Cc:* coreboot(a)coreboot.org; Yang, York <york.yang(a)intel.com>; Wang, > Stephanie <stephanie.wang(a)intel.com>; Mahesh, Divya < > divya.mahesh(a)intel.com> > *Subject:* Re: [coreboot] Debugging MRC issues with FPS > > > > Hello Adolfo (you are somehow known to me, isn't it that you are working > for INTEL Inside support, or maybe not)!? What does it mean _cr in your > email address (Costa Rica, isn't it)?! ;-) > > > > Let us ask this very relevant people in INTEL Inside, who MANDATORY should > know info you are asking, since they are responsible, aren't they (INTEL > insider is asking for FSP POST codes Coreboot outsiders, which will again > ask much more relevant INTEL Insiders)??? IN -> OUT -> IN schema. Shouldn't > it be: IN -> IN schema ONLY??? :-)) > > > > Verrückt (Deutsche Sprache)?! :LOL: > > _______ > > > > Hello Stephanie, > > > > You realize how this all strange is (the context)? *BTW, we, Coreboot > members... We should once forever know these POST codes are (you hide > inside FSPs - probably reminiscence of BIOS MRC post codes, or you tell us > all?!)? Could you, please, make this as public info to INTEL Outside?* > > > > Divya, > > > > Could you, please, arrange what I am (in *RED*) asking for (INTEL Inside > and INTEL Outside)? You do realize why I am asking this, correct???💡 > > > > (don't touch/blame Adolfo... You should ask many questions somewhere > else... You know exactly where!) > > > > Thank you, > > Zoran Stojsavljevic, independent FREE contributor > > > > On Sun, Sep 25, 2016 at 5:55 PM, Adolfo Sanchez <adolfo_sm_cr(a)hotmail.com> > wrote: > > Hello > > > > I would like to know the best way to get information about a Failure > related with Memory Initialization when using FPS. > > Specially when the FSPmemoryinit is being called but then the system > hangs. POST Code 0x50 > > What flags can be enable to get more information? > > > > Best Regards, > > Adolfo Sanchez > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > > >

1 0

Re: [coreboot] What problems are there with native RAM initialization on Intel Sandy Bridge?
by Kyösti Mälkki 26 Sep '16

26 Sep '16

Hi One issue I know of with native raminit is when you have different capacity for the DDR3 channels. At least samsung/lumpy fails in configuration of 2GiB on-board and 4 GiB SO-DIMM, while MRC blob works fine. Should not be hard to fix, if you have hardware to test different configs, see: https://review.coreboot.org/#/c/15330/ Kyösti On Mon, Sep 26, 2016 at 8:12 PM, Matt DeVillier <matt.devillier(a)gmail.com> wrote: > Hi Paul, > > I received feedback from a couple of users of my Stumpy firmware that they > thought it had bricked the machine, only to realize it wasn't bricked when > the either removed one of the sodimms or swapped out the factory modules > for another pair. I wanted to compare results with the MRC blob vs native > raminit, which is what led me to finding the compilation issue with the > former. I don't yet have any feedback on whether the MRC init worked > better for these users, just that the native was problematic > > regards, > Matt > > On Sun, Sep 25, 2016 at 10:33 AM, Paul Menzel <paulepanter@users. > sourceforge.net> wrote: > >> Dear Matt, >> >> >> You commented in [1], that there are problems with native RAM >> initialization on Intel Sandy Bridge. >> >> > using native raminit seems to be problematic on several >> > samsung/stumpy devices, hence the use of the MRC blob instead >> >> In #coreboot, I was asked which ones there are. Could you please report >> those here, or in the bug tracker [2]. >> >> >> Thanks, >> >> Paul >> >> >> [1] https://review.coreboot.org/16735/ >> [2] https://ticket.coreboot.org/ > > > > -- > 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
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2016