coreboot April 2018

coreboot@coreboot.org

68 participants
128 discussions

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 24 Apr '18

24 Apr '18

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. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1390566: Control flow issues (DEADCODE) /src/soc/mediatek/mt8173/spi.c: 262 in spi_ctrlr_xfer() ________________________________________________________________________________________________________ *** CID 1390566: Control flow issues (DEADCODE) /src/soc/mediatek/mt8173/spi.c: 262 in spi_ctrlr_xfer() 256 /* Driver implementation does not support full duplex. */ 257 if (bytes_in && bytes_out) 258 return -1; 259 260 while (bytes_out || bytes_in) { 261 if (bytes_in && bytes_out) >>> CID 1390566: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "min_size" inside this statement: "min_size = ((((bytes_out < ...". 262 min_size = MIN(MIN(bytes_out, bytes_in), MTK_FIFO_DEPTH); 263 else if (bytes_out) 264 min_size = MIN(bytes_out, MTK_FIFO_DEPTH); 265 else if (bytes_in) 266 min_size = MIN(bytes_in, MTK_FIFO_DEPTH); 267 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Article in March Linux Journal on LinuxBoot
by Gregg Levine 23 Apr '18

23 Apr '18

Hello! I just finished reading the article on LinuxBoot in the March issue of Linux Journal. And I am working on the one on a customized embedded Linux build, which is in the same issue. (There wasn't a February issue, or even ones for December last year or a January this year.) It does make a good point on the subject of how to properly boot Linux without a proprietary or even closed source BIOS used. And I remember reading Eric's article from the beginning of the Century and it did not go into enough detail. Ron and company that was a well written article. To be honest when I joined the original list for LinuxBIOS I had a plan to apply that to running a system for the purposes of running an emulator called Hercules, who rather effectively emulates the IBM mainframe. Sadly it was never realized. I believe given what was described in the article that I am a lot closer. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

1 0

Re: [coreboot] Coreboot events 2018
by Zaolin 23 Apr '18

23 Apr '18

Last year I organized the European Coreboot Conference 2017 - ecc2017.coreboot.org . and this year I am the organizer of the Open Source Firmware Conference 2018 - www.osfc.io . So feel free to join us ;) On 22.04.2018 13:36, Alexey Borovikov wrote: > I want to visit in 2018 a conference on Coreboot. For the purpose of > planning a business trip, please inform future events and venue? > >

3 2

Re: [coreboot] [PATCH 0/5] coreboot table bus and framebuffer driver
by Greg Kroah-Hartman 23 Apr '18

23 Apr '18

On Wed, Mar 14, 2018 at 09:22:04PM +0000, Julius Werner wrote: > [resend in plain text] > > > It would be great to get some of the google developers to ack these, as > > this touches their code... > > From the coreboot point of view I guess we're fine with it since it claims > to maintain all of the existing functionality. It's just changing the > kernel-level plumbing for these drivers and I don't really have the > expertise to comment on whether this is better or worse than the old code > (maybe Dmitry or Guenter will?). It seems a little odd to me to call this a > "bus", but if we think that's the most fitting abstraction the kernel has > for it, I'm okay with that. All I care about is that it will work (in all > combinations... e.g. regardless of probe order and even if some parts are > compiled as modules and loaded/unloaded at runtime). Thanks for the response, patches are all now queued up. greg k-h

1 0

Open Source Firmware Conference 2018
by Zaolin 22 Apr '18

22 Apr '18

Hi There! On behalf of the 9elements GmbH and the Siemens AG, I would like to invite you to the Open Source Firmware Conference 2018, that is going to be held from **September 12th to 15th* *in Erlangen, Germany. Open source has revolutionised the process of software development. However, firmware has traditionally been developed closed source by hardware manufacturers. Today’s use cases have new requirements regarding security and features like running web browser inside the firmware. Our conference is for everyone who is interested in the use cases and possibilities offered by open source firmware development. The OSFC 2018 is the first conference which focuses on all Open Source firmware projects. We aim to bring together as many Open Source firmware projects, hardware manufacturers and developers as possible to collaborate and share their knowledge. Projects who will join our conference so far: LinuxBoot, coreboot and Tianocore. Four days full of talks, workshops and a hackathon await you. Join OSFC 2018 and let us change the way of firmware development together! Further information: www.osfc.io <http://www.osfc.io/> Newsletter: https://goo.gl/7JF7NW Twitter: osfc_io

2 1

Coreboot events 2018
by Alexey Borovikov 22 Apr '18

22 Apr '18

I want to visit in 2018 a conference on Coreboot. For the purpose of planning a business trip, please inform future events and venue?

1 0

HP Elitebook 8570w support
by Gaby M 21 Apr '18

21 Apr '18

Hello everybody, I bought an Elitebook 8570w few years ago, and ever since I've been trying to set up some features to make it work better. However, the BIOS configuration utility is pretty bald, so after reaching out HP Support with no luck and having googled for years, I'm still wearing nappies. The main problems are two: ASPM and Intel HD4000. Even though MS-Windows manages to turn off the discrete NVidia K2000M and start using the Intel card, (although in a subtle way, as it won't provide any information about the device in use), I haven't been able to make it work in Linux (OpenSuse); moreover, it's not even shown with 'lspci'. This means I'm not able to disable dGPU in order to use Intel one for lower power consumption purposes. As for ASPM, I couldn't find a way of turning it ON other than overriding FADT from the EFIShell. If I do it this way, and add 'pcie_aspm=force' as boot parameter, I still see 'ASPM: Could not configure common clock', and ASPM appears 'disabled' in most of the devices listed with 'lspci'. Actually, the few that appear 'enabled' if I override FADT will also show that way if I don't. On the other hand, If I don't override FADT, I get 'ACPI FADT declares the system doesn't support PCIe ASPM, so disable it' and some others. Few questions: Assuming it's possible to flash the ROM to use 'coreboot' instead of the firmware provided by HP, would I be able to enable at least this two features? will I need to de-solder the ROM chip to do it?, would I lose other functionalities? I mean, is it possible to know whether all other devices are also supported? Following the guide I found in FAQs, I attached bellow what I understand is necessary to answer this questions. Please let me know if it's not complete. Thanks in advance! Gabriel. HP EliteBook 8570w: Motherboard: HP 176b CPU: 8x Intel Core i7-3820QM @ 2.7Ghz Chipset: Mobile Intel QM77 Express VGA: Intel HD4000 / NVidia K2000M (Hybrid) HP product specifications' website: https://support.hp.com/gb-en/product/hp-elitebook-8570w-mobile-workstation/… 'lspci' 00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4) 00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4) 00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation QM77 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) 01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K2000M] (rev a1) 01:00.1 Audio device: NVIDIA Corporation GK107 HDMI Audio Controller (rev a1) 24:00.0 FireWire (IEEE 1394): JMicron Technology Corp. IEEE 1394 Host Controller (rev 30) 24:00.1 System peripheral: JMicron Technology Corp. SD/MMC Host Controller (rev 30) 24:00.2 SD Host controller: JMicron Technology Corp. Standard SD Host Controller (rev 30) 25:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 3e) 'lspci -tvnn' -[0000:00]-+-00.0 Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] +-01.0-[01]--+-00.0 NVIDIA Corporation GK107GLM [Quadro K2000M] [10de:0ffb] | \-00.1 NVIDIA Corporation GK107 HDMI Audio Controller [10de:0e1b] +-14.0 Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] +-16.0 Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] +-19.0 Intel Corporation 82579LM Gigabit Network Connection [8086:1502] +-1a.0 Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] +-1b.0 Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] +-1c.0-[02]-- +-1c.1-[03-23]-- +-1c.2-[24]--+-00.0 JMicron Technology Corp. IEEE 1394 Host Controller [197b:2380] | +-00.1 JMicron Technology Corp. SD/MMC Host Controller [197b:2392] | \-00.2 JMicron Technology Corp. Standard SD Host Controller [197b:2391] +-1c.3-[25]----00.0 Intel Corporation Centrino Ultimate-N 6300 [8086:422b] +-1d.0 Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] +-1f.0 Intel Corporation QM77 Express Chipset LPC Controller [8086:1e55] +-1f.2 Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e03] \-1f.3 Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller [8086:1e22] 'superiotool<https://www.coreboot.org/Superiotool> -dV' Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e... Found SMSC LPC47N217 (id=0x7a, rev=0x08) at 0x4e No dump available for this Super I/O Probing for VIA Super I/O at 0x3f0... PCI device 1106:0686 not found. 'flashrom -p internal -V' Found chipset "Intel QM77" with PCI ID 8086:1e55. Enabling flash write... Root Complex Register Block address = 0xfed1c000 GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) Top Swap: not enabled 0xfff80000/0xffb80000 FWH IDSEL: 0x0 0xfff00000/0xffb00000 FWH IDSEL: 0x0 0xffe80000/0xffa80000 FWH IDSEL: 0x1 0xffe00000/0xffa00000 FWH IDSEL: 0x1 0xffd80000/0xff980000 FWH IDSEL: 0x2 0xffd00000/0xff900000 FWH IDSEL: 0x2 0xffc80000/0xff880000 FWH IDSEL: 0x3 0xffc00000/0xff800000 FWH IDSEL: 0x3 0xff700000/0xff300000 FWH IDSEL: 0x4 0xff600000/0xff200000 FWH IDSEL: 0x5 0xff500000/0xff100000 FWH IDSEL: 0x6 0xff400000/0xff000000 FWH IDSEL: 0x7 0xfff80000/0xffb80000 FWH decode enabled 0xfff00000/0xffb00000 FWH decode enabled 0xffe80000/0xffa80000 FWH decode enabled 0xffe00000/0xffa00000 FWH decode enabled 0xffd80000/0xff980000 FWH decode enabled 0xffd00000/0xff900000 FWH decode enabled 0xffc80000/0xff880000 FWH decode enabled 0xffc00000/0xff800000 FWH decode enabled 0xff700000/0xff300000 FWH decode disabled 0xff600000/0xff200000 FWH decode disabled 0xff500000/0xff100000 FWH decode disabled 0xff400000/0xff000000 FWH decode disabled Maximum FWH chip size: 0x100000 bytes SPI Read Configuration: prefetching enabled, caching enabled, BIOS_CNTL = 0x2a: BIOS Lock Enable: enabled, BIOS Write Enable: disabled Warning: BIOS region SMM protection is enabled! Warning: Setting Bios Control at 0xdc from 0x2a to 0x09 failed. New value is 0x2a. SPIBAR = 0x00007fb869355000 + 0x3800 0x04: 0xe008 (HSFS) HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 Warning: SPI Configuration Lockdown activated. Reading OPCODES... done 0x06: 0x0004 (HSFC) HSFC: FGO=0, FCYCLE=2, FDBC=0, SME=0 0x50: 0x00000a0b (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0x0a, BRRA 0x0b 0x54: 0x00000000 FREG0: Warning: Flash Descriptor region (0x00000000-0x00000fff) is read-only. 0x58: 0x0fff0b00 FREG1: BIOS region (0x00b00000-0x00ffffff) is read-write. 0x5C: 0x0aff0003 FREG2: Warning: Management Engine region (0x00003000-0x00afffff) is locked. 0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x00001000-0x00002fff) is read-write. Not all flash regions are freely accessible by flashrom. This is most likely due to an active ME. Please see https://flashrom.org/ME for details. 0x74: 0x8fff0f70 PR0: Warning: 0x00f70000-0x00ffffff is read-only. Writes have been disabled for safety reasons. You can enforce write support with the ich_spi_force programmer option, but you will most likely harm your hardware! If you force flashrom you will get no support if something breaks. On a few mainboards it is possible to enable write access by setting a jumper (see its documentation or the board itself). 0x90: 0x84 (SSFS) SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0 0x91: 0xfc4200 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=2, SME=0, SCF=4 0x94: 0x5006 (PREOP) 0x96: 0x7f48 (OPTYPE) 0x98: 0x0405039f (OPMENU) 0x9c: 0x0102d820 (OPMENU+4) 0xA0: 0x00000000 (BBAR) 0xC4: 0x00800000 (LVSCC) LVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=1 0xC8: 0x00002005 (UVSCC) UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20 0xD0: 0x00000000 (FPB) PROBLEMS, continuing anyway ... Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) mapped at physical address 0x00000000ff000000. Chip status register is 0x00. ... Found Winbond flash chip "W25Q128.V" (16384 kB, SPI). This chip may contain one-time programmable memory. flashrom cannot read and may never be able to write it, hence it may not be able to completely clone the contents of this chip (see man page for details). No operations were specified. Restoring MMIO space at 0x7fb8693588a0 Restoring PCI config space for 00:1f:0 reg 0xdc

1 0

Re: [coreboot] How is our SPI API supposed to work?
by Julius Werner 19 Apr '18

19 Apr '18

> While you guys are at it, it might be worth folding spi_claim_bus() > and spi_release_bus() into these changes so that CS is managed > automatically for things like SPI flash transactions. Right now they > return 0 for controllers that don't define ctrlr->claim_bus and > ctrlr->release_bus, meaning those which do fused ops and might not > even allow the user to manually drive CS. In those cases the behavior > feels like silent failure since they don't even attempt to do the > thing the user asked, yet they are required to be in the common > codepaths for generic SPI controllers. This is currently used in the Cr50 driver to send a little wakeup pulse on CS (without clock) before starting the actually transaction. We also rely on it for certain Chrome ECs that need a wakeup delay between CS assertion and the first clock (as you may remember... you wrote that ;) ). So we can't fully remove it without finding a different solution for those things. In general, I'm a fan of letting software do stuff explicitly rather than relying on controller automatism, because it allows you do things like that and also because controllers often have their own unique issues when they try to be too clever by themselves. I think it would be better to keep the explicit CS controls for the controllers that can support it, and then controllers that don't may not work correctly with peripherals where it really matters, I guess. (FWIW on many chips you can pinmux the CS pin to a GPIO and control it that way even if the controller itself doesn't allow that.)

1 0

Re: [coreboot] How is our SPI API supposed to work?
by David Hendricks 19 Apr '18

19 Apr '18

On Thu, Apr 19, 2018 at 3:54 PM, Aaron Durbin <adurbin(a)google.com> wrote: > >> OK. It's just moving code around. > > > > Yeah, I just want to shuffle code around. Nothing is broken right now, it's > > just working in a confusing and inconsistent way. We should have an API > > where the callbacks share the same semantics across all implementations > > (and also document those semantics more clearly). > > I can send some CLs out. While you guys are at it, it might be worth folding spi_claim_bus() and spi_release_bus() into these changes so that CS is managed automatically for things like SPI flash transactions. Right now they return 0 for controllers that don't define ctrlr->claim_bus and ctrlr->release_bus, meaning those which do fused ops and might not even allow the user to manually drive CS. In those cases the behavior feels like silent failure since they don't even attempt to do the thing the user asked, yet they are required to be in the common codepaths for generic SPI controllers. The result would be that functions such as do_spi_flash_cmd() no longer need to explicitly manage CS by claiming/releasing the SPI bus. On the other hand, one might want to transfer one or more vectors without toggling CS, so we may need to expose a way to leave CS alone e.g. thru struct spi_op or another function parameter.

1 0

Re: [coreboot] How is our SPI API supposed to work?
by Aaron Durbin 19 Apr '18

19 Apr '18

On Thu, Apr 19, 2018 at 4:51 PM, Julius Werner <jwerner(a)chromium.org> wrote: >> How does it mean two different things? The pairing of a controller and >> device where a full duplex operation is needed but the controller >> doesn't support things should indeed fail. I do not undertand how >> xfer() means two different things. Whenever pairing hardware together >> one needs to validate that things work when married. > > spi_xfer_two_vectors() takes a call like this: > > struct spi_op vectors[2] = { {.dout = out, .din = NULL, ...}, {.dout = > NULL, .din = in, ...}; > spi_xfer_vector(..., vectors, 2); > > and turns it into > > spi_xfer(..., dout, ..., din, ...); > > Those are two different things. The former means "first transfer dout on > MOSI and ignore MISO, then read in din on MISO and send zeroes or whatever > out on MOSI". The latter means "do a full-duplex transaction where you read > from MISO into din and write dout out on MOSI at the same time". If you did > the latter call on a controller supporting full-duplex it wouldn't actually > be a correct SPI flash transaction. But all the controllers that use > spi_xfer_two_vectors() have implemetations of xfer() that don't actually do > the thing I just described... instead they do the "first out, then in" > behavior even though that's normally not what spi_xfer(..., dout, ..., din, > ...) means. I think those implementations of xfer() are wrong and violating > the API. If they were corrected, spi_xfer_two_vectors() wouldn't make sense > the way it works right now. I said it was helper to fuse the ops. Sure we can invert the code paths. > >> OK. It's just moving code around. > > Yeah, I just want to shuffle code around. Nothing is broken right now, it's > just working in a confusing and inconsistent way. We should have an API > where the callbacks share the same semantics across all implementations > (and also document those semantics more clearly). I can send some CLs out.

1 0

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2018