coreboot January 2017

coreboot@coreboot.org

75 participants
186 discussions

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system
by Zoran Stojsavljevic 20 Jan '17

20 Jan '17

Ron (also Stefan Reinauer), You're all Google employees. Coreboot primes bought by Google. You all (Patrick, I am targeting you as well) earn lot of bucks... Don't you all? And you all have an influence. Don't deny this! And... Sergey Brin makes lot of monies. Quite. And... I know Russian mentality. I do. As Russian language. Russian teachers (from Detain camps in Sebirea teached me). Do NOT sell to me (at least) these reasons. Do not sell me this sh@@t! Either: Google will support Coreboot, either, Google will let you all to beg... And here, you (Google employees) you are asking?! For what??? Thank you, Zoran Stojsavljevic (independent/not to be blackmailed by anybody) contributor! On Wed, Jan 18, 2017 at 2:14 AM, ron minnich <rminnich(a)gmail.com> wrote: > Speaking from a former buyer of hardware, I can tell you from long > experience, it is *really* hard to specify coreboot as a mandatory > requirement. I've got stories going back 17 years now. > > Even when it makes sense, it's hard. > > I don't think we should count on the gov't to do the right thing. > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Proposal: "Freedom level" field for boards supported by coreboot
by Taiidan＠gmx.com 20 Jan '17

20 Jan '17

On 01/19/2017 06:16 PM, Andrés Domínguez wrote: > 2017-01-18 23:39 GMT+01:00 Timothy Pearson <tpearson(a)raptorengineering.com>: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> All, >> >> I've been working on a new way to classify boards supported by coreboot >> based on their freedom level. > Very good idea. > >> I uploaded the classification criteria to >> the Wiki here >> >> https://www.coreboot.org/Board_freedom_levels > There are a few things that I don't like about your categories, > specially the "scary red Pwned": Don't you think that people reading > the coreboot web page, will think that the "Pwned" are worse than > buying any random board not supported by coreboot, with the same > freedom issues? I would use not colored not named for the last > category. Gold, Silver and Bronze sound good to me, you could always > add Platinum and Iridium if more free boards appear and + or - for > every category that needs subcategories. > > I also agree with Julius about the ARM platforms that have not > supported GPU or WIFI. For many use cases GPU is not needed, and WIFI > can be replaced by PCIe or USB one. > > Andrés FSP coreboot isn't the real thing, it is almost absolutely pointless as it doesn't really do anything at all - we shouldn't entertain the purism idiots who support that. x86 is dead, in a year or so you won't be able to find any new non FSP/ME/PSP type motherboards so we will be reduced to buying overpriced used boards from ebay (kgpe-d16 - get em new while you can boys) At this point the only realistic option is a campaign to make libre one of the more affordable POWER8 systems, eventually they will come down in price and it'll be affordable (in 2012 a brand new kgpe d16 plus new cpu ram etc would be just as much as a lower end POWER8 is now) Unfortunate despite all the linux sysadmin's who are making 100K+ per year the authentic "hacker" culture[1] is nearly dead so nobody really cares about free firmware enough to cough up real money for to make it a reality, which is why TALOS failed. [1] people who work for facebook, google or another web 2.0 trendster company and who call themselves a "hacker" don't fall in to this category.

2 1

Re: [coreboot] Using as default external monitor for booting in x230
by Peter Stuge 20 Jan '17

20 Jan '17

Car.cuevas via coreboot wrote: > Well actually, for me what's important is that I can be able to see > through DP2 from the docker, If I can alter actually the backlight > sequence, and setup the DP2 as the first one, but I have to say > sorry because from your explanations I am not sure if it means that > with Coreboot, the OS would be able to handle to show through the > DP2 the video signal or not?.. Firmware and OS need to both support using the external port. coreboot does not currently have end-user-consumable support for the external port. Two different development efforts seem possible: 1. Try to find out if you can use vendor VGA BIOS with or without SeaBIOS to use the external port. I estimate chance of success to be 95% and the effort to be fairly small, but you will need to reverse engineer x86 assembly. 2. Connect Nico's libgfxinit (written in Ada) with the coreboot panel and backlight power code. > For the mod, I have now actually in the BIOS didn't have to do a > thing, just to set up in the bios as default screen the DP2, So you did have to do a thing, and you'll be the first person doing that thing with coreboot, if you want to have a go at it. //Peter

1 0

Re: [coreboot] Coreboot binary for ASUS F2A85-M
by Daniel Kulesz 20 Jan '17

20 Jan '17

Hi Max, I had my F2A-85M working with an A10-6700 which needed some additional tweaking because the Quadcore-CPU was causing timing issues in SeaBIOS. On my previous cpu (A4-5300) everything was fine so I suppose the same should work on your dualcore as well. You can find my config files (for the A10-6700) together with some logs in this commit: https://review.coreboot.org/cgit/board-status.git/commit/?id=947fdae2518172… However, I also had the issue that I didn't receive any video output unless the Linux kernel initialized the video or I plugged an PCIe GPU. I tried including the VBIOS, but were out of luck for both CPUs/APUs. Did you try hooking up a serial cable to see what is going on (provided you have debug instructions compiled in). Cheers, Daniel

1 0

Re: [coreboot] Proposal: "Freedom level" field for boards supported by coreboot
by Timothy Pearson 20 Jan '17

20 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/19/2017 05:16 PM, Andrés Domínguez wrote: > 2017-01-18 23:39 GMT+01:00 Timothy Pearson <tpearson(a)raptorengineering.com>: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> All, >> >> I've been working on a new way to classify boards supported by coreboot >> based on their freedom level. > > Very good idea. > >> I uploaded the classification criteria to >> the Wiki here >> >> https://www.coreboot.org/Board_freedom_levels > > There are a few things that I don't like about your categories, > specially the "scary red Pwned": Don't you think that people reading > the coreboot web page, will think that the "Pwned" are worse than > buying any random board not supported by coreboot, with the same > freedom issues? I would use not colored not named for the last > category. Gold, Silver and Bronze sound good to me, you could always > add Platinum and Iridium if more free boards appear and + or - for > every category that needs subcategories. > > I also agree with Julius about the ARM platforms that have not > supported GPU or WIFI. For many use cases GPU is not needed, and WIFI > can be replaced by PCIe or USB one. > > Andrés No problem. I'll see about revising the last category some this weekend. Thank you all for your input! - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJYgU0OAAoJEK+E3vEXDOFbQQoH/iRToqXNfs7Zpsp1ZKwKzZ7g 6sg2bcK7DcWMonthPCcwNqtmm4Xn0x/hpcSsNhtfZ4p15YZn1V+1bLRwu/afAmRq /R+R9aG3yWxWSmaOeJnQCdKQc7cYlFMacLOQ8Cjb+/cIR7EjE6Vpb9fv0benynCK 6m/WTu/FrOuo7Wi0Xs/aCP4PGABMdtIAzAhZ2/XOHdRSR8Go2yk95xPwxbB2VMAX DPg8qEjYjYzZf4tsNfJpk8yunpUIDxuzTNcQCePA0X8PqbqDMV9cu/+3XZVNy2Q9 Wuhifvv0HO5oXUn89HMEXFrj8giy/1SIuC0uH0kusyBS5AtRafQBtrA63oz8sUs= =Bft/ -----END PGP SIGNATURE-----

1 0

Re: [coreboot] Proposal: "Freedom level" field for boards supported by coreboot
by Sam Kuper 20 Jan '17

20 Jan '17

On 19/01/2017, Andrés Domínguez <andresdju(a)gmail.com> wrote: > 2017-01-18 23:39 GMT+01:00 Timothy Pearson <tpearson(a)raptorengineering.com>: >> https://www.coreboot.org/Board_freedom_levels > > There are a few things that I don't like about your categories, > specially the "scary red Pwned": Don't you think that people reading > the coreboot web page, will think that the "Pwned" are worse than > buying any random board not supported by coreboot, with the same > freedom issues? Any random board that *isn't* pre-2010 Intel or pre-2014 AMD? I think the "Pwned" category is pretty well described. Timothy: good work. Thank you for doing it. Btw, about SBCs, might be worth seeing if the classifications used on the FSF's SBC page, and those used within Coreboot (if Timothy's proposal is adopted), could be harmonised. That would, I hope, improve clarity/standardisation, and reduce confusion. I'm CC'ing Paul Kocialkowsi, the maintainer of the FSF page. https://www.fsf.org/resources/hw/single-board-computers

1 0

Re: [coreboot] Proposal: "Freedom level" field for boards supported by coreboot
by Peter Stuge 20 Jan '17

20 Jan '17

I would also like to establish a classification. Thank you for making a concrete suggestion. Julius Werner wrote: > So as a quick brainstorming, I'd rather suggest a ranking roughly like > this to fairly reflect the risk the user is exposed to: > > A. Everything free. > B. Non-essential component (e.g. GPS sensor) requiring proprietary firmware. > C. Network component (e.g. WiFi) requiring proprietary firmware if it > can be bypassed (e.g. USB, expansion card). > D. Input/output-sniffing component (pointing device, keyboard, > display, audio) requiring proprietary firmware if it can be bypassed, > or CPU requiring microcode if it can be bypassed (e.g. just using > factory ROM code). > E. CPU or equivalently privileged processor requiring non-resident > proprietary boot firmware. > F. Network component requiring proprietary firmware that cannot be > bypassed (e.g. no USB ports). > G. Input/output-sniffing component requiring proprietary firmware that > cannot be bypassed, or CPU requiring microcode that cannot be > bypassed. > H. CPU or equivalently privileged processor requiring resident > proprietary firmware (e.g. Intel ME, Qualcomm TrustZone). I like this a lot. A few points: The name should communicate "end-user ownership". Well-established software terminology (like "open", "free" and "libre") is too niche to be helpful in a store. Higher score meaning lower "end-user ownership" seems counter-intuitive. It's important to keep classification simple. The EU has an energy consumption label. They started with {A,B,C,D} in 1992 and had to introduce A{+,++,+++} later, as technology improved. https://en.wikipedia.org/wiki/European_Union_energy_label We should re-use those classes, and learn from that project. I think the malus-contributing components in a system could be broken down into a small number, and could also be displayed using pictograms. (Here, even a distinction between Wi-Fi and Ethernet is problematic.) Finally, please consider how successful a classification will be if every single product on the market except one gets a failing grade. //Peter

1 0

Proposal: "Freedom level" field for boards supported by coreboot
by Timothy Pearson 20 Jan '17

20 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I've been working on a new way to classify boards supported by coreboot based on their freedom level. I uploaded the classification criteria to the Wiki here https://www.coreboot.org/Board_freedom_levels and some initial values for common boards here https://review.coreboot.org/#/c/18168 Comments and suggestions are welcome! - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJYf+6tAAoJEK+E3vEXDOFbOzMIAJeUkRhUCX55f6WZmslrsWjS CirrWec/221w57lZ2tIqNqm0iFywXsks56gGJajErPNL5fTsbuMfxgvIZbHCO8hK pUaPEO0rz+rltxyETpOEvTwWa1RfZ5yCkniKu93QYFFw+62p8DLckeuNqOX3JVQg 5MULlwGJ24QYSgLidydHAP5hCDCWR+rPnDNUD0GsHXxGDUYwMLeatxaONNL++564 ylEbx4GyTJIlv5k5L7SRALURcNTDgTO5ZGHvHJTzXm+zlVmQQeEACg8BmiGFp+rz EXZSDHpekM0UZm6vGcZu0KWr4wV+9TOWtLtnghTForMrWT5vGO3OQ0NHQzN3Aks= =0ycX -----END PGP SIGNATURE-----

3 2

Re: [coreboot] Using as default external monitor for booting in x230
by Car.cuevas 19 Jan '17

19 Jan '17

Hi, thanks for both answers Nico and Ron, Well actually, for me what's important is that I can be able to see through DP2 from the docker, If I can alter actually the backlight sequence, and setup the DP2 as the first one, but I have to say sorry because from your explanations I am not sure if it means that with Coreboot, the OS would be able to handle to show through the DP2 the video signal or not?.. For the mod, I have now actually in the BIOS didn't have to do a thing, just to set up in the bios as default screen the DP2, but nothing else was needed, actually the operating system detects as they were 2 screens and manage them. Thanks once more for your help :) -------- Original Message -------- Subject: Re: [coreboot] Using as default external monitor for booting in x230 Local Time: January 15, 2017 7:20 PM UTC Time: January 15, 2017 6:20 PM From: rminnich(a)gmail.com To: Nico Huber <nico.h(a)gmx.de>, Car.cuevas <car.cuevas(a)protonmail.com>, coreboot(a)coreboot.org <coreboot(a)coreboot.org> On Sun, Jan 15, 2017 at 10:09 AM Nico Huber <nico.h(a)gmx.de> wrote: It wouldn't matter as the current native gfx code in coreboot doesn't support external displays. Yes. I started that code as a "let's get chromebooks to not use the video binary blob" project. That was five years ago, if you can believe it. I did not realize when I started it just how complicated it would get. But external display support was not a goal. Of course, with support from the chipset vendor it would have gone much more smoothly and we could have all been using open source gfx code for five years now, but you all know how that story ends ... Note that x86 chromebooks still use the VGA BIOS. If you want OSS for the gfx initialization, there's also libgfxinit (written in Ada, see 3rdparty/libgfxinit in the coreboot tree). It can enable external displays but would need some patching to make the panel power and backlight control work with that. Yes. I think the Ada code is far superior to the C code at this point. I think it makes sense to focus on extending it as opposed to working on the C gfx code. ron

1 0

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system
by Timothy Pearson 19 Jan '17

19 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/17/2017 11:24 AM, Martin Roth wrote: > Hi Everyone, > I suspect that everyone has already heard that unfortunately, the > funding for Raptor Engineering's Talos workstation project was not > successful, so I wanted to make a final post to wrap this up. Between > 12 people, we had raised enough to buy the full system and a > processor, and I'd like to once again thank everyone who committed > money to helping the project. > > If you haven't read Timothy's final post, I thought it was fairly > relevant, although I suspect that many of the people in the coreboot > community already know many of his points. > https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstati… > > Also in the final update, Timothy mentions some of the future projects > that Raptor is planning to work on, including developing an open BMC > board for the Asus KGPE-D16 board. If anyone would like to help fund > that, or transfer any of the money that they were going to use to > support the Talos project, I'll match contributions with the money I > was going to put towards Talos. He also mentions that he's going to > keep working on open-power solutions, so I'm definitely looking > forward to seeing what happens with that. Regarding the BMC work, we're looking to enable a fully libre BMC on the KGPE-D16. This is a complex process involving significant reverse engineering efforts, writing new kernel drivers for the BMC, etc. With the BMC enabled, proper fan control can be established on the KGPE-D16, in addition to remote console access and of course remote power on / power off / reset functionality. If this work can be funded, Raptor would chip in a matching amount to lower the costs to the community; essentially we're looking to fund half of the work internally but cannot justify the full cost of the work as the sole sponsor. Every little bit helps, so even if you can only chip in $100 please consider doing so. I strongly encourage the community to assist in this effort; until OpenPOWER systems come down in price or RISC-V improves in performance (likely over a decade or more), the KGPE-D16 represents the maximum performance hardware available to those requiring a fully libre, blob-free firmware and kernel stack. Enabling a libre BMC option on these boards will make it easier for the organizations that rely on this hardware to manage their systems, helping them spend less time on routine maintainance and more time on their mission and/or further libre software development. Thanks! - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJYfn1uAAoJEK+E3vEXDOFbTV4H+QHqUiszRRI7kp5Qd0p/uI7G tOyL32CzMrUqekDj+A/V1gC5lYtQbjN6WzcMrBFQ9lvJrQy/GxFoRn0cHaZtteya MmqugPSGotjARM2quWCkbIdhNGgyzKWr+BHwpImH9SyiJ0nozl4RDGDfqhqdPI3+ 7nt4TAc54Kq9yhUlP9XLpYq6Gi67sYt0qgVXyNhekiT4a7HrG+0aLtu8mzOVMktc /oIqnhHlZQnX6LDvNkKJkifanrjL5NXigEEB/iwaFW56Pm9avs07pQeU0wnJjL4G pcNKQ7/4j2opEn//bBqofU3u60thdbxb16O3aBcAJTkUDFtNjeX0VNPNb56/5HQ= =uc5x -----END PGP SIGNATURE-----

6 9

← Newer
1
...
7
8
9
10
11
12
13
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2017