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
* 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
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
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
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
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
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
* 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
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
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
