coreboot February 2015

coreboot@coreboot.org

45 participants
93 discussions

Re: [coreboot] [review 1/2] Subject: Prepare for Clevo D900T
by Erika Tibbs 12 Feb '15

12 Feb '15

Hi, Im looking at picking up an old alienware with this mainboard in it. I have read that the mainboard actually supports up to 8gb ram and that it can handle a 512mg video card. It looks like you may have done some bios tweaking and such to allow for significant upgrading beyond original bios limits. If this is the case wondering if you would share the program. I've read that this mainboard seems to have issues with seeing new hdds larger than 120gb(at least in the alienware model I'm looking at) and I'm hoping that among other improvements if you have made a bios upgrade that it might also address this issue. Thank you in advance, Erika Sent from my Sprint Samsung Galaxy® Note 4.

1 0

ASUS KFSN4-DRe: Board status with incomplete coreboot console and time stamps showing long device init
by Paul Menzel 11 Feb '15

11 Feb '15

Dear Timothy, thanks again for improving the support for the ASUS KFSN4-DRE and being so responsive. It’s a great example for how to work with upstream! You uploaded the board status output [1] with commit 8057285 [2]. Thanks! But, it looks like a lot of information is missing from the coreboot console messages, like it was cut. Could you upload another run with the same commit or, for example, from latest master? Does `util/cbmem/cbmem -c` show all messages? You’d need to enable CBMEM console in Kconfig for that though. (SeaBIOS is also able to write its messages to CBMEM console.) Lastly, you put the time stamps on the Wiki page [3]. Could you please also upload those into the board status repository as people expect such information to be there? They would probably not go looking in the Wiki and in the board status repository the time stamps can be mapped to a specific commit. 10:start of ramstage 20,261 30:device enumeration 25,566 (5,304) 40:device configuration 50,219 (24,653) 50:device enable 108,559 (58,339) 60:device initialization 109,734 (1,175) 70:device setup done 1,056,523 (946,789) 75:cbmem post 1,057,578 (1,054) 80:write tables 1,058,641 (1,063) 90:load payload 1,064,180 (5,539) 99:selfboot jump 1,123,383 (59,202) Looking at the actual time stamps below do you see from your logs why the device initialization takes almost one second? As the timings on the Wiki page [3] show, it’s not related to enabling graphics/VGA. I guess SeaBIOS executes fairly quickly too? Do you have timing data for that as well? Or do you use COMBOOT as a payload? Just for comparison, how long does the vendor firmware take to get to COMBOOT [4] or whatever you use? Thanks, Paul [1] http://review.coreboot.org/gitweb?p=board-status.git;a=commitdiff;h=96b9b0f… [2] http://review.coreboot.org/8270 [3] http://coreboot.org/Board:asus/kfsn4-dre [4] http://www.syslinux.org/doc/comboot.txt

2 1

Re: [coreboot] dell sputnik
by Gregg Levine 11 Feb '15

11 Feb '15

Hello! Okay, I'll send them along to the list where we should be having this conversation. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again." On Wed, Feb 11, 2015 at 7:18 PM, Benny <benediktwindolph(a)gmail.com> wrote: > I attached 2 files, i hope it contains the required information. > If there is something missing let me know. > > > Am Mittwoch, den 11.02.2015, 18:59 -0500 schrieb Gregg Levine: >> Hello! >> How about you do us the favor of telling us more about your laptop? >> You will need to run certain programs or use specific Linux commands >> to tell us what the laptop wears. >> >> Please note that the majority of laptops wear specialty chips who are >> specifically configured to run those features that enable the special >> functions that make them different from desktop motherboards. >> >> For example there is an embedded controller involved who handles those >> functions, and typically information is not involved. >> >> The one of the Linux commands are #lspci who will tell you what the >> internal PCI bus looks like and there are others. The coreboot wiki >> contains these, plus the programs needed, flashrom to, ah, program the >> flash, superio to identify that part. >> >> Please study this site http://www.coreboot.org/Welcome_to_coreboot >> from there you'll find out more then I can provide here. Plus you have >> the support of these friendly people to help you further. >> >> My problem is that your Dell Sputnik or Dell traveler is not known to me. >> ----- >> Gregg C Levine gregg.drwho8(a)gmail.com >> "This signature fought the Time Wars, time and again." >> >> >> On Wed, Feb 11, 2015 at 6:30 PM, Benny <benediktwindolph(a)gmail.com> wrote: >> > Hey everyone, >> > >> > is there a chance coreboot comes to the Dell Sputnik (XPS13, L322X1Y1)? >> > >> > Thanks, >> > >> > Benny >> > >> > >> > -- >> > coreboot mailing list: coreboot(a)coreboot.org >> > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

How to get rid of your UEFI
by Torsten Duwe 11 Feb '15

11 Feb '15

Your flash chip is protected? You're dealing with hideous SMM? Maybe this will help: http://blog.cr4.sh/2015/02/exploiting-uefi-boot-script-table.html Based on a 31c3 talk. I thought I'd post it here as long as it's useful. Torsten

1 0

x201t + windows7
by Alexander Couzens 11 Feb '15

11 Feb '15

Hi, I tried today a windows 7 installation usb stick and a cd disc. Both 32bit and 64bit. Both Windows' stopping at disk.sys and the hdd led on. 32bit: sometimes windows boots, most time not. Any ideas, what's wrong? Best, lynxis -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)jabber.ccc.de mobile: +4915123277221

1 0

code of conduct (reloaded)
by Alexandru Gagniuc 11 Feb '15

11 Feb '15

This comes in a new thread because my ML membership was somehow hosed coreboot-side, so I have no mail to reply to. I have until now ignored this code of conduct. There's been talk about how people feel unwelcome in _other_ projects, about how _other_ projects (fill in the blank). What there hasn't been any talk of, however, is any instance where this has been a problem in _our_ community. coreboot _is_ a hard thing. You _do_ need a _hard_skin_ to do coreboot. That's just the nature of our work. That is not because of our attitude; hardware is crap. People get annoyed at it. They bash it and vent out. It's normal. There's absolutely no point in burdening our developers with a generic code of of conduct. I don't know how much time Marc actually spends on IRC, but we have been great at policing ourselves. Pretending someone else's problem as our own is just silly. The fact is, the problem Marc pointed out, and the problems he tries to solve with this code of conduct are non-present in our community. I've seen more helpful people jumping to aid than in any other project. I've seen more good will and personal time invested to help others than in any other project. I've only seen Peter give new guys the RTFW, RTFS, or STFW, and those have been well deserved by the person receiving them. Are we going to start taking action against some of our most experienced and valuable developers because they didn't waste their personal time doing someone else's homework? There's a phenomenon of "Oh, I saw this thing here, so let's implement it irrespective of whether or not it's actually relevant". I call that liberal bullshit. That's exactly what this is. This code of conduct is an insult to our hard work over the years, and an insult to our friendly nature and countless personal hours spent helping others. When you've put up this code of conduct, you've basically said "our community is not capable of bettering itself by peer action and common sense, so we need to enforce it". It degrades every person who has ever contributed, and degrades the community as a whole. It's a degrading document that has no place. Alex

4 3

Fwd: Re: New interface for I2C in coreboot
by Alex G. 10 Feb '15

10 Feb '15

I knew there was something wrong to typing that from an Android phone. It didn't get sent to the list. -------- Forwarded Message -------- On Feb 10, 2015 2:19 AM, "Patrick Georgi" <> wrote: > Am 10.02.2015 um 08:56 schrieb Alexandru Gagniuc: > > 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. > But hardware doesn't. The API is fine when you bitbang everything, but > not when there's a controller that takes over some of the work, like > programming the address. > > On such a controller, you have to pick apart struct i2c_seg* to figure > out which elements are addresses and which are data, and split things > into different registers. > Is that proper i2c or smbus controllers? Smbus is a different beast that we really shouldn't simplify to i2c++ . Assuming it's i2c proper, how do we handle such cases? I2c is i2c and it makes more sense to abstract the nature of the hardware in an i2c centric way. A silicon-specific API is the wrong way here. I have patches in my pipeline to introduce generic i2c over displayport aux channel code. That makes use of the low level nature of i2c_seg to properly break down the AUX bus transactions in a hardware-agnostic way. > I really don't see how it's useful to keep the data structures as low > level as possible and then require drivers for more capable devices to > uplift them to a higher abstraction level. > See section about abstracting hardware details above. There's no measurable penalty for internal abstraction. There is however a penalty for driving the hardware in a suboptimal way. That's the driver's job. Sure, we can make a context based i2c API based on ops. Then we can check the direct_read pointer and use that if it's not null. Though most people will get it wrong when writing drivers. KISS. Alex

1 0

BB-xM spi
by The Gluglug 10 Feb '15

10 Feb '15

1 0

Re: [coreboot] updating coreboot && SeaBIOS on an Acer C720
by Myles Watson 10 Feb '15

10 Feb '15

My C720 shuts down as well. Someone in this thread suggested that it was related to whether or not the adapter is connected: https://productforums.google.com/forum/#!topic/chromebook-central/gjSnZJeME… I've yet to have it shut down when the adapter is connected, whether or not the adapter is plugged into the wall. Although that's not an optimal solution, it has removed a lot of the frustration to have a workaround. Thanks, Myles On Mon, Feb 9, 2015 at 7:20 AM, Aaron Durbin <adurbin(a)chromium.org> wrote: > On Mon, Feb 9, 2015 at 1:32 AM, Matthias Apitz <guru(a)unixarea.de> wrote: > > 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. > > > > On the surface this doesn't sound like anything coreboot or SeaBIOS > specific. Can you grab the cbmem console logs on the boot after the > power off (cbmem -c)? There is also an eventlog sitting in memory as > well that can be grabbed. mosys > ( > https://chromium.googlesource.com/chromiumos%2Fplatform%2Fmosys/+/refs%2Fhe… > ) > should be able to do that work for you: mosys eventlog list > > The last thing to get is the EC console log. That's much harder to get > as you have a kernel that doesn't have the EC driver in it. If you > feel adventurous the tool (util/ectool) can be found here: > > https://chromium.googlesource.com/chromiumos%2Fplatform%2Fec/+/refs%2Fheads… > > Hope that helps. > > -Aaron > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Release Engineering (again)
by Patrick Georgi 10 Feb '15

10 Feb '15

Hi, we had our last big discussion about building coreboot releases in November. It quickly moved to the topic of removing boards that don't comply to any kind of metric, and the discussion mostly went down with that. So, since I really like to get a release process up and running, let me a 'minimum viable' proposal here: Let's decide on a schedule and create releases, with only minimal testing for now. There's no support and no guarantees which things work (before you scream, see below). The main goal is to learn how to do releases, and go from there. From my point of view, a release entails the following: - a timeline (for now, an announcement akin to 'next release will be on february 32th') - a git tag - a tarball that contains that tree state - release notes and changelog (a bit more than just git log) For the first few releases, until we broaden the scope, those release notes need to be very clear about the nature of these releases (and that they are merely code dumps, not tested pieces of engineering). From there, we could set ourselves goals, for example 'by the release date the board(s) I maintain work with a commit that is at most a week old, and I'll provide board-status reports with the released version'. This provides us with a record of what happened between two points in time. It provides goalposts to attach goals to. And we're building experience with what kind of 'things work' guarantees are actually realistic for us and which aren't. From there we can discuss further ways to make use of those goalposts (including dropping boards or chipsets, at some point). Or drop the release concept if all that turns out not to be worthwhile - but with the knowledge why it isn't. Thoughts? Patrick

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