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.
Scott Duplichan [mailto:sc...@notabs.org] wrote:
]The UEFI payload project I have been working on is usable now,
]though it has been tested on a single board only (ASRock E350M1).
I updated this payload project so that coreboot modifications are
no longer needed. Now the payload is added using
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
Dear Dave, dear coreboot folks,
hopefully this can be discussed and agreed upon more quickly on the
list.
Am Samstag, den 14.12.2013, 01:25 +0100 schrieb Dave Frodin:
Dave Frodin (dave.fro...@se-eng.com) just uploaded a new patch set to gerrit,
which you can find at
On 12/14/2013 06:08 AM, Paul Menzel wrote:
Dear Dave, dear coreboot folks,
hopefully this can be discussed and agreed upon more quickly on the
list.
[...]
Are there boards in the tree with hard-coded memory
configuration/settings?
Yes. A number of google boards have DRAM chips
Am Samstag, den 14.12.2013, 09:35 -0600 schrieb mrnuke:
I have no idea how much data such a file contains. If it is rather small
can it be put into `devicetree.cb` directly?
Devicetree is used in ramstage, but you need the SPD in romstage.
The devicetree is available in romstage (read-only).
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
I try boot PC without payload. In make menuconfig have selected this options:
Devices:
Run VGA Option ROMs
Run non-VGA Option ROMs
VGA BIOS - Add a VGA BIOS image
(SC4-F400.BIN)
(5333,8a20)
PXE ROM:
(gpxe.rom) or (rtspxe_m.lom)
(10ec,8139)
PC boot and have only flash
Thanks everybody for the review and comments.
I'm going to push a new commit that does what needs to be done in
hopefully a better way.
The reading of the SPD will no longer be in the northbridge/ path but will
be in a lib function.
Thanks,
Dave
On Sat, Dec 14, 2013 at 9:40 AM, Patrick Georgi
On 12/14/2013 01:06 PM, Dave Frodin wrote:
Thanks everybody for the review and comments.
I'm going to push a new commit that does what needs to be done in
hopefully a better way.
The reading of the SPD will no longer be in the northbridge/ path but will
be in a lib function.
Thanks,
Dave
Dave Frodin wrote:
The reading of the SPD will no longer be in the northbridge/ path
but will be in a lib function.
Where will it read from?
Please don't answer just half of the comments.
What about devicetree.cb?
//Peter
--
coreboot mailing list: coreboot@coreboot.org
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.
24 matches
Mail list logo
