coreboot April 2014

coreboot@coreboot.org

42 participants
85 discussions

F2A85-M LE
by Dominic Walden 03 Apr '14

03 Apr '14

Hi all, I understand the f2a85-m is working with coreboot. Does anyone know if the "Limited Edition" version will also work, or whether it will require some work? I ask because there's one going on eBay I've got my eye on ;). Thanks, Dominic

2 1

Re: [coreboot] New addendums to INTEL FSP family
by Marc Jones 03 Apr '14

03 Apr '14

On Thu, Apr 3, 2014 at 1:03 AM, David Hendricks <david.hendricks(a)gmail.com> wrote: > On Wed, Apr 2, 2014 at 11:11 PM, Stojsavljevic, Zoran > <zoran.stojsavljevic(a)intel.com> wrote: >> >> > I really don't want to be rude here, not trying to be, but there's a lot >> > of talk on this issue that is driven by ignorance. And the people who know >> > what's going on, can't talk; the people who don't know, talk >> :-) Twas ever thus. >> >> People who do know, in most cases do NOT want to talk (in some they >> cannot), but people who do NOT know, they always talk, even they're not >> asked to! > > > Let's be polite. After all, this is an open source community forum, the > operative word being open. Not "open when mrnuke approves" or "open only to > those with insider knowledge." > > Thanks for your hard work here, by the way! I would certainly like to see > components of FSP open up over time, however coreboot+FSP is still a lot > better than no coreboot at all in my opinion. It also seems like a logical > step to help vendors take control of their platforms and see the benefits > that increased transparency can bring. Well put, David. Thank you. Marc -- http://se-eng.com

1 0

Re: [coreboot] New addendums to INTEL FSP family
by David Hendricks 03 Apr '14

03 Apr '14

On Wed, Apr 2, 2014 at 11:11 PM, Stojsavljevic, Zoran < zoran.stojsavljevic(a)intel.com> wrote: > > I really don't want to be rude here, not trying to be, but there's a lot > of talk on this issue that is driven by ignorance. And the people who know > what's going on, can't talk; the people who don't know, talk > :-) Twas ever thus. > > People who do know, in most cases do NOT want to talk (in some they > cannot), but people who do NOT know, they always talk, even they're not > asked to! > Let's be polite. After all, this is an open source community forum, the operative word being *open*. Not "open when mrnuke approves" or "open only to those with insider knowledge." Thanks for your hard work here, by the way! I would certainly like to see components of FSP open up over time, however coreboot+FSP is still a lot better than no coreboot at all in my opinion. It also seems like a logical step to help vendors take control of their platforms and see the benefits that increased transparency can bring.

1 0

Re: [coreboot] New addendums to INTEL FSP family
by Stojsavljevic, Zoran 02 Apr '14

02 Apr '14

> I really don't want to be rude here, not trying to be, but there's a lot of talk on this issue that is driven by ignorance. And the people who know what's going on, can't talk; the people who don't know, talk :-) Twas ever thus. People who do know, in most cases do NOT want to talk (in some they cannot), but people who do NOT know, they always talk, even they're not asked to! Zoran Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

Re: [coreboot] ioapic dump tool
by Zoran s 02 Apr '14

02 Apr '14

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

2 1

coreboot work
by Aaron Durbin 02 Apr '14

02 Apr '14

Hi Folks, Some of you may know I have lots of ideas floating around in my head for technical changes within coreboot. I'd like to layout many of those ideas so that 1. it's written down 2. people can discuss the merit. I plan on pursuing each of these changes, but I am not sure in what way (personal playground?). Many of these proposed may be x86-centric at first glance, but I feel that is reflective of the current code base. Solving some of the generic/infrastructure issues inherently will impact x86 systems. Also note that some of these ideas aren't fully fleshed out, however I believe the underlying problems still need to be addressed in some form. Availability Features/Subsystems There is currently quite a bit of code using macro guards around code based on __PRE_RAM__, for example, to imply what stage a compilation unit is being compiled for. While some of these heuristics may have been true in the past it's definitely not true any longer -- especially with the introduction of coreboot supporting some of the ARM SoC's. However, here is also a runtime component to feature availability -- not just static or compile time. Kyösti Mälkki has started to address the compile-time component: http://review.coreboot.org/#/c/5410/ I think we should take it further by having notions of "has devicetree", for example. The runtime notion of availability of features is also important. Trying to unify romstage (see below) will rely on having common points that can be used to piggy back infrastructure changes. To that end a construct of "mode" seems logical. The mode of the system would include current stage as well as features (read: flags). During the process of booting flags would be turned on triggering action. For example, after main memory is available that flag would be flipped and action could thus be taken (setting up cbmem, e.g.). The notion of "is this boot a resume boot?" comes to mind as well. On an ABI change front, I think it's important to pass this information on the next corresponding change (romstage -> ramstage, e.g.). x86's bootblock would not have such a notion since it currently has no memory to work with. Passing information directly to the next stage will provide direct dissemination of previous knowledge (e.g. where is cbmem?). Taming the Wild West of Romstage Many people who have ventured into making changes that impact romstage may know that there isn't a consistent framework/path. On x86, the entry point is typically some assembly code that sets up cache-as-ram then calls into a chipset specific C code. Memory is trained, cbmem is brought up, exit back to assembly, cache-as-ram is torn down, then call back into C code to locate and load ramstage. All of that typically happens within the confines of a chipset. That means when needing to make changes to APIs and/or assumptions in the infrastructure the task is very high-touch affecting quite many boards. On the other side of the spectrum the ARM SoCs have their own romstage paths that sit entirely in C code. Thus, I think it's important to solidify on a consistent API for booting through romstage like we have for ramstage. It wouldn't be like ramstage's hardwaremain.c, but it would provide a set of functions that should be called/implemented. Extending that concept further, the same constructs could be employed on more forgiving architectures' bootblock code. Q: What about such and such? It doesn't do things like that. A: I think we need to start conforming boards/chipsets into using the common infrastructure. It should provide consistency as well easier development cost in the long run for code changes. x86-specific Romstage Changes The above changes to romstage flow could be quite a big change for each chipset transitioning over. However, there's a lot of duplication w.r.t. setting up MTRRs and obtaining the stack location after cache-as-ram is torn down. A set of common functions should be introduced to manage the MTRRs and choosing stack location. This approach is utilized in the haswell and baytrail code although the code is essentially duplicated. Either through C code or some common assembler the new stack would be processed after tearing down cache-as-ram to initialize the new MTRR values and enable caching. What makes this work even more worthwhile is the carrot dangling in front of us at this point. Utilizing Ron Minnich's paging work (http://review.coreboot.org/5354) we can get rid of CAR_GLOBAL. The objects placed in CAR_GLOBAL currently would just live in the BSS section. Just before tearing down cache-as-ram that region would be copied into memory and page tables would be set up to map the address space occupied by cache-as-ram to point to memory. All other physical regions are identity mapped. The implication is that cache-as-ram is not a first class citizen that always needs to be thought about. However, that does require that x86 systems that utilize cache-as-ram need tp set up cbmem, but that's not too bad because that assumption was already being carried with some of the romstage unification. Removing CAR_GLOBAL should allow for having a richer (or maybe not as clumsy) APIs within the core infrastructure. Currently, x86 is holding other architectures back in this regard. x86 Assumptions It's not surprising that there are some x86-isms that have crept into the core components/libraries. One of the main issues that has been talked about as of late is the access pattern and APIs surrounding CBFS access patterns. The good news on that front is that there is a GSoC proposal to attack that problem. To take that one step further the medium on which CBFS resides can be used for other purposes aside from CBFS. ChromeOS devices very much use this: memory training data, event log, and verified boot. The regions patch (http://review.coreboot.org/5394), as implemented, is a first-pass at not just rectifying CBFS access patterns but also providing an abstraction to the underlying medium into a single interface. That allowed for a unified way to access the SPI flash. One of the nicer things the regions support allows is to easily ship in-memory CBFS updates as well as have the ability to carve out subregions while still utilizing the underlying medium-access implementation. Path Forward I plan on working on the above things with a few boards. I have haswell and baytrail boards. I should be getting some cubie paraphernalia this week to have both an x86 and arm environment. Yes, some of the proposals are somewhat soft and fluffy so there will be some exploration involved, but most of these things are quite doable in a small amount of time. Stealing Patrick's word, the hard part will be "dragging" other systems forward. Thanks for your time. -Aaron

1 0

Re: [coreboot] New addendums to INTEL FSP family
by mrnuke 02 Apr '14

02 Apr '14

On Wednesday, April 02, 2014 10:25:39 AM ron minnich wrote: > On Wed, Apr 2, 2014 at 10:17 AM, David Hubbard > > <david.c.hubbard+coreboot(a)gmail.com> wrote: > > Could the two interested parties negotiate a compromise? In my mind that's > > Google calling Intel, and they talk it over. That probably just > > demonstrates how little I understand about who and what is involved. > > Goodness, you think that has not happened, frequently, not just with > Google but with many parties over the last 15 years? I'm afraid it > demonstrates what you said :-( > Going back to the original FSP issue here. What does it take to get Intel to consider putting FSP in a reasonably upstreamable state? Alex

1 0

Re: [coreboot] New addendums to INTEL FSP family
by mrnuke 02 Apr '14

02 Apr '14

On Wednesday, April 02, 2014 10:17:13 AM ron minnich wrote: > On Wed, Apr 2, 2014 at 10:15 AM, mrnuke <mr.nuke.me(a)gmail.com> wrote: > > $ git grep -i intel |grep -i copyright |grep -v microcode > > Point being? > I talk about Intel and their attempt to circumvent the wishes of the rightsholders. You talk about vendors also being rightsholders. Intel has no significant code, and zero contributions to coreboot. Alex

1 0

Re: [coreboot] New addendums to INTEL FSP family
by ron minnich 02 Apr '14

02 Apr '14

On Wed, Apr 2, 2014 at 10:17 AM, David Hubbard <david.c.hubbard+coreboot(a)gmail.com> wrote: > Could the two interested parties negotiate a compromise? In my mind that's > Google calling Intel, and they talk it over. That probably just demonstrates > how little I understand about who and what is involved. Goodness, you think that has not happened, frequently, not just with Google but with many parties over the last 15 years? I'm afraid it demonstrates what you said :-( But, really, if you did know, your head would explode, as mine does, frequently. > > But I ordered an HP Pavilion m6-1035dx. It appears the OEM's neglect of AMD > has meant they haven't "added features," which makes our job easy and > weakens Intel's negotiating position. I doubt it weakens anyone's position on anything. Well, I don't doubt it -- I know it. The only way it works is if HP starts distributing coreboot on that laptop. And, clearly, they don't perceive that as in their interest. It's all about quantity. That's what the vendors used to hit me over the head with, repeatedly. I got sick of hearing "tell me how many million more systems this will sell", but I heard it from all of them, save AMD. AMD has been very visionary in their attitudes in many ways. Would that the OEM's were as visionary. I really don't want to be rude here, not trying to be, but there's a lot of talk on this issue that is driven by ignorance. And the people who know what's going on, can't talk; the people who don't know, talk :-) Twas ever thus. Anyway, one more pass, and I mute this thread :-) ron

1 0

Re: [coreboot] New addendums to INTEL FSP family
by mrnuke 02 Apr '14

02 Apr '14

On Wednesday, April 02, 2014 10:08:37 AM ron minnich wrote: > On Wed, Apr 2, 2014 at 9:38 AM, mrnuke <mr.nuke.me(a)gmail.com> wrote: > > That is a clear attempt to circumvent the > > > > wishes of the rightsholders to this project. > > That part I believe you are missing here is that this is a balancing > act. The vendors are rightsholders too. They have knowledge we need. > Unfortunately, most of them no longer want to release it -- it's not > 1999. It's all well and good to say "well sod them then" but that's > simply not an option on a large scale. I don't like it, you don't like > it, we don't like it, ... but there it is. > $ git grep -i intel |grep -i copyright |grep -v microcode Alex

2 2

← Newer
1
2
3
4
5
6
7
8
9
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 April 2014