Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

Zoran, read this : https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/ It might help you understand what that IFD and 0x5aa5f00f is (little endian makes it 0x0FF0A55A) I had the same confusion when I started, and when I figured things out, I wrote that blog post that explained the

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

t least SBIOS and descriptor.bin from real (UEFI) > BIOS, and put, where? > > And then, to add to the Coreboot image. Using make menuconfig. Where and > how? > > (Courtesy Aaron Durbin): http://elinux.org/Minnowboard:MinnowMaxCoreboot# > TXE_and_SPI_descriptor > > Thank you all

Re: [coreboot] Intel ME The Way of the Static Analysis

Thanks for the links. This is the article that I had seen : http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-analysis.html On Tue, Apr 25, 2017 at 10:38 AM, Shawn wrote: > slide: > https://www.troopers.de/downloads/troopers17/TR17_ME11_Static.pdf > > video: >

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

Looks like I failed at answering Taiidan without generating a flame war. Sorry if anyone got offended, that wasn't my aim. To answer the various questions that were thrown, here's what I think : Taiidan, you ask why Purism doesn't just create laptops using FX2 or ARM or whatever... Well, because

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

On Mon, May 1, 2017 at 7:22 PM, taii...@gmx.com wrote: > On 05/01/2017 06:44 PM, ron minnich wrote: > > On Mon, May 1, 2017 at 1:17 PM Rene Shuster >> wrote: >> >> Yes Puri.sm has been debunked. >>> >>> I disagree. I've seen the systems. From what I

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

nic...@gmx.de> wrote: > On 03.05.2017 01:39, Youness Alaoui wrote: > > to answer Nico's other post: > > I'm quite surprised and disappointed by your answer. You have every right > > to say that you are disappointed or distrusting Purism due to past > actions, &

Re: [coreboot] Will we maintain Skylake/FSP1.1?

I thought FSP 1.1 was for skylake and FSP 2.0 for Kabylake, I didn't realize 2.0 would be compatible with skylake too. Does this mean a skylake port could use fsp 1.1 or 2.0 ? In that case, is the 2.0 version better maintained, more stable, easier to integrate, etc.. or are both 1.1 and 2.0

[coreboot] SPI Flash debug console

Hi everyone, I mentioned this during my presentation at the coreboot conference last week, and I was waiting for it to be merged before I announced it on the mailing list. For those of you working on recent hardware (this was tested on skylake only, for broadwell to work, we need to add the spi

Re: [coreboot] VGA rom doesn't work

Congratulations on getting the ME working again. Your VGA device is 8086,1616, so that's what you need to set. The 8086,0406 is probably just the default one in coreboot, but you still have to configure it. In 'make menuconfig', go to Devices menu and set the "VGA Device ID" to "8086,1616", then

[coreboot] GPIO PADRSTCFG conflict in datasheet

Hi, I'm working on a skylake port and I've noticed something with the PADRSTCFG field of the GPIO Pad configuration. If you look at the 100-series datasheet volume 2 ( https://www-ssl.intel.com/content/www/us/en/chipsets/100-series-chipset-datasheet-vol-2.html). The Pad configuration DW0 for

Re: [coreboot] Denver conference

If you registered for the conference, and didn't receive the invoice to pay the conference attendance fees, then let Martin know that you didn't receive the invoice. If you received it, then pay it and that's it. On Thu, Jun 1, 2017 at 2:35 PM, Zoran Stojsavljevic

Re: [coreboot] Denver conference

boot list? ;-) > > Zoran > > On Thu, Jun 1, 2017 at 9:31 PM, Youness Alaoui > <kakar...@kakaroto.homelinux.net> wrote: >> >> If you registered for the conference, and didn't receive the invoice >> to pay the conference attendance fees, then let Martin know that

Re: [coreboot] Denver conference

wrote: > On Thu, Jun 1, 2017 at 2:46 PM, Youness Alaoui > <kakar...@kakaroto.homelinux.net> wrote: >> >> Then I suppose once they arrive at the conference registration booth >> to get their lanyard, they'll be told hat they haven't paid yet and >> that

[coreboot] PCIe Role-based error reporting

Hi, I'm looking at the src/device/pciexp_device.c file trying to understand what it does and I've noticed this in pciexp_enable_aspm : /* Enable ASPM role based error reporting. */ devcap = pci_read_config32(endp, endp_cap + PCI_EXP_DEVCAP); devcap |= PCI_EXP_DEVCAP_RBER; pci_write_config32(endp,

Re: [coreboot] GPIO PADRSTCFG conflict in datasheet

ues for RSMRST depending on whether it's GPP or GPD, so I vote for changing the define in coreboot so it stops being confusing for those who want to use RSMRST. I'll send a patch shortly to do it as I suggested in my previous email, unless someone else has a better idea. Thanks, Youness. On Thu, May

Re: [coreboot] SPI Flash debug console on H8SCM

Hi Fabian, It was ported to older intel architectures by Nicola Corna here : https://review.coreboot.org/#/c/21107/ I don't know what would need to be done to port it to work with amd, but in theory, all it needs is for the chipset to support SPI operations. If it can read and write to the spi

Re: [coreboot] greetings and laptop questions

> While I understand your frustration, and agree with the general thrust > of your email, and disregarding the "10 years", the Samsung Chromebook > Plus (and many other devices of similar age) beg to differ. > There are devices from 2016 and 2017 shipping with coreboot and no CPU > level blobs in

Re: [coreboot] greetings and laptop questions

On Sun, Oct 8, 2017 at 6:15 PM, taii...@gmx.com wrote: > >> >> (I also am looking at system76 and Purism but I am bit leery of spending a >> lot with a small / new company - comments appreciated) > > Purism dishonestly markets their products - while they claim that their >

Re: [coreboot] Coreboot Purism BIOS is free? open?

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

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

ear...@raptorengineering.com> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Thank you for the detailed response; I figured there had to be some > basic miscommunication somewhere. :-) So I assume we now agree that the > ME on Sylake + is not disabled, merely limited? &

Re: [coreboot] Black screen during SeaBIOS boot

Try a 'cbmem -t' to see how long coreboot itself took to boot. There might be some delay somewhere causing it to take longer to boot (current system I'm on, it takes 8 seconds, and on other systems I saw it take 15 seconds, because it waits for the ME to respond until it times out) so it might not

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

s) the kernel loads the BUP, and the HAP bit only disables > the normal userspace processes [1]. > > What proof do you have that the kernel itself is halted? > > [1] http://blog.ptsecurity.com/2017/08/disabling-intel-me.html > > On 12/13/2017 11:34 AM, Youness Alaoui wrote

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

> I guess I still disagree with the use of the word "disabled". If the ME > wasn't required for boot, and was actually disabled within a few cycles > of its CPU starting, the remaining attack surface simply wouldn't exist. > This is not what happens though, and AFAIK even the ME kernel continues

Re: [coreboot] Coreboot Purism BIOS is free? open?

On Tue, Dec 19, 2017 at 2:07 PM, Timothy Pearson wrote: > -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

Re: [coreboot] What’s the release plan for coreboot 4.7?

Hi, What happened with the plan for the 4.7 release? I thought it was supposed to be out at the end of October, now we're approaching the end of November. Was it forgotten, delayed or cancelled ? If delayed, what's the blocking issue ? Thanks, Youness. On Wed, Oct 4, 2017 at 11:24 AM, Martin

[coreboot] FSP 2.0 headers in coreboot

Hi, I've just pushed a commit for review on gerrit (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to open the discussion here on whether the public coreboot code should have the FSP headers that match the public FSP headers or if they should match the 'google fsp' headers. My

Re: [coreboot] FSP 2.0 headers in coreboot

Sorry for being late to answer to my own thread (busy busy busy). A few notes : The initial check-in of the kabylake FSP was uploaded with a BSD license : https://github.com/IntelFsp/FSP/tree/d88078a708e768c7b6ee5cbc996299d303c3c702/KabylakeFspBinPkg Later commits added Intel's Restricted Use

Re: [coreboot] FSP 2.0 headers in coreboot

I feel like this discussion is getting slightly out of hand, so let's try to regroup a bit and move the discussion back to the original topic : how to handle the FSP headers in coreboot. I fully understand and agree with Nico's frustration about the blobs situation and I think that's a bigger

Re: [coreboot] FSP 2.0 headers in coreboot

On Fri, May 18, 2018 at 2:59 PM, Nico Huber wrote: > > I have to admit, I don't like your patch. While it gets the job done, > it brings `MemInfoHob.h` and `FspsUpd.h` out of sync, so the state in > coreboot as a whole would match neither version. > Good point. It is a

Re: [coreboot] Exception on Skylake after enabling ACPI timer emulation

Hi Piotr, The Librems use the FSP 2.0 for SKL because I was told (I can't remember by who, but I think it was on coreboot IRC channel) that the FSP 2.0 works for both Skylake and Kabylake and that FSP 2.0 was better supported within coreboot than FSP 1.1. We had the Librems use FSP 1.1 before,

Re: [coreboot] Exception on Skylake after enabling ACPI timer emulation

et so it's at that address, and the len has to match (or be superior) to the ucode file size. I hope that helps, Youness. On Sun, May 20, 2018 at 7:25 PM, Piotr Król <piotr.k...@3mdeb.com> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > > On 05/18/2018 07:53 PM,

Re: [coreboot] Porting coreboot to new board

Hi, I suggest you read the wiki : https://www.coreboot.org/Developer_Manual and https://www.coreboot.org/Motherboard_Porting_Guide I would also suggest maybe (optional) that you read my blog posts about my own experience porting coreboot to a new motherboard :

Re: [coreboot] Porting coreboot to new board

ard ? > I think there are no "Intel® XEON® Processor E3-1505M v5" boards in last > version of coreboot. > Am I right ? > > Best regards, > Zvika > > On Tue, May 29, 2018 at 9:15 PM Youness Alaoui > wrote: >> >> Hi, >> >> I suggest y

Re: [coreboot] Coreboot Purism BIOS is free? open?

On Tue, Dec 19, 2017 at 8:04 PM, taii...@gmx.com <taii...@gmx.com> wrote: > On 12/18/2017 01:59 PM, Youness Alaoui wrote: > >> 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 >

Re: [coreboot] Coreboot Purism BIOS is free? open?

oncerns, and we have > experience with truly blob-free, powerful hardware -- combining those > two could yield an interesting machine... > > On 12/19/2017 02:41 PM, Youness Alaoui wrote: >> On Tue, Dec 19, 2017 at 2:07 PM, Timothy Pearson >> <tpear...@raptorengineeri

Re: [coreboot] Coreboot Purism BIOS is free? open?

On Sat, Dec 23, 2017 at 12:28 AM, Zoran Stojsavljevic wrote: > Hello Youness, > > With all due respect, you write too long emails, trying to defend > Purism. Lot of yours argument I do not buy. > Some of them I do. > I know I write too long emails, a long time ago I

Re: [coreboot] Coreboot Purism BIOS is free? open?

On Sat, Dec 23, 2017 at 11:32 PM, taii...@gmx.com wrote: > On 12/23/2017 07:16 PM, Todd Weaver wrote: > >> Intel did not mislead, we told them, and continue to, that we _want_ an >> ME-less design (which is their term for what we asked for). And as we >> grow our leverage will

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

g (or AMI is doing right.. my guess is that it's probably something with the EC ACPI code), we'd have to figure that out first in order to get the read/write support. > > Latest status update for Origami-EC firmware: > https://www.mail-archive.com/coreboot@coreboot.org/msg50646.

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

Hi Marty, Unfortunately, the EC firmware on the Librems is not open and we have someone working on that aspect, but with everything we have to handle, I think it's only being done part time. We found something similar to you with the private submodule for the PS/2 module on the OLPC code. More

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

/O on the device via UART. Also, > note that the emulator can now emulate a virtual console so it's > already possible to build and interract with the firmware! > That's some really great news. A dev board will definitely be useful for testing/debugging/developing Origami-EC! > Cheers, > >

Re: [coreboot] Kaby Lake FSP

y, I would expect the > frequency of FSP releases to lengthen as a platform ages. > > Thanks, > Nate > > -Original Message- > From: Youness Alaoui [mailto:kakar...@kakaroto.homelinux.net] > Sent: Monday, July 16, 2018 12:29 PM > To: Desimone, Nathaniel L

Re: [coreboot] Using linux as payload

Hi, I might not be the best one to answer your question, but here are my thoughts : - the "unknown type 'payload'" error is probably because cbfs changed the type name from "payload' to "simple elf" since you can add elfs in there that are not actual 'payloads'. I think though that it

Re: [coreboot] Intel ME what is it? And when did this dangerous thing get installed?

I think there's a good explanation of it in the FAQ of the libreboot project here : https://libreboot.org/faq.html#intelme If there are more specific questions that you have, ask them and I might be able to answer them! On Wed, Aug 29, 2018 at 2:36 AM Gregg Levine wrote: > > Hello! > Would one

Re: [coreboot] Kaby Lake FSP

Hi Nate, Thanks a lot for listening to our request and taking care of this! I'm happy to see the binaries finally updated and the FSP headers in coreboot having a matching publicly available binary to use. You've only mentioned Kabylake in your email, is it safe to assume that you'll use these

Re: [coreboot] T450S + Coreboot

because it's younger" nor will it be based on "for some unknown reason, AMD will be fine with us reverse engineering it". Besides, my understanding is that coreboot does not support ryzen CPUs, so a huge amount of work would be required if we went that way, no ? > Best r

Re: [coreboot] T450S + Coreboot

for "Youness" to see my blog posts in chronological order on the right side bar. Good luck with your project! > Make It So, > Brian Herman > > > > > > > > > > > > So you have made it to the end.. > Thanks for reading! > > On Wed, Aug 29

Re: [coreboot] T450S + Coreboot

On Sat, Sep 8, 2018 at 2:31 PM Peter Stuge wrote: > > Youness Alaoui wrote: > > So, back to the ME, we know exactly what it does, it's all extremely > > well documented and explained > > I disagree with this. > > It is absolutely true that *some* of what the ME does

Re: [coreboot] T450S + Coreboot

Wow, Mike, seriously, I am going to side 100% with Nico, you are spreading FUD, making your own personal opinions (which are themselves derived from other people's FUD) and stating them as the universal law. The ME is not known to be a backdoor. It doesn't mean that it's not a backdoor, it simply

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

I set that, I was able to access Index I/O on my coreboot-ed machine, and that opens up the software-based flashing support. On Mon, Mar 5, 2018 at 5:34 PM, Youness Alaoui <kakar...@kakaroto.homelinux.net> wrote: > Thanks for the advice Mike, but I think you misunderstood the issue. I

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski <cont...@paulk.fr> wrote: > Hi, > > Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit : >> > > Sure, you can trust hardware flashing more than software flashing, >> > > but >> > &

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

tp://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate ; > in short : use a keyboard flex cable to reach EC spi pins as well as > its' ground, and a test hook clip to easily get a ground of your > motherboard > > On Mon, Mar 5, 2018 at 11:00 PM, Youness Alaoui > <kakar...@kakaroto.h

Re: [coreboot] SPI controller and Lock bits

Thanks everyone for the responses. So far my understanding on the task at hand is : - Add a CONFIG to decide if we set FLOCKDN or not (and one to decide if we lock it on the resume path?) - Remove the chipset_lockdown devicetree config and change the code to always assume it's LOCKDOWN_COREBOOT

Re: [coreboot] SPI controller and Lock bits

Hi Everyone! Sorry for the 2 weeks late reply, I've read your responses, but I've been too busy and dealing with stuff and haven't had/taken the time to reply but your input was very much appreciated and not ignored! One thing to note is that this week will be my last week at Purism as I'm going

Re: [coreboot] SPI controller and Lock bits

ks! I had a lot of fun, and this community is really great! I hope we still get to work together again in the future and cross paths! > On Tue, Oct 16, 2018 at 7:45 PM Sam Kuper wrote: >> >> Hi Youness, >> >> On 15/10/2018, Youness Alaoui wrote: >> > One t

Re: [coreboot] SPI controller and Lock bits

On Thu, Sep 27, 2018 at 10:18 PM Sam Kuper wrote: > > On 28/09/2018, Peter Stuge wrote: > > Youness Alaoui wrote: > >> avoid any malware writing to the flash > > > > Just disallow flash writes by the platform. Allow flash writes only > > by dedicated hard

Re: [coreboot] SPI controller and Lock bits

Oh boy, lots of emails to answer! So first, thanks for everyone who shared their input, I very much appreciate it. > I think you can decide what hardware your products include, right? I meant dedicated hardware on the mainboard. Yes, but I'm currently looking for a solution to existing hardware,

Re: [coreboot] SPI controller and Lock bits

On Sat, Sep 29, 2018 at 12:21 PM Nico Huber wrote: > > On 9/27/18 10:29 PM, Youness Alaoui wrote: > > Thanks everyone for the responses. > > So far my understanding on the task at hand is : > > - Add a CONFIG to decide if we set FLOCKDN or not (and one to decide > &g

[coreboot] SPI controller and Lock bits

Hi, I'm trying to add a way to lock the SPI flash to be read-only via software *after* coreboot boots. The scenario is basically with using Heads, you could authenticate to it (with a yubikey/nitrokey/librem key) then be able to flash a new rom (update your BIOS), but once you boot an OS, Heads