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 ;).
On Thu, Apr 3, 2014 at 1:03 AM, David Hendricks
> 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.
On Wed, Apr 2, 2014 at 11:11 PM, Stojsavljevic, Zoran <
> > 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.
> 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!
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
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?
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
coreboot mailing list: coreboot(a)coreboot.org
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.
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'
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.
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.
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.
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?
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.
On Wed, Apr 2, 2014 at 10:17 AM, David Hubbard
> 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
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 :-)
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