coreboot December 2013

coreboot@coreboot.org

40 participants
108 discussions

Re: [coreboot] [Bug 66261] Kernel oops upon reboot from suspend - Flashed Acer C7 using coreboot
by Christopher Lang 08 Dec '13

08 Dec '13

Hi, I have a suspend issue using mainline kernel 3.12.02 on Ubuntu 13.10. I am using the latest coreboot branch and the latest seabios branch. I have built coreboot using the reference tool set. The issue is that the system suspends but upon resume the kernel oops. The hardware is an Acer C7 Parrot board. I have attached the kernel config, coreboot config and the kernel oops message log. Thanks for your help. Chris On Wed, Dec 4, 2013 at 7:09 PM, Stefan Reinauer <reinauer(a)google.com> wrote: > Yeah sending some info to the coreboot mailing list would be best I > think... A kernel oops could be helpful, plus your configuration of the > kernel, coreboot, etc. > > > On Wed, Dec 4, 2013 at 5:01 PM, Christopher Lang < > christopherlang1(a)gmail.com> wrote: > >> Hi Stefan, >> >> >> >> Thanks for getting back to me and for the info. I just built the >> reference toolchain and am going to recompile and that build to test again. >> I am using mainline kernels (3.11 and 3.12.2) with Ubuntu. If it still >> fails should I send something to the coreboot list or the kernel list? What >> sort of diagnostic information would be required? I do get a crash log of >> the kernel oops, but no vmcore is generated. >> >> >> >> Thanks, >> >> >> >> Chris >> >> >> >> >> >> *From:* Stefan Reinauer [mailto:reinauer@google.com] >> *Sent:* Wednesday, December 4, 2013 18:54 >> *To:* Christopher Lang >> >> *Subject:* Re: [Bug 66261] Kernel oops upon reboot from suspend - >> Flashed Acer C7 using coreboot >> >> >> >> Yes, the ACPI tables should be identical. >> >> >> >> On Sun, Dec 1, 2013 at 5:38 PM, Christopher Lang < >> christopherlang1(a)gmail.com> wrote: >> >> Hi Stefan, >> >> For the Acer C7 'Parrot' are the coreboot acpi tables the same acpi >> tables as the official ChromeOS bios? I have been trying to use a coreboot >> bios with my C7 and suspend does not work properly. The system suspends but >> upon resume the kernel oops. I have tried multiple kernel versions (3.11 >> and 3.12) and am also trying the latest coreboot from the coreboot git. >> Please let me know if I should post this to the coreboot mailing list. >> >> Thanks, >> >> Chris >> >> >> >> ---------- Forwarded message ---------- >> From: *Christopher Lang* <christopherlang1(a)gmail.com> >> Date: Sun, Dec 1, 2013 at 7:31 PM >> Subject: Re: [Bug 66261] Kernel oops upon reboot from suspend - Flashed >> Acer C7 using coreboot >> To: bugzilla-daemon(a)bugzilla.kernel.org >> >> Hi Aaron, I will ask. I should think they have the same tables since the >> support came from Google. >> >> Thanks, >> >> Chris >> >> >> >> On Sun, Dec 1, 2013 at 7:19 PM, <bugzilla-daemon(a)bugzilla.kernel.org> >> wrote: >> >> https://bugzilla.kernel.org/show_bug.cgi?id=66261 >> >> --- Comment #4 from Aaron Lu <aaron.lu(a)intel.com> --- >> I think you can ask this on coreboot's mailing list, they may know better. >> >> -- >> You are receiving this mail because: >> You are on the CC list for the bug. >> You reported the bug. >> >> >> >> >> >> >> >> >> >> -- >> >> Stefan Reinauer >> >> Google Inc. >> > > > > -- > Stefan Reinauer > Google Inc. >

1 0

Re: [coreboot] INTEL FSP support coreboot-v4.0-4966
by mrnuke 08 Dec '13

08 Dec '13

On 12/07/2013 06:01 PM, ron minnich wrote: > On Sat, Dec 7, 2013 at 2:59 PM, mrnuke <mr.nuke.me(a)gmail.com> wrote: > >> The best option is to have the source of FSP's payload under >> src/vendorcode/fsp. >> >> There, I fixed it for you. Can I have a cookie now? > > not until you tell me what that means. FSP's payload? What's that? > If FSP is the vehicle, as you've put it, then the executable code it contains is the payload, and that payload was not created from a computer's arse. It has a source (code). Alex

1 0

Re: [coreboot] INTEL FSP support coreboot-v4.0-4966
by mrnuke 08 Dec '13

08 Dec '13

On 12/07/2013 04:38 PM, ron minnich wrote: > On Sat, Dec 7, 2013 at 2:34 PM, mrnuke <mr.nuke.me(a)gmail.com> wrote: >> The best option is to have the FSP source under src/vendorcode/fsp. >> That's also the only way people can comment on, and help improve the >> API. This already happened with CIMX and AGESA. > > FSP is a delivery vehicle for binary code. It is designed to be a > binary blob with well-defined entry points. > > So, what you're saying is "the best option for delivering the binary > blob is to be delivered as not a binary blob." > > At that point my head explodes as I try to parse the contradiction. :-) > The best option is to have the source of FSP's payload under src/vendorcode/fsp. There, I fixed it for you. Can I have a cookie now? Alex

2 1

Please test (microcode updates on older Intel CPU processors)
by mrnuke 08 Dec '13

08 Dec '13

Please test: http://review.coreboot.org/4495 Console output in case the microcode is not updated is also nice. Thanks, Alex

1 0

Re: [coreboot] Supported Mainboards page
by mrnuke 07 Dec '13

07 Dec '13

On 12/07/2013 04:39 PM, ron minnich wrote: > On Sat, Dec 7, 2013 at 2:31 PM, mrnuke <mr.nuke.me(a)gmail.com> wrote: >> On 12/07/2013 02:26 AM, Patrick Georgi wrote: >>> Long term, I'd love to autogenerate them from data in the source tree - >>> some yet to invent status.{txt,yaml,whatever that is not xml} in each >>> board's directory. >>> >> For that, markdown is very nice. Just put a README.md in the >> ${maiboard_dir}. >> > > > For any of this, patches, not email messages, are very nice :-) > > ron > You know I always speak out of my arse, expecting someone else to do the legwork. :p Alex

1 0

Supported Mainboards page
by Patrick Georgi 07 Dec '13

07 Dec '13

Hi, as you might have noticed, http://www.coreboot.org/Supported_Motherboards looks slightly different from what it looked like yesterday. (and if you didn’t, the old version is still available at http://www.coreboot.org/Supported_Motherboards/old). The new version looks boring, and one could think there’s no board supported at all in coreboot. Which might in fact be true - what is the most recent commit on coreboot master that was booted on, let’s say, getac/p470? This is where you come in: The page is generated from data pushed into the board-status repository (no review desired, even though it’s hosted on review.coreboot.org - just push to master). coreboot's util/board_status/ contains the tools to compile that data. The more often you can show that your system runs a recent coreboot build, the better its support looks like on the page. The wiki-page generation scripts are in that repository (but will likely move to coreboot’s util/ soon), so if you have proposals on how to improve matter, patches (and later: changesets on gerrit) are welcome! Patrick

5 7

Re: [coreboot] INTEL FSP support coreboot-v4.0-4966
by mrnuke 07 Dec '13

07 Dec '13

On 12/06/2013 10:47 AM, ron minnich wrote: > Here are my thoughts on FSP. > > FSP is how we deal with a bad situation: the fact that Intel chipsets > are no longer open (the way they were until 2000 or so) and require a > binary blob from Intel to get them working. > The best option is to have the FSP source under src/vendorcode/fsp. That's also the only way people can comment on, and help improve the API. This already happened with CIMX and AGESA. Alex

2 1

On using multiple email addresses on gerrit
by Patrick Georgi 07 Dec '13

07 Dec '13

Hi, I removed the "forge author" capability on gerrit. Up to now this allowed to push commits where the git "Author:" field is different from your registered gerrit email addresses. I know there are a number of users that use their regular email address as well as some other address for OpenID-authentication and rely on this feature. Instead, please add your regular email addresses on http://review.coreboot.org/#/settings/contact (Register New Email...), so gerrit knows how to match them up. In case of problems, please contact me privately, so we can sort things out. Thanks, Patrick

1 0

Re: [coreboot] libpayload not building drivers/usb/xhci.c
by mrnuke 07 Dec '13

07 Dec '13

On 12/03/2013 11:37 AM, Dave Frodin wrote: > I'm seeing a problem building payloads. The problem is actually occuring > when libpayload gets built prior > to being copied down to the payload. I'm building a different payload, > but the problem can be seen > when building coreinfo. Here's the sequence I used > Just noticed this today > drivers/usb/xhci.c:146:1: error: conflicting types for ‘xhci_init’ > In file included from drivers/usb/xhci.c:36:0: > drivers/usb/xhci.h:37:8: note: previous declaration of ‘xhci_init’ was her'e void * vs const void * > drivers/usb/xhci.c: In function ‘xhci_pci_init’: > drivers/usb/xhci.c:314:13: error: incompatible types when assigning to > type ‘hci_t’ from type ‘struct hci_t *’ > drivers/usb/xhci.c:315:12: error: invalid type argument of ‘->’ (have > ‘hci_t’) > drivers/usb/xhci.c:319:2: error: incompatible types when returning type > ‘hci_t’ but ‘struct hci_t *’ was expected > drivers/usb/xhci.c: In function ‘xhci_shutdown’: > drivers/usb/xhci.c:417:38: error: ‘hci_t’ has no member named ‘bus_address’ > drivers/usb/xhci.c: In function ‘xhci_pci_init’: > drivers/usb/xhci.c:320:1: warning: control reaches end of non-void > function [-Wreturn-type] > Yup. looks like the xhci changes weren't properly tested. > I bisected the problem down to this commit > > commit 8992e53c23cb088efbdafbf3e2ba77e7d8778d71 > Author: Stefan Reinauer <reinauer(a)chromium.org > <mailto:reinauer@chromium.org>> > Date: Thu May 2 16:16:41 2013 -0700 > Stefan, not you.

1 0

Re: [coreboot] Lenovo X201i
by Vladimir 'φ-coder/phcoder' Serbinenko 06 Dec '13

06 Dec '13

On 30.11.2013 17:51, Chris Mailer wrote: > Hello Coreboot, > > I would like to play around with Coreboot on a Lenovo X201i convertible > laptop. > According to http://www.coreboot.org/Supported_Motherboards#Laptops and > some wiki-entries Coreboot does do well on the X201. Does this imply > Coreboot will do on a X201i (<-note the "i"), as to my knowledge the > only difference between these two versions is that the latter one > features a multitouch touchscreen? > Thank you in advance! > My tree should work on X201i as well. The screen probably doesn't matter unless it has different vbt in which case you'll need to change fake vbt or use VGA option ROM. Some X201 submodels may have weird differences The top of my thread is http://review.coreboot.org/#/c/3408/ In any case you need external flasher and follow intstructions on the wiki. If it fails you can always reflash original BIOS. > Chris > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2013