coreboot December 2017

coreboot@coreboot.org

68 participants
177 discussions

Re: [coreboot] coreboot support for Minnowboard Turbot E3845
by Piotr Król 14 Dec '17

14 Dec '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 12/13/2017 07:29 PM, Michael Graichen wrote: > Hey, Hi Michael, > > I've bought a Minnowboard Turbot (quad core / E3845) to start > developing on the Atom's. > > I was hopping that it has support like the Minnowboard Max but it > get stuck right after FspInitApi(&FspInitParams); in > coreboot/src/drivers/intel/fsp1_0/fsp_util.c. The last output i can > see is "POST: 0x92" which comes from > post_code(POST_FSP_MEMORY_INIT); right before > FspInitApi(&FspInitParams); I'm not expert in MinnowBoard Turbot, but I play recently with E3826 and saw similar behavior when incorrect microcode was used (or no microcode). What are your ucode configuration ? Best Regards, - -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAloxsggACgkQsu5x6Weq nkzfPg/+PM8fk80pbmexWQw5IO4LbDOX4vw5LYkrkeTxh/3T6hAAjBt7KJ6OA4Ft vW8d/Ll37/r7zutrOXemXZRtxulHy4FL/7aGcDdu8JPxnO4ysLGM0fOZxkZtuyNA WYI7nS5mYcVdA69driI3rW0cSuGVAy7LiOBIzzV5Z8iWjQXop56cMJiP6In7zayr 7B5XZ6Ix934AzYihK6hZ5Rz5jZyouKb0NJRQLnRB+MljuL4sLa18bnX5NUBqgDxu cbw54UYgkgd6CsrbGw3XIGB63k7jYYOUayZwBaqg4QYIxPs798pX5MTe7VMJneFc kmg+t8HHZxQkaF9YjoVwyS5y4/24FgwQ5bROo/ztNqZMz2q0nK6jd7vQjobFKTVb Hc7w0jQIY37z3ZConHj9hHeVQ4AILFgpUl+NJj04hekcs4aAwJhbMun7YEAmchkp cCsv+WvXmOUZwTZR+CoH1xTYSMIX6JkMDZlmlhR/UGlAdpIkxMKQ6MezJXgyihvn rBBAMDKGvNxeZ00Cf35d+tI9OwDWw/YxYDMV3nx5MzeIkvho4Umg6ey824QlqxBF D+3wYuiB4ZO/uEViYkW62jFOMHxeTZ9lBNdigPsnuclDiXhvAoA1uImsaLHjNHpQ xndtfh+FPE3kB6c4koorgXxa3OZacd+4pGDmyjOy7Vl+TZk5hkA= =r1Ls -----END PGP SIGNATURE-----

2 1

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

14 Dec '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Positive Technologies, on Skylake and higher (like the Purism machines) the kernel loads the BUP, and the HAP bit only disables the normal userspace processes [1]. What proof do you have that the kernel itself is halted? [1] http://blog.ptsecurity.com/2017/08/disabling-intel-me.html On 12/13/2017 11:34 AM, Youness Alaoui wrote: >> I guess I still disagree with the use of the word "disabled". If the ME >> wasn't required for boot, and was actually disabled within a few cycles >> of its CPU starting, the remaining attack surface simply wouldn't exist. >> This is not what happens though, and AFAIK even the ME kernel continues >> to run since the ME needs to continue handling platform power events. >> If this many holes are present in even the ROM code, then having the ME >> kernel running remains a massive security problem. >> > > I'm just going to answer the bit about the use of the term "disabled". > I've explained it in my blog post before (here if you missed it : > https://puri.sm/posts/deep-dive-into-intel-me-disablement/) but I do > believe the ME is in this case Disabled. What you are thinking about > is what I called "Removed". The reason it's called disabled is because > the ME stops running, it's not actively doing anything, it doesn't > respond to HECI, it doesn't even boot into the kernel. You said that > "the ME kernel continues to run", but that's not the case. The entire > ME core stops execution during the bring-up phase, so it's technically > disabled because it stops itself at some point after boot. > Having the ME *removed* would be interesting because that would mean > that even the bring up phase wouldn't get executed and we could remove > the entire ME firmware from the flash. But that still wouldn't mean > that nothing runs on the ME core because there is still some small > code embeded in the ROM. > Anyways, that's my justification on why using the term "disabled" is > valid in this case when HAP is enabled. You are free to disagree if > that didn't convince you. - -- 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 iQEcBAEBAgAGBQJaMWk6AAoJEK+E3vEXDOFbTnkH/30CN22Q0JG0bxxvG7NaRjUX i4bsAVpdP+rbd9IlmMHDCPtYnmdoBWq81yXZx8iBAzTx5DJrU0lA0Kqr0RzIyNRx pE4omRU2St342bQS5bf/UsFwT2WKR2vlE8u8NR4YiOXnJNySJ1gSQqzxB4uGwd7I rcyMnScr4IKEgwiE3GA7HU4vHE2w66M6g0skhYQtquAm3ypajmwLUbFwsgiAp0l1 Azbt9pUFlp7McZTJusuRroWsDv1oOWQit3nH54i0yP6EajGWbZJ4+sAEQJSXVr9Q 6iuVDE8WfZsydARlvfM+hc0TyrGIv08EnLkhNOQjA4bfab6TxK1l2EnNE1STwXc= =7rNS -----END PGP SIGNATURE-----

3 2

Re: [coreboot] Disabling Intel ME 11 via undocumented mode
by R S 14 Dec '17

14 Dec '17

Thanks for elaborating and shedding light on this for some of us non-experts who are just lurking around. On Thu, Dec 14, 2017 at 2:20 AM, Youness Alaoui < kakaroto(a)kakaroto.homelinux.net> wrote: > Hi, > > From the PT article you linked to, after the stage 5 of BUP execution : > "It is at this stage that we find HAP processing; in this mode, BUP > hangs instead of executing InitScript. This means that the remaining > sequence of actions in normal mode has nothing to do with HAP and will > not be considered. The main thing we would like to note is that in HAP > mode, BUP initializes the entire platform (ICC, Boot Guard) but does > not start the main ME processes." > > As for the kernel, that's my mistake, I remembered that prior to ME > 11.x, the KERNEL module was removed by me_cleaner, and BUP was the > first process loaded. I hadn't realized that the execution order > changed in ME 11.x, and that explains why the KERNEL module cannot be > removed by me_cleaner in ME 11.x. > On ME 10.x and lower, the BUP module was the first executed, and it > would then load the KERNEL, so if BUP is halted before it did that, > then the kernel doesn't run. In ME 11.x however, they changed the > order, the KERNEL module is first to be loaded, but it only starts the > BUP process : > "The first process that the kernel creates is BUP, which runs in its > own address space in ring-3. The kernel does not launch any other > processes itself; this is done by BUP itself" > So, you are right, on Skylake+ (ME 11.x), the kernel would be running > but the BUP process is the one halted and no other processes get > launched, but on ME 10.x and lower, the kernel wouldn't be running > since BUP is loaded first (this is true for me_cleaned ME 10.x, and > I'm not sure what exactly the MeAltDisable flag does, which is the > equivalent of HAP on previous versions, but there wasn't any specific > research done on that). > > I hadn't realized that until now when researching an error-free > response to you, so thanks for helping me notice that mistake in my > understanding. > > Youness. > > > > On Wed, Dec 13, 2017 at 12:54 PM, Timothy Pearson > <tpearson(a)raptorengineering.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > According to Positive Technologies, on Skylake and higher (like the > > Purism machines) the kernel loads the BUP, and the HAP bit only disables > > the normal userspace processes [1]. > > > > What proof do you have that the kernel itself is halted? > > > > [1] http://blog.ptsecurity.com/2017/08/disabling-intel-me.html > > > > On 12/13/2017 11:34 AM, Youness Alaoui wrote: > >>> I guess I still disagree with the use of the word "disabled". If the > ME > >>> wasn't required for boot, and was actually disabled within a few cycles > >>> of its CPU starting, the remaining attack surface simply wouldn't > exist. > >>> This is not what happens though, and AFAIK even the ME kernel > continues > >>> to run since the ME needs to continue handling platform power events. > >>> If this many holes are present in even the ROM code, then having the ME > >>> kernel running remains a massive security problem. > >>> > >> > >> I'm just going to answer the bit about the use of the term "disabled". > >> I've explained it in my blog post before (here if you missed it : > >> https://puri.sm/posts/deep-dive-into-intel-me-disablement/) but I do > >> believe the ME is in this case Disabled. What you are thinking about > >> is what I called "Removed". The reason it's called disabled is because > >> the ME stops running, it's not actively doing anything, it doesn't > >> respond to HECI, it doesn't even boot into the kernel. You said that > >> "the ME kernel continues to run", but that's not the case. The entire > >> ME core stops execution during the bring-up phase, so it's technically > >> disabled because it stops itself at some point after boot. > >> Having the ME *removed* would be interesting because that would mean > >> that even the bring up phase wouldn't get executed and we could remove > >> the entire ME firmware from the flash. But that still wouldn't mean > >> that nothing runs on the ME core because there is still some small > >> code embeded in the ROM. > >> Anyways, that's my justification on why using the term "disabled" is > >> valid in this case when HAP is enabled. You are free to disagree if > >> that didn't convince you. > > > > > > - -- > > 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 > > > > iQEcBAEBAgAGBQJaMWk6AAoJEK+E3vEXDOFbTnkH/30CN22Q0JG0bxxvG7NaRjUX > > i4bsAVpdP+rbd9IlmMHDCPtYnmdoBWq81yXZx8iBAzTx5DJrU0lA0Kqr0RzIyNRx > > pE4omRU2St342bQS5bf/UsFwT2WKR2vlE8u8NR4YiOXnJNySJ1gSQqzxB4uGwd7I > > rcyMnScr4IKEgwiE3GA7HU4vHE2w66M6g0skhYQtquAm3ypajmwLUbFwsgiAp0l1 > > Azbt9pUFlp7McZTJusuRroWsDv1oOWQit3nH54i0yP6EajGWbZJ4+sAEQJSXVr9Q > > 6iuVDE8WfZsydARlvfM+hc0TyrGIv08EnLkhNOQjA4bfab6TxK1l2EnNE1STwXc= > > =7rNS > > -----END PGP SIGNATURE----- > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- Tech III * AppControl * Endpoint Protection * Server Maintenance Buncombe County Schools Technology Department Network Group ComicSans Awareness Campaign <http://comicsanscriminal.com>

1 0

coreboot support for Minnowboard Turbot E3845
by Michael Graichen 13 Dec '17

13 Dec '17

Hey, I've bought a Minnowboard Turbot (quad core / E3845) to start developing on the Atom's. I was hopping that it has support like the Minnowboard Max but it get stuck right after FspInitApi(&FspInitParams); in coreboot/src/drivers/intel/fsp1_0/fsp_util.c. The last output i can see is "POST: 0x92" which comes from post_code(POST_FSP_MEMORY_INIT); right before FspInitApi(&FspInitParams); From FSP it should return to src/soc/intel/fsp_baytrail/fsp/chipset_fsputil.c ChipsetFspReturnPoint but i never gets here. So far I've tried Minnowboard Max config and bayleybay_fsp both with the same result. I'm using Minnowboards original Firmware and overright the las 3MB with coreboot. As FSP I use the branch BayTrail from https://github.com/IntelFsp/FSP Am I missing something to make it boot? Is anyone booting coreboot on the Turbot? Best Regards, Micha

1 0

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

13 Dec '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/08/2017 08:40 AM, Alberto Bursi wrote: > > > On 12/08/2017 02:59 PM, Timothy Pearson wrote: >> >> 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. >> >> > > Hacking them requires being able to write in the SPI flash, or to have > buggy UEFI firmware. Which means most systems are still vulnerable. > > But it is also true that if someone can hack UEFI he pwns you anyway, > even without ME. > > So imho ME with the HAP bit can be called "disabled", although the fight > isn't over as ME isn't the only thing that was a threat anyway. I guess I still disagree with the use of the word "disabled". If the ME wasn't required for boot, and was actually disabled within a few cycles of its CPU starting, the remaining attack surface simply wouldn't exist. This is not what happens though, and AFAIK even the ME kernel continues to run since the ME needs to continue handling platform power events. If this many holes are present in even the ROM code, then having the ME kernel running remains a massive security problem. Pretty much every computing platform, with the exception of some of the ARM SBCs with key fuses or Talos with FlexVer, are vulnerable to attack via Flash reprogramming, so I agree that this in and of itself should not be a disqualifier for many use cases. I simply take issue with calling the ME "disabled" when the reality is very different. - -- 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 iQEcBAEBAgAGBQJaKqe8AAoJEK+E3vEXDOFblnQH/0tvczmOm+8UfyBLdaZiLta1 d4iUhn1lotThx/tAxdBfpn3FqRPtfbFfNfEIyqjIqiTHVVKMTHVb+Z/5BY66eNvy d5D3BbK4wu4A6SHho5/oxNw6RGSy9YqAhJwtSdmBNMyVnU6KVcRzyrPzb+fgWQac vEYIik4Z+cZAmQqk37dBgPQGJT706DL55NJyiKjii9+MSYxPTlF0yogUYB93SNAw x5V0rZoGkx9GTHCKL+MSIB9INBROQ/fc2C8TLQS/lSA4vZD7pHHVynsL3wTcqppB rM3GMIC7xu88qpsR0ZwJ4YqaejwDmqgVYPCA0pv9be0mR2OZ878k53fLKKaOigc= =yNRx -----END PGP SIGNATURE-----

2 1

Can't disable CONFIG_ENABLE_FSP_FAST_BOOT flag on Intel Baytrail platform
by GARRETT DOORENBOS 13 Dec '17

13 Dec '17

Hello, I'm running coreboot on an Intel Atom Bay Trail based platform. When I turn off the CONFIG_ENABLE_FSP_FAST_BOOT flag, I get stuck in the Intel FSP (it never returns) after a warm boot. The only way around it is a power cycle. Has anyone seen this before? Thanks, Garrett Doorenbos Software Engineer - Almost Hardware Office: 256.963.6369 Email: garrett.doorenbos(a)adtran.com<mailto:garrett.doorenbos@adtran.com> Web: www.adtran.com<http://s.bl-1.com/h/CoY1mz9?url=http://www.adtran.com> ADTRAN 901 Explorer Boulevard Huntsville, AL 35806 - USA [ADTRAN]<http://s.bl-1.com/h/CoY1mz9?url=http://www.adtran.com>

3 3

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 13 Dec '17

13 Dec '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 4 new defect(s) introduced to coreboot found with Coverity Scan. 19 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 1383613: Integer handling issues (BAD_SHIFT) /src/mainboard/google/poppy/variants/nami/memory.c: 38 in variant_memory_params() ________________________________________________________________________________________________________ *** CID 1383613: Integer handling issues (BAD_SHIFT) /src/mainboard/google/poppy/variants/nami/memory.c: 38 in variant_memory_params() 32 void variant_memory_params(struct memory_params *p) 33 { 34 memset(p, 0, sizeof(*p)); 35 p->type = MEMORY_DDR4; 36 37 /* Rcomp resistor values are different for SDP and DDP. */ >>> CID 1383613: Integer handling issues (BAD_SHIFT) >>> In expression "1 << variant_memory_sku() - 1", shifting by a negative amount has undefined behavior. The shift amount, "variant_memory_sku() - 1", is -1. 38 if (ddp_bitmap & MEM_ID(variant_memory_sku())) { 39 p->rcomp_resistor = rcomp_resistor_ddp; 40 p->rcomp_resistor_size = sizeof(rcomp_resistor_ddp); 41 } else { 42 p->rcomp_resistor = rcomp_resistor_sdp; 43 p->rcomp_resistor_size = sizeof(rcomp_resistor_sdp); ** CID 1383612: Incorrect expression (UNUSED_VALUE) /src/soc/amd/stoneyridge/bootblock/bootblock.c: 94 in load_smu_fw1() ________________________________________________________________________________________________________ *** CID 1383612: Incorrect expression (UNUSED_VALUE) /src/soc/amd/stoneyridge/bootblock/bootblock.c: 94 in load_smu_fw1() 88 */ 89 static void load_smu_fw1(void) 90 { 91 u32 base, limit; 92 93 /* Open a posted hole from 0x80000000 : 0xfed00000-1 */ >>> CID 1383612: Incorrect expression (UNUSED_VALUE) >>> Assigning value "2147483648U" to "base" here, but that stored value is overwritten before it can be used. 94 base = 0x80000000; 95 base = (0x80000000 >> 8) | MMIO_WE | MMIO_RE; 96 limit = (ALIGN_DOWN(HPET_BASE_ADDRESS - 1, 64 * KiB) >> 8); 97 pci_write_config32(SOC_ADDR_DEV, D18F1_MMIO_LIMIT0_LO, limit); 98 pci_write_config32(SOC_ADDR_DEV, D18F1_MMIO_BASE0_LO, base); 99 ** CID 1383611: Incorrect expression (MIXED_ENUMS) /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 710 in vb2_developer_menu() ________________________________________________________________________________________________________ *** CID 1383611: Incorrect expression (MIXED_ENUMS) /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 710 in vb2_developer_menu() 704 disable_dev_boot = 1; 705 VB2_DEBUG("dev_disable_boot is set.\n"); 706 707 /* If dev mode is disabled, only allow TONORM */ 708 current_menu = VB_MENU_TO_NORM; 709 prev_menu = VB_MENU_TO_NORM; >>> CID 1383611: Incorrect expression (MIXED_ENUMS) >>> Mixing enum types "enum _VB_DEV_WARNING_MENU" and "enum _VB_TO_NORM_MENU" for "current_menu_idx". 710 current_menu_idx = VB_TO_NORM_CONFIRM; 711 } 712 } 713 714 vb2_set_disabled_idx_mask(shared->flags); 715 /* Show the dev mode warning screen */ ** CID 1383610: Null pointer dereferences (REVERSE_INULL) /3rdparty/vboot/firmware/lib/vboot_audio.c: 272 in VbAudioLooping() ________________________________________________________________________________________________________ *** CID 1383610: Null pointer dereferences (REVERSE_INULL) /3rdparty/vboot/firmware/lib/vboot_audio.c: 272 in VbAudioLooping() 266 uint64_t now; 267 uint16_t freq = audio->current_frequency; 268 uint16_t msec = 0; 269 int looping = 1; 270 271 /* if no audio context, never timeout */ >>> CID 1383610: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "audio" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 272 if (!audio) 273 return 1; 274 275 now = VbExGetTimer(); 276 while (audio->next_note < audio->note_count && 277 now >= audio->play_until) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Is Goryachy's JTAG hack a chance for free firmware ?
by Enrico Weigelt, metux IT consult 12 Dec '17

12 Dec '17

Hi folks, i'm curios whether Goryachy's JTAG hack is a chance for getting rid of all proprietary ME/UEFI firmware. If i'm correct, the ME firmware (or parts of it) is signed, and the CPU won't run (or switches off) if signatures don't match. Can the JTAG channel be used to get around that ? thx. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info(a)metux.net -- +49-151-27565287

5 6

Hardware vendors offering systems with Intel ME disabled
by echelon＠free.fr 12 Dec '17

12 Dec '17

Hello, First I apologize in advance for introducing some "off topic" noise in the coreboot mailing list, but I would like to point to you a story which was posted on slashdot 4 days ago : https://hardware.slashdot.org/story/17/12/03/2113220/dell-begins-offering-l… . So I have some questions to the coreboot community regarding this story (if you have the time and if you bother to read it..) : - I know that the aim of the coreboot project is to produce a fully open-source firmware alternative (and I fully subscript to this noble aim!..), but if we put ourselves in the place of a (corporate?) end-user, who NEEDS the security of a system with "features" like ME or PSP DISABLED, isn't "buying" the option "ME disabled" straight from the vendor a viable solution?.. Or in other words (I hope that I will avoid getting sued for this.. ;-)) : do you think that "buying" this advertised "option" is as reliable as say .. using open source tools like me_cleaner (DIY approach)?.. - And a more "politically sensitive" question (you can simply ignore it if it is too dangerous to answer..): do you think that Intel is somewhat .. "collaborative" (or at least indifferent..) to this new initiative of Dell or System76?.. Thanks in advance for your answers, Florentin Demetrescu

5 5

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

11 Dec '17

Thanks! But my main purpose right now is to make standard OS-battery interface through ACPI embedded controller. And as I understand embedded controller in 'twinkie' isn't the one suitable for this case, as 'twinkie' is separate board that implements USB-PD sniffing dongle with Type-C connectors . Best Regards, Aladyshev Konstantin -----Original Message----- From: shawnn(a)google.com [mailto:shawnn@google.com] On Behalf Of Shawn N Sent: Friday, December 08, 2017 8:14 PM To: Аладышев Константин Cc: Vadim Bendebury; Randall Spangler; Coreboot Subject: Re: [coreboot] Embedded Controller (EC) 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

← Newer
1
...
10
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