[coreboot] Fwd: [Libreboot] libreboot kfsn4-dre servers on sale
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 thought someone here might be interested too - Doorgestuurd bericht Onderwerp: [Libreboot] libreboot kfsn4-dre servers on sale Datum: Wed, 06 Jan 2016 17:35:58 + Van: Francis Rowe <i...@gluglug.org.uk> Aan: libreb...@nongnu.org <libreb...@nongnu.org> Hi, I have 6 of these server motherboards, fully tested and working: http://libreboot.org/docs/hcl/kfsn4-dre.html Each of them has CPU heatsinks and fans already installed, in addition to 2 quad-core CPUs on each board. They all have 16GiB of RAM. They will come with libreboot preinstalled. The CPUs and heatsinks are already attached, as is the RAM, so you only need to put these inside a case with a PSU and you should be good to go. I was going to use them, but now have decided on a different plan, so these need a new owner. They're perfect for any kind of high-demand server or workstation usage, and performance is generally excellent for almost anything you can think of. This is a one-off sale, sold as-is. Price is negotiable, and dependent on quantity. Contact me off-list if interested. (I'm the person who runs the Ministry of Freedom, and the libreboot project). Happy hacking! Regards, Francis Rowe. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWjVJUAAoJEP9Ft0z50c+UT5gH/ii9o64Ukg6CejQfoAG1akgT oKANBrOYz/xcorzXNtZfdYFQhTCVQPD3pq97GdKVm4OVod5NEafNoGsR0PehmL3j IjYPnOHwcTvCZusI0Fz1iCAcn8de024xe7sXcbCPDA+HLQ7R6+i2DntGyZxR8X1c FURvbbyc4VqB03p0Lu8T9T3mtNYUvHg2HMgMlWGgrHT4DOJ6AEcLmp+tiLJEGfIr sZpLyYbbjbzAQO8wNTfwbukNt1BeqUaqlvHmIEV5LL+PdAPES3rjVxKkRWi7lCqO OwhOY376U/LAmGaYM3vsEI9phAZTWMIBL/+mWctMY0+ziklew9yKdJvpqM60Kww= =/EDI -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS KCMA-D8 workstation board port offer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/15 21:44, Timothy Pearson wrote: > All, > > After reviewing some of the comments on the ASUS KGPE-D16 being > essentially too large of a system and too expensive for many > people, and the fact that modern, blob-free systems are not really > available in the mid-range arena, Raptor Engineering would like to > offer to create a native initalization blob-free port for the ASUS > KCMA-D8, which is essentially the KGPE-D16's ATX-compatible "little > brother". > > We would be asking $15,000 for the port, including upstreaming to > the master coreboot tree. We already have extensive experience > with these Family 10h/15h boards, and would be able to create a > port of similar quality to the existing KGPE-D16 source in terms of > both code quality and overall functionality. > > If this is something you might be interested in please let me know. > We are able to accept multiple payments from various sources for > the same project (within limits), so if this is something your > local Linux groups or similar might be interested in we should be > able to keep the cost on any one individual or organization to a > reasonable level. > > Thank you for your consideration, > > To be clear, Timothy is trying to gauge potential interest in a collective crowd funding source, between interested parties within the coreboot project. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJWQWmAAAoJEP9Ft0z50c+UwsAIAK4KOWHaUNVnm0GDIE/U1a8z FldJ/uXCvrb+BpLaQgE7FReDeJnawwxcBypo16qaq2pC3kKfawV0baOWBkQXhbau gvO7kye7KvTIGguGPokyGuLdXp0ZwDJUnQgI34gn2cynDR53uOwwzdxi5qNdshJu DK2f/c713AP1APqE8pnlFYFgenZMXeOCoq+Oz7gBFv28AzAEC7FqiX+dKhQes1wM cov3alODt8IZsXIrt0A9T5Zpy1STu0zju38A9pzMaKsuaGBLAIb69fduZgOZjh7K SR0+WaXYOouflEJA/BG7LHC2i9PqQjCfLiVv1r5A8Ef0rpHnJQpjC6gT27/j/nk= =yNCo -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Removal of AGESA - to be or NOT to be? A story of G505S
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/11/15 02:48, Francis Rowe wrote: > > > On 06/11/15 10:11, Vladimir wrote: >> * Did you know that Lenovo G505S is still widely available at >> some parts of the world? (e.g. in Russia, 50+ online shops are >> still selling it) * Did you know that Francis Rowe, head >> Libreboot developer, has proposed the addition of G505S to >> Coreboot LTS Candidates list of laptops? > > Hey, please don't make it look like I endorse this hardware. I > don't. There are several blobs (SMU firmware, Video BIOS, XHCI > firmware and others) that make this laptop a non-option for > libreboot at present. I only mentioned it as a future candidate, to > be added once these issues are resolved. > Also, you were talking about the LTS list on the coreboot wiki, which I did not create. Someone else did that. I only work on libreboot. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJWPrhmAAoJEP9Ft0z50c+UBCkH/Rh2whsYl3rwZFY2dnuAeXaE ECw2vk8fsOl1oTYWEssenqJHA1RhPxql5sNxZQeJ0qIOPhWAbK2rI5GKnCTVGiD5 z/JMUwOJwwDDyYviHoGnXKKmdQDgDG0Mv6uZWoeBbcfkysoTA6nESEh2dH1t4jH2 AncTyYZKsTyb/iDuWPqlnCJnWplSOGrZ0hPTxpRD41zVEUJgXWBsBkbRT4EVbPtm Mq9UBwUocwNa0m2fncerRv0ZFszucNO7COcr5LCZX2Re1kOfwwUXbd1ww9Ffi60K EPYn7Y0mEX6R7yAxNYxyVaQffQhIrMiJhYpmz25S3lokEbVdAWAuaEqBfKuljQc= =vscQ -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Removal of AGESA - to be or NOT to be? A story of G505S
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/11/15 10:11, Vladimir wrote: > * Did you know that Lenovo G505S is still widely available at some > parts of the world? (e.g. in Russia, 50+ online shops are still > selling it) * Did you know that Francis Rowe, head Libreboot > developer, has proposed the addition of G505S to Coreboot LTS > Candidates list of laptops? Hey, please don't make it look like I endorse this hardware. I don't. There are several blobs (SMU firmware, Video BIOS, XHCI firmware and others) that make this laptop a non-option for libreboot at present. I only mentioned it as a future candidate, to be added once these issues are resolved. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJWPrf3AAoJEP9Ft0z50c+Um3QH/1PT7yQCof6Lnsfi0kdP+tH0 xDUADsLk/R5AkZdAxPeSaNJZbkEfoep9AHThyay6H5wGTScTJqaqrj6rK5TLqrxo hDf/onjhklSKisvlTTKTOROOWcWaYmQgrLb2MZd16XzuOa+WfdnE2Ypt3CP8cn4e CeWgpCYhwEyaErtApd73+l5yjZpw+m/pbh/Y3frhrkFqg+1jJxq6/BMKUr4t6to9 a8vlKWYutonlOYMiY2xmLrclsotoXALw9rrJy8/ka7PEqTgRvGyVT4q9vF/8kSME f42yBRlFZkpaRIaFctpcDHgLCvX+7MxwBtBLLMlZXlGyyBBy7n+hnc2iiSe2gTw= =xbvM -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] mute button on X200
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On the Lenovo X200 with coreboot installed, the volume up/down keys on the keyboard work, but the mute key doesn't (it does in factory BIOS). I'm investigating this myself, but in case I fail, I'm also reporting this here. First I tried monitoring it in xev, but that doesn't seem to show anything in factory bios either. This button is controlled by the EC, isn't it? And coreboot has to expose that somehow. I tried looking in the coreboot src to see what I needed to modify, but I haven't found it yet. I looked in src/ec/lenovo/h8/acpi/ec.asl mostly. Any ideas? Regards, Francis Rowe. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV2DsEAAoJEP9Ft0z50c+U2ZoIAKloxikP2I1F3oRlWCIDLuCE Dd6ylZVGImMnBB1cEL/uac8uedToFOFKKRr170cY2WN3jR5fybWyQ80sGHeWdOD3 MrbbIqYNJGnSbzNfHdSqgS3wDqvCXPzMX6dNLo8MU6uLIZheG5/laEaAMpPuRyYI hkwD3pJhk7Wer1W9nFAAhZBzCOdl8Eh5KAMEp6xJqvAAlp623J8tuIzUQRl+Din6 enpJjDnc/ksiZqXoTs2iM65FmEVRj3rwImem54eIjcLWbrQrtnFyUYOZUHaIVj7G gCv+ES2wDOqDn51TqHlHyr5KLBFsxqaEfQsy1WuLNmdGOb3tNXa2LWd+AYQMnMI= =TLev -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] mute button on X200
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/08/15 13:48, Idwer Vollering wrote: 2015-08-22 11:04 GMT+02:00 Francis Rowe i...@gluglug.org.uk: Any ideas? Boot into vendor BIOS/EFI thing, install and start acpi_listen, then press the mute button. http://linux.die.net/man/8/acpi_listen I tried that just now. I don't see any events in acpi_listen, when I use the mute button. I do see events for the up/down volume buttons. The mute button does work (only in factory BIOS), but I don't see any events in the OS. The volume in gnome isn't shown muted, either. I think the mute button might be hardware based, while the volume buttons are software (ACPI). On 22/08/15 14:09, Alexander Couzens wrote: On Sat, 22 Aug 2015 and take a look on Interaction with the Embedded Controller at https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips you want to know which _QXX function is called. maybe that one is empty in the coreboot aml for h8s.. Thanks, I'll take a look. It doesn't seem like the mute button is controlled by ACPI, though. Perhaps I could use ectool (and other utils?) to see what happens when muting. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV2IoGAAoJEP9Ft0z50c+UkVkH/1tv8GLz3nrsUW8girDImciJ eT1jsnnlehTBmEIQtJ4SADqZYrtCUdLIutuV+/r53LIqxHT/LRAGDd67HotBY8UY sIWFx2YysDqwpCBnPIdptLVUHrd2xBwS4oGYfiPd8muhFTuhnJ72/+50EhmD96w3 RwDZrZJ/NWbF9OX4YaptOvoBoOkuyMO+thpNBnqcAfUkD/9IEjLOrm7ig7YxCIkm jNhiR9FobQWQhjq8Vl1k6NyRLZdx6Q8YKb8uubbQYL6E95+G76xhpLK62rTFMBJ4 cmHiOX/kcUqey8qI1kHYRtuAK0NIc/jm9WhEitHXudLtivNwZr0OfQHyAisfX9E= =TE96 -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] mute button on X200
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please disregard this thread. from the #coreboot IRC channel: francis7 lynxis, hi * redpill has quit (Ping timeout: 264 seconds) * redpill (~redpill@unaffiliated/redpill) has joined #coreboot lynxis 0x30 does volumecontrol. I've also written that down in http://www.coreboot.org/EC:lenovo/x201 francis7 oh lynxis try to play with that using ectool -w -z francis7 Yes, to see if that changes volume. lynxis you can try to read the disassemlbed acpi code. take a look on the dsdt. acpi asm is very easy to read. * siro has quit (Quit: Leaving.) francis7 lynxis, confirmed francis7 lynxis, I have this running: francis7 sudo watch -n .1 ./ectool -i francis7 When I mute (factory bios), 0x30 changes from 0x03 to 0x43 francis7 When unmuting, it changes back to 0x03 lynxis on x201: it's 0x40 or 0x00 francis7 The same also happens in coreboot. francis7 However, on coreboot, no actual muting occurs. lynxis x201: the speaker got muted. francis7 ok, wtf francis7 I tested it on another X200 with coreboot francis7 mute works francis7 wtf lynxis francis7: can you send me a dump of the acpi with OEM bios? francis7 lynxis, acpidump acpidump.log ? lynxis acpidump -b dump_dir francis7 -b outputs nothing lynxis it should dump everything into a directory lynxis sudo acpidump -b . francis7 ok now it works lynxis francis7: 0x84 should be the fan speed francis7 seems I already have your GPG key francis7 (public one) lynxis 0xA0DF8604 fp: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604 francis7 yep * tlaurion (~tlaur...@dsl-154-8.b2b2c.ca) has joined #coreboot francis7 lynxis, weird though francis7 the mute didn't seem to work earlier. francis7 maybe I was only testing it on headphones francis7 even in factory bios, the mute only mutes the internal speakers built into the laptop francis7 external speakers/headphones are not muted via that button francis7 I apologize for wasting your time On 22/08/15 18:40, Francis Rowe wrote: On 22/08/15 18:13, Alexander Couzens wrote: Would it help if I include logs here? If so, which logs? ectool will also show some timers, which are counting upwards in the dump. Last time I've looked at the ECDT (x201) it doesn't contain any additional information. There are multiple ways to provide the information saved in the ECDT. Coreboot is using the DSDT for that. Let's say you know which byte is changing in the EC ram, what would you do than? Best, lynxis PS: http://www.coreboot.org/EC:lenovo/x201 Here is the diff (from factory BIOS): user@user-ThinkPad-X200:~/Desktop$ diff -u ectool.log ectool.mute.log --- ectool.log2015-08-22 16:14:32.602441403 +0100 +++ ectool.mute.log 2015-08-22 16:14:38.780364169 +0100 @@ -2,13 +2,13 @@ 00: a6 05 a0 00 fe 96 00 00 1f 02 47 00 00 00 80 00 10: 00 00 ff ff f4 3c 87 09 5b ff 83 04 ff ff 2d 00 -20: 00 00 00 00 00 00 00 60 00 00 00 00 00 00 00 80 -30: 07 00 02 00 30 04 00 00 00 00 20 10 00 50 00 00 +20: 00 00 00 00 00 00 00 df 00 00 00 00 00 00 00 80 +30: 47 00 02 00 30 04 00 00 00 00 20 10 00 50 00 00 40: 00 00 00 00 00 00 14 04 40 01 00 00 00 00 00 00 50: 00 c0 02 19 df 07 08 16 0e 0a 31 04 04 d0 07 48 60: 0d d8 0e cc 10 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 12 30 80 27 32 80 2c 80 80 80 80 -80: 00 00 00 06 ce 0e 03 00 00 00 00 00 00 00 6c 00 +80: 00 00 00 06 e3 0e 03 00 00 00 00 00 00 00 6c 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x27 changes. 0x30 changes. 0x84 changes. Here is the diff from coreboot (on another X200, though, so probably different EC version): user@user-ThinkPad-X200:~/Desktop$ diff -u ectool.log ectool.mute.log --- ectool.log2015-08-22 17:31:27.684144336 +0100 +++ ectool.mute.log 2015-08-22 17:31:34.775508137 +0100 @@ -2,17 +2,17 @@ 00: a6 04 a0 11 fe 96 00 00 1f 02 43 00 00 00 80 00 10: 00 00 ff ff f4 3c 80 01 01 ff ff ff ff ff 00 00 -20: 00 00 00 00 00 00 00 2b 00 00 00 00 00 00 00 80 -30: 03 00 00 00 30 04 00 00 00 00 70 10 00 00 00 00 +20: 00 00 00 00 00 00 00 58 00 00 00 00 00 00 00 80 +30: 43 00 00 00 30 04 00 00 00 00 70 10 00 00 00 00 40: 00 00 00 00 00 00 14 04 42 01 00 00 00 00 00 00 50: 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 12 30 80 30 2f 80 33 80 80 80 80 -80: 00 00 00 00 6c 0e 00 00 00 00 00 00 00 00 00 00 +80: 00 00 00 00 6a 0e 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -c0: 33 38 80 80 80 80 80 80 00 41 1a 00 00 00 00 00 +c0: 33 37 80 80 80 80 80 80 00 41 0d 00 00 00 00 00 d0: 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 10 60 b9 06 04 2e 55 03 f0: 37 58 48 54 32 34 57 57 13 74 62 b4 13 74 61 9c
Re: [coreboot] mute button on X200
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For my future reference: lynxis francis7: on x201 it doesn't generate any acpi event. francis7 on X200 it doesn't, either. lynxis francis7: in dsdt, bit 7 of 0x30 is named HMUT francis7 HMUT = hardware mute? lynxis it's bit6, if you count from 0. yes. acpi variables names are limited to 4 bytes. francis7 lynxis, please assume that I will be counting from the right-most bit (^0) francis7 and assume that I will count from 0 francis7 If you say bit 7, I'll think you mean the one that equals 128 or 0x80 when set to 1 francis7 when really you meant 64 or 0x40 lynxis francis7: me too, but I miscounted it this time. please forgive me ;) francis7 :) francis7 this is what causes off by one errors in programming lynxis it was more reading it. because it says 6 bit are empty, nextbit is HMUT On 22/08/15 19:37, Francis Rowe wrote: Please disregard this thread. from the #coreboot IRC channel: francis7 lynxis, hi * redpill has quit (Ping timeout: 264 seconds) * redpill (~redpill@unaffiliated/redpill) has joined #coreboot lynxis 0x30 does volumecontrol. I've also written that down in http://www.coreboot.org/EC:lenovo/x201 francis7 oh lynxis try to play with that using ectool -w -z francis7 Yes, to see if that changes volume. lynxis you can try to read the disassemlbed acpi code. take a look on the dsdt. acpi asm is very easy to read. * siro has quit (Quit: Leaving.) francis7 lynxis, confirmed francis7 lynxis, I have this running: francis7 sudo watch -n .1 ./ectool -i francis7 When I mute (factory bios), 0x30 changes from 0x03 to 0x43 francis7 When unmuting, it changes back to 0x03 lynxis on x201: it's 0x40 or 0x00 francis7 The same also happens in coreboot. francis7 However, on coreboot, no actual muting occurs. lynxis x201: the speaker got muted. francis7 ok, wtf francis7 I tested it on another X200 with coreboot francis7 mute works francis7 wtf lynxis francis7: can you send me a dump of the acpi with OEM bios? francis7 lynxis, acpidump acpidump.log ? lynxis acpidump -b dump_dir francis7 -b outputs nothing lynxis it should dump everything into a directory lynxis sudo acpidump -b . francis7 ok now it works lynxis francis7: 0x84 should be the fan speed francis7 seems I already have your GPG key francis7 (public one) lynxis 0xA0DF8604 fp: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604 francis7 yep * tlaurion (~tlaur...@dsl-154-8.b2b2c.ca) has joined #coreboot francis7 lynxis, weird though francis7 the mute didn't seem to work earlier. francis7 maybe I was only testing it on headphones francis7 even in factory bios, the mute only mutes the internal speakers built into the laptop francis7 external speakers/headphones are not muted via that button francis7 I apologize for wasting your time On 22/08/15 18:40, Francis Rowe wrote: On 22/08/15 18:13, Alexander Couzens wrote: Would it help if I include logs here? If so, which logs? ectool will also show some timers, which are counting upwards in the dump. Last time I've looked at the ECDT (x201) it doesn't contain any additional information. There are multiple ways to provide the information saved in the ECDT. Coreboot is using the DSDT for that. Let's say you know which byte is changing in the EC ram, what would you do than? Best, lynxis PS: http://www.coreboot.org/EC:lenovo/x201 Here is the diff (from factory BIOS): user@user-ThinkPad-X200:~/Desktop$ diff -u ectool.log ectool.mute.log --- ectool.log 2015-08-22 16:14:32.602441403 +0100 +++ ectool.mute.log2015-08-22 16:14:38.780364169 +0100 @@ -2,13 +2,13 @@ 00: a6 05 a0 00 fe 96 00 00 1f 02 47 00 00 00 80 00 10: 00 00 ff ff f4 3c 87 09 5b ff 83 04 ff ff 2d 00 -20: 00 00 00 00 00 00 00 60 00 00 00 00 00 00 00 80 -30: 07 00 02 00 30 04 00 00 00 00 20 10 00 50 00 00 +20: 00 00 00 00 00 00 00 df 00 00 00 00 00 00 00 80 +30: 47 00 02 00 30 04 00 00 00 00 20 10 00 50 00 00 40: 00 00 00 00 00 00 14 04 40 01 00 00 00 00 00 00 50: 00 c0 02 19 df 07 08 16 0e 0a 31 04 04 d0 07 48 60: 0d d8 0e cc 10 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 12 30 80 27 32 80 2c 80 80 80 80 -80: 00 00 00 06 ce 0e 03 00 00 00 00 00 00 00 6c 00 +80: 00 00 00 06 e3 0e 03 00 00 00 00 00 00 00 6c 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x27 changes. 0x30 changes. 0x84 changes. Here is the diff from coreboot (on another X200, though, so probably different EC version): user@user-ThinkPad-X200:~/Desktop$ diff -u ectool.log ectool.mute.log --- ectool.log 2015-08-22 17:31:27.684144336 +0100 +++ ectool.mute.log2015-08-22 17:31:34.775508137 +0100 @@ -2,17 +2,17 @@ 00: a6 04 a0 11 fe 96 00 00 1f 02 43 00 00 00 80 00 10: 00 00 ff ff f4 3c 80 01 01 ff ff ff ff ff 00 00 -20: 00 00 00 00 00 00 00 2b 00 00 00 00 00 00 00 80 -30: 03 00 00 00 30 04 00 00 00 00 70
Re: [coreboot] mute button on X200
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I haven't got anywhere yet, but I did notice that factory BIOS defines a table called ECDT, while coreboot doesn't. iasl shows this as being related to the EC. I can see different ectool output (using the -i option) option on different runs, even without changing the mute/unmute status, and also some changes when muting, but I haven't managed to figure it out yet. Would it help if I include logs here? If so, which logs? On 22/08/15 16:07, Alexander Couzens wrote: Thanks, I'll take a look. It doesn't seem like the mute button is controlled by ACPI, though. Perhaps I could use ectool (and other utils?) to see what happens when muting. maybe, maybe not. acpi_listen only helps you, when something in the user space is missing. It'll show you what acpi event is generated from acpi code. But when the acpi code is missing, you don't see anything there. Take a look on the ubutun wiki and do the kernel debug thing it's described there. ectool might show you what's changed, but I would bet, the ec is generating an ACPI query event, which must be handled by _Qxx function. cheers, lynxis - -- Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Tel: +44 (0) 1268 857 837 | Web: http://minifree.org/ Use free software. Use GNU/Linux. https://www.gnu.org/philosophy/free-sw.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV2KpUAAoJEP9Ft0z50c+U/u4H/2FsCD2fcyJjMCA72nn1l3Jl MJzu9mAsPl8qIuw4zbdFMQFYF0XAZWW5L9XsLOjXxYOPPbv4m00ZdbERDz3ZfM4G LYrBsoY1rLeLN7xD4Y3DaCKFOUNbHKhFbC3Xe0WL/yirZHbqrREKYlOkvLVfGc2t mFm53nftyyWMW2sI7gF+0l9ZqnjL0dLWtrV2h55SliMn3Trk7lLcba0CRJFqX33i z9s6J8M4Pnjk+EH7qPUGq6QP53XC8zBrYiHs3EHSsHwmEl1HQxfpmNhajCZpIwt5 x/im1OzkXc4wHISNnnDo4BoPduoTFire1DzXthuYpeBeQadZ0c/FsKp8Uyv1cdo= =fOK6 -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] mute button on X200
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/08/15 18:13, Alexander Couzens wrote: Would it help if I include logs here? If so, which logs? ectool will also show some timers, which are counting upwards in the dump. Last time I've looked at the ECDT (x201) it doesn't contain any additional information. There are multiple ways to provide the information saved in the ECDT. Coreboot is using the DSDT for that. Let's say you know which byte is changing in the EC ram, what would you do than? Best, lynxis PS: http://www.coreboot.org/EC:lenovo/x201 Here is the diff (from factory BIOS): user@user-ThinkPad-X200:~/Desktop$ diff -u ectool.log ectool.mute.log - --- ectool.log2015-08-22 16:14:32.602441403 +0100 +++ ectool.mute.log 2015-08-22 16:14:38.780364169 +0100 @@ -2,13 +2,13 @@ 00: a6 05 a0 00 fe 96 00 00 1f 02 47 00 00 00 80 00 10: 00 00 ff ff f4 3c 87 09 5b ff 83 04 ff ff 2d 00 - -20: 00 00 00 00 00 00 00 60 00 00 00 00 00 00 00 80 - -30: 07 00 02 00 30 04 00 00 00 00 20 10 00 50 00 00 +20: 00 00 00 00 00 00 00 df 00 00 00 00 00 00 00 80 +30: 47 00 02 00 30 04 00 00 00 00 20 10 00 50 00 00 40: 00 00 00 00 00 00 14 04 40 01 00 00 00 00 00 00 50: 00 c0 02 19 df 07 08 16 0e 0a 31 04 04 d0 07 48 60: 0d d8 0e cc 10 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 12 30 80 27 32 80 2c 80 80 80 80 - -80: 00 00 00 06 ce 0e 03 00 00 00 00 00 00 00 6c 00 +80: 00 00 00 06 e3 0e 03 00 00 00 00 00 00 00 6c 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x27 changes. 0x30 changes. 0x84 changes. Here is the diff from coreboot (on another X200, though, so probably different EC version): user@user-ThinkPad-X200:~/Desktop$ diff -u ectool.log ectool.mute.log - --- ectool.log2015-08-22 17:31:27.684144336 +0100 +++ ectool.mute.log 2015-08-22 17:31:34.775508137 +0100 @@ -2,17 +2,17 @@ 00: a6 04 a0 11 fe 96 00 00 1f 02 43 00 00 00 80 00 10: 00 00 ff ff f4 3c 80 01 01 ff ff ff ff ff 00 00 - -20: 00 00 00 00 00 00 00 2b 00 00 00 00 00 00 00 80 - -30: 03 00 00 00 30 04 00 00 00 00 70 10 00 00 00 00 +20: 00 00 00 00 00 00 00 58 00 00 00 00 00 00 00 80 +30: 43 00 00 00 30 04 00 00 00 00 70 10 00 00 00 00 40: 00 00 00 00 00 00 14 04 42 01 00 00 00 00 00 00 50: 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 12 30 80 30 2f 80 33 80 80 80 80 - -80: 00 00 00 00 6c 0e 00 00 00 00 00 00 00 00 00 00 +80: 00 00 00 00 6a 0e 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - -c0: 33 38 80 80 80 80 80 80 00 41 1a 00 00 00 00 00 +c0: 33 37 80 80 80 80 80 80 00 41 0d 00 00 00 00 00 d0: 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 10 60 b9 06 04 2e 55 03 f0: 37 58 48 54 32 34 57 57 13 74 62 b4 13 74 61 9c 0x27 changes. 0x30 changes. 0x84 changes. Also on this dump, 0xc1 and 0xca change. I'm not currently sure what to make of this. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV2LP2AAoJEP9Ft0z50c+UEpMIAMGK/j6chv25uquOIuyzeDo+ mNgXkQJwSjXvulg0DekU9AzZNKIetrWzR4Qg7QarqthDIrLe7n89lQzsgaTiOkx6 GEC13il29UItNVZ0p4I3EIrdHWswsyWz/oNJ5AzgsVhZQT9j4Tg4vRn+1Ivbs8nC FbVMrezp6yPglJG7S1ASqeI0xfKx53Wvu+fOoqgsbb07980N3TfzJJ+OGOy30FnV rKHikR5bDEl6n16YHYa0szydDo/e2BEoE4DipSO1W7UV4ZfJWui6gp9JrwjHxBM8 Fr5qTI/RT3zzoW3HeJZ+Nvb6TXPjVleipyp+VKRcs7AvIAcbtNKZ3G7N3G2MD5Q= =WARv -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] x86 smm: memory sinkhole attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I've been reading lately about this attack: https://github.com/xoreaxeaxeax/sinkhole Some summary articles: * http://www.theregister.co.uk/2015/08/11/memory_hole_roots_intel_processors * http://www.bit-tech.net/news/hardware/2015/08/07/x86-security-flaw/1 My basic question is: are coreboot systems affected by this vulnerability, and if so, what work is being done to patch it? Specifically, in my case, I am interested in the following coreboot systems: * i945 platforms (Lenovo X60/T60, Macbook2,1) * GM45 platforms (Lenovo X200/T400/T500/R400/R500) * fam10h AMD platforms (ASUS KFSN4-DRE, ASUS KGPE-D16) Could someone shed a light on this? Regards, Francis Rowe. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVy1gdAAoJEP9Ft0z50c+UYm0H/RutL81jWDKpYx9AGaSnIt5Y kwhyRj5MByd4pB6TUF/nVEwvxtpef/rhLvE611Gv3s85+7oCRoqdg6kcgMuOvtW/ /8xN3XnzmbJlQgCvc99rN1Tm/GJ1oqHcVUZx8Rj3ljG2l9qGtdGIaKiZmhwW82pD TeV9IUEKb7KTLaX/asSCZoJexRMd4zmfFb36wHpbHih9XDSUxdf1QKXRRBr1PhLf IxXLhS/0+YXmfUHksvOco5z5pB96ApMfzU409ewbJb3kDK7Dfp2C37QRqjP+S2wO kqPQBgGrQc74vzbgdQjxg3f9XqNzhUlZH56Tw2sUPNlUJxRCvKJLIcpjxvtSLEE= =z7lk -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Please turn on CBMEM console for payloads in Libreboot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/15 10:21, Paul Menzel wrote: Dear Libreboot folks, Am Sonntag, den 05.07.2015, 09:42 +0200 schrieb Paul Menzel: Am Samstag, den 04.07.2015, 11:11 +0200 schrieb kr...@posteo.be: […] the payload - I dont know to get or find it. It is GRUB. Unfortunately, I do not see GRUB’s debug messages in CBMEM. Could you please enable logging to CBMEM console in your payloads? For GRUB you’d need to enable the CBMEM console terminal by adding the line below below your terminal setting in your `etc/grub.cfg` in CBFS. terminal_output --append cbmemc Done. http://git.savannah.gnu.org/cgit/libreboot.git/commit/?id=08b4126023fa16f1d473fa71800560e84f4684da Maybe Vladimir has some other suggestions. I will ask him. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVotRBAAoJEP9Ft0z50c+U7VEIAIFwkPVg9J3qtkOlFj6AMR7x gLXZjbZKIiFF67RI36eEJDWOzeMm8mYz4ZrijfZpOYcLQ0xkvsBGXJNtPQ18uMC5 OG+BEYf5Cw1yCR8IVAmIjGl2DjKo5Hr57HKTnU0q1mNNPKftnmgaWU0cCd1BGG5x gjJSqY/0ZX8KSGPZMM1Oj163CtYsRJOv3JLPBugdsi8exyWeJja9MWSJrh7A81KW V8/pFLvnEOMxyiSKVyd6M6i8zHQymmQIGOIizXPTUXVP+yigVbiDhQ57lviNvk8J 2QjJDEhzYQR1kam4OAVeZ2ONsLgY7KiTTsouxZeTGCrOwKw2KgIdPBtw7/TwRYA= =kHvy -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T400 screen issue / EDID handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/07/15 15:27, kr...@posteo.be wrote: Hello, I allready contacted Francis from libreboot and he forwared me to this list, because it seems to be an issue regarding coreboot. I have flashed a Lenovo T400 with libreboot. The T400 has an Intel GPU and I am able to use it with an external display connected to the onboard vga-port. The issue is, that I can't use the internal display, which is an 1440x900 Samusung LTN141WD-L05, EDID dump: https://paste.debian.net/plainh/b3699c60 It seems like the internal screen is powered on while booting but it stays black. Francis assumes that this is due to bugs in how coreboot handles the EDID. Here is an EDID dump of a working display: http://paste.debian.net/plainh/776705d5 Anyone is able to help? Thanks in advance! Dear coreboot community, tty0_ in #coreboot/#libreboot found a partial fix. See: http://libreboot.org/docs/hcl/gm45_lcd.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVobEOAAoJEP9Ft0z50c+UJSgH/3tj9DiBbitS1eCgJ98743Ij sARuL4cFbUNMeT6nZmnhMEmv+O8Na9SO2yuvVb/iqcYLzbQc6gGmD8wzIln77c+c jXZ+Tje7RSwwCJvt3gDtXG1UTvnDGthJy+qUh5JqQxyNljSNFUQNCpkZw/vhAgJa aXcxO8w1W7eFRO5ueTR0HqF57JQXjyNBTicfCKqRpRJ/ac93ipbuKQBAIUywjjdD +LD3a31RfEjmd8YpAzEXbvUhl3b4NWTuy0nqQj9amaQGeJKycNSAYisLKqriPZXe r0WW9mfSUWWPTYpTtRREK8uBkKmRF0qMLKZES2B9SiDsZ3RcF0+CRAP+6UTwP+Y= =gxaG -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T400 screen issue / EDID handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thank you. Unfortunately, I was unable to see anything suspicious in there. Libreboot seems to strip of the coreboot revision it uses from the banner, which is not good. It might be in the revision file in CBFS. Libreboot builds coreboot without the .git directory, so it's not possible to get the coreboot revision. You can find out what version of coreboot it is by looking at resources/scripts/helpers/download/coreboot He is using libreboot 20150518, so the coreboot revision that he's using is e19c8b0091022ae3f490601aed0c290cd5171b79 See http://git.savannah.gnu.org/cgit/libreboot.git/tree/resources/scripts/helpers/download/coreboot?id=r20150518fix -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVmUXaAAoJEP9Ft0z50c+UzDwIAIvUK5lpPHveEKdoGeHRIvZ/ wrfTuzqtM2snIT2baypZTpcirxCfcLonr4dntKG4VkL5edxzWTjWpPF855vLyCeQ gLBdGjHlZ+NTyZZDvkPoHJNGaPhoYUaUk/2L6GafUgYBRgxWcOjJs5xyfHk1VU/L BcXFztVKfPM2BDWW0nue8ycdxzo3fTfAwNdCCCFBaypi22eEQXqEt4WNjAxlKbwE Y1VxUn7klMDqP0HYCtWDr2Gmgw58LirZ2ZCq+Q00oae8ZXYIJzpp/qM6si8n25HI lzuU9AHIzDiMQ/hGAuU0J6VOK9uHw+DTgFjWyCgu69DgInA9mfihoQbLd+ro/Lo= =1+ZG -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T400 screen issue / EDID handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/15 15:57, Francis Rowe wrote: Thank you. Unfortunately, I was unable to see anything suspicious in there. Libreboot seems to strip of the coreboot revision it uses from the banner, which is not good. It might be in the revision file in CBFS. Libreboot builds coreboot without the .git directory, so it's not possible to get the coreboot revision. You can find out what version of coreboot it is by looking at resources/scripts/helpers/download/coreboot He is using libreboot 20150518, so the coreboot revision that he's using is e19c8b0091022ae3f490601aed0c290cd5171b79 See http://git.savannah.gnu.org/cgit/libreboot.git/tree/resources/scripts/helpers/download/coreboot?id=r20150518fix Note: this bug also affects coreboot upstream, using no additional patches, from the latest version in the master branch from http://review.coreboot.org/coreboot -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVmUZmAAoJEP9Ft0z50c+UGw8IAMCziSv5jfp078b9lokEapUb kuWPtXAGPrAaZN92kaQRRlGPcp5OF0vAJxhpBPQlMBzl7taizhCb0+BSXKVncusY GL/eXc2eKRt/sYRWCJxM8Eu3uukUH3ybhHLubR/kOmQ1gi2fuzYXbo+qb2ViJ5dZ +wF+lyIHxj9RxCEY2TvuLO7c0MjdduC3GdUmlp9am7P+5qWbFr22lok0VznkZ54B QKorLCxrLPrZnmpZJr1rL0UfkgGZ6uurtK6kbMYhdIsOXTlvgvuu22lnjqKr9fJ2 EwcLWAM9ywq8Aph4HyhEMcVCbj2izVdAURTsK7vGUAwaV7R9s2yfVCLcWmr7mXQ= =71Qg -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T400 screen issue / EDID handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't understand why you're removing the .git directory. But anyhow, you should patch the coreboot version script. The script should take your specific version of your libreboot build script git repo. Please prefix the version with libreboot, it makes all our live easier to know what version is running and from where the version comes from. And btw. this makes your coreboot' build reproducible, which isn't it atm. Libreboot removes all of the blobs from coreboot. In doing so, a diff showing those deletions (therefore, containing the blobs) is shown. The git history in coreboot also shows blobs that have been added or deleted, over time. By not deleting the .git directory, libreboot would be distributing blobs. That's why it's deleted. However, your comment is valid; I should patch the build system in coreboot so that it shows libreboot-insert revision here in the coreboot-libre boot logs (as seen from serial output, EHCI debug output or cbmem -c). I've added a note for myself, reminding me to do this. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVmZtuAAoJEP9Ft0z50c+UW3AH+QGjaH5w/rIEWhKCYvXUDFOj U6yNgGFT8kkXEWaS+vZY1iVrDdIGbEx9SM27ZXroUWLlIS90XiHyzYGqztJgzfrB 3XaYFI17WYwpoQ5f3OGyF8uycc1JlQQQ8zs7xDZywNNVYR4pJUkXHleaYEOb9k3U GJ4PdO22fqTcyZH5XZXk0ga0oZp8N3ChLJgA2gy7L0fGfX73VxQL0CvQ/bMdMsOG hERR4wf7cy4Z6BV1p65lt4Hi60kbEiQ5JpTBawQ80xGUCq2yVyxjJDrY+Pn/1W2l vHmyeM2iBpAroUEZ0f2XnWH8KDEAkoMiM1H6vu6ZHybGrK/JNqf+Le9AXA5oWfo= =p9+b -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Idea: Friday Coreboot Wiki IRC Meeting - FCWIRCM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Friday Free Software Directory IRC Meeting or FFSDIRCM This is an event held in the #fsf IRC channel on FreeNode, every Friday starting in the evenings (Boston/Massachusetts time zone). Essentially, it is a weekly gathering where people collectively add/update information on http://directory.fsf.org/ which is a wiki dedicated to listing as many free software packages as possible. Coreboot (and also libreboot) are listed there. Of course, people also contribute to it at other times of the week, but Friday evenings are when there is the most activity. The idea is, that it is a set time each week where lots of people come together and try to improve the wiki as much as possible. This means that every week, there is a burst of activity; this is also when the moderators are most active, reviewing changes (coreboot wiki doesn't have moderators, so this isn't relevant there). Having such a date means that you are also advertising the existence of the wiki, encouraging more people to contribute, who would otherwise not contribute. Essentially, my idea is to have something similar for the coreboot wiki. Every week (on a set day - Friday evening is optimal, for various reasons), people would come together and improve the wiki as much as possible. This could be anything from adding pages about boards in coreboot which are not currently documented, improving existing pages, making the wiki easier to read, and so on. Anything that improves the efficiency of the wiki, so that it is a more effective source of information for coreboot users and developers. Thoughts? -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVgu9jAAoJEP9Ft0z50c+UQlAH/AsEXn1LK87RfutY0GX5joWh Q7V8zhg/14ILT13yrwSQSeaaNBf4DWVmVnnmbxw64ExWmnzNP43AER1mFX8U1Gxj WiLasiA2IZHwBTiVs1ShaAx2PtlsHVbO3PndLjHo4yTAkVbZpBVRfpkkrfVDZD3Y 8ySOkNQCmDtkAdnfvOdI5VqJK2J6lfJ9ZnEksVvDip4dAUqjVXPYIRZniFDponB1 uNDM+fOV38wWdWJo0Hq4A3c+SxExrYkUrUv+gosL0lWp7qwTv7q0mIdh51lSMgpn uWINtMHSxOxkOaU1FD2mhTvpk1S6GwcSxx+o0Dq4Gx9+NH9twc7ECRREMMYkP3g= =eod8 -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
