Hi Alex,
thanks for this effort. Without having looked at the patches yet, I
think moving microcode into 3rdparty / blobs.git is the right way to
go. This is one of the (my) original intentions of having CBFS to begin
with.
Stefan
* mrnuke mr.nuke...@gmail.com [131214 00:48]:
Hi all,
Processors which need microcode updates?
On Fri, Dec 13, 2013 at 9:28 PM, mrnuke mr.nuke...@gmail.com wrote:
On 12/13/2013 11:24 PM, Gabe Black wrote:
If you don't want to hear it, ignore it. We shouldn't break things just
so people with mistaken opinions are happy, nor how long it took to
On 12/13/2013 11:30 PM, Gabe Black wrote:
Processors which need microcode updates?
And how are we breaking them when the defaults don't change? You already
have the option, today, to not include microcode updates. It's just not
on by default.
On Fri, Dec 13, 2013 at 9:28 PM, mrnuke
Defaults should work. Why should I have to know about a magic option that
will make my computer not crash at random? If you don't want your computer
to work that badly, you should also be motivated enough to find the magic
switch that will break it. Breaking people by default in mysterious and
On 12/13/2013 11:35 PM, Gabe Black wrote:
Defaults should work. Why should I have to know about a magic option
that will make my computer not crash at random? If you don't want your
computer to work that badly, you should also be motivated enough to find
the magic switch that will break it.
There's a knob. It's called 'microcode updates'. If you set the knob
to 'offf' the firmware image you build, and boot, may let the CPU do
very bad things to you, in unpredictable ways, at unpredictable times,
including (on some CPUs) cause very difficult to detect data
corruption because (on some
On 12/14/2013 12:36 AM, ron minnich wrote:
And I think it even worse to put the microcode blobs in a location in
the tree that implies, by its existence, that you can build without
them and get a more free, working firmware image.
You can't have a working build on a bunch of recent hardware
On Fri, Dec 13, 2013 at 10:46 PM, mrnuke mr.nuke...@gmail.com wrote:
You can't have a working build on a bunch of recent hardware without
blobs. So the assumption that you can build without blobs is false.
Pure and simple.
ok, so you are upset that clueless (your word, not mine :-) people
On 12/14/2013 05:44 AM, ron minnich wrote:
Scott, I don't see the point of this change either.
In the beginning, we had no microcode in coreboot, per the main goal:
let linux do it. We just let Linux do the update. Not our problem.
At some point, ca. 2005 or so, we had to let the blobs in
Hello!
What are we breaking? Tradition. Also reality. And probably a heck of
a lot of rules and means and methods. Plus some physical laws
regarding technology, that we won't know we've broken, until our new
gadget works, and probably starts up and does everything properly,
unlike its earlier boot
On 12/14/2013 12:59 AM, ron minnich wrote:
On Fri, Dec 13, 2013 at 10:46 PM, mrnuke mr.nuke...@gmail.com wrote:
You can't have a working build on a bunch of recent hardware without
blobs. So the assumption that you can build without blobs is false.
Pure and simple.
ok, so you are upset
Am 14.12.2013 06:24, schrieb Gabe Black:
If you don't want to hear it, ignore it.
That's rude. It works if you don't care at all for the people with that
(somewhat weird) opinion, but there are a number of contributors that
are uneasy about these binary things.
The point isn't to break things
On 14.12.2013 07:46, mrnuke wrote:
On 12/14/2013 12:36 AM, ron minnich wrote:
And I think it even worse to put the microcode blobs in a location in
the tree that implies, by its existence, that you can build without
them and get a more free, working firmware image.
You can't have a working
On 14.12.2013 07:59, ron minnich wrote:
On Fri, Dec 13, 2013 at 10:46 PM, mrnuke mr.nuke...@gmail.com wrote:
What's the point? Why not just enlighten them? I just can not understand this.
Some distros have a policy of putting free and non-free components in
separate repositories (E.g Debian
On Fri, Dec 13, 2013 at 11:47 PM, Kyösti Mälkki kyosti.mal...@gmail.com wrote:
Microcode update files downloaded from Intel or AMD sites may contain
licensing terms not compatible with GPLv2. Those original license texts have
not been enclosed in the same commit with microcode update when they
ok, ok, removing -2. Doesn't mean I like it, but I'm willing to accept
that I'm probably wrong (again :-)
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
ron minnich wrote:
I do not understand why you are against moving microcodes to blobs.git.
because we have something that works today
That is, unfortunately, quite telling. :( I would hope that the
coreboot community as a whole strives for a whole lot better than
works thank you very much.
Hi all,
Following some recent discussions on IRC, we've see that some people
just don't like us shipping microcode in the main repository. OK,
microcode is a blob, so it belongs in blobs. Let's leave that at that.
Kyösti and I are working on making all CPUs update microcode from CBFS.
This is
mrnuke [mailto:mr.nuke...@gmail.com] wrote:
]Hi all,
]
]Following some recent discussions on IRC, we've see that some people
]just don't like us shipping microcode in the main repository. OK,
]microcode is a blob, so it belongs in blobs. Let's leave that at that.
De-blobing agesa is going to be
Scott, I don't see the point of this change either.
In the beginning, we had no microcode in coreboot, per the main goal:
let linux do it. We just let Linux do the update. Not our problem.
At some point, ca. 2005 or so, we had to let the blobs in because many
of the new CPUs are *broken* without
On 12/13/2013 09:44 PM, ron minnich wrote:
I guess I don't understand why people feel better being able to build
a firmware image which will boot the CPU in a broken mode.
I have no idea either. However, what I do have is chronic fatigue from
hearing clueless people complain and moan about
If you don't want to hear it, ignore it. We shouldn't break things just so
people with mistaken opinions are happy, nor how long it took to rearrange
things into a broken state.
Gabe
On Fri, Dec 13, 2013 at 9:14 PM, mrnuke mr.nuke...@gmail.com wrote:
On 12/13/2013 09:44 PM, ron minnich wrote:
On 12/13/2013 11:24 PM, Gabe Black wrote:
If you don't want to hear it, ignore it. We shouldn't break things just
so people with mistaken opinions are happy, nor how long it took to
rearrange things into a broken state.
What exactly are we breaking?
--
coreboot mailing list:
23 matches
Mail list logo
