coreboot February 2018

coreboot@coreboot.org

49 participants
79 discussions

QEMU x86_64 Q35 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 06 Feb '18

06 Feb '18

The QEMU x86_64 Q35 fails verification for branch master as of commit 485c0ad0783aa168feab8944e498a393774512fd The following tests failed: BOOT_FAILURE Commits since last successful test: 485c0ad0 inteltool: Add Cougar- and Pantherpoint PCH PCI IDs for SPI 921fa84 inteltool: Fix displaying 64bit spi registers ad28259 mb/google/kahlee: Fix grunt I2C rise/fall times f9d9781 soc/intel/appololake: Remove dead MPINIT code selection 4004081 cpu/intel/haswell: Don't select PARALLEL_CPU_INIT <5 commits skipped> 75f5d99 mb/asus/m2v-mx_se: Add `cmos.default` 25874b8 mb/google/eve: Enable HotPlug on PCIe root port for WiFi 74ea48e soc/intel/skylake: Add devicetree variable for PCIe HotPlug f5e3775 google/kahlee: Initialize non-early i2c buses in mainboard_init e0ea982 soc/amd/stoneyridge: Add API to initialize non-early_init i2c buses See attached log for details This message was automatically generated from Raptor Engineering's QEMU x86_64 Q35 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

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

06 Feb '18

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 7 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 7 of 7 defect(s) ** CID 1385770: Memory - corruptions (OVERRUN) /3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 629 in rockchip_soc_cores_pwr_dm_on() ________________________________________________________________________________________________________ *** CID 1385770: Memory - corruptions (OVERRUN) /3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 629 in rockchip_soc_cores_pwr_dm_on() 623 int rockchip_soc_cores_pwr_dm_on(unsigned long mpidr, uint64_t entrypoint) 624 { 625 uint32_t cpu_id = plat_core_pos_by_mpidr(mpidr); 626 627 assert(cpu_id < PLATFORM_CORE_COUNT); 628 assert(cpuson_flags[cpu_id] == 0); >>> CID 1385770: Memory - corruptions (OVERRUN) >>> Overrunning array "cpuson_flags" of 6 4-byte elements at element index 4294967295 (byte offset 17179869180) using index "cpu_id" (which evaluates to 4294967295). 629 cpuson_flags[cpu_id] = PMU_CPU_HOTPLUG; 630 cpuson_entry_point[cpu_id] = entrypoint; 631 dsb(); 632 633 cpus_power_domain_on(cpu_id); 634 ** CID 1385769: Memory - corruptions (OVERRUN) /3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 630 in rockchip_soc_cores_pwr_dm_on() ________________________________________________________________________________________________________ *** CID 1385769: Memory - corruptions (OVERRUN) /3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 630 in rockchip_soc_cores_pwr_dm_on() 624 { 625 uint32_t cpu_id = plat_core_pos_by_mpidr(mpidr); 626 627 assert(cpu_id < PLATFORM_CORE_COUNT); 628 assert(cpuson_flags[cpu_id] == 0); 629 cpuson_flags[cpu_id] = PMU_CPU_HOTPLUG; >>> CID 1385769: Memory - corruptions (OVERRUN) >>> Overrunning array "cpuson_entry_point" of 6 8-byte elements at element index 4294967295 (byte offset 34359738360) using index "cpu_id" (which evaluates to 4294967295). 630 cpuson_entry_point[cpu_id] = entrypoint; 631 dsb(); 632 633 cpus_power_domain_on(cpu_id); 634 635 return PSCI_E_SUCCESS; ** CID 1385768: Code maintainability issues (UNUSED_VALUE) /3rdparty/arm-trusted-firmware/drivers/arm/gic/v3/arm_gicv3_common.c: 40 in arm_gicv3_distif_pre_save() ________________________________________________________________________________________________________ *** CID 1385768: Code maintainability issues (UNUSED_VALUE) /3rdparty/arm-trusted-firmware/drivers/arm/gic/v3/arm_gicv3_common.c: 40 in arm_gicv3_distif_pre_save() 34 /* 35 * The GICR_WAKER.Sleep bit should be set only when both 36 * GICR_WAKER.ChildrenAsleep and GICR_WAKER.ProcessorSleep are set on 37 * all the Redistributors. 38 */ 39 for (unsigned int i = 0; i < gicv3_driver_data->rdistif_num; i++) { >>> CID 1385768: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "gicv3_driver_data->rdistif_base_addrs[i]" to "gicr_base" here, but that stored value is overwritten before it can be used. 40 gicr_base = gicv3_driver_data->rdistif_base_addrs[i]; 41 assert(gicr_base); 42 assert(gicr_read_waker(gicr_base) & WAKER_CA_BIT); 43 assert(gicr_read_waker(gicr_base) & WAKER_PS_BIT); 44 } 45 ** CID 1385767: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1385767: Memory - corruptions (OVERRUN) /3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 633 in rockchip_soc_cores_pwr_dm_on() 627 assert(cpu_id < PLATFORM_CORE_COUNT); 628 assert(cpuson_flags[cpu_id] == 0); 629 cpuson_flags[cpu_id] = PMU_CPU_HOTPLUG; 630 cpuson_entry_point[cpu_id] = entrypoint; 631 dsb(); 632 >>> CID 1385767: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 6 by passing argument "cpu_id" (which evaluates to 4294967295) in call to "cpus_power_domain_on". 633 cpus_power_domain_on(cpu_id); 634 635 return PSCI_E_SUCCESS; 636 } 637 638 int rockchip_soc_cores_pwr_dm_off(void) ** CID 1385766: Memory - corruptions (NEGATIVE_RETURNS) /3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 629 in rockchip_soc_cores_pwr_dm_on() ________________________________________________________________________________________________________ *** CID 1385766: Memory - corruptions (NEGATIVE_RETURNS) /3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/pmu/pmu.c: 629 in rockchip_soc_cores_pwr_dm_on() 623 int rockchip_soc_cores_pwr_dm_on(unsigned long mpidr, uint64_t entrypoint) 624 { 625 uint32_t cpu_id = plat_core_pos_by_mpidr(mpidr); 626 627 assert(cpu_id < PLATFORM_CORE_COUNT); 628 assert(cpuson_flags[cpu_id] == 0); >>> CID 1385766: Memory - corruptions (NEGATIVE_RETURNS) >>> Using variable "cpu_id" as an index to array "cpuson_flags". 629 cpuson_flags[cpu_id] = PMU_CPU_HOTPLUG; 630 cpuson_entry_point[cpu_id] = entrypoint; 631 dsb(); 632 633 cpus_power_domain_on(cpu_id); 634 ** CID 1353332: Memory - illegal accesses (OVERRUN) /3rdparty/arm-trusted-firmware/lib/psci/psci_on.c: 63 in psci_cpu_on_start() ________________________________________________________________________________________________________ *** CID 1353332: Memory - illegal accesses (OVERRUN) /3rdparty/arm-trusted-firmware/lib/psci/psci_on.c: 63 in psci_cpu_on_start() 57 * CPU_ON platform hooks have been implemented. 58 */ 59 assert(psci_plat_pm_ops->pwr_domain_on && 60 psci_plat_pm_ops->pwr_domain_on_finish); 61 62 /* Protect against multiple CPUs trying to turn ON the same target CPU */ >>> CID 1353332: Memory - illegal accesses (OVERRUN) >>> Overrunning array "psci_cpu_pd_nodes" of 6 16-byte elements at element index 4294967295 (byte offset 68719476720) using index "target_idx" (which evaluates to 4294967295). 63 psci_spin_lock_cpu(target_idx); 64 65 /* 66 * Generic management: Ensure that the cpu is off to be 67 * turned on. 68 * Perform cache maintanence ahead of reading the target CPU state to ** CID 1353164: Memory - illegal accesses (NEGATIVE_RETURNS) /3rdparty/arm-trusted-firmware/lib/psci/psci_on.c: 63 in psci_cpu_on_start() ________________________________________________________________________________________________________ *** CID 1353164: Memory - illegal accesses (NEGATIVE_RETURNS) /3rdparty/arm-trusted-firmware/lib/psci/psci_on.c: 63 in psci_cpu_on_start() 57 * CPU_ON platform hooks have been implemented. 58 */ 59 assert(psci_plat_pm_ops->pwr_domain_on && 60 psci_plat_pm_ops->pwr_domain_on_finish); 61 62 /* Protect against multiple CPUs trying to turn ON the same target CPU */ >>> CID 1353164: Memory - illegal accesses (NEGATIVE_RETURNS) >>> Using variable "target_idx" as an index to array "psci_cpu_pd_nodes". 63 psci_spin_lock_cpu(target_idx); 64 65 /* 66 * Generic management: Ensure that the cpu is off to be 67 * turned on. 68 * Perform cache maintanence ahead of reading the target CPU state to ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware
by Mike Banon 06 Feb '18

06 Feb '18

Thank you very much for telling about EC-1.75 project! http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A1 Maybe some of its' elements could be borrowed for Origami if the hardware is similar? (haven't compared the datasheets) @ Youness and Marty : Proprietary firmware of KB9012 explicitly disables EDI - ENE Debug Interface (the protocol used to access the internal memory of KB9012) unless pin 42 is grounded _before_ powering the KB9012 controller ! Maybe its the same with your another KB ? If you ground that pin (not necessarily 42, your KB's pin number could be different) to put your EC into debug mode, maybe then you could successfully read/write it ? Here is the full description of my successful KB9012 hardware flashing setup through the keyboard port using a flex cable with soldered wires: 0.5mm pitch makes it hard to solder directly to keyboard port, and also I like flex cable solution because its much faster to remove/insert a cable than to solder/desolder the wires http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate ^^^ Had to unite three grounds ( programmer's, mainboard's and KB9012's 42 pin ) to make it work Currently we are actively working on the inclusion of KB9012 flashing support to the official flashrom - but its already possible via the unofficial patches. Changes 23258 - 23263 at the https://review.coreboot.org/#/q/project:flashrom I haven't compared the datasheets of KB9012 and your KB, so I don't know if they are using exactly the same debug interface or it is slightly different (please check if there are differences, maybe you'll have to write some code) I trust hardware flashing more than the software, especially your current AMI BIOS setup which isn't free software. Maybe the direct hardware flashing is also possible for you Latest status update for Origami-EC firmware: https://www.mail-archive.com/coreboot@coreboot.org/msg50646.html Best regards, Mike Banon On Mon, Feb 5, 2018 at 9:47 PM, Youness Alaoui <kakaroto(a)kakaroto.homelinux.net> wrote: > 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 specifically : > http://lists.laptop.org/pipermail/openec/2011-January/000158.html > And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A1 > > I had opened a ticket a while ago here : > https://tracker.pureos.net/T178 which mentions Origami-EC. I don't > know the status of that project, maybe you can contact the developer > (Paul Kocialkowski) and see where he's at with his development of that > project (which, I need to mention, hasn't been publicly launched yet, > as far as I know) and he might benefit from your help if you are > interested in doing that. > The last time we spoke he said : > "The OLPC code is nowhere close to usable on any other platform. > Additionally, it is so poorly written that I don't think it is a > suitable codebase for any future development. On the other hand, my > Origami-EC project (that I will publicly launch soon) should provide a > flexible codebase to add support for new devices." > > Note that the tracker ticket above is quite outdated, we know how to > dump the EC (the problem was that it can't be done via hardware > because the EC is on the same power rail as the 64KB flash chip, so > when we power the flash via hardware, the EC boots and takes control > of the SPI lines) but for some reason, we could only dump it via > software (using ectool) through the AMI BIOS firmware, with coreboot, > we only get 0xFF returned, I don't believe we had time to investigate > the cause for that. > > Sorry for not having any better news for you, but I hope this helps a > little you at least. > > Good luck, > Youness. > > > On Fri, Feb 2, 2018 at 10:17 AM, Marty E. Plummer > <hanetzer(a)startmail.com> wrote: >> Greetings, >> >> Currently working on a port for the hp g7-2247us laptop, which features >> an ene kb3940q ec, which hopefully should be very similar to the kb3930 >> ec, which has a datasheet available to the public in a few places. >> >> Said similar ec is used in some OLPC devices, as well as some purism >> devices, and I was hoping someone in the list would have some contacts >> with those guys so as to be able to use their ec firmware as a bit of a >> reference design, but the OLPC ec firmware repo has a 'private' >> submodule which I cannot access and I simply cannot find a repo for the >> purism ec firmware to reference. >> >> Any assistance you could provide on this matter would be greatly >> appreciated. >> >> Marty E. Plummer >> >> -- >> 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

ENE KB3940Q-A1 embedded controller custom firmware
by Marty E. Plummer 05 Feb '18

05 Feb '18

Greetings, Currently working on a port for the hp g7-2247us laptop, which features an ene kb3940q ec, which hopefully should be very similar to the kb3930 ec, which has a datasheet available to the public in a few places. Said similar ec is used in some OLPC devices, as well as some purism devices, and I was hoping someone in the list would have some contacts with those guys so as to be able to use their ec firmware as a bit of a reference design, but the OLPC ec firmware repo has a 'private' submodule which I cannot access and I simply cannot find a repo for the purism ec firmware to reference. Any assistance you could provide on this matter would be greatly appreciated. Marty E. Plummer

2 1

Re: [coreboot] [flashrom] Erase failure on Sapphire Pure Platinum H61 with coreboot
by Nico Huber 04 Feb '18

04 Feb '18

Hi Nicola, On 01.02.2018 09:48, Nicola Corna wrote: > Hi Nico, > > any update on this? omg sorry, looks like I completely forgot about it. And even worse, now that I looked into it, it seems to be impossible to do like I suggested. Because bd82x6x/finalize.c is run in SMM and we don't have the device- tree there. I guess we have to prepare the register contents and only lock them in the finalization function. Don't have time to test it, but [1] might work. Nico [1] https://review.coreboot.org/#/c/coreboot/+/23587 > > Best, > Nicola > > September 5, 2017 11:01 AM, "Nico Huber" <nico.h(a)gmx.de> wrote: > >> On 04.09.2017 19:31, Nicola Corna wrote: >> >>> September 3, 2017 12:24 AM, "Nico Huber" <nico.h(a)gmx.de> wrote: >>> >>>> TLDR; it would be a lot slower. >>>> >>>> Alas, there is no usual byte-program mode. Most chips do a 256B page >>>> program which uses op code 0x02 too. For the SST25VF032B it's really a >>>> 1B program. If you use that instead of the AAI write, you get lots of >>>> overhead (6B total, if I'm not mistaken, instead of ~1.5B per actual >>>> written byte + twice the polling for write-in-progress). >>>> >>>> Nico >>> >>> Thank you. >>> >>> I've noticed that some boards have already an extra "finalize", which overrides >>> the default opmenu and optype (see mb/siemens/mc_bdx1/mainboard.c): >> >> AFAICS, these boards use very different code paths with different inter- >> faces to override the op menu configuration. >> >>> should I >>> copy that implementation or add the configurations in the device tree and modify >>> every sb/intel/*/pch.h (as you suggested before)? >> >> I didn't mean to suggest modifying every pch.h, but only sb/intel/ >> bd82x6x/finalize.c (the pch.h should stay intact to give defaults). >> It's probably easier if I put my idea into a patch for discussion. >> Stay tuned. >> >> Nico >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Why does the Opteron 6328/6220 have two NUMA nodes?
by Robert Reeves 03 Feb '18

03 Feb '18

Socket C32 uses a single die per package, G34 is always a dual die MCM, even if it's merely one of the 4 or 8 core SKUs. This is because it needs the dual channel memory controllers from two bulldozer dies in order to support the quad channel memory of G34 platforms.On Feb 2, 2018 8:35 PM, Taiidan(a)gmx.com wrote: > > I was under the assumption that they are a single CPU package like their > desktop FX-8100/8300 counterparts, however under linux the 6328 is > reported as two NUMA nodes (CPU 0-3 and 4-7) like the dual CPU 6386 > package is. > > This presents a serious performance issue. > > I am not sure what is reported under the stock BIOS as I am unable to > reflash right now, does anyone know if this is a bug? > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

3 4

Why does the Opteron 6328/6220 have two NUMA nodes?
by Taiidan＠gmx.com 03 Feb '18

03 Feb '18

I was under the assumption that they are a single CPU package like their desktop FX-8100/8300 counterparts, however under linux the 6328 is reported as two NUMA nodes (CPU 0-3 and 4-7) like the dual CPU 6386 package is. This presents a serious performance issue. I am not sure what is reported under the stock BIOS as I am unable to reflash right now, does anyone know if this is a bug?

1 1

Re: [coreboot] Does the coreboot build system support external patches?
by David Hendricks 02 Feb '18

02 Feb '18

In addition to what Martin suggested they might also consider storing their code in a separate repository and pulling it in as a git submodule into the coreboot/3rdparty/ directory. What's best for them depends on their use case, like if they're mostly adding new files with an API or modifying existing files. On Thu, Feb 1, 2018 at 12:26 PM, Martin Roth <gaumless(a)gmail.com> wrote: > coreboot uses the site-local directory to allow users to extend the > coreboot build outside of the regular coreboot coreboot files. > Create the coreboot/site-local directory, and add Makefile.inc and Kconfig > files. Both of these files will get picked up by coreboot. > > To run steps at the start of the build, you can create a target that does > whatever is needed, then calls the 'all:' target to do the build. > At the end of the build, you can hook into the 'build_complete::' target > to run whatever finalization steps are needed. > > Martin > > On Thu, Feb 1, 2018 at 10:53 AM, Jay Talbott <JayTalbott@sysproconsulting. > com> wrote: > >> I got this question from a client yesterday that I didn’t know how to >> answer because I focus primarily on the porting effort (getting coreboot to >> build and boot for their hardware) and let the client figure out how they >> want to manage the resulting code base once the porting effort is complete. >> So I offered to inquire of the coreboot community to see if anybody can >> provide an answer for my client. >> >> >> >> Below is the inquiry that I received: >> >> >> >> I’m looking at how best to structure our coreboot repositories. Does the >> coreboot build system support the concept of external patches? With >> buildroot you can keep your changes is a directory tree separate from the >> FOSS tree. Then during the build step your patches get applied and compiled >> using another separate build tree. >> >> >> >> Thanks, >> >> >> >> - Jay >> >> >> >> Jay Talbott >> Principal Consulting Engineer >> SysPro Consulting, LLC >> 3057 E. Muirfield St. >> Gilbert, AZ 85298 >> (480) 704-8045 >> (480) 445-9895 (FAX) >> JayTalbott(a)sysproconsulting.com >> >> http://www.sysproconsulting.com >> >> >> >> -- >> 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

Does the coreboot build system support external patches?
by Jay Talbott 01 Feb '18

01 Feb '18

I got this question from a client yesterday that I didn't know how to answer because I focus primarily on the porting effort (getting coreboot to build and boot for their hardware) and let the client figure out how they want to manage the resulting code base once the porting effort is complete. So I offered to inquire of the coreboot community to see if anybody can provide an answer for my client. Below is the inquiry that I received: I'm looking at how best to structure our coreboot repositories. Does the coreboot build system support the concept of external patches? With buildroot you can keep your changes is a directory tree separate from the FOSS tree. Then during the build step your patches get applied and compiled using another separate build tree. Thanks, - Jay Jay Talbott Principal Consulting Engineer SysPro Consulting, LLC 3057 E. Muirfield St. Gilbert, AZ 85298 (480) 704-8045 (480) 445-9895 (FAX) <mailto:JayTalbott@sysproconsulting.com> JayTalbott(a)sysproconsulting.com <http://www.sysproconsulting.com/> http://www.sysproconsulting.com

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 February 2018