Re: [coreboot] [skylake] Can not turn monitor on

On 10/5/18 4:43 PM, Zheng Bao wrote: > I transfer all the GPIO setting to my code. What do you mean? did you have wrong GPIO settings before? > After this, the linux can turn the monitor on, but in BIOS stage, > monitor can not be turn on. > Is that the way it is? Can BIOS turn the display on?

Re: [coreboot] SPI controller and Lock bits

Hi, Am 05.10.18 um 08:39 schrieb Martin Kepplinger: > is there already a gerrit change you are working on this? Do plan to > support / test > a X230 flash chip's lock bits? > * MX25L6406E/MX25L6408E > * EN25QH64 > * MX25L3206E not about this request in particular but such flash-chip features in

Re: [coreboot] [skylake] Can not turn monitor on

Hi Zheng, On 10/3/18 4:06 PM, Zheng Bao wrote: > I tried both the vgabios extracted in linux /sys/ and seavgabios. don't know why GOP+SeaVGABIOS fails but an Intel VBIOS extracted from memory never worked for me. You might have more luck by extracting it from a firmware image with uefitool. >

Re: [coreboot] USB 2.0 EHCI debug dongle doesn't print logs (at Lenovo G505S)

On 9/30/18 5:55 PM, Ivan Ivanov wrote: > Thank you very much for your help, Nico! Enabling CONFIG_CONSOLE_USB > indeed got FT232H working! :-) I wonder why CONFIG_CONSOLE_USB isn't > enabled by default if CONFIG_USBDEBUG is enabled... Maybe this default > behaviour should be changed? Yes, I think

Re: [coreboot] SPI controller and Lock bits

On 10/3/18 12:31 AM, Sam Kuper wrote: > On 02/10/2018, Nico Huber wrote: >> Am 02.10.18 um 13:48 schrieb Sam Kuper: >>> On 02/10/2018, Nico Huber wrote: >>>> You need to tamper more than just HEADS, otherwise the attestation of >>>> the firmware

Re: [coreboot] removing bounce buffers

On 10/2/18 10:16 PM, ron minnich wrote: > we are at long last removing bounce buffers from selfboot. > https://review.coreboot.org/c/coreboot/+/28647 > > This greatly simplifies the code and there are almost no platforms left > that need them. Here are the ones that seem to: > >

Re: [coreboot] SPI controller and Lock bits

Am 02.10.18 um 14:31 schrieb Martin Kepplinger: > Am 02.10.2018 13:51 schrieb Nico Huber: >> Am 02.10.18 um 13:01 schrieb Martin Kepplinger: >>> Am 26.09.2018 01:30 schrieb Youness Alaoui: >>>> Hi, >>>> >>>> I'm trying to add a way to lock

Re: [coreboot] SPI controller and Lock bits

Am 02.10.18 um 13:48 schrieb Sam Kuper: > On 02/10/2018, Nico Huber wrote: >> Am 02.10.18 um 11:53 schrieb Sam Kuper: >>> On 01/10/2018, Youness Alaoui wrote: >> tldr; whether the effort to disable write protection is reasonable >> or not depends on what you want

Re: [coreboot] SPI controller and Lock bits

Am 02.10.18 um 13:01 schrieb Martin Kepplinger: > Am 26.09.2018 01:30 schrieb Youness Alaoui: >> 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

Re: [coreboot] SPI controller and Lock bits

Am 02.10.18 um 11:53 schrieb Sam Kuper: > On 01/10/2018, Youness Alaoui wrote: >>> [...] Youness and others at Purism: if you are reading this, please do >>> spec a momentary switch to control flashing on future Librems. Your >>> security-conscious users will thank you for it. >> >> Yes, I

Re: [coreboot] SPI controller and Lock bits

Am 28.09.18 um 03:20 schrieb Prasun Gera: >> The problem is we want to allow users to update their flash and >> coreboot doesn't have a "flash update utility" integrated, so it has >> to happen in the payload, which is why coreboot needs to not lock >> anything then let the payload do the locking

Re: [coreboot] USB 2.0 EHCI debug dongle doesn't print logs (at Lenovo G505S)

Hi Ivan, On 9/28/18 11:50 PM, Ivan Ivanov wrote: > Thank you for spkmodem comments, now I'm trying out a more reliable > way - FT232H dongle - to extract the logs from AMD Lenovo G505S. I > plug it into the correct port - USB 2.0 at laptop's right side. > However it doesn't print anything except

Re: [coreboot] flashrom and 256 MiB S256FL256S

On 9/29/18 6:35 PM, Nico Huber wrote: > On 9/28/18 11:20 PM, ron minnich wrote: >> I spoke too soon. It just flat out does not work to have sf100 and 256Mbit >> part AFAICT > > Ah, crap. I just gave this another thought and now I'm convinced that it > can't wo

Re: [coreboot] flashrom and 256 MiB S256FL256S

On 9/28/18 11:20 PM, ron minnich wrote: > I spoke too soon. It just flat out does not work to have sf100 and 256Mbit > part AFAICT Ah, crap. I just gave this another thought and now I'm convinced that it can't work with the current code. dediprog_spi uses its own functions for read/write that

Re: [coreboot] flashrom and 256 MiB S256FL256S

On 9/28/18 1:16 AM, Peter Stuge wrote: > ron minnich wrote: >> yeah, also is there a programmer you recommend for 32MiB parts? > > I don't have a recommendation just yet, but a question: > > Speed aside, is single bit IO good enough for 32MiB, or is DIO/QIO required? SIO is generally enough.

Re: [coreboot] SPI controller and Lock bits

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 > if we lock it on the resume path?) Maybe no config at all, see discussion of PRR34_LOCKDN

Re: [coreboot] SPI controller and Lock bits

On 9/28/18 1:30 AM, 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 hardware (maybe ChromeEC?) which implements a simple and > efficient security protocol. It's not as easy

Re: [coreboot] SPI controller and Lock bits

On 9/28/18 4:18 AM, 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 hardware (maybe ChromeEC?) which implements a simple and >>

Re: [coreboot] SPI controller and Lock bits

On 9/27/18 6:24 PM, Lance Zhao wrote: > Okay, then I believe we should leave the decision on CONFIG instead of > force lockdown blindly. As of now, that's still optional I believe. AFAIK, EISS is not a configurable option in coreboot atm. And it shouldn't be, IMHO, as it encourages to weaken

Re: [coreboot] flashrom and 256 MiB S256FL256S

ers are faster (FT232H/ FT2232H/FT4232H), serprog programmers (some may not be too slow), Bus- Pirate rather slow too. Nico > > thanks > > ron > > On Thu, Sep 27, 2018 at 1:10 PM Nico Huber wrote: > >> Ah, dediprog... you happen to have the one programmer that is har

Re: [coreboot] flashrom and 256 MiB S256FL256S

Ah, dediprog... you happen to have the one programmer that is hard to support. On 9/27/18 9:49 PM, ron minnich wrote: > hmm, is this useful? > > Found Spansion flash chip "S25FL256S..0" (32768 kB, SPI) on dediprog. > Erasing and writing flash chip... 4-byte address requested but master can't

Re: [coreboot] flashrom and 256 MiB S256FL256S

Hi Ron, On 9/27/18 8:05 PM, ron minnich wrote: > sadly, they do not work ... what does work? does flashrom detect the chip reliably? What programmer do you use? what is your physical setup? If these patches don't work, I would expect that the failure is not about the flash chip model. Nico --

Re: [coreboot] SPI controller and Lock bits

Am 26.09.18 um 22:26 schrieb Lance Zhao: > I am reading the "flash security recommendation" from PCH BIOS writer > guide now, it did say strongly recommend to take those actions. The EISS > feature to ensure BIOS region can only get modfiyed from SMM. The EISS bit is a highly questionable

Re: [coreboot] how users can control additional features?

On 9/23/18 6:38 PM, Patrick Rudolph wrote: > On 2018-09-23 12:22 PM, Nico Huber wrote: >> Hi Lynxis, >> >> TLDR; I would prefer NVRAM settings and reading (but not writing) NVRAM >> from ASL code directly. >> >> On 9/15/18 10:05 PM, Alexander Couzens

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip

Hi Zvika, On 9/25/18 10:59 PM, Zvi Vered wrote: > Thank you very much for the detail information. > The output of ifdtool in layout.txt is: > :0fff fd > 0030:007f bios > 1000:002f me > > So the original bios size is 0x50 = 5MB > > You wrote: > if the size of the

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip

Hi, On 9/26/18 9:19 AM, Jose Trujillo via coreboot wrote: > No, don't change it, you change the size of coreboot only if during the > building process "make" complain that there is not enough space but in > your case your build was already successful leave it like that. this advice seems very

Re: [coreboot] SPI controller and Lock bits

Am 26.09.18 um 10:50 schrieb Patrick Rudolph: > Hi Youness, > On 2018-09-26 01:30 AM, Youness Alaoui wrote: >> 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

Re: [coreboot] SPI controller and Lock bits

Hi Youness, Am 26.09.18 um 01:30 schrieb Youness Alaoui: > There's a couple of things happening here : > First, the FLOCKDN bit is set which prevents us from enabling the > write protection. the BIOS Interface lock down is controlled by the > chipset_lockdown config variable, but the FLOCKDN is

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip

Hello Zvika, On 9/24/18 9:18 PM, Zvi Vered wrote: > I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: > > CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 > Northbridge: 8086:0f00 (Bay Trail) > Southbridge: 8086:0f1c (Bay Trail) > IGD: 8086:0f31

Re: [coreboot] compile coreboot for xeon 5570

Hello Zahra, On 9/24/18 2:51 PM, zahra rahimkhani wrote: > I am trying to use coreboot for a motherboard that have cpu of Xeon x5570. TLDR; it won't work. coreboot needs to be adapted to every mainboard, and, in this case, even to the processor and chipset. Without docu- mentation from Intel

Re: [coreboot] Flashing Coreboot on Lenovo G505s

On 9/23/18 7:26 PM, Matt B wrote: Speaking of microcode, I've seen on other threads that the microcode has to be manually updated for some boards, and for the g505s this is especially complicate with many manual steps. Can anyone provide a more explicit series of steps than the below? Is this

Re: [coreboot] how users can control additional features?

Hi Lynxis, TLDR; I would prefer NVRAM settings and reading (but not writing) NVRAM from ASL code directly. On 9/15/18 10:05 PM, Alexander Couzens wrote: I would like to merge https://review.coreboot.org/c/coreboot/+/12888 But how the user can control this feature (and all other "special

Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"

Hi Jose, On 20.09.2018 15:58, Jose Trujillo via coreboot wrote: > I will follow your advise of checking EC and about the base FW I am > using the original UEFI AMI FW but, if still doesn't boot I will replace > ME and descriptor as you suggested. Better don't. The Firmware Descriptor and ME are

Re: [coreboot] Coreboot for Apollolake

Hi Antony, On 20.09.2018 09:28, Antony AbeePrakash X V wrote: > Thanks for the response , we extracted the flash descriptor from the > BIOS Image using the ifdtool as below if you already have a working firmware combination for your board (I assume the BIOS Image you mention is one), I can only

Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"

Hi Jose, On 12.09.2018 15:12, Jose Trujillo via coreboot wrote: > To begin with the system didn't find memory attached... > but there is memory attached, SPD address mismatch? I will check. > > ...Timeout while sending command 0x0d to EC! I'm not sure what this is about. Did you try

Re: [coreboot] Intel G41 - Asrock G41M-GS: no coreboot screen output from Intel GPU on VGA

On 01.09.2018 23:13, h...@memeware.net wrote: > Cherry picking did not worked for me. I cloned coreboot today on an new > linux installation. The submodule pointer didn't change since June. Something must be wrong with your checkout. To be sure I just picked said commit on 718c79b: $ git log

Re: [coreboot] APIC and lspci

Hi Hilbert, On 03.09.2018 12:36, Hilbert Tu(杜睿哲_Pegatron) wrote: > I have a customized Intel Denverton-NS platform similar like Harcuvar > CRB. In dmesg, I can see following: > [ 10.973387] ACPI: PCI Interrupt Link [LNKA] (IRQs 6 7 10 *11 12 14 15) > [ 10.981587] ACPI: PCI Interrupt Link

Re: [coreboot] Lenovo X230 + 32GB RAM ?

Hi David, On 03.09.2018 19:13, David Potocnik wrote: > Coreboot, or perhaps rule it out completely? it's impossible, unless you want to heavily mod the mainboard. Ivy Bridge supports 4 ranks per channel, max 4GiB per rank. SO-DIMMs have only 2 ranks. So with 2 SO-DIMM slots, there are physical

Re: [coreboot] Porting Qotom Q355G4 SBC (similar to Librem 13)

Hi John, Am 29.08.18 um 04:02 schrieb John Keates: > Thank you for your reply! Sadly, Boot Guard is enabled in Verified Boot > mode. I’ll ask if Qotom can spin up a batch without any public key > burned into the CPU, or perhaps share the private key. (which is > obviously unlikely — but one can

Re: [coreboot] T450S + Coreboot

Hi Mike, On 30.08.2018 15:51, Mike Banon wrote: >> The fact that it's closed source and not user-controlled (Even if you had >> the sources, you can't modify them and update it to your custom ME >> version) is where the problem actually is. There *might* be a backdoor >> hidden somewhere in

Re: [coreboot] T450S + Coreboot

*sigh*, On 28.08.2018 22:00, Mike Banon wrote: > You are right, my choice of words has been far from ideal. I apologize > for that. However, to be confident that Intel ME is a backdoor > (personal opinion) - one does not have to be its' creator. sorry I meant the creator of us (God) not the ME.

Re: [coreboot] T450S + Coreboot

Hi Mike, you can be as much biased as you want, and you can express that here. I have no trouble with that. What I don't like is your choice of words. For instance with "Undoubtedly, Intel ME is a backdoor," you imply to know everybody's opinion on the matter. Because I don't think you are the

Re: [coreboot] T450S + Coreboot

Hi Mike, please don't spread FUD on this list. On 28.08.2018 09:54, Mike Banon wrote: > And even if there weren't any problem with Intel Boot Guard, its not > that easy to add a support for new board (impossible to do it over > weekends, especially for the newcomers). The T450s would probably

Re: [coreboot] Coffee Lake FSP Released

On 8/23/18 11:47 PM, Zimmer, Vincent wrote: We agree See https://github.com/IntelFsp/FSP/blob/master/FSP_License.pdf This is great news. Nate, Vincent thank you very much! IMHO, you two just doubled what Intel did for coreboot so far; in one day! This is the first time in five years that we

Re: [coreboot] USB cannot work

Hi Hilbert, On 8/24/18 4:22 AM, Hilbert Tu(杜睿哲_Pegatron) wrote: Do you know how to check USB2.0/USB3.0 in Grub2? I am trying to prove it. not sure. GRUB has an `lsmod` command, if that lists something with ehci or xhci, that might give a clue. Actually, I would just grep the source code. In

Re: [coreboot] Intel G41 - Asrock G41M-GS: no coreboot screen output from Intel GPU on VGA

Hello H42, there is an issue with upscaling VGA text mode on G4x that is about to be fixed [1]. Looking at your logs again, you are likely also affected (scaling 640x400 to 1920x1080). The fix is already merged to the lib- gfxinit repository, but the submodule pointer in coreboot is not updated

Re: [coreboot] USB cannot work

Hi Hilbert, Am 23.08.18 um 09:14 schrieb Hilbert Tu(杜睿哲_Pegatron): > Yes, you are right. So can I say Grub2’s driver has issues in supporting > Denverton xHCI controller? I just want a root cause to explain why USB > cannot work in this case. Thanks. I still believe that GRUB doesn't have an

Re: [coreboot] USB cannot work

Hi Hilbert, Am 22.08.18 um 03:24 schrieb Hilbert Tu(杜睿哲_Pegatron): > Maybe you are right. But as I know, CRB Harcuvar is one of supported > board of Coreboot and it includes xHCI controller and USB interfaces. Harcuvar is indeed supported by coreboot. But coreboot only initializes the hardware

Re: [coreboot] USB cannot work

Hello Hilbert, Am 21.08.18 um 12:09 schrieb Hilbert Tu(杜睿哲_Pegatron): > From BWG(BIOS Write Guide), there are two steps needed to be done for USB to > work: > > 1. Pre-Operating Software Initialization > > 2. EHCI Initialization for Pre-OS Software Usage > > Does anyone know where

Re: [coreboot] Intel G41 - Asrock G41M-GS: no coreboot screen output from Intel GPU on VGA

On 16.08.2018 12:27, h...@memeware.net wrote: > On 2018-08-15 21:22, Nico Huber wrote: >> Hi, >> >> On 14.08.2018 13:41, h...@memeware.net wrote: >>> So it seems to have detected that my screen is 1920*1080. GPU + screen >>> detection seems to be work

Re: [coreboot] Building an image a second/third/... time fails

On 16.08.2018 12:47, h...@memeware.net wrote: > I have not changed anything. I was able to reproduce that every single > time i tried. Ah, sorry I wasn't referring to the error but to your mail's subject. The "second/third/... time fails" (as opposed to the first time) because you changed

Re: [coreboot] Build fails on Thinkpad W520

Hi Andreas, On 16.08.2018 08:25, Andreas Restle wrote: > Building coreboot for Thinkpad W520 currently fails with the following > error: > > CC romstage/northbridge/intel/sandybridge/raminit_common.o > In file included from src/northbridge/intel/sandybridge/raminit_common.c:18: >

Re: [coreboot] Building an image a second/third/... time fails

On 14.08.2018 12:49, h...@memeware.net wrote: > I had build once a coreboot image for a Intel G41 board. Then i liked to > build for an other Intel G41 board. It looks like you either used an older IASL for this initial build or chose a different SeaBIOS version. Nico > I first removed the

Re: [coreboot] Intel G41 - Asrock G41M-GS: no coreboot screen output from Intel GPU on VGA

Hi, On 14.08.2018 13:41, h...@memeware.net wrote: > So it seems to have detected that my screen is 1920*1080. GPU + screen > detection seems to be working. But i dont get any coreboot output on the > screen. you can set CONFIG_DEBUG_ADA_CODE to enable verbose messages in libgfxinit. At least

Re: [coreboot] Build failure, build log dont link in a proper way

Hi, On 14.08.2018 12:08, h...@memeware.net wrote: > I cloned today the fresh code on a new machine. I first installed the > dependencies listed here https://www.coreboot.org/Build_HOWTO and then i > liked to build the whole build gcc for all platforms. I ran 'make > crossgcc CPUS=6' in the fresh

Re: [coreboot] Reducing the boot time

Hello Antony, On 11.08.2018 12:55, Antony AbeePrakash X V wrote: > Coreboot FSP Performance Data > ID: 950 - 951: 8118676370 - 2354813461 --> 4433ms (TS_FSP_MEMORY_INIT_START > - TS_FSP_MEMORY_INIT_END) > ID: 952 - 953: 10675414728 - 8905813067 --> 1361ms > (TS_FSP_TEMP_RAM_EXIT_START -

Re: [coreboot] Kaby Lake FSP

Hi, On 11.07.2018 18:18, Desimone, Nathaniel L wrote: > However, there is nothing in the license that prevents you from > providing links to github.com/IntelFsp. It might not be exactly what you > were hoping for but would adding a git submodule in coreboot blobs that > points to

Re: [coreboot] RV: Error booting with TPM enabled.

F01 code! Good luck! Nico > > ____ > De: Nico Huber > Enviado: viernes, 29 de junio de 2018 15:47:09 > Para: Jorge Fernandez Monteagudo; coreboot@coreboot.org; Zaolin > Asunto: Re: [coreboot] RV: Error booting with TPM enabled. > > On 29.06.2018 12:48, Jorge Fe

Re: [coreboot] RV: Error booting with TPM enabled.

On 29.06.2018 12:48, Jorge Fernandez Monteagudo wrote: > Ok, I think I've found the problem... If I force in > 'src/drivers/pc80/tpm/tis.c' > > the path value to "\\_SB_.PCI0.LIBR" it works! > > Now, I'll try to guess from where the "\_SB.\_SB.LIBR" current value comes > from... > but now it's

Re: [coreboot] Porting Kabylake laptop

On 27.06.2018 17:35, ron minnich wrote: > On Wed, Jun 27, 2018 at 8:18 AM Nico Huber wrote: >> What about PEI, is that manageable too? >> > > it's a blob. What can I say? We take that blob. It's manageable. If you > accept that you'll have to use a blob, my exper

Re: [coreboot] flashrom programmer

Hi Zvika, On 27.06.2018 05:04, Zvi Vered wrote: > How can I know what is the right flashrom programmer I should use ? for your case, `internal` is correct. > The vendor's programmer works without any external hardware. > When I tried: flashrom --programmer internal, I got: >

Re: [coreboot] Porting Kabylake laptop

Hi, On 27.06.2018 13:37, chrisglow...@tutanota.com wrote: > 26. Jun 2018 20:02 by rminn...@gmail.com : >> For a case like this, where your choice is between two binary blobs (FSP >> or UEFI) I would argue that linuxboot is a better way to go. Question is, what is this

Re: [coreboot] Porting Kabylake laptop

Hi Ron, On 27.06.2018 16:47, ron minnich wrote: > On Wed, Jun 27, 2018 at 4:37 AM wrote: > >> >> Doesn't linuxboot also require the FSP blob for memory and silicon >> initialization on any Intel board after Ivy Bridge? >> > No. On x86 we do assume UEFI, however. That's a safe assumption. From

Re: [coreboot] Porting Kabylake laptop

e dumped using acpidump Yes. > and then used in the ec.asl file? Not verbatim. For a fully working implementation you'll have to under- stand and reimplement it. This is usually the biggest part of a laptop port. Nico -- M. Sc. Nico Huber Senior Consultant SINA Software Development a

Re: [coreboot] Porting Kabylake laptop

Hi Chris, On 25.06.2018 16:50, chrisglow...@tutanota.com wrote: > I have a Kabylake laptop with a Sunrise Point chipset, that I want to > port to coreboot using the FSP blob. I have no coding skills, but can > follow the Librem build coreboot script and use code from ports using > FSP 2.0 (Librem

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

On 25.06.2018 09:55, Shawn wrote:> Hi Ron, > On Sun, Jun 24, 2018 at 12:55 AM, ron minnich wrote: >> On Wed, Jun 20, 2018 at 11:03 PM taii...@gmx.com wrote: >>> Whats the deal with SMM? What a shame they thought to add it. >> >> It's a huge disappointment. I made some effort a few years ago to

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

On 25.06.2018 01:55, Timothy Pearson wrote: > On 06/24/2018 06:41 PM, Timothy Pearson wrote: >> On 06/24/2018 06:35 PM, Nico Huber wrote: >>> On 24.06.2018 23:52, Timothy Pearson wrote: >>>> On 06/24/2018 03:43 PM, Nico Huber wrote: >>>>> On 24.06.2018

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

On 24.06.2018 23:52, Timothy Pearson wrote: > On 06/24/2018 03:43 PM, Nico Huber wrote: >> On 24.06.2018 21:37, taii...@gmx.com wrote: >>> On 06/24/2018 02:59 PM, ron minnich wrote: >>>> On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer >>>> >>&

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

On 24.06.2018 21:37, taii...@gmx.com wrote: > On 06/24/2018 02:59 PM, ron minnich wrote: >> On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer >> wrote: >> >>> >>> >>> "While we’d love to provide you with this information, we believe we >>> cannot. However, we can’t prevent anyone from

Re: [coreboot] RV: Error booting with TPM enabled.

On 23.06.2018 07:58, Jorge Fernandez Monteagudo wrote: >> I guess it's used, but you need an acpi name for all devices along the >> path. "LIBR" is the name for the LPC device, there should also be one >> for the PCI bus/domain. I would try `src/northbridge/amd/pi/00660F01/ >> northbridge.c`. > >

Re: [coreboot] Thinkpad SD card controller DMA

Hi Thomas, On 21.06.2018 22:33, Thomasheidler wrote: > Sounds like disabling the PCIe port of the device is the safest > solution. Will switching the value in the devicetree be enough or is > that too uncertain? I think, I already answered that but you lost the quote: >> If you want to be sure,

Re: [coreboot] RV: Error booting with TPM enabled.

Hello Jorge, On 22.06.2018 12:52, Jorge Fernandez Monteagudo wrote: > I've found the src/southbridge/amd/pi/hudson/lpc.c, the related to the AMD > Bettong demoboard, and > > 'lpc_acpi_name' and 'lpc_ops' are already defined... Maybe they are not > enabled or used? I guess it's used, but you

Re: [coreboot] What happened to the Option ROM options?

On 21.06.2018 23:09, taii...@gmx.com wrote: > On 06/21/2018 04:51 AM, Nico Huber wrote: >> On 21.06.2018 03:47, taii...@gmx.com wrote: >>> Ah oops overlooked this. >>> https://review.coreboot.org/#/c/coreboot/+/2531/ >>> >>> Paging ron minnich! It se

Re: [coreboot] Thinkpad SD card controller DMA

On 21.06.2018 13:20, Jose Trujillo via coreboot wrote: > If you don't enable a device in devicetree the initialization routine will > not be executed. Interpretation of the devicetree on/off values depends on the chipset code. And even if the chipset code disables (or doesn't enable) some-

Re: [coreboot] What happened to the Option ROM options?

On 21.06.2018 03:47, taii...@gmx.com wrote: > Ah oops overlooked this. > https://review.coreboot.org/#/c/coreboot/+/2531/ > > Paging ron minnich! It seems at the end of the comments various people > note the mistake however it never got fixed. There is no mistake here. The change was only a

Re: [coreboot] Bayley Bay FSP-based CRB

On 21.06.2018 02:34, Zvi Vered wrote: > In case of PCIe enumeration, the generation of PCIe (1,2,3) can be set> > Should vendor supply code for this ? or any other information ? PCIe configuration is SoC specific and should be done by FSP. However, I can't find any PCIe specific settings for the

Re: [coreboot] Bayley Bay FSP-based CRB

Hello Zvika, On 18.06.2018 05:24, Zvi Vered wrote: > 1. The size of CBFS is: 0x20. Is it a fix size or should I change it > according to my board (which is also bay trail) ? on Intel platforms, the SPI flash is shared with other chipset compo- nents. The CBFS_SIZE should be at most the size

Re: [coreboot] Porting coreboot to new board

Hello Zvika, On 31.05.2018 04:39, Zvi Vered wrote: > The links you provided: > https://www.coreboot.org/Motherboard_Porting_Guide > https://www.coreboot.org/Developer_Manual > > Does not mention Intel's FSP at all. there is few FSP documentation maintained by the coreboot community. But there

Re: [coreboot] Who is still using a 1980's tty for coreboot development?

On 29.05.2018 14:23, Patrick Georgi wrote: > Am Fr., 25. Mai 2018 um 18:40 Uhr schrieb Nico Huber : >> o Set a hard limit around 100 chars (96 would be a nice number). >> o If a line doesn't contain a string literal, recommend a >> visible width <= 72 chars. &

Re: [coreboot] Building coreboot for Apollo Lake: missing 'IFWI' region

Hello Hal, On 28.05.2018 08:06, Hal Martin wrote: > Name Offset Type Size Comp > ... > cpu_microcode_blob.bin 0x6f00 microcode 0 none The size looks troubling, I think you really need the correct microcode binary to get into

Re: [coreboot] Who is still using a 1980's tty for coreboot development?

On 25.05.2018 10:15, Patrick Georgi via coreboot wrote: > That is, who would unbearably suffer from 132 characters gper line of code? Humans. Code quality. Eyes get too tired too fast. The cost of our eyes' "carriage return" grows over-linear with the line length. Although, that's hard to

Re: [coreboot] Asus Vivobook 14 E406SA 1.0 - Intel ME

Hi permanentjpeg, On 23.05.2018 21:39, permanentj...@firemail.cc wrote: > On 2018-05-23 19:32, permanentj...@firemail.cc wrote: >> Hi, >> >> I recently acquired an Asus Vivobook E406SA 1.0, which I have been >> investigating to see if there is a possibility to port to coreboot. >> While doing

Re: [coreboot] Building coreboot for Apollo Lake: missing 'IFWI' region

Hi, On 19.05.2018 02:27, Julius Werner wrote: > Apollolake looks quite different, and I don't really know all the details, > but somehow the reset vector is interwoven with that IFWI thing near the > front of the ROM. You can see an example Chrome OS Apollolake FMAP in >

Re: [coreboot] FSP 2.0 headers in coreboot

On 18.05.2018 20:59, Nico Huber wrote: > Well, my vote, in order of preference: > > 1. Poke Intel. > 2. Get a verbatim copy of the GitHub headers in (in a way of effort for * least effort > the community). Maybe in a month from now? no matter the outcome >

Re: [coreboot] FSP 2.0 headers in coreboot

On 11.05.2018 21:18, Youness Alaoui wrote: > 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

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

Hello Piotr, On 17.05.2018 18:20, Banik, Subrata wrote: >>> FSP2.0, I'm following Librem Purism options since they seem to boot the >>> same SoC. They use KabyLake FSP obtained by get_blobss.sh [1], if you >>> think this is incorrect then I would like to know why, because it may >>> mean that

Re: [coreboot] Proposing a change to Coding Style

On 18.05.2018 14:54, Julien Viard de Galbert wrote: > I really like this proposal. And agree that this is error prone. I also like > the > } else { option. Just to make sure nobody gets this wrong: } else { on a single line is already mandated by our Coding Style. It's not an option

Re: [coreboot] Proposing a change to Coding Style

On 16.05.2018 17:15, Patrick Georgi via coreboot wrote: > Hi everybody, > > after just running into an issue on the EC code base, I hereby propose that > going forward, we should always wrap conditional blocks in braces, even > one-liners. > That is: > > if (foo) { >bar(); > } > > instead

Re: [coreboot] [flashrom] MX66l51235f

Hi Ron, On 14.05.2018 18:01, ron minnich wrote: > anyone got the incantation to flash this with an sf100 ;-) TLDR; If it doesn't work with current master, you can try [1]. 512M, huh? what's that for, UbuntuBoot? xD You need 4-byte addresses to access the full chip and that's rather delicate

Re: [coreboot] FSP 2.0 headers in coreboot

On 11.05.2018 01:39, Timothy Pearson wrote: > Not to jump too far into the fray, but couldn't this be handled by > simply not blocking coreboot development on proprietary blobs? For > instance, if someone wants to implement a feature that requires > repository-wide changes (e.g. the timestamp

Re: [coreboot] FSP 2.0 headers in coreboot

On 11.05.2018 01:32, Aaron Durbin wrote: > On Thu, May 10, 2018 at 5:10 PM, Nico Huber <nic...@gmx.de> wrote: >> Ok, I'll try to break this loop here. You are repeating the great bene- >> fits for a user (that I agree to) even if a blob is involved. And I keep >> asking

Re: [coreboot] FSP 2.0 headers in coreboot

On 11.05.2018 01:31, Julius Werner wrote: >> Ok, I'll try to break this loop here. You are repeating the great bene- >> fits for a user (that I agree to) even if a blob is involved. And I keep >> asking why it should happen on our master branch (I don't see how we >> would take something away by

Re: [coreboot] FSP 2.0 headers in coreboot

Ok, I'll try to break this loop here. You are repeating the great bene- fits for a user (that I agree to) even if a blob is involved. And I keep asking why it should happen on our master branch (I don't see how we would take something away by not maintaining everything. Also, I never tried to

Re: [coreboot] FSP 2.0 headers in coreboot

In general, I like Nico's idea of setting up rules for blobs, but my worry is that no matter how great and logical the rules are, the blob-makers might simply ignore them.. you can ask for signed blobs, but what if they refuse to sign it? Or even better, you can ask for redistributable blobs, but

Re: [coreboot] FSP 2.0 headers in coreboot

On 10.05.2018 00:17, Julius Werner wrote: Yes, I agree and already did so when writing the above. That's why I made it a recommendation and not a requirement. I also intentionally didn't write "vendor". Just whoever provides the blob should sign it. I still don't really get what signing in

Re: [coreboot] FSP 2.0 headers in coreboot

On 09.05.2018 01:04, Nico Huber wrote: >>>>> Unless a pointer as described above exists for a given plat- >>>>> form that relies on a blob, all changes* to that platform >>>>> *shall* be refused. >> >> I think this is counte

Re: [coreboot] FSP 2.0 headers in coreboot

On 08.05.2018 20:35, Julius Werner wrote: Providers of blobs should sign them and take responsibility that the signed blobs were unaltered after compilation (e.g. do not contain malware). It is *recommended* that the public key needed to verify the signature

Re: [coreboot] FSP 2.0 headers in coreboot

On 06.05.2018 00:03, Aaron Durbin wrote: > On Sat, May 5, 2018 at 5:36 AM, Nico Huber <nic...@gmx.de> wrote: >> On 04.05.2018 23:41, Aaron Durbin via coreboot wrote: >>> On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui >>> <kakar...@kakaroto.homelinux.net> wro

Re: [coreboot] FSP 2.0 headers in coreboot

On 04.05.2018 23:41, Aaron Durbin via coreboot wrote: > On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui > wrote: >> 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

[coreboot] Contribution trolling (was Re: Thread derailment)

Hello Zoran, did you just try to derail the thread-derailment thread? Or did you try to make any point at all? > [coreboot] How to handle vbt.bin > https://www.mail-archive.com/coreboot@coreboot.org/msg51401.html > > You, GOOGLE designers, are here talking essays (War and Peace) about > what to

<    1   2   3   4   5   6   7   8   9   >