coreboot February 2015

coreboot@coreboot.org

45 participants
93 discussions

GSoC 2015
by Carl-Daniel Hailfinger 10 Feb '15

10 Feb '15

Applications for organizations are open again. The deadline is very short this time: Only 10 days! http://www.google-melange.com/gsoc/homepage/google/gsoc2015 Regards, Carl-Daniel

4 3

Re: [coreboot] New interface for I2C in coreboot
by Julius Werner 10 Feb '15

10 Feb '15

I think the idea behind this change was mostly that the old API was too inflexible and some I2C device drivers could not be properly written with it. Take a look at line 139 in this file from the first patch: http://review.coreboot.org/#/c/7751/3/src/drivers/i2c/tpm/tpm.c@139 . What this really does is trying to do all of the normal parts of an I2C read transaction manually, because TPMs can add so long delays at any point that the normal I2C controller drivers would already hit their timeout. With the old API this was only possible with a crude hack of setting the address length to 0 (so i2c_read() would skip the register address write completely). Doing a "raw read" with the new API does the same thing much clearer, and it's far more obvious to controller driver authors that they need to implement this (otherwise, it's easy to just assume alen == 0 is illegal until someone tries to use the TPM driver with it, which I think is what hit us on Tegra). The new API also makes the rules about when to use a repeated start vs a complete stop and start much clearer (which should not make a difference for the device, but in practice sometimes does). I think Werner's original issue is easy to solve: you can either just construct struct i2c_seg structures and call i2c_transfer() directly, or implement a new i2c_write() wrapper similar to i2c_writeb() (just with a variable data length). Maybe even just make i2c_writeb() a one-line wrapper macro on top of the new function... all fine by me, I think the only reason we didn't make more convenience functions is because we didn't need them at the time. The implementation problems Patrick mentioned are unfortunately true for some controllers which attempt to be more clever than they should... however, the thing is that we need to somehow implement raw I2C reads anyway (to support the alen == 0 case in the old API and make things like that TPM driver work). In the end we probably need to implement less primitives for the new API ("raw write" and "raw read") than for the old one ("full write", "full read", "raw write" and "raw read"). If that means we end up not using the do-everything-in-one-transaction "feature" of some controllers in favor of more controllable low-level accesses, I don't see a problem with that.

1 0

Re: [coreboot] coreboot code of conduct
by Carl-Daniel Hailfinger 10 Feb '15

10 Feb '15

On 16.01.2015 19:15, Marc Jones wrote: > A coreboot code of conduct has been posted on the wiki. > - http://www.coreboot.org/Code_of_Conduct > > I have written a blog post about why we have a code of conduct. > - http://blogs.coreboot.org/blog/2015/01/16/coreboot-code-of-conduct/ > > Feel free to give feedback on the policy and how else we can contribute to > a welcoming and collaborative environment. How do we handle a conflict between our own Code of Conduct and the Code of Conduct of a conference where coreboot is participating? Will we ignore our own CoC or will we simply not attend? Does it depend on whether the CoC is similar in spirit or not? Some conferences declare their own CoC as binding for everyone and disallow participating projects from enforcing any project CoC. Other conferences allow every participating project to declare the project CoC as binding. Having a Code of Conduct is no silver bullet against people criticizing you on the internet: The FOSDEM conference has a CoC on every printed conference programme, tells attendees to report concerns to any staff member, and the contact phone number is of one of the female staff members. FOSDEM staff+volunteers will do everything possible to make you feel welcome at their conference. The number of reports of harassment for FOSDEM apparently is zero, both for reports to the staff and reports on the internet. That didn't help them, though. A quick google search will find a few people calling for a boycott of FOSDEM because they think the FOSDEM CoC is "no proper code of conduct", others complaining that "zero reports is not the same as zero occurrences" and claiming that if harassment happens at other conferences it also must have happened at FOSDEM. Some people even complained that FOSDEM allowed individual communities to declare their own community CoC as binding for the community developer rooms. The Code of Conduct yes/no problem is a no-win situation with ideological background. Regardless of what we do, someone will be unhappy. It is fundamentally similar to the blob yes/no problem in coreboot vs. libreboot. I sincerely hope this will not cause a community split into a coreboot-be-nice and a coreboot-CoC camp. Side note: Most advocates for a CoC on the internet seem to live in the US and/or have visited conferences in the US. The harassment reports I found online about tech conferences seem to have a statistical anomaly: a disproportionately higher amount of complaints about US conferences. Some female colleagues of mine prefer to visit conferences in the EU for that reason. I would love to see a solid statistical study about this, though. So far it's only a first impression for me. Regards, Carl-Daniel

1 0

Re: [coreboot] New interface for I2C in coreboot
by Alexandru Gagniuc 10 Feb '15

10 Feb '15

On Tuesday, February 10, 2015 07:29:33 AM Werner Zeh wrote: > Hi coreboot community. > Hi back at you. > 1. Store the offset we need (in this case 20) into a buffer > 2. Call i2c_write_raw(bus, chip_adr, &buffer, 1); > 3. Call i2c_read_raw(bus, chip_adr, &buffer,10); > That's actually the way I2C is designed to work, and this sort of API models it more accurately. Linux uses it. libeopencm uses it. spidev uses it. > Here are my personal problems with this kind of interface: Then provide utility functions to do i2c_reg_(read|write) which wrap i2c_transfer() directly. Construct the complete I2c transaction as an array of i2c_seg and pass that to i2c_transfer(). > 1. Where we earlier had one simple call to i2c_read(), we now have to fill > one variable with the length we need and call two different functions > (i2c_write_raw and i2c_read_raw). 2. Though the read transfer is one > logical access to the slave, we have split it into two (without any benefit > I can see now) 3. We have added two wrapper layers where we earlier had > none! > Not quite so. The i2c read/write of the past actually squashed together several steps, which ended up being more code as you had to fully model every sort of transaction you could think of doing. There's no extra wrapping. The code was just reorganized. Alex

2 1

New interface for I2C in coreboot
by Werner Zeh 09 Feb '15

09 Feb '15

Hi coreboot community. Although I am working on coreboot for now more than one year mostly behind the scenes I am fairly new on the contributor side. Yesterday, I have started contribution and one of my first value that I would like to give back to the community is a driver for I2C controllers that starts to get integrated into x86-chips from intel (Baytrail has one as well as X1000 Quark). Please be aware that this is not a driver for the well-known SMBus controller. I have written the driver a few weeks ago and at this time there was a pretty simple and therefore really generic interface for I2C buses in coreboot. The interface is described in src/include/device/i2c.h and was consist of two simple functions: i2c_read() and i2c_write(). With this interface the user of the driver (which in most of the cases will be another driver for let’s say an EEPROM) can simply call for instance the i2c_read()-function and provide as arguments the i2c-bus, the chip-address of the slave (EEPROM here), the address inside the slave, a length and a buffer where to store the driver. With these parameters, the I2C driver is able to read the desired data in one call and store them into the buffer provided. Similar procedure is for the write function. You can see that one logical transfer can be directly mapped to one function call of the driver (i2c_read or i2c_write). In mid-December 2014, the interface was changed massive by this two commits: 7947 and 7751. I have had a look at the new interface and what should I say: It is not only completely different (what in general would be OK for me) but it is in my point of view a step back. Let’s see what is happened here. The functions i2c_read() and i2c_write() where replaced by i2c_readb(), i2c_writeb(), i2c_read_raw() and i2c_write_raw(). The first two functions can read a single byte from a slave on a given register address (EEPROM address in my example here). The second two are meant to read a chunk of data from the slave. Both of the functions actually are a wrapper to call the real i2c driver interface called i2c_transfer(). But wait a moment…with the last two functions there is no way to tell the driver _where_ to start reading inside the slave. Let us have a closer look to how this interface can be used to transfer a chunk of data from a given address inside the slave. To do this, let us consider we want to read 10 bytes starting at offset 20. 1. Store the offset we need (in this case 20) into a buffer 2. Call i2c_write_raw(bus, chip_adr, &buffer, 1); 3. Call i2c_read_raw(bus, chip_adr, &buffer,10); Here are my personal problems with this kind of interface: 1. Where we earlier had one simple call to i2c_read(), we now have to fill one variable with the length we need and call two different functions (i2c_write_raw and i2c_read_raw). 2. Though the read transfer is one logical access to the slave, we have split it into two (without any benefit I can see now) 3. We have added two wrapper layers where we earlier had none! Unfortunately, the first two mentioned functions of the interface cannot be used for transferring more than byte because the length field is missing. In contrast, the two functions that have a length field do not have a slave address field. This is frustrating! If one have a hardware implemented I2C-controller in mind, this interface is really not that intuitive and simple. This is because we have to perform a function switch in the middle of a logical bus action. And: why should one perform i2c_write operation in order to read the data? This is not logical to me. I know that I2C bus works this way, but it is the responsibility of the driver to hide this from the user. And with this interface, this “hiding” is simply impossible because now the user have to do it! I do not see any benefits of this interface and I really cannot see the need for the introduced change in the interface. Of course it is technical possible to read and write data over I2C with this interface…but to be honest: I would not be proud of this solution! Of course we can add an address field to the i2c_read_raw and i2c_write_raw functions. But at the end we will end up with a complex interface for a very simple bus. And we will have several wrapper layers compared to the interface we had before. There is even no need of _one_ wrapper layer for this bus! I hope I was able to point out what my concern is about and want to discuss this with the community. I want to hear more opinions on this interface and at the end want to know whether it is worse to change my I2C driver to be used with this interface. The last point I will do if one can show me the _real_ benefit of the new interface. Thank you Werner

1 0

Bay trail and SATA legacy IDE mode
by Berth-Olof Bergman 08 Feb '15

08 Feb '15

Hi all, Has anyone run a Bay Trail SOC in SATA legacy IDE mode? It doesn’t work on my boards, even though I have identical settings of the PCI configuration space as AMI and Phoenix BIOS. The port works, but the IRQs are wrong polarity. Thus when issuing a command, I don’t get an interrupt. If I read the IDE status register (alternate or main) I get an interrupt. As reading the IDE status register, negates interrupt, I get the high level edge as the polarity is inverted. Can you verify if IDE legacy mode works for Bay Trail with correct? Best regards, B-O Bergman Winzent Technologies

2 1

updating coreboot && SeaBIOS on an Acer C720
by Matthias Apitz 08 Feb '15

08 Feb '15

Hello, I'm new to this list and do not even know if it is the right place to ask my question. So please be patient and/or forgive me. I'm running FreeBSD 11-HEAD on an Acer C720 Chromebook, booting directly into SeaBIOS. I'm facing seldom (let's say once a week with 12h++ uptime per day) problems of complete power-off of the device. I.e. the problem is not related to ChromeOS (because it is not running anymore in my C720) and perhaps unrelated to FreeBSD (because I see with Google Linux users with the same problem). Before returning the C720 to Acer, which perhaps say "we can not reproduce" your problem, I wanted to check if the problem is related to changes or bugs in coreboot or in SeaBIOS. I git'ed out both, but can't see any lists or release notes of fixed issues. My C720 says about version of BIOS: SeaBIOS ver. 20131001_113210-build123-m2, and about coreboot: BIOS Information Vendor: coreboot Version: Release Date: 08/13/2014 ROM Size: 8192 kB Characteristics: PCI is supported PC Card (PCMCIA) is supported BIOS is upgradeable Selectable boot is supported ACPI is supported Targeted content distribution is supported BIOS Revision: 4.0 Firmware Revision: 0.0 Thanks in advance for any pointers to related information, esp. to lists of fixed issues or release notes. matthias -- Matthias Apitz, guru(a)unixarea.de, http://www.unixarea.de/ +49-170-4527211 La referencia de la Duma a la anexión de la RDA, en este caso al contrario con la Crimlía sin referéndum, no solamente tiene gracia sino da en el blanco.- Marinos Yannikos @MarinosYannikos en un blog de RTdeutsch.

3 3

Re: [coreboot] coreboot code of conduct
by Carl-Daniel Hailfinger 07 Feb '15

07 Feb '15

Hi Marc, On 19.01.2015 01:49, Marc Jones wrote: > On Sat Jan 17 2015 at 8:12:20 PM Carl-Daniel Hailfinger wrote: >> Hi Marc, >> >> thanks for writing this up. >> >> On 16.01.2015 19:15, Marc Jones wrote: >>> A coreboot code of conduct has been posted on the wiki. >>> - http://www.coreboot.org/Code_of_Conduct >>> >>> I have written a blog post about why we have a code of conduct. >>> - http://blogs.coreboot.org/blog/2015/01/16/coreboot-code-of-conduct/ >>> >>> Feel free to give feedback on the policy and how else we can contribute >>> to a welcoming and collaborative environment. >> Given that the Code of Conduct has been announced publicly in a blog >> post, the feedback is probably expected to be public as well. Apologies >> if that is not the case. >> >> The current wording suggests that anyone can be expelled from the >> community permanently without warning for either perceived harrassment >> or for strongly enforcing the code of conduct. This is probably not the >> intention. > Open discussion is acceptable. Adding that sentence to the CoC would be helpful. >> Furthermore, the second paragraph of "Unacceptable Behaviour" is either >> redundant or woefully incomplete. If you really think the word >> "harassing" from the first paragraph needs to be defined, you should >> define the other words from the first paragraph "intimidating", >> "abusive", "discriminatory", "derogatory" and "demeaning" as well. I >> suggest deleting that second paragraph. > I'll disagree. Harassment is the most common problem in online communities Real citation needed, not just some sentiment. For example, quite a few feminist blogs point to intimidating and derogatory speech/actions as the primary hurdles against female participation in online communities. > and warrants the paragraph about those unacceptable behaviors. If harassment is the most common problem, that definitely warrants listing harassment first (which is not the case in the current CoC). > Defining > every other term would not make this policy any more robust. Is the term "harassment" so unclear it warrants explanation? I thought there was universal agreement that harassment is bad, but having to define harassment implies that there is no such universal agreement (you can't agree on something undefined). I argue that creating our own homegrown definition of harassment (or copying someone else's homegrown definition) makes this policy less robust because this current homegrown definition is woefully incomplete. >> Please define "community organizers". Did you mean "arbitration team"? >> Or is it the community members present at an event? > It isn't not meant to be specific to an arbitration team. These members may > not be present in all cases and organizers of events and online communities > should uphold the good standards of the community. Thanks for clarifying. The CoC would benefit from adding this clarification. >> How can we deploy this against people not part of our community? If >> they're not part of the community in the first place, it is by >> definition impossible to exclude them from our community and the Code of >> Conduct in its current form does not apply. If, on the other hand, we >> define everyone on the mailing list, everyone on IRC and everyone >> visiting our booths at various conferences and trade shows as being part >> of our community, we're going to overshoot the mark. I don't want to be >> guilty by association just because some troll on IRC joins all channels, >> spews some random offensive crap and disappears. > It applies to everyone that participates in coreboot communication, online, > at an event or in a conference booth. People that are not up to this > standard of behavior are not welcome in our community and they should be > asked to leave. If a troll joins and spams the channel, clearly ask them to > leave. If they don't leave report them to a channel or IRCOP. If there is a > question of the policy or of a behavior, please contact an organizer or > someone from the arbitration team. Great, thanks for the explanation and guideline! Regards, Carl-Daniel

3 11

Re: [coreboot] Plans for upcoming Broadwell Thinkpads
by Zaolin 07 Feb '15

07 Feb '15

Hi, let's say goodbye to all Intel notebooks produced by OEM's which are not Google ( Chromebooks ). Maybe the haswell/broadwell notebooks of Lenovo without U/Y processor can be used ( Thinkpad tXX xXX ). It depends if they are supporting Intel Boot Guard on the southbridge and if they are locked down... Regards Zaolin > On 02/06/2015 06:29 AM, Zaolin wrote: > > Hi, > > > > new thinkpad's can't be used anymore for coreboot. Especially the U and > > Y Intel CPU Series. > > They come with Intel Boot Guard and you are won't be able to boot > > anything which is unsigned and > > not approved by OEM. This means the OEM are fusing SHA256 public key > > hashes into the southbridge. > > > > For more details take a look at Intel Boot Guard architecture. It could > > be also confirmed by Secunet AG and Google. > > > > Regards Zaolin > > That's scary to say the least. No more Thinkpads for us... >

3 3

Re: [coreboot] Plans for upcoming Broadwell Thinkpads
by Zaolin 06 Feb '15

06 Feb '15

Hi, new thinkpad's can't be used anymore for coreboot. Especially the U and Y Intel CPU Series. They come with Intel Boot Guard and you are won't be able to boot anything which is unsigned and not approved by OEM. This means the OEM are fusing SHA256 public key hashes into the southbridge. For more details take a look at Intel Boot Guard architecture. It could be also confirmed by Secunet AG and Google. Regards Zaolin > I should probably not post about any Thinkpads till I get to test the > T410s port... but anyway has anybody considered a port for the incoming > Broadwell Thinkpads - especially the T450s? It would definitely be a > plus to know that there will be others hacking at it as well before > buying ;) >

3 2

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

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 2015