On Mon, 15 Jul 2013 08:14:22 -0700 ron minnich rminnich@gmail.com wrote:
I don't see how excluding the new, fixed version from coreboot helps anything. Further, it means you don't have bug-fixed microcode, which seems bad.
It is at least a licensing problem: That microcode has a proprietary license in its header, with some terms that are incompatible with the GPLv2... And coreboot is released under the GPLv2.
Denis.
On Mon, Jul 22, 2013 at 11:25 AM, Denis 'GNUtoo' Carikli GNUtoo@no-log.org wrote:
It is at least a licensing problem: That microcode has a proprietary license in its header, with some terms that are incompatible with the GPLv2... And coreboot is released under the GPLv2.
Given the effort into making sure that was not going to be an issue, I'd like to understand your concerns.
ron
On 07/22/2013 01:25 PM, Denis 'GNUtoo' Carikli wrote:
On Mon, 15 Jul 2013 08:14:22 -0700 ron minnich rminnich@gmail.com wrote:
I don't see how excluding the new, fixed version from coreboot helps anything. Further, it means you don't have bug-fixed microcode, which seems bad.
It is at least a licensing problem: That microcode has a proprietary license in its header, with some terms that are incompatible with the GPLv2... And coreboot is released under the GPLv2.
Denis,
We have in place a pretty darn good infrastructure of separating the microcode from the coreboot stages. It's very easy to store microcode as a _separate_ CBFS file. Not all CPUs use this, but changing this is trivial. Patches welcome.
Alex
* Alex G. mr.nuke.me@gmail.com [130725 22:23]:
Denis,
We have in place a pretty darn good infrastructure of separating the microcode from the coreboot stages. It's very easy to store microcode as a _separate_ CBFS file. Not all CPUs use this, but changing this is trivial. Patches welcome.
I agree with Alex: If you are concerned by this issue, please make an effort to fix it. It would be great to bring the clear level of separation that we have on newer systems to older CPU types. In the sense of licensing, CPU microcode is just data processed by coreboot.
Stefan
On Tue, Jul 30, 2013 at 02:40:16AM +0200, Stefan Reinauer wrote:
I agree with Alex: If you are concerned by this issue, please make an effort to fix it. It would be great to bring the clear level of separation that we have on newer systems to older CPU types. In the sense of licensing, CPU microcode is just data processed by coreboot.
Does the ARM chromebook have microcode?
On 7/29/13 11:43 PM, Eugen Leitl wrote:
On Tue, Jul 30, 2013 at 02:40:16AM +0200, Stefan Reinauer wrote:
I agree with Alex: If you are concerned by this issue, please make an effort to fix it. It would be great to bring the clear level of separation that we have on newer systems to older CPU types. In the sense of licensing, CPU microcode is just data processed by coreboot.
Does the ARM chromebook have microcode?
No, but it comes with an 8k signed, binary primary bootloade that loads coreboot from flash.
On Tue, Jul 30, 2013 at 2:39 AM, Stefan Reinauer stefan.reinauer@coreboot.org wrote:
No, but it comes with an 8k signed, binary primary bootloade that loads coreboot from flash.
in other words, the days when we could have 0 binary blobs are fast ending.
I don't like that either. But I don't create the chips.
ron
-
Alex G. -
Denis 'GNUtoo' Carikli -
Eugen Leitl -
ron minnich -
Stefan Reinauer