coreboot December 2017

coreboot@coreboot.org

68 participants
177 discussions

Re: [coreboot] Embedded Controller (EC)
by Аладышев Константин 11 Dec '17

11 Dec '17

I'm a little bit confused. When we say 'main EC' controller, do we mean ACPI EC controller? The one that provides special interface with EC_SC, EC_DATA registers as defined in ACPI spec. Cause my main purpose right now is to make standard OS-battery interface through embedded controller. And I’m looking for the simplest way to do it. As I understand ‘chromeec’ projects describes all embedded controllers used in chromebooks and this includes as standard ACPI EC controllers, as special embedded controllers for things like USB Type-C to DP/HDMI/VGA adapter. Are there any boards in 'chromeec' project that use STM32 as 'main EC'? Or STM32 is only used for other special things like USB Type-C to DP/HDMI/VGA adapter? And is there any info document that describes all boards in ‘board’ catalog? Best Regards, Aladyshev Konstantin From: rspangler(a)google.com [mailto:rspangler@google.com] On Behalf Of Randall Spangler Sent: Friday, December 08, 2017 7:30 PM To: Аладышев Константин Cc: Vadim Bendebury; Coreboot; Shawn N Subject: Re: [coreboot] Embedded Controller (EC) On Fri, Dec 8, 2017 at 5:57 AM, Аладышев Константин <aladyshev(a)nicevt.ru> wrote: Thanks for your answer! I've looked more closely at Chromium Embedded Controller project and EC chips it supports. To my surprise 'chromeec' even supports ordinary STM32 controllers without ACPI EC registers (am I right?). Yes, we've used it for everything from the main EC to a USB-PD controller to a charger. STM32 isn't suitable as the main EC for x86-based Chromebooks, of course, due to lack of eSPI / LPC. So I think is it very important to do schematics as it is in Chromebooks to make use of this project. Is there any chance to find schematics for Chromebook boards, to get reference design of implementing ECs with ‘chromeec’ project? I don't know. But it supports several STM32 discovery boards, so you can tinker with it on ready-built hardware. Best regards, Aladyshev Konstantin From: rspangler(a)google.com [mailto:rspangler@google.com] On Behalf Of Randall Spangler Sent: Friday, December 01, 2017 7:02 PM To: Vadim Bendebury Cc: Аладышев Константин; Coreboot; Shawn N Subject: Re: [coreboot] Embedded Controller (EC) On Fri, Dec 1, 2017 at 6:32 AM, Vadim Bendebury <vbendeb(a)chromium.org> wrote: [+cc a couple of guys who might have some advice in this respect] On Fri, Dec 1, 2017 at 5:07 AM, Аладышев Константин <aladyshev(a)nicevt.ru> wrote: Hello! I'm trying to understand, what is the easiest way today to integrate EC to custom motherboard? What controller should I choose for new custom motherboard? 1) First of all, are there any ECs on market that ship with embedded firmware, where all you need to do is just a little bit of register configuration (like SuperIO)? Or is it always like you need to write all firmware by yourself? Most EC vendors that sell dedicated ECs also sell their SDK and source code, but it's not cheap. So usually roll your own, hopefully based on an open design. In that case what is the main difference between ordinary microcontroller (for example STM32) and some controller marked by vendor as EC? Interfaces. EC will have: • Keyboard scanner • eSPI / LPC for connecting to x86 SoC • More I2C ports (and in the old days, PECI and PS/2 ports). 2) How stable and flexible are projects about open EC firmware? Is it possible to adapt these projects for my custom motherboard? I'm talking about: - Chromium Embedded Controller: http://www.chromium.org/chromium-os/ec-development This is used on all current Chromebooks, so it's full-featured and stable. We do tend to branch old boards, so if your motherboard has an old chipset on it you may need to look back in time to find support for it. - Origami-EC: https://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary 3) What is the current status of EC support from coreboot point of view? https://review.coreboot.org/cgit/coreboot.git/tree/src/ec Best regards, Aladyshev Konstantin -- coreboot mailing list: coreboot(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Embedded Controller (EC)
by Аладышев Константин 09 Dec '17

09 Dec '17

Hello! I'm trying to understand, what is the easiest way today to integrate EC to custom motherboard? What controller should I choose for new custom motherboard? 1) First of all, are there any ECs on market that ship with embedded firmware, where all you need to do is just a little bit of register configuration (like SuperIO)? Or is it always like you need to write all firmware by yourself? In that case what is the main difference between ordinary microcontroller (for example STM32) and some controller marked by vendor as EC? 2) How stable and flexible are projects about open EC firmware? Is it possible to adapt these projects for my custom motherboard? I'm talking about: - Chromium Embedded Controller: http://www.chromium.org/chromium-os/ec-development - Origami-EC: https://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary 3) What is the current status of EC support from coreboot point of view? https://review.coreboot.org/cgit/coreboot.git/tree/src/ec Best regards, Aladyshev Konstantin

4 4

Re: [coreboot] Hardware vendors offering systems with Intel ME disabled
by awokd 09 Dec '17

09 Dec '17

On Fri, December 8, 2017 4:44 am, Zoran Stojsavljevic wrote: > Let me try again to state what I stated before, with some new insides, > because Tim brought the new equation: HAP into > this discussion. In addition to all the issues with ME listed so far, systems from Dell etc. ship with UEFI BIOS. Due to its complexity and closed source approach, many different UEFI implementations have suffered many different vulnerabilities. Many (all?) include a full network stack. Coreboot is open source and simply a bootstrap, closing out large swaths of attack surfaces.

2 1

Move LinuxBoot mailing list to Mailman
by Paul Menzel 09 Dec '17

09 Dec '17

Dear Ron, Am Montag, den 04.12.2017, 15:58 +0000 schrieb ron minnich: > On Mon, Dec 4, 2017 at 12:37 AM Paul Menzel wrote: > > > > I can’t find the mailing list. Could you please share the URL (and put > > the list in CC)? > > https://groups.google.com/forum/#!forum/linuxboot Strange, that it wasn’t found. But *linuxboot* consists of two keywords used in different contexts too. > I sent an invite to you, Paul! Thank you I got that, and subscribed. I do not know, if Google Groups changed, but in the past, I always had a lot of problems to subscribe and manage such a subscription without a Google account. I just tried it again, and I do not even find a subscribe button. So, as it’s still early, I’d really welcome it, if you decided to move to Mailman. Would that be possible? > > Regarding the content of LinuxBoot [1], it will mostly then be > > documenting stuff, how LinuxBoot can be achieved? > > We're not sure. UEFI is so complex, and there are so many vendors writing > bad code for it, that at least part of this work involves "figure out what > a mess the ODM made of UEFI and work around it." > > Trammell had a very interesting post just today, concerning how Boot Device > Selection does all sort of things unrelated to Boot Device Selection -- on > an Intel board, of course. > > The purpose of the group: "Welcome to the LinuxBoot mailing list, wherein > we discuss using a Linux kernel as the ramstage (coreboot) or > DxeCore/BdsExe/UEFISHell replacement." s/SHell/Shell/ Though I got: > Generic list for the LinuxBoot firmware, not tied to any specific project > (coreboot, NERF, Heads, etc). Kind regards, Paul

2 1

Re: [coreboot] Embedded Controller (EC)
by Shawn N 08 Dec '17

08 Dec '17

On Fri, Dec 8, 2017 at 8:30 AM, Randall Spangler <rspangler(a)chromium.org> wrote: > On Fri, Dec 8, 2017 at 5:57 AM, Аладышев Константин <aladyshev(a)nicevt.ru> > wrote: >> >> Thanks for your answer! >> >> I've looked more closely at Chromium Embedded Controller project and EC >> chips it supports. To my surprise 'chromeec' even supports ordinary STM32 >> controllers without ACPI EC registers (am I right?). > > > Yes, we've used it for everything from the main EC to a USB-PD controller to > a charger. STM32 isn't suitable as the main EC for x86-based Chromebooks, > of course, due to lack of eSPI / LPC. > >> >> So I think is it very important to do schematics as it is in Chromebooks >> to make use of this project. >> >> Is there any chance to find schematics for Chromebook boards, to get >> reference design of implementing ECs with ‘chromeec’ project? > > > I don't know. But it supports several STM32 discovery boards, so you can > tinker with it on ready-built hardware. There are also schematics available for several misc. peripherals that use stm32 + cros_ec, see twinkie for example: https://www.chromium.org/chromium-os/twinkie Unfortunately there are no schematics for actual Chromebook mainboards publicly available. I looked into making some public, but there were some overriding concerns. > >> >> Best regards, >> Aladyshev Konstantin >> >> >> >> From: rspangler(a)google.com [mailto:rspangler@google.com] On Behalf Of >> Randall Spangler >> Sent: Friday, December 01, 2017 7:02 PM >> To: Vadim Bendebury >> Cc: Аладышев Константин; Coreboot; Shawn N >> Subject: Re: [coreboot] Embedded Controller (EC) >> >> On Fri, Dec 1, 2017 at 6:32 AM, Vadim Bendebury <vbendeb(a)chromium.org> >> wrote: >> [+cc a couple of guys who might have some advice in this respect] >> >> On Fri, Dec 1, 2017 at 5:07 AM, Аладышев Константин <aladyshev(a)nicevt.ru> >> wrote: >> Hello! I'm trying to understand, what is the easiest way today to >> integrate >> EC to custom motherboard? What controller should I choose for new custom >> motherboard? >> >> 1) First of all, are there any ECs on market that ship with embedded >> firmware, where all you need to do is just a little bit of register >> configuration (like SuperIO)? Or is it always like you need to write all >> firmware by yourself? >> >> Most EC vendors that sell dedicated ECs also sell their SDK and source >> code, but it's not cheap. So usually roll your own, hopefully based on an >> open design. >> >> In that case what is the main difference between >> ordinary microcontroller (for example STM32) and some controller marked by >> vendor as EC? >> >> Interfaces. EC will have: >> • Keyboard scanner >> • eSPI / LPC for connecting to x86 SoC >> • More I2C ports >> (and in the old days, PECI and PS/2 ports). >> >> >> 2) How stable and flexible are projects about open EC firmware? Is it >> possible to adapt these projects for my custom motherboard? >> >> I'm talking about: >> - Chromium Embedded Controller: >> http://www.chromium.org/chromium-os/ec-development >> >> This is used on all current Chromebooks, so it's full-featured and stable. >> We do tend to branch old boards, so if your motherboard has an old chipset >> on it you may need to look back in time to find support for it. >> >> >> - Origami-EC: https://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary >> >> 3) What is the current status of EC support from coreboot point of view? >> https://review.coreboot.org/cgit/coreboot.git/tree/src/ec >> >> Best regards, >> Aladyshev Konstantin >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> >> >> >

1 0

Re: [coreboot] Embedded Controller (EC)
by Аладышев Константин 08 Dec '17

08 Dec '17

Thanks for your answer! I've looked more closely at Chromium Embedded Controller project and EC chips it supports. To my surprise 'chromeec' even supports ordinary STM32 controllers without ACPI EC registers (am I right?). So I think is it very important to do schematics as it is in Chromebooks to make use of this project. Is there any chance to find schematics for Chromebook boards, to get reference design of implementing ECs with ‘chromeec’ project? Best regards, Aladyshev Konstantin From: rspangler(a)google.com [mailto:rspangler@google.com] On Behalf Of Randall Spangler Sent: Friday, December 01, 2017 7:02 PM To: Vadim Bendebury Cc: Аладышев Константин; Coreboot; Shawn N Subject: Re: [coreboot] Embedded Controller (EC) On Fri, Dec 1, 2017 at 6:32 AM, Vadim Bendebury <vbendeb(a)chromium.org> wrote: [+cc a couple of guys who might have some advice in this respect] On Fri, Dec 1, 2017 at 5:07 AM, Аладышев Константин <aladyshev(a)nicevt.ru> wrote: Hello! I'm trying to understand, what is the easiest way today to integrate EC to custom motherboard? What controller should I choose for new custom motherboard? 1) First of all, are there any ECs on market that ship with embedded firmware, where all you need to do is just a little bit of register configuration (like SuperIO)? Or is it always like you need to write all firmware by yourself? Most EC vendors that sell dedicated ECs also sell their SDK and source code, but it's not cheap. So usually roll your own, hopefully based on an open design. In that case what is the main difference between ordinary microcontroller (for example STM32) and some controller marked by vendor as EC? Interfaces. EC will have: • Keyboard scanner • eSPI / LPC for connecting to x86 SoC • More I2C ports (and in the old days, PECI and PS/2 ports). 2) How stable and flexible are projects about open EC firmware? Is it possible to adapt these projects for my custom motherboard? I'm talking about: - Chromium Embedded Controller: http://www.chromium.org/chromium-os/ec-development This is used on all current Chromebooks, so it's full-featured and stable. We do tend to branch old boards, so if your motherboard has an old chipset on it you may need to look back in time to find support for it. - Origami-EC: https://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary 3) What is the current status of EC support from coreboot point of view? https://review.coreboot.org/cgit/coreboot.git/tree/src/ec Best regards, Aladyshev Konstantin -- coreboot mailing list: coreboot(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

2 1

Re: [coreboot] Disabling Intel ME 11 via undocumented mode
by Timothy Pearson 08 Dec '17

08 Dec '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 That's just the HAP bit. The ME is limited but NOT disabled, and the remaining stubs are still hackable [1]. Neither the ME or the PSP can ever be removed from their respective systems. They can both be limited to some extent, but to call either of them "disabled" is rather far from the truth. This all being said, it's great to see a light being shed on the ME. It shows just how dangerous an embedded, mandatory core with signed firmware can be. [1] https://twitter.com/rootkovska/status/938458875522666497 On 12/08/2017 07:51 AM, Zoran Stojsavljevic wrote: > Disabling Intel ME 11 via undocumented mode > http://blog.ptsecurity.com/2017/08/disabling-intel-me.html > > I just managed (few hours ago) to read this article (way after replying > to previous thread about Dell HAP, I read only few intro paragraphs)... > It is, after all, amazing how far these two people, *Mark Ermolov and > Maxim Goryachy* progressed with ME debugging/cracking > and understanding how ME is connected/related to the INTEL platforms' > bring up! > > I just stumbled over it upon searching about ME, and I know what they > did achieve previously. They achieved some > steps forward... :-) > > I did not see that this article was published before on Coreboot (excuse > me for my ignorance if I missed it), but it is worth > reading, every word of it, especially the second part! > > What is described on the second part is way (much) more than I was > willing to lament on (since in the lieu of the Legal > issues). Especially on BringUP stages. Excellent read! > > Something is definitely changing in the Open Source World... And I say, > I am very happy to read such articles! > > Man, there are very serious people out there trying to demystify secrets. > > I will read again this article later, very concentrated... Trying to put > some more comprehensive picture in my mind. > > Thank you, all of you, Black Hat, Positive Technology, and others! > > Molodci, rebjata! > > Zoran > - -- 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 iQEcBAEBAgAGBQJaKprdAAoJEK+E3vEXDOFbvZUH/0NN/gXYoyR3UIi/JWtZliYL bo7UAdl7lzLHPzNcZLBeuoYFICl38qKStS/fOHtDj8kHqRzSrMsrWsp7o11K8JjL vypOIhXnb+S+zBPI9e/ZLx6d9EKSV6KgWQJnVnzdh5ynNP+duR7Hbc322fu0qb/O XbEyZwlwmMwT9+OJ6fRusyACMdf8RtOrgrg3lyJ4oW66s48RYr3UN+PLImwYH3fX 2Kid5DxtqMQ2BR6cDHKnlGJuV+X83CTZempfgodJWSaQneg7tKqwCa39/Zv9FbC6 RFQ4Z3gkGtXDl4Br2ovxHcuqUtMuuVUwYSoa31nilu0GJRVpA2mgjVMxVw7UGf0= =AeQJ -----END PGP SIGNATURE-----

3 2

Disabling Intel ME 11 via undocumented mode
by Zoran Stojsavljevic 08 Dec '17

08 Dec '17

Disabling Intel ME 11 via undocumented mode http://blog.ptsecurity.com/2017/08/disabling-intel-me.html I just managed (few hours ago) to read this article (way after replying to previous thread about Dell HAP, I read only few intro paragraphs)... It is, after all, amazing how far these two people, *Mark Ermolov and Maxim Goryachy* progressed with ME debugging/cracking and understanding how ME is connected/related to the INTEL platforms' bring up! I just stumbled over it upon searching about ME, and I know what they did achieve previously. They achieved some steps forward... :-) I did not see that this article was published before on Coreboot (excuse me for my ignorance if I missed it), but it is worth reading, every word of it, especially the second part! What is described on the second part is way (much) more than I was willing to lament on (since in the lieu of the Legal issues). Especially on BringUP stages. Excellent read! Something is definitely changing in the Open Source World... And I say, I am very happy to read such articles! Man, there are very serious people out there trying to demystify secrets. I will read again this article later, very concentrated... Trying to put some more comprehensive picture in my mind. Thank you, all of you, Black Hat, Positive Technology, and others! Molodci, rebjata! Zoran

1 0

Re: [coreboot] ASUS P2-99 with P2B config
by Branden Waldner 07 Dec '17

07 Dec '17

While testing the 22687 change set, I ended up having the board fail to boot after rebooting. After getting the logs organized I figured I check it out with a clean rom and sure enough, after rebooting from the grub prompt six times with ctl+alt+del, it ended up failing to boot. It looks to always be failing around the same point very early on. Just in case, I tried again with the bios chip fully inserted and it ended up failing on the first reboot.

1 0

Re: [coreboot] Support for a 2004 HP Workstation
by Taiidan＠gmx.com 07 Dec '17

07 Dec '17

On 12/06/2017 10:15 AM, Giancarlo A Jones wrote: > Hi corebooters > > Just joined the list. Hi :D welcome sir or madame! > I have a Pentium 4 HP workstation (xw6200) with which the urge to tinker is strong. https://support.hp.com/us-en/document/c00215315. There is no webpage for the motherboard but there is a service manual. http://jp.ext.hp.com/lib/doc/manual/workstation/hp_workstation/c00213035.pdf Honestly I don't think it is worth it. You can buy a new-enough-to-be-useful motherboard for the Opteron C32 or G34 sockets for around $30 used and there is a large amount of AMD provided documentation for Fam15h (they used to be very kind to us :3) It is a decent effort to port a board even when the silicon init code already exists for its socket class (ex: KCMA-D8/KGPE-D16) so if I was you I would do it for something that can be useful and fun thus more rewarding IMO (you can play new games with a 6328 or 4386 CPU) and be a service to the community (for those less committed the usual $300+ for a D8/D16 turns them off, I myself only got mine as I needed a new gaming PC) > I want to swap out the vendor bios for SeaBIOS purely out of the need to tinker. SeaBIOS is a payload for coreboot or qemu - it doesn't do silicon init on its own. I for one like to use grub2 as a coreboot payload to skip the middle-man.

1 0

← Newer
1
...
11
12
13
14
15
16
17
18
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 December 2017