coreboot February 2016

coreboot@coreboot.org

31 participants
69 discussions

Can not have IRQ from ethernet device connected to the PCIe #4 in legacy mode
by benoit 11 Feb '16

11 Feb '16

Hi all, I am facing a legacy IRQ under OS. I am currently using Coreboot + FSP on baytrail. My OS is running with IRQ in legacy using PIRQ described in coreboot/src/mainboard/intel/bayleybay_fsp/irqroute.h . Under the OS USB, SATA, SMBus are working well using legacy interrupt. Nevertheless I have an ethernet device connected on the PCIe root #4 and no IRQs are received. I tried to change the IRQ in the interrupt line register without success. I can compare also with a Phoenix BIOS, and with the same OS binary the ethernet is working. I check out also the ilb registers + 0x4d0 and 0x4d1 registers (ECL). Everything is correctly initalized. Do I need to activate/deactivate something in the PCIe root #4 to forward legacy interrupt to the 8259 PIC ? Many thanks in advance Benoit

2 1

Re: [coreboot] RFC: coding style: "standard" defines
by Alex G. 10 Feb '16

10 Feb '16

On 02/08/2016 11:29 AM, Julius Werner wrote: >>> On 08.02.2016 12:10, Patrick Georgi via coreboot wrote: >>>> 2016-02-04 10:35 GMT+01:00 Patrick Georgi <pgeorgi(a)google.com>: >>>>> during the review of some commits that are in the process of being >>>>> upstreamed from Chrome OS, people noticed that chipset drivers like to >>>>> define their own TRUE/FALSE defines (sometimes prefixed to), and I >>>>> have seen a bunch of #define BIT{0-31} ..., too, because that seems to >>>>> be the house rules in some firmware communities. >>>> Seems like for the BIT defines, all variants are popular. Any >>>> objection with moving them to src/include instead of having various >>>> copies across the tree? >>> How about something like src/include/please_dont_use.h ? >>> >> I don't know about that but I'd have no objection to a comment in the file >> itself that these are vile constructs. > > If we agree on what not to use, why not just fix it completely? > coccinelle is great for that sort of thing. > (For the record, I don't mind BIT(x) too much but I also prefer (1 << > x), since it's more consistent with multi-bit fields like (5 << x).) Other than BITxx macros, really, what's the purpose of this? Sure, standardization sounds great, but can anyone point to reasons why _not_ standardizing results in loss of productivity? As I've said before, we do import code from other codebases, which oftentimes are not even self-consistent. There's loss in productivity from being forced to convert one style of bit macro to another. Just from that, it seems that trying to "standardize" is a net loss. Pretty code is useless when it's slow and clumsy to write. Alex

1 0

Google Summer of Code 2016
by Patrick Georgi 09 Feb '16

09 Feb '16

Hi all, so Google just announced[0] that they're running their Summer of Code program again. I'm preparing to be the project admin this year, but to make this real we'll need contributors that are willing to step up as mentors. I need to know the number of candidates by Feb 19th, and we're told by end of February if we participate in the program this year. If so, students will apply in March and we'll try to find mentors for them (ideally two per student). We expect mentors to help students get comfortable in the community and to support them with their project. The "active" time for students (and thus also mentors) begins late April with the "community bonding period" and ends late August with the end of the "coding" phase of the program. Mentors should be available for their students in that time frame, although one reason for planning for two mentors per students is to allow for vacation and the like. If you're still interested in mentoring, please tell me so I can update the number of mentor candidates (which I need to state in the project's application to GSoC). If you have ideas that are possible to work through with ~3 months of effort by a new contributor, please add them to our project ideas wiki page[1] (that I still need to clean up a bit). Thanks, Patrick [0] https://summerofcode.withgoogle.com/ [1] https://www.coreboot.org/Project_Ideas -- 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

1 0

Removed boards list.
by Denis 'GNUtoo' Carikli 09 Feb '16

09 Feb '16

Hi, When boards are removed, they are also automatically removed from the supported boards page[1] in the wiki. The unfortunate downside is that, assuming that coreboot worked fine on such boards in the past (and may still do), they don't show up in any list. A place where to put the list of such boards already exist in the wiki[2]. Would it be possible to get such page updated (for instance by the commit author) when the commit has been pushed to master? A pointer to the commit would also be very appreciated, like I did in "Graveyard (v4, - v4.2)" status. The use case I had in mind was to make it easier to check if a given board was supported, and how (by pointing to its commit). References: ----------- [1]https://www.coreboot.org/Supported_Motherboards [2]https://www.coreboot.org/Graveyard Denis.

2 1

Re: [coreboot] RFC: coding style: "standard" defines
by Julius Werner 08 Feb '16

08 Feb '16

>> On 08.02.2016 12:10, Patrick Georgi via coreboot wrote: >> > 2016-02-04 10:35 GMT+01:00 Patrick Georgi <pgeorgi(a)google.com>: >> >> during the review of some commits that are in the process of being >> >> upstreamed from Chrome OS, people noticed that chipset drivers like to >> >> define their own TRUE/FALSE defines (sometimes prefixed to), and I >> >> have seen a bunch of #define BIT{0-31} ..., too, because that seems to >> >> be the house rules in some firmware communities. >> > Seems like for the BIT defines, all variants are popular. Any >> > objection with moving them to src/include instead of having various >> > copies across the tree? >> How about something like src/include/please_dont_use.h ? >> > I don't know about that but I'd have no objection to a comment in the file > itself that these are vile constructs. If we agree on what not to use, why not just fix it completely? coccinelle is great for that sort of thing. (For the record, I don't mind BIT(x) too much but I also prefer (1 << x), since it's more consistent with multi-bit fields like (5 << x).)

1 0

Re: [coreboot] RFC: coding style: "standard" defines
by Nico Huber 08 Feb '16

08 Feb '16

On 08.02.2016 12:10, Patrick Georgi via coreboot wrote: > 2016-02-04 10:35 GMT+01:00 Patrick Georgi <pgeorgi(a)google.com>: >> during the review of some commits that are in the process of being >> upstreamed from Chrome OS, people noticed that chipset drivers like to >> define their own TRUE/FALSE defines (sometimes prefixed to), and I >> have seen a bunch of #define BIT{0-31} ..., too, because that seems to >> be the house rules in some firmware communities. > Seems like for the BIT defines, all variants are popular. Any > objection with moving them to src/include instead of having various > copies across the tree? How about something like src/include/please_dont_use.h ? Nico

2 1

Re: [coreboot] RFC: coding style: "standard" defines
by ron minnich 08 Feb '16

08 Feb '16

makes sense to me. On Mon, Feb 8, 2016 at 3:10 AM Patrick Georgi via coreboot < coreboot(a)coreboot.org> wrote: > 2016-02-04 10:35 GMT+01:00 Patrick Georgi <pgeorgi(a)google.com>: > > during the review of some commits that are in the process of being > > upstreamed from Chrome OS, people noticed that chipset drivers like to > > define their own TRUE/FALSE defines (sometimes prefixed to), and I > > have seen a bunch of #define BIT{0-31} ..., too, because that seems to > > be the house rules in some firmware communities. > Seems like for the BIT defines, all variants are popular. Any > objection with moving them to src/include instead of having various > copies across the tree? > > > 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 > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] RFC: coding style: "standard" defines
by Patrick Georgi 08 Feb '16

08 Feb '16

2016-02-04 10:35 GMT+01:00 Patrick Georgi <pgeorgi(a)google.com>: > during the review of some commits that are in the process of being > upstreamed from Chrome OS, people noticed that chipset drivers like to > define their own TRUE/FALSE defines (sometimes prefixed to), and I > have seen a bunch of #define BIT{0-31} ..., too, because that seems to > be the house rules in some firmware communities. Seems like for the BIT defines, all variants are popular. Any objection with moving them to src/include instead of having various copies across the tree? 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

1 0

Lenovo Thinkpad Yoga 11e (Windows Version)
by Christopher Grossarth 05 Feb '16

05 Feb '16

I would like to build coreboot for the Thinkpad Yoga 11e (Model 20DAS02N00). It is the Windows version of the hardware, with a 2.5" HDD, ethernet port, and removable RAM chips (currently 2x4GB). I do not know the best procedure for this; should I attempt to edit the GLIMMER board config to more closely match the differences in the hardwares, or start with a RAMBI config and build off that? I have succesfully built and flashed libreboot for the Macbook 2,1, but libreboot is limited to a few models and the documentation is vague for building for new boards. Any help will be greatly appreciated. Best, -nobodyweird

1 0

Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
by Alex G. 05 Feb '16

05 Feb '16

On 02/01/2016 11:36 AM, Martin Roth wrote: > What I don't read in that blog post is anything about the > coreboot project being a democracy. I'd normally find such a statement very disappointing, but I'm pretty certain you're off on that one. I'm not sure how involved you've been in coreboot public before leaving SAGE -- I've mostly known your name from patches Marc submitted. What I can tell you with great confidence is that the picture you try to portray of coreboot has historically not been true. I've been around for a long time, maybe too long, and I remember many an issue having been publicly discussed. I remember cases where things were brought up for discussion, and the so-called leadership team decided the exact opposite of what it had intended. I remember the switch to git and gerrit, and I remember seeing quite some back and forth on the issue. I'm not sure why you have such a dark picture of coreboot in your mind. I've haven't heard anyone from the so-called "coreboot leadership" team make the claims you do. I'm sorry you feel that way, but that shouldn't be a reason to shut down Paul's proposal > Please note that these are just my own personal thoughts on these > subjects Exactly! Alex

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 February 2016