coreboot February 2015

coreboot@coreboot.org

45 participants
93 discussions

Need help with MSI MS-7260 (K9N Neo) / MSI MS-7250 (K9N SLI)
by cjn＠post1.dansknet.dk 20 Feb '15

20 Feb '15

Hi, I'd like to run coreboot on my MSI MS-7250 (K9N SLI) mainboard. This board is apparently quite similar to the MSI MS-7260 (K9N Neo) which is already supported: http://www.coreboot.org/Board:msi/ms7260 This is what my board looks like, though mine is a version 2.2: http://www.msi.com/product/mb/K9N_SLI.html#hero-specification I tried booting the board with a coreboot ROM built for the MS-7260 (and an "AMD Athlon(tm) 64 X2 Dual Core Processor 5000+" CPU, 4 1GB DIMM sticks, and a Radeon 7000 graphics card). That didn't work, but I've attached the log. I've also attached the outputs from lspci, superiotool, and flashrom, for good measure. What needs to be done and what's a good place to start? Christian

2 1

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

19 Feb '15

On Thu, Feb 19, 2015 at 12:21 AM, Werner Zeh <werner.zeh(a)gmx.net> wrote: > OK, forget my last Mail...I was to blind to see the truth :-) > We already have my approach with the new interface. > > We maybe can expand it to have informations like time-out or retry count for a given segment. One word of caution I'd like to add here is that making this API more complex/powerful requires significant effort, now and in the future. We already have 4 I2C driver implementations in coreboot, and 4 more are going to be upstreamed soon from the Chromium tree. As we scale up to we'll probably add at least one new driver per SoC vendor, maybe even per SoC. Adding complex functionality like retries to the API will require us to account for it over an over again in every single implementation. I think the question is really what we would gain from this. Even though some I2C controllers have more efficient modes that do multiple things at once, all I've yet seen could somehow be coerced to do real simple step-by-step transfers. Since we need to implement that anyway for the API, why do anything more? Efficiency? I think I2C transfers are generally so slow that a little more overhead here and there isn't going to make a measurable difference. These transaction-at-a-time hardware features are designed for operating systems that have other threads to schedule or the power impact of a high interrupt frequency to worry about, not us.

1 0

Re: [coreboot] Automated test system: Nominations wanted
by Kevin O'Connor 19 Feb '15

19 Feb '15

On Thu, Feb 19, 2015 at 12:35:11PM +0100, Patrick Georgi via coreboot wrote: > 2015-02-19 0:14 GMT+01:00 Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net>: > > I am currently planning to set up a test system with 5 (later up to 10) > > machines boot testing each new coreboot commit. This test system will be > > serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST office hours. > > > > Current goals for every commit: > > - Check if coreboot + SeaBIOS are able to boot Linux to a point where > > network is up and running > > > > Current goals for every work day: > > - Check if screen, keyboard and touchpad/mouse work > > - Check if USB works and has the expected transfer speed (i.e. if USB > > High and Super Speed both work) > http://blogs.coreboot.org/blog/author/ayushsagar/ documents last > year's GSoC project to implement some of those - incl. a screen test > using the display present signals. > > Through external flashing, there's also no need to handle unbricking manually. This is a bit off topic, but I've been thinking that a neat project would be to package up an automated test and recovery system using the Beagle Bone Black board. The Beagle Bone Black isn't too expensive ($55), it is widely available, it has an SPI interface (for emergency flashing), has GPIOs (which, with a level shifter, could be used to turn on/off the board and report LED status), and can emulate a USB client. The emulated USB client could (in theory) be used to emulate a USB boot drive, a USB networking adapter, a USB keyboard, a USB serial port, and/or a USB debug device. In theory, one could wrap many of the target board's standard interfaces so that automated testing and remote development could be done. It would be a bit of work to get the software working and packaged nicely - but if it was, I think it could enable many more users to participate in automated tests and remote development. -Kevin

2 1

Re: [coreboot] updating coreboot && SeaBIOS on an Acer C720
by Matthias Apitz 19 Feb '15

19 Feb '15

El día Sunday, February 08, 2015 a las 11:14:10PM +0100, Idwer Vollering escribió: > ? > > 2015-02-08 21:55 GMT+01:00 Matthias Apitz <guru(a)unixarea.de>: > > El día Sunday, February 08, 2015 a las 02:40:45PM -0600, Alex G. escribió: > > > >> Suspect number one is the device overheating. The shutdown is > >> triggered by the EC. I don't know how you can enable ACPI debug output > >> on BSD though. On linux, it would be "echo 1 > > >> /sys/module/acpi/parameters/aml_debug_output", so whatever the FreeBSD > >> equivalent of that is. > > hw.acpi.verbose=1 would be a start. > ... Thanks for all the hints. As I said, the events are sporadic, seldom, but complete power-off (like as you would cut the cable from the motherboard). Of course the system has no chance to write anything to /var/log/messages or console. My hope while writing to coreboot@ was to get a pointer to the list of open ore solved issues within coreboot and/or SeaBIOS to see if this issue is somewhat known, solved or could be related to some known or solved issue. Where can I find such a list which is normally (as we do in my company) attached to the Release Notes of a new version of software. Thanks in advance Matthias http://www.coreboot.org/pipermail/coreboot/2015-February/079219.html -- 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 2

Re: [coreboot] New interface for I2C in coreboot
by Peter Stuge 19 Feb '15

19 Feb '15

Werner Zeh wrote: > We already have my approach with the new interface. > > We maybe can expand it to have informations like time-out or retry > count for a given segment. I think this is a really good idea. I also think that this structure applies to SPI as well. //Peter

1 0

Re: [coreboot] New interface for I2C in coreboot
by Werner Zeh 19 Feb '15

19 Feb '15

OK, forget my last Mail...I was to blind to see the truth :-) We already have my approach with the new interface. We maybe can expand it to have informations like time-out or retry count for a given segment. Werner > Gesendet: Donnerstag, 19. Februar 2015 um 07:41 Uhr > Von: "Werner Zeh" <werner.zeh(a)gmx.net> > An: "Julius Werner" <jwerner(a)chromium.org>, gaumless(a)gmail.com, pgeorgi(a)google.com > Cc: coreboot(a)coreboot.org > Betreff: Re: [coreboot] New interface for I2C in coreboot > > Hi all. > > I am fully aware of how I2C bus works and I never liked this interface. This is because you cannot really probe devices on the bus, there is not really a status information available on the bus and one can confuse a slave in that way that it will block the bus without a way to reset it (at least there is a trick available). > After I have thought for a long time about this issue, I can understand the need of the change that has been done. Nevertheless, I still not want the place where the cut in the interface was done. > > With the new interface the driver for I2C bus is truncated because with this interface the driver do not have the knowledge of the whole transfer that must be performed on the bus. Instead, the driver is fed with small pieces of data. In this way, we cannot design a driver that is smarter and can use all the abilities a hardware given I2C controller can provide. > > I would like to discuss the following approach: > Construct all the data you need to transmit/receive outside of the I2C driver (i.e. inside the user of I2C driver which can be itself a driver for the slave e.g. an EEPROM, tpm, whatever). We can use a similar structure approach the new interface already has and chain this structures to build a complete transaction. We can add control information (read/write data, start/stop condition...) to every piece of the transaction (let's call it chunk) as well as needed timeout or retry requirements. The list of all this chunks builds up the complete transaction. This transaction will be passed into the I2C driver. > Now the driver can handle the list as it wants to. We can write simple drivers that consist of GPIO manipulation to emulate the I2C controller. But we also can write smart drivers which can use all the abilities a given hardware controller provide. > In my opinion this approach will allow us to be more flexible without wasting hardware possibilities and with a comparable complexity we currently have with the new interface. > > Any thoughts are welcome. > > Werner > > > > > Gesendet: Dienstag, 10. Februar 2015 um 20:36 Uhr > > Von: "Julius Werner" <jwerner(a)chromium.org> > > An: "Werner Zeh" <werner.zeh(a)gmx.net> > > Cc: coreboot(a)coreboot.org, "Julius Werner" <jwerner(a)chromium.org>, "Marc Jones" <marc.jones(a)se-eng.com>, martin(a)se-eng.com, "Patrick Georgi" <pgeorgi(a)google.com> > > Betreff: Re: New interface for I2C in coreboot > > > > 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. > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] New interface for I2C in coreboot
by Werner Zeh 19 Feb '15

19 Feb '15

Hi all. I am fully aware of how I2C bus works and I never liked this interface. This is because you cannot really probe devices on the bus, there is not really a status information available on the bus and one can confuse a slave in that way that it will block the bus without a way to reset it (at least there is a trick available). After I have thought for a long time about this issue, I can understand the need of the change that has been done. Nevertheless, I still not want the place where the cut in the interface was done. With the new interface the driver for I2C bus is truncated because with this interface the driver do not have the knowledge of the whole transfer that must be performed on the bus. Instead, the driver is fed with small pieces of data. In this way, we cannot design a driver that is smarter and can use all the abilities a hardware given I2C controller can provide. I would like to discuss the following approach: Construct all the data you need to transmit/receive outside of the I2C driver (i.e. inside the user of I2C driver which can be itself a driver for the slave e.g. an EEPROM, tpm, whatever). We can use a similar structure approach the new interface already has and chain this structures to build a complete transaction. We can add control information (read/write data, start/stop condition...) to every piece of the transaction (let's call it chunk) as well as needed timeout or retry requirements. The list of all this chunks builds up the complete transaction. This transaction will be passed into the I2C driver. Now the driver can handle the list as it wants to. We can write simple drivers that consist of GPIO manipulation to emulate the I2C controller. But we also can write smart drivers which can use all the abilities a given hardware controller provide. In my opinion this approach will allow us to be more flexible without wasting hardware possibilities and with a comparable complexity we currently have with the new interface. Any thoughts are welcome. Werner > Gesendet: Dienstag, 10. Februar 2015 um 20:36 Uhr > Von: "Julius Werner" <jwerner(a)chromium.org> > An: "Werner Zeh" <werner.zeh(a)gmx.net> > Cc: coreboot(a)coreboot.org, "Julius Werner" <jwerner(a)chromium.org>, "Marc Jones" <marc.jones(a)se-eng.com>, martin(a)se-eng.com, "Patrick Georgi" <pgeorgi(a)google.com> > Betreff: Re: New interface for I2C in coreboot > > 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] Unifying IO accessor macros
by David Hendricks 19 Feb '15

19 Feb '15

On Wed, Feb 18, 2015 at 2:47 PM, Julius Werner <jwerner(a)chromium.org> wrote: > > I think nobody disagrees that type checking is a bad idea here. > > I ain't not unsure that you failed to not make no mistake with the > missing lack of double negatives there... ;) > > > I don't think this argument makes sense for code that is being actively > > developed in other code bases and imported into coreboot. Of course, if > > you're importing stable code and don't expect much churn, tidying things > up > > is a fine idea. But increasing deltas while a project is still under > active > > development only serves to make integration and maintenance efforts more > > troublesome and prone to error. It's not a productive use of anyone's > time > > when there are real bugs to solve. > > > > Vendors often have code which they have already qualified and are > > understandably reluctant to make any changes to it, even trivial > aesthetic > > ones. I'd like to make it easier for them to contribute directly to > > coreboot, and throwing up artificial barriers does not help them gain > > traction. > > Do we really want to facilitate more of these wholesale imports of > untouched, existing code dumps from other sources into coreboot? I don't think that's necessarily a bad thing during heavy development. Obviously we'd want to tidy things up after the fact and use wrappers until then, but insofar as this whole write32/writel and arg ordering discussion goes there hasn't been much to aspire to in terms of tidying things. So basically what I'm advocating is to define a "proper" approach that we apply to coreboot in general, while being flexible about importing code. Once we define the proper approach, then applying an spatch to bring the style into conformance and remove the scaffolding should be relatively painless. It > seems to me that those always end up bad for us... code is hard to > read and follow because of switched conventions, Yep. And for the person porting the code, switching conventions on-the-fly might be even more confusing. I generally like to see code working before making such changes. > it could have > depended on different requirements for the environment than what > coreboot provides, it often includes a lot of hacky and > overcomplicated code that the original use case might have needed but > we don't, people will end up making changes after the import that > desync it with the source, etc. True, and I think it's more productive to prioritize fixing those issues over aesthetic ones. I'm all for re-factoring code. I just don't think forcing huge deltas from the get-go during heavy development is a great way to do it. > I think for small stuff like > individual drivers we're better off just rewriting them with a sound > design from the ground up tailored to our use case (at least that > guarantees that someone really understood and thought through how it > all works within the coreboot context). Agreed - For small stuff I'm totally on-board. That might not be the case, however, for more complicated stuff. For example, if a vendor updates DRAM init code in u-boot multiple times over a period of weeks/months and we need to apply the same updates to coreboot, having hundreds of cosmetic changes show up in the diff just makes the porting process more difficult and more prone to error. > For really large scale > external imports (like AMD Agesa), we can stow it away in vendorcode/ > with translator headers to allow it to keep its own conventions > completely unchanged, without risk of it leaking out into the rest of > coreboot. > Yep. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

On the subject of collaboration
by Alexandru Gagniuc 18 Feb '15

18 Feb '15

On Saturday, February 14, 2015 12:33:11 AM Marc Jones wrote: > On Fri Feb 13 2015 at 5:13:04 PM Alexandru Gagniuc <mr.nuke.me(a)gmail.com> > > wrote: > > On Saturday, February 14, 2015 12:05:28 AM Marc Jones wrote: > > > Hi Everyone, > > > > Hi, > > > > > Please update the wiki page with project ideas. > > > http://www.coreboot.org/Project_Ideas > > > > That's the first unlocked page in the coreboot wiki I have seen for quite > > some > > time. > > This comment is off topic. Please don't hijack the thread about GSOC. If > you would like to discuss locked wiki pages please start another thread. > I respectfully disagree. I think collaboration is very relevant, _especially_ in the context of GSoC. And yet we have been moving away from this school of thought. It's that time of the year it seems. Last year, there were talks about reducing the number of gerrit submitters. I'm certain you remember the anger this caused amongst non-commercial members of the community when the proposed list contained exclusively commercial community members, and I'm certain you remember how that almost lead to a fork. This year's theme goes on the same lines. Except that it's not as tactful as last year. It's no longer "I'm planning to do this". It's "I've already done this". Let's see. We've locked most wiki pages to a select few contributors. A so-called code of conduct was unilaterally introduced. Let's look at each in part. When it comes to the locked wiki pages keep in mind that most contributors make minor edits in response to real events. It has happened in the past that people were confused by the wording. So someone comes in and clarifies it on the spot, before they forget. Now those contributions get lost behind a non- collaborative barrier. Now the code of conduct... What constitutes any of the 'bad' behaviors mentioned? What you really get is people refusing to express an idea or opinion in fear of violating said ill-defined code, and in fear of retaliation. It's called a chilling effect. Again, good ideas get lost behind a non-collaborative barrier. Do we really want to push people's nerves every year until we finally get a fork? Alex > Thanks, > Marc

6 14

Re: [coreboot] Unifying IO accessor macros
by Julius Werner 18 Feb '15

18 Feb '15

> I think nobody disagrees that type checking is a bad idea here. I ain't not unsure that you failed to not make no mistake with the missing lack of double negatives there... ;) > I don't think this argument makes sense for code that is being actively > developed in other code bases and imported into coreboot. Of course, if > you're importing stable code and don't expect much churn, tidying things up > is a fine idea. But increasing deltas while a project is still under active > development only serves to make integration and maintenance efforts more > troublesome and prone to error. It's not a productive use of anyone's time > when there are real bugs to solve. > > Vendors often have code which they have already qualified and are > understandably reluctant to make any changes to it, even trivial aesthetic > ones. I'd like to make it easier for them to contribute directly to > coreboot, and throwing up artificial barriers does not help them gain > traction. Do we really want to facilitate more of these wholesale imports of untouched, existing code dumps from other sources into coreboot? It seems to me that those always end up bad for us... code is hard to read and follow because of switched conventions, it could have depended on different requirements for the environment than what coreboot provides, it often includes a lot of hacky and overcomplicated code that the original use case might have needed but we don't, people will end up making changes after the import that desync it with the source, etc. I think for small stuff like individual drivers we're better off just rewriting them with a sound design from the ground up tailored to our use case (at least that guarantees that someone really understood and thought through how it all works within the coreboot context). How often have we pulled in updates for something like that anyway? For really large scale external imports (like AMD Agesa), we can stow it away in vendorcode/ with translator headers to allow it to keep its own conventions completely unchanged, without risk of it leaking out into the rest of coreboot.

1 0

← 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