coreboot November 2015

coreboot@coreboot.org

38 participants
97 discussions

Re: [coreboot] Long boot delay with a large CBFS

by Ben Gardner

Hi Patrick, On Mon, Nov 16, 2015 at 12:54 PM, Patrick Georgi <pgeorgi(a)google.com> wrote: > 2015-11-16 19:32 GMT+01:00 Ben Gardner <gardner.ben(a)gmail.com>: >> What is the purpose behind continuing if a bad entry is encountered? >> It appears that a 'bad' entry only occurs at the end of the CBFS. > With a properly chained CBFS, there are no such entries (except one at > the end, maybe), and large empty regions are simply skipped because > there's an empty file entry. > > Since we're in firmware with few recovery options, we don't want the > computer to die with a black screen if all that happened may be some > minor corruption in a data structure, and so we do a best-effort > recovery by trying to find a new entry point into the chain. The > theory being that it can't get worse. That makes sense. I must have had some corruption in the ROM image. I rebuilt with CONFIG_CBFS_SIZE=0x00EC0000 again and I'm not seeing the long pause. I think I was playing with the 'fast boot' option at the time (now disabled). I'll retry with that enabled. Thanks, Ben

4 years, 10 months

Re: [coreboot] Long boot delay with a large CBFS

by Patrick Georgi

2015-11-16 19:32 GMT+01:00 Ben Gardner <gardner.ben(a)gmail.com>: > What is the purpose behind continuing if a bad entry is encountered? > It appears that a 'bad' entry only occurs at the end of the CBFS. With a properly chained CBFS, there are no such entries (except one at the end, maybe), and large empty regions are simply skipped because there's an empty file entry. Since we're in firmware with few recovery options, we don't want the computer to die with a black screen if all that happened may be some minor corruption in a data structure, and so we do a best-effort recovery by trying to find a new entry point into the chain. The theory being that it can't get worse. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

4 years, 10 months

Re: [coreboot] Long boot delay with a large CBFS

by Ben Gardner

[The previous email got chopped. This is a re-send.] Hi all, I have a 16 MB BIOS flash on a fsp_baytrail based design. I tried expanding the CBFS to fill the whole space, but found that to cause a 10-15 sec boot delay. The offending code appears to be in cbfs_locate() in lib/cbfs.c: if (memcmp(file.magic, CBFS_FILE_MAGIC, sizeof(file.magic))) { offset++; offset = ALIGN_UP(offset, CBFS_ALIGNMENT); continue; } In SeaBIOS, the equivalent code does a break instead of a continue. I'n not terribly familiar with the design goals of the CBFS. What is the purpose behind continuing if a bad entry is encountered? It appears that a 'bad' entry only occurs at the end of the CBFS. Thanks, Ben

4 years, 10 months

Long boot delay with a large CBFS

by Ben Gardner

Hi all, I have a 16 MB BIOS flash on a fsp_baytrail based design. I tried expanding the CBFS to fill the whole space, but found that to cause a 10-15 sec boot delay. The offending code appears to be here:

4 years, 10 months

coreboot leadership meeting notes for November 5, 2015

by Martin Roth

Attendance: ----------- Stefan, Martin, Aaron, Patrick Agenda: ------- * This meeting was initially set up as a consortium meeting. We need to decide if this is a consortium meeting or a coreboot leadership meeting. - It was decided that the meetings are leadership meetings, and that the consortium is simply a part of what is being discussed by the leadership. * Decide on goals for coreboot over the next two years. - Goals were discussed, but not decided upon. Discussion will continue. * Discussion on coreboot leadership. - Work on documenting coreboot leadership definition, roles, and responsibilities. * Review Documents: Developer acceptance guidelines, Code removal guidelines - Documents will continue to be worked on until they are ready for release. - Related: A method will be devised to identify dead files in the tree * We need a way for reporting issues (because board-status is a positive list) - probably bug tracker

4 years, 10 months

GM45 S3 resume issues

by Patrick 'P. J.' McDermott

Hi, I've been looking into S3 resume on GM45 mainboards, which often fails in rather interesting ways. Many X200 units resume on every try (barring any panics in Linux, of course). Some only resume about half of the time. And some/most T400 units fail to resume all of the time. These systems fail to resume in one of the following ways: * S3 resume (indicated by the SLP_TYP bit) is detected, SLP_TYP is cleared, DRAM receive-enable calibration fails with a timing under/overflow, the system resets, and coreboot boots normally into the payload (with the sleep LED still on) because SLP_TYP is now unset. See x200-resume-fail-receive-enable-calibration.log and t400-resume-fail-receive-enable-calibration.log. * S3 resume is detected, SLP_TYP is cleared, raminit and the rest of romstage completes without error, but then something between the southbridge's smm_init() and cpu_initialize() hangs (maybe the system is stuck in SMM). See x200-resume-fail-smm-hang.log and t400-resume-fail-smm-hang.log. * S3 resume is detected, SLP_TYP is cleared, romstage completes, but something within smm_init() hangs before dumping (possibly while clearing [1]) TCO1_STS bits. See t400-resume-fail-tco-hang.log There are a couple of other ways in which I've seen S3 resume fail, but these are the most common. I thought of working around the first issue (clearing SLP_TYP, resetting due to a raminit error, then booting into the payload) by clearing SLP_TYP near the end of the romstage main() (after raminit). So I tried the following patch: --- diff --git a/src/mainboard/lenovo/x200/romstage.c b/src/mainboard/lenovo/x200/romstage.c index 86a973f..915baf2 100644 --- a/src/mainboard/lenovo/x200/romstage.c +++ b/src/mainboard/lenovo/x200/romstage.c @@ -103,10 +103,6 @@ void main(unsigned long bist) #if CONFIG_HAVE_ACPI_RESUME printk(BIOS_DEBUG, "Resume from S3 detected.\n"); s3resume = 1; - /* Clear SLP_TYPE. This will break stage2 but - * we care for that when we get there. - */ - outl(pm1_cnt & ~(7 << 10), DEFAULT_PMBASE + 0x04); #else printk(BIOS_DEBUG, "Resume from S3 detected, but disabled.\n"); #endif @@ -190,6 +186,11 @@ void main(unsigned long bist) /* Magic for S3 resume */ pci_write_config32(PCI_DEV(0, 0, 0), D0F0_SKPD, SKPAD_ACPI_S3_MAGIC); + + /* Clear SLP_TYPE. This will break stage2 but + * we care for that when we get there. + */ + outl(pm1_cnt & ~(7 << 10), DEFAULT_PMBASE + 0x04); } else { /* Magic for S3 resume */ pci_write_config32(PCI_DEV(0, 0, 0), D0F0_SKPD, SKPAD_NORMAL_BOOT_MAGIC); --- But that just made these errors even more frequent. Trying to resume from S3 put the system into a reset loop with receive-enable calibration errors (see x200-patched-resume-fail-receive-enable-loop.log). So instead of rebooting into the payload or hanging, the system just resets forever. So, it seems that whenever the system boots with SLP_TYP set, something is very likely to go wrong in coreboot and cause either a reset or a hang. Does anyone have any ideas why this might be? [1]: Tangentially, I noticed that the i82801ix reset_tco_status() says "Don't clear BOOT_STS before SECOND_TO_STS" when it clears BOOT_STS. In the next two lines it clears BOOT_STS if set. It never clears SECOND_TO_STS. Is this a bug? However, according to the ICH9 datasheet, there is no SECOND_TO_STS bit in TCO1_STS (the high bits of that register are reserved). Thanks, -- Patrick "P. J." McDermott http://www.pehjota.net/ Lead Developer, ProteanOS http://www.proteanos.com/

4 years, 10 months

Re: [coreboot] Re : FOSDEM deadlines now!

by Carl-Daniel Hailfinger

[DEADLINE IS NOW+48 hours!] Hi, thanks to Paul and Florentin for announcing they will come and thanks to Paul for submitting a talk! Who else is coming? Do we want one or two tables? Regards, Carl-Daniel On 21.10.2015 10:15, echelon(a)free.fr (Florentin) wrote: > +1 > > * for the stands count me in : I can bring my AMD boards and if all is going well I will be able to do demos on my G505s laptop. (I will also bring various electronic stuff and tools..) > * for the main tracks I cannot help unfortunately > * for the lightining traks I have some (bold!) ideeas but they are not mature yet (and I must first discuss with you about this .. maybe on irc..) On 31.10.2015 10:41, Paul Kocialkowski wrote: > I will definitely be around at FOSDEM, not sure I should have a seat at > the table at this point (I'm still pretty new to the community), but I'd > be happy to come by! > ----- Mail d'origine ----- > De: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> > À: coreboot <coreboot(a)coreboot.org>, flashrom <flashrom(a)flashrom.org> > Envoyé: Tue, 20 Oct 2015 23:20:56 +0200 (CEST) > Objet: [coreboot] FOSDEM deadlines now! > > Hi, > > we obviously want to participate in FOSDEM. > https://fosdem.org/2016/news/2015-09-24-call-for-participation/ > > ACT NOW! > > Some deadlines already expired. Some can still be managed. > > Main track talks: Deadline 2015-10-30 (10 days left) > One hour of entertainment, huge audience. > Anyone up for the challenge? > > Stands: Deadline 2015-11-13 (24 days left) > I can send in the proposal if I'm not going to be alone there. > How many tables do we want for our stand/booth(s)? > Who is coming? > > Lightning talks: Deadline 2015-11-27 (38 days left) > Short and to the point. Your 15-minute elevator pitch. > Can you sell the project? > > All deadlines are at 23.59 UTC > > Developer room proposal: Deadline EXPIRED > Maybe some developer room will accept talks/demos from us. > > Regards, > Carl-Daniel > >

4 years, 10 months

[ANNOUNCEMENT] ASRock E350M1 supports ACPI S3!

by Paul Menzel

Dear coreboot folks, just a late notice, that – thanks to the work of Kyösti Mälkki – as of commit 68825740 (asrock/e350m1: Add ACPI S3 support) suspend to RAM and resume works now on the ASRock E350M1! I successfully tested it under Debian 8.2 with the Linux kernel 4.2. If somebody wants to test Microsoft Windows or other operating systems, that would be interesting. It’s great to see the coreboot support on this “old” AMD desktop board, using AGESA, getting more and more complete. It’s also the board some developers use to test 64-bit coreboot on – thanks, Scott and Stefan! So to my knowledge the missing piece are to get the PS/2 controller going. Getting rid of the SMU(?) and ATOMBIOS is probably not going to happen though. Kyösti, big thanks again! Thanks, Paul [1] http://review.coreboot.org/12215

4 years, 10 months

Re: [coreboot] Re : FOSDEM deadlines now!

by Zaolin

I will be there. Regards Zaolin > [DEADLINE IS NOW+48 hours!] > Hi, > > thanks to Paul and Florentin for announcing they will come and thanks > to > Paul for submitting a talk! > > Who else is coming? > Do we want one or two tables? > > Regards, > Carl-Daniel > > On 21.10.2015 10:15, echelon(a)free.fr (Florentin) wrote: > > +1 > > > > * for the stands count me in : I can bring my AMD boards and if all > > is going well I will be able to do demos on my G505s laptop. (I > > will also bring various electronic stuff and tools..) > > * for the main tracks I cannot help unfortunately > > * for the lightining traks I have some (bold!) ideeas but they are > > not mature yet (and I must first discuss with you about this .. > > maybe on irc..) > > > On 31.10.2015 10:41, Paul Kocialkowski wrote: > > I will definitely be around at FOSDEM, not sure I should have a > > seat at > > the table at this point (I'm still pretty new to the community), > > but I'd > > be happy to come by! > > > ----- Mail d'origine ----- > > De: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> > > À: coreboot <coreboot(a)coreboot.org>, flashrom < > > flashrom(a)flashrom.org> > > Envoyé: Tue, 20 Oct 2015 23:20:56 +0200 (CEST) > > Objet: [coreboot] FOSDEM deadlines now! > > > > Hi, > > > > we obviously want to participate in FOSDEM. > > https://fosdem.org/2016/news/2015-09-24-call-for-participation/ > > > > ACT NOW! > > > > Some deadlines already expired. Some can still be managed. > > > > Main track talks: Deadline 2015-10-30 (10 days left) > > One hour of entertainment, huge audience. > > Anyone up for the challenge? > > > > Stands: Deadline 2015-11-13 (24 days left) > > I can send in the proposal if I'm not going to be alone there. > > How many tables do we want for our stand/booth(s)? > > Who is coming? > > > > Lightning talks: Deadline 2015-11-27 (38 days left) > > Short and to the point. Your 15-minute elevator pitch. > > Can you sell the project? > > > > All deadlines are at 23.59 UTC > > > > Developer room proposal: Deadline EXPIRED > > Maybe some developer room will accept talks/demos from us. > > > > Regards, > > Carl-Daniel > > > > > >

4 years, 10 months

Re: [coreboot] Fwd: sgabios ans grub2 payload (without SeaBIOS)

by Stefan Reinauer

* maxime de Roucy <maxime.deroucy(a)gmail.com> [151105 10:32]: > ---------- Forwarded message ---------- > From: maxime de Roucy <maxime.deroucy(a)gmail.com> > Date: 2015-11-05 10:25 GMT+01:00 > Subject: Re: [coreboot] sgabios ans grub2 payload (without SeaBIOS) > To: Gerd Hoffmann <kraxel(a)redhat.com> > > 2015-11-05 10:16 GMT+01:00 Gerd Hoffmann <kraxel(a)redhat.com>: > > That isn't going to work I think. sgabios works by hijaking vgabios, > > and when loaded as coreboot payload grub2 probably will not try to use > > vgabios in the first place ... > > It works great when sgabios is run by SeaBIOS even if serial support > disable in seabios and grub (so I am sure the serial output is > generated by sgabios). Without SeaBIOS there is no way of doing intXX callbacks after coreboot is finished running, that is why you wouldn't see any output in that case. Your two options are indeed to put the serial (or whatever output) code in grub2 directly, or use SeaBIOS as an intermediate step. Stefan

4 years, 10 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2015