Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
On 25.08.2014 04:39, Charles Devereaux 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 How is the OS supposed to react to them? - errors when trying to make the leds blink with tpacpi details? usecase? - errors during TPM initialization Some people here would call it a feature. Ideally, the DSDT should be fixed within coreboot, but this goes beyond my present abilities. Not true. Just do the same changes to the corresponding *.asl files in coreboot repo and send the patch to gerrit. Other than a layer of preprocessing, it's exactly the same code as you got from disassembly. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
On Sun, Aug 24, 2014 at 8:39 PM, Charles Devereaux coreb...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
-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- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
Hello On Mon, Aug 25, 2014 at 2:42 AM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: - missing ACPI events when the stylus is inserted/removed How is the OS supposed to react to them? Issue stylus insert and remove messages which can then be mapped to scripts [ 1778.225577] acpid[440]: completed netlink event ibm/hotkey IBM0068:00 0080 500c [ 1778.734936] acpid[440]: received netlink event ibm/hotkey IBM0068:00 0080 500b - errors when trying to make the leds blink with tpacpi details? usecase? echo 0 blink /proc/acpi/ibm/led Currently fails with : [ 104.727409] ACPI Warning: For \_SB_.PCI0.LPCB.EC__.LED_: Excess arguments - needs 1, found 2 (20130328/nspredef-272) Blinking leds are a simple way to do many things (ex: indicate successful system boot on a screenless computer) - errors during TPM initialization Some people here would call it a feature. I do not call non working hardware a feature, especially if linux drivers exist. Letting users be able to use or not use their hardware in anyway they chose is a feature. TPM is just a glorified way to store hashes, but it could have some uses say. Ideally, the DSDT should be fixed within coreboot, but this goes beyond my present abilities. Not true. Just do the same changes to the corresponding *.asl files in coreboot repo and send the patch to gerrit. Other than a layer of preprocessing, it's exactly the same code as you got from disassembly. I did not realize that and thought it interacted with static defines - and so I would have to create a coreboot version-specific DSDT. Thanks. I will see if I can have that work. For the ACPI Warning about SystemIO, I have no idea though. Charles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
Hello, On Mon, Aug 25, 2014 at 5:54 AM, David Hubbard david.c.hubbard+coreb...@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) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] AMD PSP
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD PSP
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 signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD PSP
After glancing thru this PSP http://www.uefi.org/sites/default/files/resources/UEFI_PlugFest_AMD_Security_and_Server_innovation_AMD_March_2013.pdf (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. On Mon, Aug 25, 2014 at 11:37 AM, Patrick Georgi patr...@georgi-clan.de wrote: 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD PSP
On Mon, Aug 25, 2014 at 1:24 PM, David Hendricks dhend...@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@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
Ideally, the DSDT should be fixed within coreboot, but this goes beyond my present abilities. Not true. Just do the same changes to the corresponding *.asl files in coreboot repo and send the patch to gerrit. Other than a layer of preprocessing, it's exactly the same code as you got from disassembly. Sorry, I misread you. I thought that you extracted coreboot DSDT from running system then patched it and used as custom DSDT. I'm going to make few experiments on my x220t. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
On 25.08.2014 22:53, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Ideally, the DSDT should be fixed within coreboot, but this goes beyond my present abilities. Not true. Just do the same changes to the corresponding *.asl files in coreboot repo and send the patch to gerrit. Other than a layer of preprocessing, it's exactly the same code as you got from disassembly. Sorry, I misread you. I thought that you extracted coreboot DSDT from running system then patched it and used as custom DSDT. I'm going to make few experiments on my x220t. This may interest you: On X220t stylus removal: [17424.931729] ACPI : EC: = TASK = [17424.931747] ACPI : EC: --- status = 0x28 [17424.931755] ACPI : EC: --- command = 0x84 [17424.931852] ACPI : EC: = IRQ = [17424.931865] ACPI : EC: --- status = 0x09 [17424.931874] ACPI : EC: --- data = 0x5d [17424.931885] ACPI : EC: --- status = 0x08 So it's _Q5D Stylus reinsert: [17493.249126] ACPI : EC: push gpe query to the queue [17493.249198] ACPI : EC: = TASK = [17493.249207] ACPI : EC: --- status = 0x28 [17493.249213] ACPI : EC: --- command = 0x84 [17493.249293] ACPI : EC: = IRQ = [17493.249306] ACPI : EC: --- status = 0x09 [17493.249316] ACPI : EC: --- data = 0x5c [17493.249329] ACPI : EC: --- status = 0x08 So it's _Q5C Turning LID around: [17582.701907] ACPI : EC: push gpe query to the queue [17582.701979] ACPI : EC: = TASK = [17582.701987] ACPI : EC: --- status = 0x28 [17582.701994] ACPI : EC: --- command = 0x84 [17582.702075] ACPI : EC: = IRQ = [17582.702092] ACPI : EC: --- status = 0x09 [17582.702096] ACPI : EC: --- data = 0x5e [17582.702104] ACPI : EC: --- status = 0x08 So it's _Q5E Back to laptop layout: [17590.610440] ACPI : EC: push gpe query to the queue [17590.610513] ACPI : EC: = TASK = [17590.610521] ACPI : EC: --- status = 0x28 [17590.610527] ACPI : EC: --- command = 0x84 [17590.610610] ACPI : EC: = IRQ = [17590.610620] ACPI : EC: --- status = 0x09 [17590.610628] ACPI : EC: --- data = 0x5f [17590.610641] ACPI : EC: --- status = 0x08 so it's _Q5F Do you get the same events on X60t? From thinkpad-acpi.c: TP_HKEY_EV_TABLET_TABLET= 0x5009, /* tablet swivel up */ TP_HKEY_EV_TABLET_NOTEBOOK = 0x500a, /* tablet swivel down */ TP_HKEY_EV_PEN_INSERTED = 0x500b, /* tablet pen inserted */ TP_HKEY_EV_PEN_REMOVED = 0x500c, /* tablet pen removed */ So those are the values MHKP has to return. http://review.coreboot.org/6765 implements it. Please test. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] disabling bios usb stack
A friend asks me how to disable the usb stack in his bios. I have no clue, anyone? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] disabling bios usb stack
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] x60 : trying to boot to a debian in less than 2 seconds
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 :00:02.0: fb0: inteldrmfb frame buffer device [1.258984] i915 :00:02.0: registered panic notifier [1.258992] [drm] Initialized i915 1.6.0 20080730 for :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 signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] disabling bios usb stack
disabling the usb stack is the goal in this case. ron On Mon, Aug 25, 2014 at 2:32 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] x60 : trying to boot to a debian in less than 2 seconds
-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 :00:02.0: fb0: inteldrmfb frame buffer device [ 1.258984] i915 :00:02.0: registered panic notifier [ 1.258992] [drm] Initialized i915 1.6.0 20080730 for :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- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] x60 : trying to boot to a debian in less than 2 seconds
On Mon, Aug 25, 2014 at 3:21 PM, Paul Menzel paulepan...@users.sourceforge.net 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. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] bug report: i945 text-mode native graphics initialization: graphical corruption with starting Debian/Trisquel net installer.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The same issue does not occur when using coreboot with the vga rom extracted from factory bios. On 25/08/14 16:50, The Gluglug wrote: Using 6725 to enable text-mode gfx init on X60 when using native graphics initialization. Affected machines: X60, T60. It may also affect: macbook21/macbook11, X60 Tablet 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+919AAoJEP9Ft0z50c+UIFcIALLWwrcgoPINTBBOdsAUjVYD 300SAz9NgVdpnxBc0/k+G7maVf0JLccNVCen3kmdWTwkSwccZHrUb4sjfqNhiCJY YQ+CjoISrs1bCkDhgNAPxG+5wpHAO5VOClmfAmdkl2hzeT4UlCwK9gflQyOe4OIu /bKg01tGlqwK2nIsfYKW8P99uhHIdopdSqwZ8XSynHMdOeO39dE28rEEAooOO3JC w/Og7sJoygeAlB61bu1u6my8zLuWUvKlBbE8ILKLVzBDlM6dFnvrDo8mSwKZe0kP 4x5yR55ucU7lk8DGxmAAIjGpeZ7lgMd657EV1Wtu7yXi2Wn5TJIco1/DmhI5FpI= =XHHN -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
