coreboot March 2013

coreboot@coreboot.org

46 participants
782 discussions

Gene 5315 Rev.B
by sergey 25 Mar '13

25 Mar '13

Hello. I want use "coreboot" on my computer. In computer installed board Gene 5315 Rev.B . List of supported boards contains board with name "LiPPERT Cool RoadRunner-LX", which have identical configuration with "Gene". Can I use coreboot image at "LiPPERT" for programming flash chip of "Gene"? Thanks.

1 0

T60: Waking up from suspend to disk (`s2disk`) sometimes fails with `PM: Image mismatch: …`
by Paul Menzel 24 Mar '13

24 Mar '13

Dear coreboot folks, before reporting this problem to the Linux hibernation folks (<linux-pm(a)vger.kernel.org>), could you please confirm that you have seen this problem or if it is likely to be caused by using coreboot? DMI: LENOVO ThinkPad T60 / T60p, BIOS 4.0-2807-g4807892 10/04/2012 This is basically the Peter’s patchset »lenovo/t60 lenovo/x60: Override SMBIOS vendor name to all upper case« [1], which is based on the following commit. commit 1ee8b45740a2c888742cb5917ca71cd0ed86cec2 Author: Siyuan Wang <wangsiyuanbuaa(a)gmail.com> Date: Fri Sep 7 19:20:02 2012 +0800 add tyan s8226: add a new mainboard Reviewed-on: http://review.coreboot.org/1495 I reported this issue to the Debian Bug Tracking System (BTS) already, where it is tracked under the number #703787 [2], and I paste my report below. Using Debian you can import the message using `bts show --mbox 703787`. The program `bts` is packaged in `devscripts`. ---- 8< ----- >8 ---- Dear Debian folks, running Debian Wheezy/testing on a Lenovo T60 with coreboot and SeaBIOS (not sure about vendor BIOS) after having done `s2disk` three or four times, sometimes the previous session is not loaded and it boots normally. Looking at the Linux messages, I see the following /var/log/kern.log:Mar 23 02:18:42 myhostname kernel: [ 17.878056] PM: Image mismatch: memory size or /var/log/kern.log.1:Mar 17 10:33:16 myhostname kernel: [ 53.905020] PM: Image mismatch: kernel version written several times to the log files. Strangely some message seem to be not written to disk as seen by the missing »I« in »Image«. Mar 22 17:56:07 myhostname kernel: [73413.739108] PM: Basic memory bitmaps created Mar 23 02:18:42 myhostname kernel: imklog 5.8.11, log source = /proc/kmsg started. Mar 23 02:18:42 myhostname kernel: mage mismatch: memory size Mar 23 02:18:42 myhostname kernel: [ 17.878056] PM: Image mismatch: memory size Do you have any idea how that can happen? I am sure that nothing was changed about the memory. The second one might be due to an Linux kernel package upgrade. Aptitude 0.6.8.2: Protokoll So, 17. Mär 2013 00:10:11 +0100 WICHTIG: Dieses Protokoll zeigt nur geplante Aktionen an. Aktionen, die wegen dpkg-Problemen fehlschlagen, sind vielleicht nicht abgeschlossen. 86 Pakete werden installiert und 2 Pakete entfernt. 676 kB der Festplatte werden belegt. =============================================================================== […] [AKTUALISIERUNG] linux-image-3.2.0-4-686-pae:i386 3.2.35-2 -> 3.2.39-2 [AKTUALISIERUNG] linux-libc-dev:i386 3.2.35-2 -> 3.2.39-2 […] So might there be two problems or just one? Though this should not happen according to a comment in a reply on the pm-utils list [1]. I am attaching the corresponding `kern.log{,1.}.log` files containing the logs of Linux from the working suspend to disk cycles and the non-working ones. Thanks, Paul [1] http://lists.freedesktop.org/archives/pm-utils/2010-April/002117.html ---- 8< ----- >8 ---- Thanks, Paul [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703787 [2] http://review.coreboot.org/#/c/1557/

1 0

Re: [coreboot] RFC GSOC project idea ACPI 4.0/5.0 APIE and ERST for kernel pstore support
by QingPei Wang 22 Mar '13

22 Mar '13

for GSOC students, i think this ideas would be enough for new guys. we can not assume the potential guy is much familiar with coreboot. Best wishes QingPei Wang Phone: 86+18930528086 On Thu, Mar 21, 2013 at 4:53 AM, Marc Jones <marcj303(a)gmail.com> wrote: > On Wed, Mar 20, 2013 at 2:26 PM, Patrick Georgi <patrick(a)georgi-clan.de> > wrote: > > Am 20.03.2013 21:09, schrieb Marc Jones: > >> The ACPI APIE and ERST methods allow the kernel to mount pstore to > >> store information in NVRAM (coreboot cbfs). This could be used to > >> store errors that are otherwise difficult to track, like suspend and > >> resume issues. The implementation would need to be able to find an > >> area free in cbfs for storing the data. > > Reserve it beforehand? That's what I intend to do for Tiano variables > > Yes, I think we would need a cbfs file for allocating the region > before hand and then that would be used by ERST and pstore. I don' t > know how the region internals work. Also, there are problaly some > pstore limitation and knowing the flash device before hand to set > alignment (erase blocks) etc. > > Marc > > -- > http://se-eng.com > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

coreboot-libpayload 'size_t' conflicting type error
by Pradish Moorkkth Puttan Vettil 21 Mar '13

21 Mar '13

Hi**** ** ** I have downloaded the latest coreboot source and was able to build and setup the coreboot.rom**** And was able to boot on a QEMU emulator.**** ** ** Next I tried to build libpayload and when I do “make install “ it gives the following error**** ** ** /coreboot/payloads/libpayload$ make install**** CC libpci/libpci.libpci.o**** In File included from include/libpayload.h:54:0,**** from libpci/libpci.c:30:**** include/x86/arch/types.h:56:22: error: conflicting types for 'size_t'**** In file included from include/libpayload.h:49:0,**** from libpci/libpci.c:30:**** /home/pradish/coreboot/util/crossgcc/xgcc/lib/gcc/i386-elf/4.7.2/include/stdded.h:213:23: note: previous declaration of 'size_t' was here**** make: ***[build/libpci/libpci.libpci.o] Error 1**** ** ** pradish@pradish-VrtualBox:~/coreboot/paylaods/libpayload$**** ** ** can you tell me, how to resolve this , I have not any changes to the source code. Just performed ‘make’**** ** ** regards**** pradish

1 0

[RFC] GSoC proposal: Native graphics init for AMD/ATI graphics hardware
by Paul Menzel 20 Mar '13

20 Mar '13

Dear coreboot folks, similar to implementing native graphics for Intel hardware to replace the Video BIOS [1], which brings down the time from 1.5 seconds with the Video BIOS to 200 ms with native graphics init [2], the same should be done for hardware with AMD/ATI graphics. Would such a project be feasible for Google Summer of Code 2013? 1. Is that even possible for AMD/ATI hardware in their current design with ATOM BIOS and firmware? 2. Surely some student and mentor have to be found for tackling this task. I could ask the Radeon and Linux DRM folks if they would be willing to join such an effort. (Though the AMD/ATI developers seem to be understaffed.) 3. Has anyone already thought about this idea? Thanks, Paul [1] https://docs.google.com/document/d/1g8FMob25VZYxbWri2iFB8YiSL8gwF9vKJH3HGxr… [2] http://review.coreboot.org/#/c/2531/5//COMMIT_MSG

5 5

Re: [coreboot] RFC GSOC project idea ACPI 4.0/5.0 APIE and ERST for kernel pstore support
by Patrick Georgi 20 Mar '13

20 Mar '13

Am 20.03.2013 21:09, schrieb Marc Jones: > The ACPI APIE and ERST methods allow the kernel to mount pstore to > store information in NVRAM (coreboot cbfs). This could be used to > store errors that are otherwise difficult to track, like suspend and > resume issues. The implementation would need to be able to find an > area free in cbfs for storing the data. Reserve it beforehand? That's what I intend to do for Tiano variables Patrick

2 1

RFC GSOC project idea ACPI 4.0/5.0 APIE and ERST for kernel pstore support
by Marc Jones 20 Mar '13

20 Mar '13

I could use some help flushing out this idea. The ACPI APIE and ERST methods allow the kernel to mount pstore to store information in NVRAM (coreboot cbfs). This could be used to store errors that are otherwise difficult to track, like suspend and resume issues. The implementation would need to be able to find an area free in cbfs for storing the data. https://lwn.net/Articles/434821/ I'm not sure that this is a full gsoc project. Maybe part of an ACPI update project. comments? Marc -- http://se-eng.com

1 0

Re: [coreboot] IORESOURCE_UMA_FB question
by Kyösti Mälkki 20 Mar '13

20 Mar '13

On Wed, 2013-03-20 at 10:30 -0500, Aaron Durbin wrote: > On Wed, Mar 20, 2013 at 1:10 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > > On Tue, 2013-03-19 at 23:16 -0500, Aaron Durbin wrote: > >> Hi corebooters, > >> > >> I'm trying to understand the reason for the existence of > >> IORESOURCE_UMA_FB. Is this to allow one to carve out an uncacheable > >> MTRR region for the UMA framebuffer? If so, why was that ram added as > >> cacheable to begin with? > >> > >> Thanks for the help. Full disclosure: I'd like to get rid of it and > >> handle these concepts in a different manner. > >> > >> -Aaron > >> > > > > Hi Aaron > > > > Reasons are in the poor implementation of variable MTRRs and choice of > > defined IORESOURCE flags. > > > > Variable MTRR routine causes excessive use of MTRRs when the cacheable > > resources do not add to powers of 2. Try describing 3 GiB - 128 MiB > > cacheable memory, and current variable MTRR routines might use 5 MTRRs > > for that (2048+1024+512+256+128 MiB). > > Understood. That 128MiB aligned UMA area met the 64MiB alignment > minimum in the current code which led to sub-optimal variable MTRR > usage. If I understand correctly, the only way for this scheme to > work is to include 1 large resource as IORESOURCE_CACHEABLE and have a > smaller IORESOURCE_UMA_FB resource. Correct? I am not sure if you want some regions for SMM/TSEG as un-cacheable or not. I believe you could use a new type of memory resource: IORESOURCE_RESERVE | IORESOURCE_CACHEABLE When programming MTRRs these would merge with any adjacent ram_resource(), but would be exluced from OS in coreboot table. But as that variable MTRR routine is so bad, any IORESOURCE_CACHEABLE resources must be added in order and they must not overlap. > > I did quite a few changes on this topic last summer to fix issues with > > AMD boards with 4GB or more RAM. I believe I received enough change > > resistance to not touch MTRR further. > > I'm not sure what 4GiB or more of RAM has to do w/ the non-optimal > variable MTRR usage. However, I've run into this very issue recently > (use too many MTRRs). Why wasn't a more suitable IO hole used? i.e. > largest memory address below 4GiB is 2^N + UMA memory size. Were you > then getting bit on the upper end (cacheable area above 4GiB) ? There may be issues with granularity of TOLM and UMA/framebuffer registers so you do not get to select the optimal base for UMA and avoid use of un-cacheable MTRR hole. For AMD there are some hardware straps involved in setting UMA/frame-buffer base and I think the decision on TOLM is done in vendorcode. > > > > Also see: http://review.coreboot.org/#/c/1431 > > Thanks for the context. I'm looking into removing > IORESOURCE_IGNORE_MTRR as that is the wrong layer to deal with OS > reserved address space. However, I wanted to properly handle the > UMA_FB type as well. Longer term, I think we can get rid of UMA_FB > too, but that will require a smarter MTRR algorithm. > > Thanks again. > > -Aaron Use of IGNORE_MTRR allows you to place a resource within a previously added ram_resource(), that was used for bad_ram_resource() for sandybridge. You could get rid of that if variable MTRR routines were improved to split and merge regions the same way coreboot table does. As for UMA_FB, I think renaming would be in order but I believe the need to carve out un-cacheable hole remains -- the base of un-cacheable region remains to be sub-optimal for some cases. Of course, if the region is un-cacheable by other rule already, this would not use additional MTRR. Kyösti

2 1

Re: [coreboot] amd_mtrr.c
by Kyösti Mälkki 20 Mar '13

20 Mar '13

On Wed, 2013-03-20 at 10:50 -0500, Aaron Durbin wrote: > Hello folks, > > I'd like to be enlightened on the amd_mtrr.c in src/cpu/amd/mtrr. I > can see there is a Makefile.inc, but for the life of me I can't see > how that Makefile is included in any build. Is that just dead code? > > -Aaron > Included from socket Makefiles. Kyösti

2 1

amd_mtrr.c
by Aaron Durbin 20 Mar '13

20 Mar '13

Hello folks, I'd like to be enlightened on the amd_mtrr.c in src/cpu/amd/mtrr. I can see there is a Makefile.inc, but for the life of me I can't see how that Makefile is included in any build. Is that just dead code? -Aaron

1 0

← Newer
1
2
3
4
5
6
7
...
79
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 March 2013