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
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
[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
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:
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
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/
[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
>
>
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
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
> >
> >
>
>
* 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
