coreboot December 2017

coreboot@coreboot.org

68 participants
177 discussions

Re: [coreboot] Depthcharge License
by tturne＠codeaurora.org 21 Dec '17

21 Dec '17

On 2017-12-19 09:53, David Hendricks wrote: > To be fair, it appears that many source files refer to a non-existent > LICENSE file. Someone on the CrOS team should probably just add the > LICENSE file for depthcharge and/or contact mal@ to see how the > license info is being collected these days (e.g. for > chrome://os-credits [3]). > Thanks for the input on the DC licensing, and because lawyers are involved I need to ask a direct question. Can a Depthcharge maintainer (anybody who has +2 gerrit authority would suffice) state on this thread that the Depthcharge project license is GPLv2 (or later)? I know this feels redundant and that the question has been asked and answered, I'm just trying to satisfy our internal legal group. Per David's point above, this direct question would not be required to satisfy the lawyers if a top-level COPYING or LICENSE file is added to Depthcharge. Which I will be happy to add once I'm able to start contributing to the project. Cheers, T.mike > On Tue, Dec 19, 2017 at 9:19 AM, ron minnich <rminnich(a)gmail.com> > wrote: > >> Is there even a question? Looks like aaron just answered the >> original question, which boils down to Read The Source? >> >> On Tue, Dec 19, 2017 at 7:58 AM Aaron Durbin via coreboot >> <coreboot(a)coreboot.org> wrote: >> >> On Tue, Dec 19, 2017 at 8:03 AM, <tturne(a)codeaurora.org> wrote: >> On 2017-12-15 13:39, tturne(a)codeaurora.org wrote: >> Preparing to mirror the coreboot.org [1] requires us to vet the >> various >> licenses, etc. >> >> There doesn't appear to be a LICENSE or COPYING file in the >> Depthcharge tree. >> >> My understanding is that Depthcharge is licensed GPLv2 (or later). >> >> How would I confirm this with an online source? >> >> Cheers, >> T.mike >> >> Should this query be posted on Chromium list rather than Coreboot >> list? > > Probably. The files in the depthcharge repository have licenses at > the top of each file. They are GPLv2. > >> Cheers, >> T.mike >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot [2] > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot [2] > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot [2] > > > > Links: > ------ > [1] http://coreboot.org > [2] https://mail.coreboot.org/mailman/listinfo/coreboot > [3] https://www.chromium.org/chromium-os/licenses

2 1

Re: [coreboot] Coreboot Purism BIOS is free? open?
by Timothy Pearson 19 Dec '17

19 Dec '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/19/2017 11:51 AM, Dame Más wrote: > I finished the University and I have free time to do things. And this > seems like an interesting project to which I dedicate many hours. > > The truth is that I read a lot these days. The work you do kakaroto is > impressive. > In general Purism is doing something big, and I spoke ahead of time. > > I saw that in the directory > coreboot/3rdparty/blobs/mainboard/purism/ > there is no content, it is right? > > Thanks The main question I have, and this is an honest question, is why Purism chose to use the x86 platform as a base for libre hardware, when it has been known for some time that said hardware could never be made fully blob-free? There were (and are) other good ways to make a system that could be fully blob-free, for instance ARM, and given the engineering effort that is said to have been put into the Purism machines I wonder what we could have had if said effort had been put into an aarch64 system instead of an x86 system? - -- 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 iQEcBAEBAgAGBQJaOWOAAAoJEK+E3vEXDOFbBZEH/1loBwNG4m2ZrqmQ0qXRrYYy 9i+bMDTA/a85sPMWm870rJ2qG79Wy9s1w6P/qXIf3iFACDWWt5DpB6/NP6t8hjUp R9848GoBH2oCt0gO2Ydbt2ThGCP96q2JQoz2sz5Qo/CWXeBccTHZogA7CRc/u/zO Uj6qSTUUEoxt7Ul0AAoaT0UIYvJJoDjatKX61Rv96hA6RtDGib7nWZ+UwiuD3+wS iiYO+lkZzrhAprrLIH8Y58IMQ8RlQYRIguWQhmD5+A6I933Xyv81QTwonaDKATBC fwi3psMjmem4vg1pfJdBOowzMwx9ZItjjuvhPVkNfgpUP1gkZb+OQbFjounucaY= =iQzP -----END PGP SIGNATURE-----

2 1

Re: [coreboot] Depthcharge License
by David Hendricks 19 Dec '17

19 Dec '17

To be fair, it appears that many source files refer to a non-existent LICENSE file. Someone on the CrOS team should probably just add the LICENSE file for depthcharge and/or contact mal@ to see how the license info is being collected these days (e.g. for chrome://os-credits <https://www.chromium.org/chromium-os/licenses>). On Tue, Dec 19, 2017 at 9:19 AM, ron minnich <rminnich(a)gmail.com> wrote: > Is there even a question? Looks like aaron just answered the original > question, which boils down to Read The Source? > > On Tue, Dec 19, 2017 at 7:58 AM Aaron Durbin via coreboot < > coreboot(a)coreboot.org> wrote: > >> On Tue, Dec 19, 2017 at 8:03 AM, <tturne(a)codeaurora.org> wrote: >> >>> On 2017-12-15 13:39, tturne(a)codeaurora.org wrote: >>> >>>> Preparing to mirror the coreboot.org requires us to vet the various >>>> licenses, etc. >>>> >>>> There doesn't appear to be a LICENSE or COPYING file in the Depthcharge >>>> tree. >>>> >>>> My understanding is that Depthcharge is licensed GPLv2 (or later). >>>> >>>> How would I confirm this with an online source? >>>> >>>> Cheers, >>>> T.mike >>>> >>> >>> Should this query be posted on Chromium list rather than Coreboot list? >>> >>> >> Probably. The files in the depthcharge repository have licenses at the >> top of each file. They are GPLv2. >> >> Cheers, >>> T.mike >>> >>> -- >>> 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 > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Coreboot Purism BIOS is free? open?
by Nico Huber 19 Dec '17

19 Dec '17

Hi, On 18.12.2017 10:07, Dame Más wrote: > Hello, > I understand. > I want implement Coreboot for current 7th and 8th generation Intel > computers. coreboot already works on 7th gen Intel (Kaby Lake). Not sure what 8th gen generally refers to. Kaby Lake Refresh might work as well, and Cannon Lake is worked on. No sign of Coffee Lake support, afaics. Though, all these newer Intel chips are only supported with coreboot's open-source infrastructure around a proprietary core, namely Intel FSP (firmware support package). You still have much more control over the boot process this way. But compared to a fully open-source coreboot it's much harder to support a new motherboard (after my first FSP port, I'd calculate at least 4 times the effort). And you have to trust Intel, ofc. > And if the Pursism BIOS was opensource, I could work with it as a base. However > I can not find the source code to work with him. Purism used a most proprietary UEFI/BIOS on their first devices. They ship now (some?) devices with coreboot. But that's as described above, build around the proprietary FSP. So there is nothing to learn from their code (as of yet). > I like GNU/Linux and the opensource because among all we do it better, but > if the code is not liberated, I can not speak well of Purism. They are working on it. Ask Youness if you can help him to reverse engineer FSP. I hope this answers your question. Sorry for all the noise here on the ML. Threads about "liberated" devices often get hijacked (especially if they are about Purism) to advocate some BS or lament about the ME (which is actually unrelated to coreboot). Nico

2 1

Re: [coreboot] Depthcharge License
by ron minnich 19 Dec '17

19 Dec '17

Is there even a question? Looks like aaron just answered the original question, which boils down to Read The Source? On Tue, Dec 19, 2017 at 7:58 AM Aaron Durbin via coreboot < coreboot(a)coreboot.org> wrote: > On Tue, Dec 19, 2017 at 8:03 AM, <tturne(a)codeaurora.org> wrote: > >> On 2017-12-15 13:39, tturne(a)codeaurora.org wrote: >> >>> Preparing to mirror the coreboot.org requires us to vet the various >>> licenses, etc. >>> >>> There doesn't appear to be a LICENSE or COPYING file in the Depthcharge >>> tree. >>> >>> My understanding is that Depthcharge is licensed GPLv2 (or later). >>> >>> How would I confirm this with an online source? >>> >>> Cheers, >>> T.mike >>> >> >> Should this query be posted on Chromium list rather than Coreboot list? >> >> > Probably. The files in the depthcharge repository have licenses at the > top of each file. They are GPLv2. > > Cheers, >> T.mike >> >> -- >> 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

1 0

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

19 Dec '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. 1 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 1 of 1 defect(s) ** CID 1383864: (UNUSED_VALUE) /src/northbridge/intel/x4x/raminit_ddr2.c: 1205 in dradrb_ddr2() /src/northbridge/intel/x4x/raminit_ddr2.c: 1203 in dradrb_ddr2() ________________________________________________________________________________________________________ *** CID 1383864: (UNUSED_VALUE) /src/northbridge/intel/x4x/raminit_ddr2.c: 1205 in dradrb_ddr2() 1199 // DRB 1200 FOR_EACH_POPULATED_RANK(s->dimms, ch, r) { 1201 if (s->dimms[ch<<1].card_type != RAW_CARD_UNPOPULATED 1202 && (r) < s->dimms[ch<<1].ranks) 1203 i = ch << 1; 1204 else >>> CID 1383864: (UNUSED_VALUE) >>> Assigning value from "(ch << 1) + 1" to "i" here, but that stored value is overwritten before it can be used. 1205 i = (ch << 1) + 1; 1206 if (ch == 0) { 1207 dra0 = (c0dra >> (8*r)) & 0x7f; 1208 c0drb = (u16)(c0drb + drbtab[dra0]); 1209 MCHBAR16(0x200 + 2*r) = c0drb; 1210 } else { /src/northbridge/intel/x4x/raminit_ddr2.c: 1203 in dradrb_ddr2() 1197 MCHBAR8(0x660) = MCHBAR8(0x660) | 1; 1198 1199 // DRB 1200 FOR_EACH_POPULATED_RANK(s->dimms, ch, r) { 1201 if (s->dimms[ch<<1].card_type != RAW_CARD_UNPOPULATED 1202 && (r) < s->dimms[ch<<1].ranks) >>> CID 1383864: (UNUSED_VALUE) >>> Assigning value from "ch << 1" to "i" here, but that stored value is overwritten before it can be used. 1203 i = ch << 1; 1204 else 1205 i = (ch << 1) + 1; 1206 if (ch == 0) { 1207 dra0 = (c0dra >> (8*r)) & 0x7f; 1208 c0drb = (u16)(c0drb + drbtab[dra0]); ________________________________________________________________________________________________________ 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

Depthcharge License
by tturne＠codeaurora.org 19 Dec '17

19 Dec '17

Preparing to mirror the coreboot.org requires us to vet the various licenses, etc. There doesn't appear to be a LICENSE or COPYING file in the Depthcharge tree. My understanding is that Depthcharge is licensed GPLv2 (or later). How would I confirm this with an online source? Cheers, T.mike

2 2

Re: [coreboot] Early debugging
by Gergely Kiss 19 Dec '17

19 Dec '17

I have made some progress since yesterday and now I have much better results: * Adding a setting to romstage to disable PCI-PCI bridge and enabling its pins as GPIO (that's what the datasheet says) made it possible to initialize the PCIe bridge @00:02.1. * Adding the base address 0x0 to unused resources helped silenting resource allocation errors reported, no side effects so far * Now that the PCIe bridge is properly initialized, I have a fully working system! Ubuntu 16.04 boots up and runs absolutely error-free and stable, even the suspend functionality works as expected. * Adding the option HAVE_CMOS_DEFAULT to the board's Kconfig file helped to make get_option() working as expected The only major issue left is the unstable operation of the USB keyboard with SeaBIOS. I have found no build parameters to fine tune keyboard-related settings like timeouts so I guess I'll have to create a patch to get this fixed. Any ideas are welcome on how to fix this. Thanks, Gergely On 18 December 2017 at 15:32, Gergely Kiss <mail.gery(a)gmail.com> wrote: > Hi, > > thanks for all the advice, so far! > > I've made a lot of progress here: after configuring all the low-level > registers (drive strength control, oscillator clock control, SIO GPIO/EC > registers) as per the vendor BIOS, coreboot finally started to boot up! > > Here's what's working so far: > > * Serial console > * GPIO & EC configuration > * Loading the VGA BIOS blob through SeaBIOS - I have text mode console > output through the D-SUB interface (other outputs need to be tested) > * Low level CPU and RAM initialization works perfectly. I have run one > pass of memtest for an hour, it could read the SPD chip and the test > completed without errors > * Coreboot boots up somewhat fine. It shows some resource allocation > issues but still, the boot process reaches to payload execution phase. > SeaBIOS, nvramcui & memtest payloads can be booted without any issues. > * Starting a bootloader through SeaBIOS works - tested with ISOLINUX & > Windows bootloader, so far > > Some problems I'm facing: > > * USB keyboard support is quite unstable with SeaBIOS, most of the time > the keyboard is not detected (it works about once every five-six boots), > regardless of what other USB devices are connected to the board > * The PCIe Bridge interface of the northbridge (@00:02.1) cannot be > configured for some reason. I can see Coreboot correctly identifies and > configures the device as a bridge but sending cmd 07 (not sure what that > means) to the device completely halts the system. Disabling the device in > devicetree makes it possible to avoid the lockup but I think I should not > let the device unconfigured. > * Booting up an OS does not work, yet, both Linux and Windows halts while > loading. This is most likely due to some resource allocation or IRQ routing > issue (I'll need to take a look at boot logs to see what's happening) > * TianoCore does not boot, it halts the system with a "division by zero" > exception displayed on the serial console. I guess it won't be easy to > debug this one so it is kind of low priority as of now. > > The questions I have: > > * How could I fix the USB keyboard issues with SeaBIOS? Is there some > timeout value I could raise to have more stable support for the keyboard? I > have tried disabling OHCI & XHCI support in SeaBIOS but that did not help. > * I can see a few resources allocation errors on the console output. For > some of these errors, the missing resources are actually unused by the > board (eg. the secondary & tertiary base address for the environment > controller). Shall I allocate the I/O address 0x0 to such devices or simply > ignore the errors? > * For the SATA controller, coreboot reports that there are 4 memory > address spaces that are not being allocated. Checking the devicetree of > other similar boards, I can see these resources are not allocated there, > either. Is it safe to ignore this error? > * Any ideas how to debug the lockup caused by the PCIe Bridge device > configuration? What does "cmd 07" mean? > * I'd like to read some settings from the CMOS memory both in romstage & > ramstage. What's the correct way to do so? Using get_option() seems not to > work at all while using read_option_lowlevel() returns a warning that I > should use get_option() in non-ROMCC stages. Is there some better way to > store user-configurable HW settings? nvramcui looks to be a "user-friendly" > tool to configure NVRAM settings, is there a similar user interface > available for CBFS, too? > > Thanks & Regards, > Gergely > > On 4 December 2017 at 18:49, ron minnich <rminnich(a)gmail.com> wrote: > >> don't forget, you can write code that runs in user mode and drives the >> superio. >> >> This is a handy way to test superio chips you're not sure about. >> >> use iopl(3) to enable arbitrary Io port access, then inb/outb to try to >> get some idea what's going on. >> >> This is obviously a little limited, since the firmware has already done >> lots of setup, but I've been able to learn things using this technique. >> >> ron >> >> On Mon, Dec 4, 2017 at 9:43 AM Kyösti Mälkki <kyosti.malkki(a)gmail.com> >> wrote: >> >>> On Mon, Dec 4, 2017 at 2:44 PM, Gergely Kiss <mail.gery(a)gmail.com> >>> wrote: >>> > Hi, >>> > >>> > I'm working on porting Coreboot to the ASUS AM1I-A motherboard and I'm >>> a bit >>> > stuck. >>> > >>> > I could successfully build Coreboot but after flashing the ROM, my >>> board >>> > looks to be bricked... >>> > >>> > Once powering on the board, the CPU fan spins up but then nothing >>> happens, I >>> > can't see any output on the serial console (the connection was tested >>> prior >>> > to flashing by running a getty on the COM port and it was working >>> fine). >>> > >>> >>> Common errors: Forgetting to use correct super-IO config base address >>> (0x2e vs 0x4e) and not providing 48MHz reference clock for the uart >>> baudrate divisor. AMD hardware often uses configurable GPIO pins for >>> this purpose, the code copied from biostar/am1ml may not be right for >>> asus/am1l-a. >>> >>> You can dump those GPIO configurations eg. with iotools or even dd >>> from /dev/mem. Related datasheets for the Kabini family should be >>> available without NDAs. >>> >>> > The board is not fried as I can load back the vendor firmware and it >>> boots >>> > up absolutely fine. >>> > >>> > I'd like to find out why Coreboot would not start but don't know what >>> tool >>> > would be the most suitable for debugging. >>> > >>> > The chipset and the CPU is already supported by Coreboot but the >>> SuperIO >>> > chip is not. It looks to me the serial interfaces of ITE chips work >>> the same >>> > for all models so I believe using the common code for ITE SIO chips >>> should >>> > work but I'm unsure (no datasheet available). >>> >>> AM1 socket support is a hack anyways, grep for >>> FORCE_AM1_SOCKET_SUPPORT. Your mileage may vary. >>> >>> It's not uncommon that PNP LDNs for the UARTs change within one vendor. >>> Did you run util/superiotool and dump SIO settings from vendor boot? >>> >>> > >>> > Shall I use a PCIe serial interface card or rather try EHCI debugging? >>> I'm >>> > afraid in case the boot process halts at some early stage (like before >>> > romstage) then I won't see any useful output using any of those. >>> > >>> >>> EHCI debug should be fine nowadays with AGESA, still not my first >>> choice here for you. >>> PCIe serial cards are untested, probably do not work early enough to >>> be useful for you. >>> Traditional serial port debug will also be silent before romstage... >>> >>> > Using a POST card would be a better approach I think but my board has a >>> > single PCIe 4x slot which seems to be unsupported by POST cards I >>> could find >>> > on the web (except one from a Chinese vendor but it costs about $1k >>> which is >>> > way too expensive). >>> >>> Those mini-PCI-e POST cards with 7-seg displays are about 4 USD and >>> your mainboard TPM connector seems to carry the required LPC signals. >>> Remember to enable and route POSTs to LPC (kconfig POST_DEVICE_LPC). >>> >>> > >>> > Here's my WIP code for reference: >>> > >>> > https://github.com/kissg1988/coreboot/tree/master/src/mainbo >>> ard/asus/am1i-a >>> > >>> > Any idea how to proceed? >>> > >>> >>> Get one of those POST cards, try to show vendor/device ID registers >>> from superio on the 7-seg display. >>> >>> > Thanks, >>> > Gergely >>> > >>> > >>> >>> HTH, >>> Kyösti >>> >>> > -- >>> > 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 >> >> >

1 0

Re: [coreboot] Coreboot Purism BIOS is free? open?
by Youness Alaoui 18 Dec '17

18 Dec '17

Hi Dame, The coreboot on Purism machines is indeed open and available, and it is all merged into upstream coreboot, so there is no specific repository for it other than the coreboot repository (the code is in src/mainboard/purism/ subdirectory). Here is the build script we use to build coreboot for our machines, from scratch : https://forums.puri.sm/t/building-coreboot-from-source-official-script/1264 I haven't updated the build script in a while, so it's actually building from here : https://code.puri.sm/kakaroto/coreboot.git but those commits were merged upstream and the upstream coreboot repository is all you need now. Note that to disable the ME, we need to use the '-S -e MFS' option to me_cleaner (the script also uses my own repository for me_cleaner, but my patches to me_cleaner were also merged upstream, so you can just use the upstream repository for me_cleaner. See my pull request here : https://github.com/corna/me_cleaner/pull/70) . You can read more about the efforts to disable the ME and the need for the -e option by reading my blog post here : https://puri.sm/posts/deep-dive-into-intel-me-disablement/ You said you want to implement coreboot for some 7th and 8th generation Intel computers. Then you'd probably also be interested in the blog posts I wrote about the porting experience. You can find all my posts on the right sidebar of our coreboot timeline page here : https://puri.sm/coreboot/timeline/ If you still have any questions, feel free to ask. As for Taiidan's response, I think Matt's response to it is pretty good already, and I'm tired of seeing Taiidan jumping at the chance to talk against Purism every chance he gets, but I won't rant about that today, I will only add this to the discussion : * The original question was on whether our coreboot port was available or not because the OP wanted to know how we disable the ME, you completely missed the question and decided to give advice on what device to buy instead... * You seem to think that the purism laptops are selling at a premium because it comes with coreboot? I'm pretty sure that the Cost/MSRP margin is the same or lower than from other laptop manufacturers, the "premium" you'd pay is because of the low volume of machines we are making, Dell/Lenovo can of course sell for lower prices because they get economy of scale, which we don't. It's not because we are increasing our revenue and using coreboot as an excuse to do it. * You said "they are charging for a whitebox re-brand.", that's actually a completely false statement, the motherboard is our own and it is designed to avoid having any firmware-based hardware so a binary-blob-free linux distribution can run on it. It is not a whitebox re-brand. If it was a whitebox re-brand, then yeah, we'd be selling for a lot lower price considering we'd be able to also take advantage of the economies of scale. * You are encouraging the purchase of lenovo machines, but as far as I know, lenovo is not actively working on reverse enginering the FSP. Also, the only reason that Lenovo can have a libreboot running on it is because the community did the port, not because the company itself is working towards freeing it or investing anything to provide more freedom to users. So yeah, sure, you could say "don't pay a 30$ premium for coreboot, buy a lenovo and do the port yourself" (assuming you know how to do the port, or you buy one that is already ported) , but you might as well say "don't pay a 30$ premium for coreboot, buy a lenovo, do the port yourself, then reverse engineer the FSP yourself while you're at it" and it would be more accurate. And that's of course ignoring the question of the harware kill switches, the fact that you can't compare a 200$ refurbished laptop from 6 years ago with a higher priced laptop from today, or that lenovo won't answer you if you ask tech support questions on coreboot or linux, etc... * We worked on disabling the ME on the purism laptops. Yes, the lion's share of the work was done by others (Corna for me_cleaner and Positive Technologies for the HAP bit), but not only did it require a significant amount of work from our side as well, to test, validate and package the ME disablement work (see above blog post link), but we are the first manufacturer to offer it standard and without us doing it, it could be argued whether or not this differentiation would have convinced System76 and Dell to also pursue offering machines with the ME disabled. So, encouraging those who are trying to pioneer the work might actually help the entire community. Do you think it might convince Intel to offer ME-less designs if they see half the manufacturers starting to ship unofficially-disabled ME machines ? Maybe, maybe not, but at least someone is trying to move things along instead of only complaining about the status of things. I could go on, but I think that's enough. Hopefully, this helps clarify the situation. Thanks, Youness. On Mon, Dec 18, 2017 at 4:07 AM, Dame Más <damemasporfavor(a)gmail.com> wrote: > Hello, > I understand. > I want implement Coreboot for current 7th and 8th generation Intel > computers. > And if the Pursism BIOS was opensource, I could work with it as a base. > However I can not find the source code to work with him. > I like GNU/Linux and the opensource because among all we do it better, but > if the code is not liberated, I can not speak well of Purism. > > 2017-12-18 6:01 GMT+01:00 Matt DeVillier <matt.devillier(a)gmail.com>: >> >> On Sun, Dec 17, 2017 at 6:58 PM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: >>> >>> On 12/17/2017 05:06 PM, Dame Más wrote: >>> >>>> Hi, >>>> The Coreboot BIOS of Purism 13 is open? >>> >>> No it isn't, while they do use coreboot the silicon init process is >>> entirely blobbed. >>> >>> Technical merits - is it better than an off the shelf dell laptop? Of >>> course, but not better enough to justify even a $30 premium let alone the >>> thousands they are charging for a whitebox re-brand. >>> It removes the brander (ex: dell) from the firmware trust equation but >>> intel still remains and so does ME. >> >> >> That's a pretty absurd exaggeration. Purism laptops certainly sell at a >> premium relative to a Dell (eg) with similar CPU/RAM/SSD, but they don't >> sell anywhere near the same volume, so their costs are higher. They also >> feature hardware kill switches for wifi/BT and mic/webcam, ship with a >> blob-free Debian-based distro, and use coreboot with a disable/neutered ME. >> Whether or not you consider those qualities, and supporting a startup >> working towards increasing owner control on modern hardware, to justify the >> price premium is certainly a valid point of discussion. >> >>> >>> >>> If I was you I would purchase a different coreboot compatible laptop then >>> compile and install coreboot while running me_cleaner yourself - this will >>> provide a better result for a lot less money as these following laptops >>> feature open source silicon init and in the case of the intel models are >>> pre-skylake so more of ME can be "cleaned". >>> >>> >>> One of these laptops is $200 max for one in good condition, vs thousands >>> for a Purism 13 - with the cash you save you can also buy a KCMA-D8 gaming >>> computer for libre gaming in a VM or otherwise. >> >> >> "better" certainly depends on how one ranks the various qualities of a >> given device. If owner-controller trumps all other considerations, then >> certainly there are "better" options, but you're not going to find anything >> for $200 that is anywhere close in terms of weight, battery life, screen >> quality, or using a modern SoC -- that's the tradeoff, and again something >> that's worth discussion, but framing it in the context of paying "thousands" >> for a Purism device vs $200 for something of equal/better capability is >> dishonest and does a disservice to the entire community IMO. > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Disabling Intel ME 11 via undocumented mode
by Felix Held 18 Dec '17

18 Dec '17

> And so far, nobody was able to crack Huffman, thus to have ability to > reverse-engineer plain kernel executable. Not true. See http://blog.ptsecurity.com/2017/12/huffman-tables-intel-me.html , https://github.com/ptresearch/unME11 and https://github.com/IllegalArgument/Huffman11 Regards Felix

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
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