coreboot February 2018

coreboot@coreboot.org

49 participants
79 discussions

Asus AM1I-A
by Elisenda Cuadros 10 Feb '18

10 Feb '18

Hello, I'm trying to use Coreboot in an Asus AM1I-A board recently ported by Gergely Kiss (thank you!). I am using the default config settings and added vga rom extracted with UEFITool from the vendor bios. After flashing and booting I get no output from vga. Serial console is extremely slow too (30 minutes to write the log) I attach the coreboot console log, config and cbfs.txt. Any hints? Thanks in advance. Best regards, -- Eli

2 1

kasten.core backdoor? new weird message after each coreboot build
by Mike Banon 10 Feb '18

10 Feb '18

While building a coreboot now I'm getting this "kasten.core" message (see below), it wasn't like that earlier! Tried to search through all the coreboot sources with ' find . -type f -print0 | xargs -0 grep "kasten" ' but no results! So thats not a new coreboot build script. It almost looks like instantly after I complete a coreboot build, something malicious modifies my coreboot.rom file. Haven't analyzed the .rom yet, I wanted to submit these findings as soon as possible. What do you think? Meanwhile I will take my system offline and remove a hard drive from it, so that someone couldn't remotely delete this backdoor before I find it CBFS payload_config CBFS payload_revision CBFS coreboot.rom kasten.core: "/home/mikeb/coreboot/build/coreboot.rom" CBFSPRINT coreboot.rom Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 320396 none fallback/ramstage 0x4e480 stage 131631 none config 0x6e700 raw 84 none revision 0x6e7c0 raw 575 none cmos_layout.bin 0x6ea40 cmos_layout 1164 none fallback/postcar 0x6ef40 stage 13268 none fallback/dsdt.aml 0x72380 raw 9016 none fallback/payload 0x74700 payload 67370 none payload_config 0x84e80 raw 1611 none payload_revision 0x85540 raw 239 none (empty) 0x85680 null 3581720 none s3nv 0x3efdc0 raw 32768 none (empty) 0x3f7e00 null 31704 none bootblock 0x3ffa00 bootblock 928 none Built lenovo/g505s (LENOVO G505S) mikeb@testing:~/coreboot$ kasten.core: "/home/mikeb/coreboot/build/coreboot.rom"

1 0

Re: [coreboot] Custom Layer or Overlay
by David Hendricks 09 Feb '18

09 Feb '18

Hi Naveed, 3rdparty/ is probably what you want. That directory is managed using git submodules: https://review.coreboot.org/cgit/coreboot.git/tree/ Documentation/submodules.txt

1 0

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware
by Youness Alaoui 09 Feb '18

09 Feb '18

On Tue, Feb 6, 2018 at 4:41 AM, Mike Banon <mikebdp2(a)gmail.com> wrote: > 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) > There will probably be some things in common. I don't know how much of ec-1.75 is good enough to be reused though, or if it's maintainable, etc.. but yes, it could be a good starting point. > @ 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 Sure, you can trust hardware flashing more than software flashing, but I really need software flashing. If it was just for me, yeah, I could fiddle with it to flash it by hardware for my personal needs, but when it's about deploying it to all our customer base, that's another story, the only solution is software flashing. Obviously, it would have to work in coreboot, so whatever coreboot is doing wrong (or AMI is doing right.. my guess is that it's probably something with the EC ACPI code), we'd have to figure that out first in order to get the read/write support. > > Latest status update for Origami-EC firmware: > https://www.mail-archive.com/coreboot@coreboot.org/msg50646.html Thanks! Good to see the status update on that. > > 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 > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

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

09 Feb '18

The QEMU x86_64 Q35 fails verification for branch master as of commit 6ee716e863117246d453e573d1a128da28b62cb7 The following tests failed: BOOT_FAILURE Commits since last successful test: 6ee716e drivers/intel/fsp2_0: Remove fsp_find_smbios_memory_info() from FSP2.0 driver 93fde11 soc/intel/cannonlake: Add support for EMMC DLL update 6b78b73 mb/intel/kblrvp: Enable Kabylake RVP8 2a81fed mb/google/poppy/variants/nami: Revise AC/DC loadlines 54fa28e soc/intel/skylake: Clean up SMBIOS Table Type 17 creation <32 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

Custom Layer or Overlay
by Naveed Ghori 09 Feb '18

09 Feb '18

Hi, At the Detroit conference someone mentioned that there can is a place to put proprietary code that is not for checking in to the public coreboot repo. I could not find this information on the coreboot website. Maybe I was looking in the wrong places or using the wrong keyword. Can some please enlighten me as to where to put such code. I believe it was a speicif name folder in the root of the repo. Thanks in advance. Best Regards, Naveed

1 0

Re: [coreboot] Intel soc ACPI generation using soc/intel/common/block/acpi
by Julien Viard de Galbert 08 Feb '18

08 Feb '18

> Le 8 févr. 2018 à 17:24, Aaron Durbin <adurbin(a)google.com> a écrit : > > On Thu, Feb 8, 2018 at 7:20 AM, Julien Viard de Galbert > <jviarddegalbert(a)online.net> wrote: >> Hello all, >> >> First sorry for mailing direclty those of you who are on the coreboot >> mailing list. >> >> I’m currently in the process of upstreaming the changes we have on >> denverton. >> On the ACPI I see a lot in common with the code available in >> soc/intel/common/block/acpi. >> However this depends on PMC which depends on GPIO. And the GPIO code >> conflicts with the code already in denverton so I can’t enable it. (I’ve not >> checked >> In details about the PMC code yet). >> >> What would be the best way to port it ? >> >> 1. Stick with what is working, duplicate some code but don’t break other >> platforms. >> 2. Try to refactor the GPIO code and denverton code so they are compatible. >> >> For point 2 the thing is that I can test for other platforms and it will >> really add more >> work now. But if the longterm goal is to refactor all intel soc to mostly >> use common/block >> then this might be worth it. >> >> What are your recommendations? >> > > What are the actual changes in the gpio blocks compared to what's there? I’ve not looked into the datasheet of other chips to see the difference. But the code is really different. The GPIO code in denverton looks like it’s been imported from the EFI code. After looking again, it seams that the underlying hardware is similar (I checked a few bits and they are at the same place). However the ‘user' interface is really different: The denverton uses a configuration structure based on enums and bitfields that is not present in common code. > >> Best Regards >> >> >> -- >> Julien Viard de Galbert - jviarddegalbert(a)online.net >> Online / Scaleway >> Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/ >> >> >> >> >> >> -- >> 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

Intel soc ACPI generation using soc/intel/common/block/acpi
by Julien Viard de Galbert 08 Feb '18

08 Feb '18

Hello all, First sorry for mailing direclty those of you who are on the coreboot mailing list. I’m currently in the process of upstreaming the changes we have on denverton. On the ACPI I see a lot in common with the code available in soc/intel/common/block/acpi. However this depends on PMC which depends on GPIO. And the GPIO code conflicts with the code already in denverton so I can’t enable it. (I’ve not checked In details about the PMC code yet). What would be the best way to port it ? 1. Stick with what is working, duplicate some code but don’t break other platforms. 2. Try to refactor the GPIO code and denverton code so they are compatible. For point 2 the thing is that I can test for other platforms and it will really add more work now. But if the longterm goal is to refactor all intel soc to mostly use common/block then this might be worth it. What are your recommendations? Best Regards -- Julien Viard de Galbert - jviarddegalbert(a)online.net Online / Scaleway Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/

2 1

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

07 Feb '18

The QEMU x86_64 Q35 fails verification for branch master as of commit 2a9e8124e19a1a9143b9461d1f1f114e8e751c8a The following tests failed: BOOT_FAILURE Commits since last successful test: 2a9e812 mb/google/fizz: Set Pmax to 120 for all SKUs dc4bc06 google/kahlee/grunt: Fix 2 device specific variables d242892 mb/amd/gardenia: Remove cmos.layout 4c5a3b6 soc/amd/common: Add generic create_struct call to wrapper c8fcc46 mb/google/poppy/variants/poppy: Enable EC_ENABLE_SECOND_BATTERY_DEVICE <26 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

ThinkPad W520 support
by Nico Rikken 06 Feb '18

06 Feb '18

I'm happy to announce a working patch for the ThinkPad W520: https://review.coreboot.org/#/c/coreboot/+/23564/ Further details on this mainboard can be found on the wiki: https://www.coreboot.org/Board:lenovo/w520 Kind regards, Nico Rikken

3 3

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