coreboot August 2014

coreboot@coreboot.org

43 participants
102 discussions

Re: [coreboot] AMD PSP
by Bruce Griffith 26 Aug '14

26 Aug '14

Here's what I know about PSP: > I'm utterly ignorant of the PSP -- is this thing like the Intel ME, and how scared should we be of it? Somewhat scared. The PSP is an actual processor that takes control when reset is released. The x86 does not start fetching code until the PSP is satisfied that BIOS meets whatever constraints have been programmed into the PSP firmware. There are TPM-like characteristics but I don't know any specifics. The PSP is capable of "locking" additional processor features that could be exploited to take over a system. > My hope is that it ... deactivates itself silently. For the coreboot implementation, it runs, decides that the x86 code is not its concern, and the x86 starts fetching code. From that point on, I think the PSP is transparent to the x86. > After glancing thru [the PSP presentation], it looks more like they are > grafting the security model of ARM-based SoCs onto x86 where a masked > ROM loads the next stage. A masked processor and associated firmware (the PSP) validate the first "stage" of x86 code. What comprises the first stage is arbitrary and gets signed with an AMD private key. Your first stage could be bootblock, bootblock plus romstage, something more involved, or something less involved. You need a legal arrangement with AMD to get your first stage signed. For coreboot, none of the x86 code is signed. > So we can kiss goodbye coreboot on AMD platforms in the future?.. How sad! :-/ That isn't true for the first processor with PSP. Coreboot support for "Steppe Eagle" is already posted to Gerrit. Steppe Eagle is the AMD Embedded variant of Mullins. The Olive Hill+ platform demonstrates building a coreboot ROM without requiring that AMD sign any part of the coreboot code. I expect to have the final version of support posted by the end of the week. Give me some +2's and we could have PSP support available next week! ;-) > Does this thing ... exist in any AMD CPUs buyable today? The processors are released as AMD Beema (A6-6310, A4-6210, E2-6110,E1-6010), AMD Mullins (A10 micro-6700T, A4 micro-6400T, E1 Micro-6200T), and AMD Steppe Eagle processors. AMD has developed reference boards similar to what was developed for AMD Kabini SoCs. I have not seen any retail "bare-bones" motherboards, but maybe there are low-end notebooks and desktops that use Mullins/Beema (perhaps Acer Aspire AXC-115-UR20)?

2 1

Rangeley reset
by Wen Wang 26 Aug '14

26 Aug '14

Hello, Has anybody tested reset signal (PMU_RESETBUTTON_B) on Rangeley/Avoton? The board seems to shut down after asserting the signal (pushing the reset button). I turn on an LED in early_mainboard_romstage_entry(). The LED was not on indicating the function was not executed. Below is what printed out on console after reset: coreboot-0f49404 Tue Aug 26 15:28:40 EDT 2014 starting... POST: 0x41 POST: 0x42 Setting up static southbridge registers... done. Disabling Watchdog timer... done. RTC Init POST: 0x46 POST: 0x47 Starting the Intel FSP (early_init) Configure Default UPD Data PcdEnableIQAT 1 PcdEnableLan 1 PcdEnableLan 1 PcdEnableLan 1 PcdEnableLan 1 PcdEnableUsb20 1 PcdEnableSata2 1 PcdEnableSata3 1 find_current_mrc_cache_local: No valid fast boot cache found. FSP MRC cache not present. For cold boot, it will continue to spit out boot messages. Thanks! -- Wen Wang

1 0

Re: [coreboot] IBM/Lenovo X60t: LED_: Excess arguments - needs 1, found 2
by Vladimir 'φ-coder/phcoder' Serbinenko 26 Aug '14

26 Aug '14

On 26.08.2014 17:53, Charles Devereaux wrote: > My understanding is that the OS does the call that correctly, but that > coreboot ASL tables only expect one argument. Please provide a refrence when doing such bold claims. LED method is not specified in ACPI, so assuming that it takes any particular arguments is wrong from OS side.

1 0

Re: [coreboot] IBM/Lenovo X60t: LED_: Excess arguments - needs 1, found 2 (was: IBM x60t test - DSDT is in fact incomplete)
by Paul Menzel 26 Aug '14

26 Aug '14

Dear Charles, dear David, Am Montag, den 25.08.2014, 11:21 -0600 schrieb David Hubbard: > I'm focusing in on this error message first: > > ACPI Warning: For \_SB_.PCI0.LPCB.EC__.LED_: Excess arguments - needs 1, > found 2 > > Can you take a look at the .asl files in your coreboot build? I believe you > will find something like "Method (LED, 2, NotSerialized)" which means the > LED method wants 2 arguments. Then look for calls to "LED ()" and if you > find one only passing 1 argument, that is the problem. I also noticed that message and quickly looked through the coreboot ASL files, but could not find anything calling that message. Looking at the Linux kernel sources I was also unable to find a call site. But I’d say the OS call this method incorrectly. […] Thanks, Paul

3 2

Re : Re: AMD PSP
by echelon＠free.fr 26 Aug '14

26 Aug '14

<TROLL> So we can kiss goodbye coreboot on AMD platforms in the future?.. How sad! :-/ </TROLL> Does this thing "Platform Security Processor" exist in any AMD CPUs buyable today (Q3 2014) or it will begin to be implemented later? Thank you for this information! Florentin ----- Mail d'origine ----- De: ron minnich <rminnich(a)gmail.com> À: David Hendricks <dhendrix(a)google.com> Cc: Coreboot <coreboot(a)coreboot.org> Envoyé: Mon, 25 Aug 2014 22:33:25 +0200 (CEST) Objet: Re: [coreboot] AMD PSP On Mon, Aug 25, 2014 at 1:24 PM, David Hendricks <dhendrix(a)google.com> wrote: > After glancing thru this PSP (Platitude Spewing Presentation), it looks more > like they are grafting the security model of ARM-based SoCs onto x86 where a > masked ROM loads the next stage. > > A couple kind of nice things they mention: > - "Isolated on-chip ROM and SRAM" - So this may be somewhat more constrained > than the multi-megabyte blobs for MEs? > - "Secure Boot does not require the system ROM image to be signed" > > Not so nice: "Access to system memory / resources". Ugh. well, we all know how well that's worked fro the ME. so, another insecure x86 platform. Great. ron -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] x60 : trying to boot to a debian in less than 2 seconds
by Paul Menzel 25 Aug '14

25 Aug '14

Am Montag, den 25.08.2014, 15:24 -0700 schrieb ron minnich: > On Mon, Aug 25, 2014 at 3:21 PM, Paul Menzel wrote: > > > Another approach would be to do it like the Chromium OS folks do it on > > the Google Chromebooks. In normal mode they do not initalize the graphic > > device (just place the Video BIOS/VGA Option ROM for VBT information), > > so you cannot see GRUB, and let just Linux initialize the graphics. Then > > they have a developer mode and only in this mode coreboot does graphics > > initialization. > > That's actually slower than having coreboot do native graphics init. > That's why we did the coreboot graphics work in the first place. Sorry for getting that wrong and thank you for the clarification. Could you please elaborate about the difference between normal and developer mode regarding graphics setup? Thanks, Paul

1 0

Re: [coreboot] x60 : trying to boot to a debian in less than 2 seconds
by Paul Menzel 25 Aug '14

25 Aug '14

Dear Charles, Am Sonntag, den 24.08.2014, 23:25 -0400 schrieb Charles Devereaux: > I'm still trying to improve boot time. nice. Thank you for keeping us in the loop. > After some further optimizations (previous results : 2.2s for the kernel, > 0.6s for the daemons), 1. So what are your coreboot numbers? (Also what `.config` and what payload (with `.config`) do you use?) 2. What hardware do you use? Especially what SSD? 3. Do you use the default Linux kernel shipped with Debian? 4. Which Debian release do you use? 5. Which init system do you use? > I believe it should be possible to get a command line in less than 2 > seconds, since most of the time is spend re-initializing the video > chip (almost a full second) while there are some features to prevent > just that. That sounds indeed possible. How do you measure the timings? > It seems that coreboot is spending some time initializing the video chip > for grub, then linux spends some time again - even when grub option "set > gfxpayload=keep" is set (which should prevent that) and when coreboot is > compiled with CONFIG_FRAMEBUFFER_KEEP_VESA_MODE > > in kernel 3.10.45 : > [ 0.291014] [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3 > [ 0.321926] [drm] initialized overlay support > [ 0.384013] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2 > [ 0.570068] fbcon: inteldrmfb (fb0) is primary device > [ 1.230010] Console: switching to colour frame buffer device 128x48 > [ 1.258981] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device > [ 1.258984] i915 0000:00:02.0: registered panic notifier > [ 1.258992] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 > > I'm currently trying a recent kernel since some i915 patches have been > backported (cf http://blog.ffwll.ch/2014/04/neat-drmi915-stuff-for-315.html), > introducing the i915.fastboot option to do just that, but it does not help. > > I must be doing something terribly wrong, but I just don't realize what > exactly. > > Has anyone succeeded in keeping the vesa mode? Sorry, I have not played with this. But I think the way to go is to contact the Linux Intel graphics folks. Best is to submit a bug report. Let’s hope to get that fixed for Debian Jessie, which is going to be frozen in November [1]. Another approach would be to do it like the Chromium OS folks do it on the Google Chromebooks. In normal mode they do not initalize the graphic device (just place the Video BIOS/VGA Option ROM for VBT information), so you cannot see GRUB, and let just Linux initialize the graphics. Then they have a developer mode and only in this mode coreboot does graphics initialization. As these are smart people and they probably did a lot of testing, that might be the only viable solution if you want to have quick boot times. Though I have no idea why they did not go the `gfxpayload=keep` route. Thanks, Paul [1] https://release.debian.org/jessie/freeze_policy.html

3 2

Re: [coreboot] x60 : trying to boot to a debian in less than 2 seconds
by The Gluglug 25 Aug '14

25 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/08/14 04:25, Charles Devereaux wrote: > Hello > > I'm still trying to improve boot time. > > After some further optimizations (previous results : 2.2s for the > kernel, 0.6s for the daemons), I believe it should be possible to > get a command line in less than 2 seconds, since most of the time > is spend re-initializing the video chip (almost a full second) > while there are some features to prevent just that. > > It seems that coreboot is spending some time initializing the video > chip for grub, then linux spends some time again - even when grub > option "set gfxpayload=keep" is set (which should prevent that) and > when coreboot is compiled with CONFIG_FRAMEBUFFER_KEEP_VESA_MODE > > in kernel 3.10.45 : [ 0.291014] [drm] GMBUS [i915 gmbus panel] > timed out, falling back to bit ban ging on pin 3 [ 0.321926] > [drm] initialized overlay support [ 0.384013] [drm] GMBUS [i915 > gmbus vga] timed out, falling back to bit bangi ng on pin 2 [ > 0.570068] fbcon: inteldrmfb (fb0) is primary device [ 1.230010] > Console: switching to colour frame buffer device 128x48 [ > 1.258981] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ > 1.258984] i915 0000:00:02.0: registered panic notifier [ > 1.258992] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 > on minor 0 > > I'm currently trying a recent kernel since some i915 patches have > been backported (cf > http://blog.ffwll.ch/2014/04/neat-drmi915-stuff-for-315.html), > introducing the i915.fastboot option to do just that, but it does > not help. > > I must be doing something terribly wrong, but I just don't realize > what exactly. > > Has anyone succeeded in keeping the vesa mode? > > Charles > > > Do you get those same errors in 3.10.45 when booting factory bios or coreboot+vgarom? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT+7f9AAoJEP9Ft0z50c+UBxoH/0LJoojt+KLktA3lXWO+wPTs 1u2dRykqxzT0vkcCvi53WiEq3tO3rLJE+PudopjfBZk1kbH08VLKKLKkXO+Q4Fp+ VwZiV6F2R+2gKsTlyGXgnm/2qqPdH16nZ+oEV25wJtPkGcLYJaBmwuYzI5fr8NSa cTmCzpmzT+0bl4SPo0PtlwcIFYzCPTCgs8QTd2Ly8tutnmDqV9iib9Wy7K1+igAT e+hiqGz9Npn54gd1drNr+cc7QYZiuMx65V6rAipl8LeuaybkSmQxy+N6qWHS3IlE ioG3/2r3J4Q7KzJiX3M9RD0+NSPoSkN4XkkzEdOtXLFjjoe+3l3F1rneIE1Fuss= =dLQ7 -----END PGP SIGNATURE-----

1 0

Re: [coreboot] disabling bios usb stack
by Vladimir 'φ-coder/phcoder' Serbinenko 25 Aug '14

25 Aug '14

On 25.08.2014 23:28, ron minnich wrote: > A friend asks me how to disable the usb stack in his bios. I have no > clue, anyone? > Doesn't sound like end goal. But I'd go through setup menu to see if something fits his *end* goal (disabling usb stack sounds like means to goal, not the goal itself). > ron >

2 1

disabling bios usb stack
by ron minnich 25 Aug '14

25 Aug '14

A friend asks me how to disable the usb stack in his bios. I have no clue, anyone? ron

1 0

← Newer
1
2
3
4
5
6
7
...
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2014