coreboot March 2014

coreboot@coreboot.org

57 participants
180 discussions

by Zoran s

Hello Ron, Marc (Jones), I am wondering where IOAPIC code resides (somewhere on SouthBridge) for IVB? Could you (or anybody) point to me the file where this code exists/lives, so I can inspect it and learn more about IOAPIC itself? This one is implemented usually on PCH, as my best understanding is, and passes MSIs to core LAPICs, via DMI links? Thank you, Zoran Stojsavljevic On Saturday, March 22, 2014 12:03 AM, ron minnich <rminnich(a)gmail.com> wrote: anybody know of a tool to dump all apics/ioapics from user mode? I'm having a Very Stupid Problem with a research OS in that we can't get the apic's and or iopiac's working. I suck at these things. We can't tell what we've got wrong.I'm hoping a register dump would help us. ron -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

6 years, 11 months

Re: [coreboot] [announce] coreboot for the 21st century

by Stefan Reinauer

* Andrew Wu <andrewwu.tw(a)gmail.com> [140327 14:00]: > Sorry, I checked Vortex86EX CPU datasheet, but it seems there is no > workaround can do it. > > So if I want to get rid of romcc, maybe I have to write DRAM init code > in assembly, That is not very easy. :( Don't worry we'll figure something out that's better than writing ram init in assembly. Stefan

6 years, 11 months

Patch set to add support for AMD based laptop HP Pavilion m6-1035dx up for review

by Paul Menzel

Dear coreboot folks, Alexandru put wood behind the arrow to get coreboot running on an AMD based laptop. He took his old HP Pavilion m6-1035dx [1] and in a day/night had coreboot running on it and he submitted the patch set for review [2]! Am Donnerstag, den 27.03.2014, 19:12 +0100 schrieb Alexandru Gagniuc: > Alexandru Gagniuc (mr.nuke.me(a)gmail.com) just uploaded a new patch set > to gerrit, which you can find at http://review.coreboot.org/5409 > > -gerrit > > commit a1bf32fa1ac7727c3d3c6b10ecc391f42aaad622 > Author: Alexandru Gagniuc <mr.nuke.me(a)gmail.com> > Date: Wed Mar 26 18:51:08 2014 -0500 > > mainboard/hp: Add initial support for Pavilion m6-1035dx > > This was a pathetically easy port, where all the components are > already supported. This is basically a verbatim copy of amd/parmer. > The EC is an ENE KB932, which is a part that does surprisingly little > for an EC. This also means we need almost no code to get it working. > I've "select"ed the EC in Kconfig, which is the only difference from > parmer, although the keyboard worked fine without it. > > I haven't coupled in the ACPI code from the EC yet, so battery level > is not readable from the OS. Hotkeys work except for brightness > control, and the CapsLock LED blinks at regular intervals instead of > following the CapsLock key. […] Congrats to being, to my knowledge, the first to get coreboot running on an AMD based laptop! Also big thanks to AMD and Sage Electronic Engineering LLC [3] for providing code and support for AMD stuff! Also thanks to Google for contributing code for the COMPAL ENE932 Embedded Controller [4]. So reviewers and help in getting the non-working stuff to work are greatly appreciated. Bad for Alex that he now has to deal with AGESA and get for example CBMEM console working with it for romstage or to refactor the code to be more maintainable. :P Thanks, Paul [1] http://h10025.www1.hp.com/ewfrf/wc/document?docname=c03383025&lc=en [2] http://review.coreboot.org/5409 [3] http://www.se-eng.com/ [4] http://review.coreboot.org/2024

6 years, 11 months

Re: [coreboot] [announce] coreboot for the 21st century

by Kyösti Mälkki

On 03/22/2014 06:18 AM, ron minnich wrote: > On Fri, Mar 21, 2014 at 6:52 PM, Alex G. <mr.nuke.me(a)gmail.com> wrote: > >> The bad-ness or good-ness of motives is relative. Note that I'm not >> using "bad" in the sense of "evil". Let's look at the six gatekeeper idea: >> * Easier for commercial entities to upstream code, therefore faster >> progress for coreboot (good motive). (a) >> * Easier for commercial entities to upstream code, therefore we can get >> lazy even if code quality drops (bad motive). (b) > > That's not the intent. The way you are stating this has a lot of > built-in assumptions, and you're mixing some things up. That's our > fault; the old rule is, that if someone did not understand what you > said, it's your fault, not theirs. So, speaking as one of the guys who > reviewed the email, I'm sorry it was not clearer. > > So, first, the intent of the six gatekeeper idea is, in part, to be > sure we're being very careful about what goes in. We've had some cases > over the past 2-3 years where some inexperienced guys pushed 'commit' > on code that broke a bunch of boards -- in ways that were not obvious. > We would like to avoid that. As we've learned the hard way a few > times, there are not that many people who have the perspective of long > experience and a view of all the boards, and know how trivial changes > can have far-reaching consequences. Hi Ron, would you be so kind and identify by commit hash some of these code merges by "inexperienced guys" from last 2-3 years that "broke a bunch of boards". I would like to see from gerrit history how these problems were ultimately dealt with and hopefully we could all learn from the mistakes that were made. I could list some breakage, but the ones I can remember were all submitted by experienced long-term commercial contributors, and would not exactly match the criteria of your argument. If we look closer, probably every suggested gatekeeper is involved with merging such commits. For an extreme sample of review process try follow this: AMD CAR: Fix issue with gcc 4.8.x http://review.coreboot.org/#/c/4205/ We have everything there -- a change in CAR init already approved in Chromium git without testing, test results for boards the changed code is never built for, test results for boards the change is not built for because of a Kconfig option not being set. We have developers from Chromium, SAGE and AMD involved in review. We have a couple commmunity developers involved. And all this to avoid breakage in some mostly obsolete K8 or fam10 platform we have in the tree. Some changes to review process are certainly welcome. I just hope Stefan would have included separate section of the current problems and more details of the goals his proposal tries to address. Even some of the obvious ones are not answered. For example, are there actual plans to bring coreboot trees from coreboot.org and Chromium back in-sync? Regards, Kyösti

6 years, 11 months

Re: [coreboot] A new, modern coreboot long-term support laptop

by mrnuke

On Monday, March 24, 2014 10:36:27 PM David Hendricks wrote: > On Mon, Mar 24, 2014 at 9:10 PM, mrnuke <mr.nuke.me(a)gmail.com> wrote: > > Chose the hardware. Set up a github temporary fork. Send me the hardware. > > I got Pomona, I got SPI, I got USB debug, and I got the burning desire to > > make this happen. > > I like your attitude. See if there's a laptop that looks doable in the > ~$500 range, buy two of 'em, and tell me how to reimburse you. > I like your attitude too. I've started developing a Candidacy page [1]. I won't start fiddling hardware or funds until a consensus is reached as to the best option. There's an interesting trend with these ProBooks. In November, when I got my chromebook, there was only one ProBook with AMD CPU available IIRC. Now there are a number of such models. That may indicate we can expect those to be on the market for a while, or I'm just remembering wrong and those have less than a year of shelf life remaining. Anyone has any experience with the AMD ProBooks? Are they built to last, or are they crap? Alex [1] http://www.coreboot.org/User_talk:MrNuke/LTS_Candidates

6 years, 11 months

Re: [coreboot] [announce] coreboot for the 21st century

by Patrick Georgi

Am 2014-03-27 14:41, schrieb Aaron Durbin: > As for the Vortex86, I'm sure we can come up with something. Off the > top of my head I'd suggest having raminit in bootblock then there > isn't a possibility of running into issues. Long term I'd like to keep it outside the bootblock, but once it runs there it's 5 minutes of Makefile changes to move the code to romstage, so yes - works for me. Patrick

6 years, 11 months

Re: [coreboot] [announce] coreboot for the 21st century

by mrnuke

On Saturday, March 22, 2014 03:56:46 AM Andrew Wu wrote: > Yes, that is right. DMP/Vortex86EX has no MTRR. So it maybe a problem > if without romcc. :( Is there any way whatsoever to temporarily use the cache as SRAM? Alex

6 years, 11 months

Re: [coreboot] Classification of blobs and respecting your freedom

by Stefan Reinauer

* David Hendricks <dhendrix(a)google.com> [140326 20:25]: > On Wed, Mar 26, 2014 at 9:47 AM, ron minnich <rminnich(a)gmail.com> wrote: > > I think it's good and well written. I'd replace your 'panic levels' with 4 > simple classifications and leave it at that. > > > Yep, good write-up overall. > > I never liked the "panic level" rating, or at least the numbers. It seems > rather arbitrary. As much as folks dislike binary MRC, for example, I wouldn't > even put it in the same ballpark as the management engine since the ME is an > always-on, persistent, non-ISA blob with similar access capabilities. Scoring > them one point apart at the top of a scale from 1 to "9000+" seems to diminish > those important distinctions. There is some more to that, even. * Also, with an NDA in place, Intel will freely give you the System Agent (MRC) source code. That will never happen with the ME firmware * MRC is usually 100-300K of binary code depending on the compile time options. ME firmware is 1.5MB - 7MB. * MRC is not digitally signed, so it can be replaced, ME firmware can not. * MRC does not contain network drivers or can read your memory and io at any time during system run time. ME firmware can. (Yes, you mentioned this) * There is no special NSA version of the MRC. So, basically, the ME is both harder (impossible) to replace or run without and has much more control over the system. It's an unfortunate combo, to say the least. The MRC is about the same classification as VGA option roms. If you don't run it, parts of your system won't work. But it's possible to replace it by throwing enough man power at it. Stefan

6 years, 11 months

flashrom-related GSoC 2014 project

by Stefan Tauner

Hi everyone, I will attempt to participate as a student again - and of course my project should be something very closely related to flashrom to exploit my knowledge in that area. I have already submitted a first alpha-stage proposal that basically includes the standard repertoire of things I do while working on flashrom in general, and also which I ended up doing in the past GSoC projects. Namely a mixture of maintenance, improvement and integration of existing patches, development of new features for flashrom. For me that worked out well and I believe it was very good for flashrom and worthwhile for the coreboot community as a whole too. I have not received too much feedback so I am not sure if everybody agrees with that and thinks that another such summer would be a good thing as well (if there are other candidates and/or proposals to choose from). If you think the GSoC slots of coreboot deserve something better, or more project-like then I could also try to work on something more confined/focused. There are a number of project ideas that might fit my profile quite well. The "End user flash tool" proposal would allow me to eventually finish libflashrom and the layout patches, maybe clean up the bios_extract repository and help those users that are fighting with vgabios extractions etc. :) Then there is the panic room idea which AFAIK is not finished and has some room for improvements, but I am not sure about its current state and if Kyösti wants to work on that this year...? Somehow related to both points above is an idea for a project I had for some time. A coreboot payload (probably)... for user flash updates that verifies a cryptographically signed image before flashing it. While currently this is relatively useless it might become interesting for distributing libreboot binary images for example. (even though I have to admit it is a bit ironic to ship binary images of a firmware that is blobfree :) IIRC the Chromebooks have a write-protected primary loader that verifies the remaining firmware etc... basically what secure boot demands. That solves a similar problem, but recovery for an end user is way more unpleasant than getting warned early before any modifications are done. Another advantage would be to have an OS-independent update mechanism... OTOH flashrom runs on every OS I deem worthy to run coreboot. :) The last project idea to be mentioned here that suits me well is what David proposed last year, see his post for details: http://www.flashrom.org/pipermail/flashrom/2013-March/010704.html So... I would be glad to get your feedback. What do you think would help us most? Do you have other ideas/wishes related to flashrom? I don't care too much on which project I work... they are all worthwhile IMHO. My preference would be to work freely on flashrom itself because it really needs it (there is no one else doing it) and I have the most knowledge in that field. But OTOH I can learn much more in every other project mentioned above and that's also very motivating. Naturally, I don't want to write multiple proposals if we can agree on one topic already... and time is rather short too :) PS: I have an asrock imb-180-h, an SPI programmer and lots of flash chips available to tinker with. There is also some ancient intel BX-based PC somewhere that I could port... I'd need to build a parallel flasher for that first though (cortex m3 board and stuff already collecting dust...) but that would probably be based on serprog and peter would veto for sure ;) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

6 years, 11 months

Re: [coreboot] Classification of blobs and respecting your freedom

by mrnuke

I should delete my "reply button". Darn! It's "reply to all". Sorry Ron. On Wednesday, March 26, 2014 03:05:47 PM mrnuke wrote: > On Wednesday, March 26, 2014 01:01:10 PM you wrote: > > Ah, that's what I meant by persistent. Let's take your name and get > > rid of mine, and we're still at 2 axes? > > Three axes. non-persistent, replaceable, non-essential. I think they're > orthogonal. > * NP and R are relevant when looking at things from a security point of > view. * R and NE are relevant from a RYF point of view. > > Think of RYF and security as two orthogonal planes which intersect at the R > axis. > > Alex

6 years, 11 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2014