coreboot August 2014

coreboot@coreboot.org

43 participants
102 discussions

Re: [coreboot] AMD PSP
by ron minnich 25 Aug '14

25 Aug '14

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

1 0

Re: [coreboot] AMD PSP
by Patrick Georgi 25 Aug '14

25 Aug '14

Am 25.08.2014 um 19:44 schrieb ron minnich: > Is it as closed off and mysterious? Its firmware is signed. So yes, closed off. My hope is that it is (and stays) like early ME: no firmware, no harm, since it deactivates itself silently. But since AMD prefers to parrot Intel's worst ideas these days... Patrick

2 1

AMD PSP
by ron minnich 25 Aug '14

25 Aug '14

I'm utterly ignorant of the PSP -- is this thing like the Intel ME, and how scared should we be of it? Is it as closed off and mysterious? ron

1 0

Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
by David Hubbard 25 Aug '14

25 Aug '14

Hi Charles, 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. Looking at the decompiled vendor DSDT did not really reveal much in this area, except that it is likely coreboot already has a "clean room" re-implementation of the vendor DSDT since they both use a method called "LED ()" David

1 0

bug report: i945 text-mode native graphics initialization: graphical corruption with starting Debian/Trisquel net installer.
by The Gluglug 25 Aug '14

25 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Using 6725 to enable text-mode gfx init on X60 when using native graphics initialization. This relies on the (merged) patch 6723 that enables text-mode graphics initialization on i945 platforms. The code is there. I then disabled "Keep VESA framebuffer" in menuconfig, to enable text-mode. error: no video mode activated This is what I see when I try to use the net install iso for Debian with the isolinux parser in grub. I also saw the same thing when trying to start Trisquel 6 isolinux menu from SeaBIOS (with SeaVGABIOS added at vgaroms/vgabios.bin from seabios's rom that I built). See attached image of what happens when I try to boot the net install from Debian (same thing happens with the Trisquel net install), using the following: linux (usb0)/install.386/vmlinuz initrd (usb0)/install.386/initrd.gz boot As you can see, there is quite a lot of flicker and parts of the screen are missing or corrupt. I think this is related to the issue above ("error: no video mode activated"). The net install for Debian and Trisquel both work when using corebootfb initialization method, but they fail (as seen in the image) for text-mode method. In case the attachment was scrubbed by the mailing list, I also put it here: http://dev.libreboot.org/x60txtmode.jpg Trisquel graphical install works (I wasn't able to figure out how to boot the Debian graphical install). I also enabled it for T60 (adding the keep/drop vesa fb option for t60/Kconfig, based on 6725, and cherry picking 5345) and the same behaviour was observed there. What does work in text-mode init (tested): memtest86+ and grub invaders. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT+1sXAAoJEP9Ft0z50c+UhtwH/jegmqnaQPzGn58veEWMN9Ik 3TNG0QpTlyVvuikY3ARsIz4FQuwN26wdTsGTg3s9pbDLbGjUkxYTWKSGvxhwDm9D 9IRu2cYiE5RMFxQx0V6074ytIJtqCc6JGuzeihHJhP9rgRXfWedSuGnIeCwcoMUB GffxXClF9SSLEgtVugPiYUVVM/E2HuFH+b0nG3aZ8mnAFMe/sqaWJkPC5+AHnuFO aRavxBUk8b+Q5AK3sGhvVBAso8YSAJY52PMtxr5ucTzGtoARi1ffa47ZQJf6pS2H tii6dYuQ1Xbr84snOKAiQYfyRJygbY9EEcH3OlupN4IaLA+tz5cnidcC3q1n6f8= =G4tP -----END PGP SIGNATURE-----

1 0

Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
by Charles Devereaux 25 Aug '14

25 Aug '14

Hello, On Mon, Aug 25, 2014 at 5:54 AM, David Hubbard < david.c.hubbard+coreboot(a)gmail.com> wrote: > > Is there a version of acpi_3.rom or the decompiled dsl version I could > look at? Others might also be interested to take a look. > Sure. Sent. > If there are copyright issues preventing the distribution of acpi_3.rom, > what steps would be required to extract it from the firmware available on > lenovo.com? > I do not know about copyright issues. If you saved your factory bios, run bios_extract on it from http://www.coreboot.org/Bios_extract, then use the iasl tools : iasl -d (to decompile)

1 0

Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
by The Gluglug 25 Aug '14

25 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Ideally, the DSDT should be fixed within coreboot, but this goes > beyond my present abilities. Alternatively, I plan to release a > patched x60t DSDT for use with libreboot. > Please submit it to upstream (coreboot). The same applies for any other patch. Libreboot is a distribution and not a fork of coreboot. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT+zGIAAoJEP9Ft0z50c+US2cH/2WZuCYg2NN210Q5x7JFQ2RP UvQ/OCmnY3KeVyt2Rxwa81xVf0qHH9VkfyxZhmYMVRN3OUCjlryBMYAcKcC5jV88 ohTHNTXj10Zej0RB5iQ+wkDHKKviAHKFpJXve5ns2CVVI5n6UFq1KQmPEvJVwU5z bcJjHByaRW7Ej/pg4rGvMkvcNTiBPsliasOmuKzRtKtYRIdpcG21geCamJLGkf2L eLHx/tn8/hqSJwJMt4K6RsHoBhr302eLRfVPFXyRaIdlBf6OD4DqnK0OppUhT/Hu 4Jkr7F7BuB0YRTOAB5PwXUzqaZUdLp+L1HktuyquQCn8zf8CVF4G5tLMKO0gUUU= =a/XJ -----END PGP SIGNATURE-----

1 0

Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
by David Hubbard 25 Aug '14

25 Aug '14

On Sun, Aug 24, 2014 at 8:39 PM, Charles Devereaux <coreboot(a)guylhem.net> wrote: > > Hello > > Previously ( http://www.coreboot.org/pipermail/coreboot/2014-July/078320.html) I mentioned that 3 bugs seemed to be related to the DSDT: > - missing ACPI events when the stylus is inserted/removed > - errors when trying to make the leds blink with tpacpi > - errors during TPM initialization > > The first bug is x60t specific, but the other 2 should also affect the other x60 models. > > At the moment, I'm trying various kernel to see how boot time can be improved, and took 5 minutes to test with a custom DSDT table created from acpi_3.rom (extracted with bios_extract, then decompiled into a dsl, then recompiled into a hex file (see for ex https://wiki.archlinux.org/index.php/DSDT) > > I do confirm this fixes both the stylus (I now get ACPI events) and the blinking leds issues (they now blink just fine), which confirms these bugs come from missing entries in coreboot DSDT, and can be corrected by fixing it. > > However, since the factory DSDT causes other issues (such as the CPU running quite hot and wake-up issues) I do not recommend using the factory DSDT, even as a temporary solution. > > Ideally, the DSDT should be fixed within coreboot, but this goes beyond my present abilities. Alternatively, I plan to release a patched x60t DSDT for use with libreboot. Is there a version of acpi_3.rom or the decompiled dsl version I could look at? Others might also be interested to take a look. If there are copyright issues preventing the distribution of acpi_3.rom, what steps would be required to extract it from the firmware available on lenovo.com? David

1 0

x60 : trying to boot to a debian in less than 2 seconds
by Charles Devereaux 24 Aug '14

24 Aug '14

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

1 0

IBM x60t test - DSDT is in fact incomplete
by Charles Devereaux 24 Aug '14

24 Aug '14

Hello Previously (http://www.coreboot.org/pipermail/coreboot/2014-July/078320.html) I mentioned that 3 bugs seemed to be related to the DSDT: - missing ACPI events when the stylus is inserted/removed - errors when trying to make the leds blink with tpacpi - errors during TPM initialization The first bug is x60t specific, but the other 2 should also affect the other x60 models. At the moment, I'm trying various kernel to see how boot time can be improved, and took 5 minutes to test with a custom DSDT table created from acpi_3.rom (extracted with bios_extract, then decompiled into a dsl, then recompiled into a hex file (see for ex https://wiki.archlinux.org/index.php/DSDT) I do confirm this fixes both the stylus (I now get ACPI events) and the blinking leds issues (they now blink just fine), which confirms these bugs come from missing entries in coreboot DSDT, and can be corrected by fixing it. However, since the factory DSDT causes other issues (such as the CPU running quite hot and wake-up issues) I do not recommend using the factory DSDT, even as a temporary solution. Ideally, the DSDT should be fixed within coreboot, but this goes beyond my present abilities. Alternatively, I plan to release a patched x60t DSDT for use with libreboot. Charles [PS: I forgot to test the TPM module, but it should also work now]

1 0

← Newer
1
2
3
4
5
6
7
8
...
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