coreboot June 2018

coreboot@coreboot.org

40 participants
105 discussions

Start a nNew thread

Intel ME Security keys Genealogy, Obfuscation and other Magic
by Shawn 09 Jun '18

09 Jun '18

https://github.com/ptresearch/IntelME-Crypto/blob/master/Intel%20ME%20Secur…

1 0

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

08 Jun '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. 2 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 1393312: Null pointer dereferences (REVERSE_INULL) /src/drivers/i2c/generic/generic.c: 222 in i2c_generic_enable() ________________________________________________________________________________________________________ *** CID 1393312: Null pointer dereferences (REVERSE_INULL) /src/drivers/i2c/generic/generic.c: 222 in i2c_generic_enable() 216 } 217 } 218 219 dev->ops = &i2c_generic_ops; 220 221 /* Name the device as per description provided in devicetree */ >>> CID 1393312: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "config" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 222 if (config && config->desc) { 223 dev->name = config->desc; 224 } 225 } 226 227 struct chip_operations drivers_i2c_generic_ops = { 228 CHIP_NAME("I2C Device") 229 .enable_dev = &i2c_generic_enable ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

BIOS upgrade before flashing coreboot
by Akendo 08 Jun '18

08 Jun '18

Hey everyone, currently I working on a x220 to flash coreboot onto it. I notice that my x220 has a current BIOS version from 2011 (1.24 UEFI/BIOS and 1.13 ECP). Within the change-log[0] variates updates and fixes are stated. Including changes to the ME engine. Within many documentation part of coreboot, it's stated, that the ME part can't be written. Here my question: Should I update the BIOS to the latest release before flashing coreboot onto it? There is for example this note: > If the UEFI BIOS has been updated to version 1.43 or higher, it is no longer > able to roll back to the version before 1.43 for security improvement. Could this cause problems? For example the CVE-2017-5715 (Spectre) would be fixed. I expect them to run role out the microcode update from Intel... so might be no problem to coreboot, right? best regards, akendo [0]https://download.lenovo.com/pccbbs/mobiles/8duj29us.txt

3 2

Re: [coreboot] POWER9 / Talos II coreboot support?
by Timothy Pearson 08 Jun '18

08 Jun '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/03/2018 06:02 PM, ron minnich wrote: > > > On Thu, May 3, 2018 at 1:20 PM Timothy Pearson > <tpearson(a)raptorengineering.com <mailto:tpearson@raptorengineering.com>> > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I think I was being a bit pessimistic / too careful here. We're close > to getting the docs publicly released, but that doesn't help anyone > wanting access right now, which is why I mentioned the other route. > IBM's committed to getting the documentation released, they're just > making sure that what they release is actually correct for the products > it covers. > > It might make sense to get our "working group" together over the next > few weeks, by which time the documentation should be available in public > form. > > Are you interested in joining? :-) > > > of course, but not until those docs are freed up. > We're getting there. First manual to be released is the processor user guide. More to follow, including register documentation, in around a week. Users guide: https://wiki.raptorcs.com/wiki/File:POWER9_um_OpenPOWER_v20GA_09APR2018_pub… > Context: I've been trying for 2 years now to get OPAL released under > dual gpl2 licensing with the current apache2 license, apache2 and gpl2 > are not compatible, so we'd be in a bit of a mess should we use OPAL > code in coreboot, and it would be easiest if we were able to use some of > that code. > > The first response from IBM was "why do you think you need coreboot?" I > worked through that, and there was agreement in the end it ought to > happen, said agreement reached about 2 years ago. Stuff Would Happen, I > was told. After that, silence. We've reignited this. It's underway. :-) > This is pretty much par for the course with Power. In 1990 I spent two > years getting an agreement that would allow me to .... get more agreements. We've plowed through this already and are at the action point. For the most part, just let me know what you need and I'll see if we can get it published. > So close doesn't count. Once I see the kind of docs I need to see, not > requiring a clickwrap, and covering all aspects of every chip on your > board, I'm in: I'll order a board. Until then, I can't really do much. Is the NIC an issue? There are several people working on REing the hardware with some great progress [1][2], but there's really no way to get Broadcom to ever release official documentation. Everything else on the libre-friendly non-SAS version either has docs available or we are close to getting them published. > Thanks for your efforts on Power! No problem! We still consider Power the best path forward for powerful libre systems at this point, getting really tired of the other vendors actively working against efforts to create open firmware (this includes SiFive at this point). Will keep you posted as we get more docs published online, but thought you and the others here might at least be interested in the users guide. > ron > > [1] https://wiki.raptorcs.com/wiki/BCM5719 [2] IRC discussions on #talos-workstation - -- 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 iQEcBAEBCAAGBQJa9pj/AAoJEK+E3vEXDOFbF70IAJohByTnLWTDC/I5q4FNi/on bS+gTBs373Cd5iIFaYCrVxYU4udDIDy3fjhBG6Y64AjQFtu4KSXkjbR/aldfnk36 mUfOul59kY+DDIaQOBEuHBsq0YoF1oFy4LBbiSpZXTZh5SDAbSleeg6tKJDqzR4Z zirXrZN8Vsv+FneQmbXAt+LqqveZcKTUz5vG5GaJCC/i6fyrkr/oI9Ffw/vlFcAI 3d9Ni/YzuKmdQN+rPcvJViNoBYsQ0aumAwrTc45omZDK5Mg3I+B+6vC27CDhwB23 TtKNw456tF5i0P9NhqjdQnqMdNc2BvocJQxyXOfvnPSXHW6DSAV4tT3+lh8PAyM= =EbtA -----END PGP SIGNATURE-----

2 4

Re: [coreboot] KGPE-D16: Trouble using three PCIe cards simultaneously
by Daniel Kulesz 08 Jun '18

08 Jun '18

Thank you for your answers, Jason and Alberto. While it's true that the hypercard is a PCIe 3.0 device, I did not see the reason yet why it would not operate in a PCIe 2.0 slot with lower throughput. And I am not sure but - is Intel VROC required to use all four M.2 slots? Anyways, I am happy to report that I "resolved" the issue partially by getting rid of the GPU that occupies two slots, replacing it by one that occupies just 1 slot. Then I installed the USB3 controller card next to it, resulting in the following setup: 1. (MIO): empty 2. GPU 3. USB3 controller card 4. Hypercard 5. Empty This way, I have graphics, USB 3.0 and two M.2 slots working. In addition, I noticed that the system (without usb3) takes around 7-8W less in idle than with the previous gpu installed. That's a bit surprising as the old gpu was advertised to use only ~5.5W total while idle (but I wondered while it gets so hot, I thought this was due to it being installed so close to CPU0's huge heatsink). As I don't need that much GPU power anyways, the swap had at least a nice (unexpected) side-effect for me. However, the fact that I still can use only two M.2 cards is somewhat disappointing. Since there are also other vendors of comparable PCIe quad-M.2 cards, I welcome any reports (both positive and negative) from people who tried different m.2 quad card models in a KGPE-D16. Cheers, Daniel

2 2

ANN: release notes are now maintained in Documentation/release
by Patrick Georgi 06 Jun '18

06 Jun '18

Hi everybody, Martin pasted the release notes into coreboot.git's Documentation folder and also added a stub for coreboot 4.9. Since the volume of coreboot changes increased a lot in the last few years, it's infeasible to create release notes after the fact by looking at the commits since last release. When you add noteworthy changes, please add a commit to your patch train that extends the upcoming release notes. Use your own words, provide some background - right now, it's mostly a list of bullet points, but it doesn't need to be. I'm quite sure that we'll manage to develop a common voice for the release notes as well for all other documentation. New chipsets and mainboards can be automatically covered by scripts that extract the information, so they don't _need_ such a manual description. These automated entries will be rather bland though, so if you want to see context, feel free to add something for them as well. Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
by Jose Trujillo 05 Jun '18

05 Jun '18

Dear coreboot developers: My system is Baytrail FSP E3845 2 LPC SIO WINBOND_W83627DHG and FINTEK_F81803 (disabled at this moment) SERIRQ has been enabled. I have the following issue in the W83627DHG SIO: ttyS2 @ 0x3e8, irq 4 doesn't work. (changing IRQ 4 to 6 does not make any difference) ttyS3 @ 0x2e8, irq 3 works OK. I am not mixing PCI interrupts with PNP ones. irqroute.h ************************************* #define PIRQ_PIC_ROUTES \ PIRQ_PIC(A, 5), \ PIRQ_PIC(B, 6), \ PIRQ_PIC(C, 7), \ PIRQ_PIC(D, 10), \ PIRQ_PIC(E, 11), \ PIRQ_PIC(F, 12), \ PIRQ_PIC(G, 14), \ PIRQ_PIC(H, 15) ************************************* devicetree.cb ************************************* device pci 1f.0 on # 8086 0F1C - LPC bridge chip superio/winbond/w83627dhg device pnp 2e.0 off end # Floppy device pnp 2e.1 off end # Parallel Port device pnp 2e.2 on # Com1 io 0x60 = 0x3e8 irq 0x70 = 4 end device pnp 2e.3 on # Com2 io 0x60 = 0x2e8 irq 0x70 = 3 end device pnp 2e.5 off end # Keyboard device pnp 2e.6 off end # SPI ************************************* Mainboard Kconfig ************************************* select SOC_INTEL_FSP_BAYTRAIL select SUPERIO_WINBOND_W83627DHG ## select SUPERIO_FINTEK_F81803 select BOARD_ROMSIZE_KB_2048 select HAVE_ACPI_TABLES select HAVE_OPTION_TABLE select TSC_MONOTONIC_TIMER select HAVE_ACPI_RESUME select CONFIG_SERIRQ_CONTINUOUS_MODE ************************************* Serial port on SuperIO is disabled in menuconfig ---> Generic Drivers. Coreboot version is 4.8.1. FSP version is Baytrail MR5 superiotool is giving me consistent information about adresses and irqs on the winbond and fintek chips. (but fintek is disabled now) so it means the SOC is communicating correctly with the SIO chips. I still didn't added superio.asl to the winbond SIO because it crash in Windows 7 and 10 with ACPI error. Original AMI firmware works correctly on both SIO chips. There is something I still missing to do? (additional configuration, routing, files like dts?? etc...) Another issue is that no matter I disable SOC legacy COM1 and menuconfig always appear ttyS0 in Linux (A ghost that I am not able to disable yet). Somebody have experience on this issue? Anyone can give me guidance in debugging this? Please tell me if i need to provide you with more information. Thank you in advance, Jose Trujillo.

1 0

Re: [coreboot] Enabling SpeedStep for all Denverton SoC variants
by Julien Viard de Galbert 05 Jun '18

05 Jun '18

> Le 29 mai 2018 à 16:48, Sumo <kingsumos(a)gmail.com> a écrit : > > Hi, > > Today denverton_core_init() is enabling the Intel SpeedStep only if turbo mode is available. As a result, the SpeedStep is not enable for the C3558 variant (and others). Any clues of why it was implemented this way? > I think it is safe to remove the "if (get_turbo_state() == TURBO_ENABLED)" test and always enable the SpeedStep technology. You are right, I also think it’s safe. (The variant I have access to have Turbo so I can’t test it). I also have no clue, but it was like this since the first denverton commit… So please test and submit a patch ;) Best Regads Julien > > Thanks, > Sumo > > > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- Julien Viard de Galbert - jviarddegalbert(a)online.net Online / Scaleway Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/

2 1

Problem in building the toolchain with gcc-8.1
by Akendo 05 Jun '18

05 Jun '18

Hello everyone, I currently having a problem build the toolchain from a freshly checkout coreboot repository. I've tried to build with different options: For example with all platforms and only with i386 support. Multi core (CPUS=4) and with a single core. Here an example build: Building toolchain using 1 thread(s). Target architecture is i386-elf Found compatible Ada compiler, enabling Ada support by default. Downloading and verifing tarballs ... * gmp-6.1.2.tar.xz (cached)... hash verified (9dc6981197a7d92f339192eea974f5eca48fcffe) * mpfr-3.1.5.tar.xz (cached)... hash verified (c0fab77c6da4cb710c81cc04092fb9bea11a9403) * mpc-1.0.3.tar.gz (cached)... hash verified (b8be66396c726fdc36ebb0f692ed8a8cca3bcc66) * binutils-2.29.1.tar.xz (cached)... hash verified (172244a349d07ec205c39c0321cbc354c125e78e) * gcc-6.3.0.tar.bz2 (cached)... hash verified (928ab552666ee08eed645ff20ceb49d139205dea) Downloaded tarballs ... ok Unpacking and patching ... * gmp-6.1.2.tar.xz o gmp-6.1.2_freebsd-configure.patch * mpfr-3.1.5.tar.xz * mpc-1.0.3.tar.gz * binutils-2.29.1.tar.xz o binutils-2.29.1_mips-gold.patch o binutils-2.29.1_no-bfd-doc.patch * gcc-6.3.0.tar.bz2 o gcc-6.3.0_ada-musl_workaround.patch o gcc-6.3.0_ada-raise.patch o gcc-6.3.0_elf_biarch.patch o gcc-6.3.0_gnat.patch o gcc-6.3.0_libgcc.patch o gcc-6.3.0_memmodel.patch o gcc-6.3.0_nds32_ite.patch o gcc-6.3.0_no-p-var.patch o gcc-6.3.0_pointer_integer.patch o gcc-6.3.0_riscv.patch Unpacked and patched ... ok Building packages ... Building GMP v6.1.2 for host ... ok Building MPFR v3.1.5 for host ... ok Building MPC v1.0.3 for host ... ok Building BINUTILS v2.29.1 for target ... ok Building GCC v6.3.0 for target ... failed. Check 'build-i386-elf-GCC/build.log'. make[3]: *** [Makefile:26: build_gcc] Error 1 make[2]: *** [Makefile:48: build-i386] Error 2 make[1]: *** [Makefile:16: all_without_gdb] Error 2 make: *** [util/crossgcc/Makefile.inc:37: crossgcc] Error 2 I also tried to do this with clang, with similar result. Here is the log from clang: [ 52%] Building CXX object projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.x86_64.dir/sanitizer_stoptheworld_linux_libcdep.cc.o /home/akendo/src/coreboot/util/crossgcc/llvm-4.0.0.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc: In function 'int __s$ nitizer::TracerThread(void*)': /home/akendo/src/coreboot/util/crossgcc/llvm-4.0.0.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:278:22: error: aggreg$ te 'sigaltstack handler_stack' has incomplete type and cannot be defined struct sigaltstack handler_stack; ^~~~~~~~~~~~~ make[2]: *** [projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.x86_64.dir/build.make:255: projects/compiler-rt/lib/sanitizer_common/$ MakeFiles/RTSanitizerCommonLibc.x86_64.dir/sanitizer_stoptheworld_linux_libcdep.cc.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:14006: projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.x86_64.dir/all] Error 2 make: *** [Makefile:152: all] Error 2 ./buildgcc: line 840: cd: /home/akendo/src/coreboot/util/crossgcc/xgcc/lib/clang/4.0.0/lib: No such file or directory A look into the build log from GCC seems to disclose a similar error: make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/akendo/src/coreboot/util/crossgcc/build-i386-elf-GCC/libdecnumber' make[1]: Entering directory '/home/akendo/src/coreboot/util/crossgcc/build-i386-elf-GCC/fixincludes' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/akendo/src/coreboot/util/crossgcc/build-i386-elf-GCC/fixincludes' make[1]: Entering directory '/home/akendo/src/coreboot/util/crossgcc/build-i386-elf-GCC/gcc' gnatgcc -c -O2 -fomit-frame-pointer -m64 -gnatpg -gnatwG -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -I../../gcc-6.3.0/gcc/ada -I../../gcc-6.3.0/gcc/ada/gcc-interface ../../gcc-6.3.0/gcc/ada/aspects.adb -o ada/aspects.o aspects.adb:38:29: warning: use clause for package "HTable" has no effect make[1]: *** [../../gcc-6.3.0/gcc/ada/gcc-interface/Make-lang.in:119: ada/aspects.o] Error 1 make[1]: Leaving directory '/home/akendo/src/coreboot/util/crossgcc/build-i386-elf-GCC/gcc' make: *** [Makefile:4108: all-gcc] Error 2 /bin/sh ../gcc-6.3.0/mkinstalldirs /home/akendo/src/coreboot/util/crossgcc/xgcc /home/akendo/src/coreboot/util/crossgcc/xgcc /bin/sh: line 3: cd: i386-elf/libgcc: No such file or directory make: *** [Makefile:10796: install-target-libgcc] Error 1 I'm using ArchLinux with a Linux kernel 4.16.13-1 and gcc 8.1.0-1, gcc-ada 8.1.0-1 I checkout the git code in different version (4.8, 4.8.1, latest master commit). I quite sure that's the problem is the compiler. However I do not know how to fix this in the moment. I added the compressed logs from the i386-elf build. Hope this can help. Thank you for reading. best regards, akendo

2 1

Re: [coreboot] Problem in building the toolchain with gcc-8.1
by Jason Lenz 05 Jun '18

05 Jun '18

I had the same problem with compiling under Archlinux. I think gcc-8.1 is too new for coreboot (currently). Debian uses an older version of gcc and works fine. Below are a couple suggestions to try. * See if you can install and use gcc6 from the AUR * Install docker and then try using coreboot-sdk from docker hub

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2018