coreboot July 2017

coreboot@coreboot.org

54 participants
131 discussions

Re: [coreboot] Using Intel e3800 pcu spi to program flash
by Nico Huber 14 Jul '17

14 Jul '17

Hello Graham, the SPI controller for the boot firmware is usually treated as sepa- rated from the OS and therefore not advertised in ACPI. AFAIK, Linux also doesn't have a driver for it. We usually use flashrom [1] to access the firmware flash. It has a special programmer target called `internal` for that (see `man flashrom`). Hope that helps, Nico [1] https://flashrom.org/ On 13.07.2017 13:26, Graham Perkins wrote: > Hi All, > I feel I am going around in circles with this problem. The task at hand is to be able to upgrade coreboot/uefi image in a winbond W25Q64 flash chip from linux. This chip is connected to the PCU SPI interface on the Intel e3805 processor. I know coreboot is writing to this chip without problem from the log: > > SF: Got idcode: ef 60 17 00 00 > SF: Detected W25Q64DW with sector size 0x1000, total 0x800000 > Need to erase the MRC cache region of 65536 bytes at ffd10000 > SF: erase 20 51 0 0 (511000) > SPI: read 0080 from 0090 > SPI: wrote 000c to 0090 > SPI: wrote 06 to 0098 > > However linux is not detecting the flash device or the PCH SPI controller. Disassembling the dsdt table I can see e3800 soc devices such as the HPET and PIC but no PCH SPI. The only SPI device is part of the SIO: > > Device (SPI1) > { > Name (_HID, "80860F0E" /* Intel SPI Controller */) // _HID: Hardware ID > Name (_UID, One) // _UID: Unique ID > Name (_DDN, "SPI Controller #2") // _DDN: DOS Device Name > > My question is does coreboot need to include the PCU SPI controller in the acpi tables and if so how do I do that? > > The platform is a custom design but very similar to the Intel Minnow Turbot board. > > Many thanks, > Graham Perkins. >

2 1

Re: [coreboot] Intel ME The Way of the Static Analysis
by Shawn 14 Jul '17

14 Jul '17

unME11 is released by the speaker: https://github.com/ptresearch/unME11 On Tue, Apr 25, 2017 at 10:38 PM, Shawn <citypw(a)gmail.com> wrote: > slide: > https://www.troopers.de/downloads/troopers17/TR17_ME11_Static.pdf > > video: > https://www.youtube.com/watch?v=2_aokrfcoUk -- GNU powered it... GPL protect it... God blessing it... regards Shawn

1 0

ASUS KFSN4-DRE Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 13 Jul '17

13 Jul '17

The ASUS KFSN4-DRE fails verification for branch master as of commit 4dc9fb026cf1834d5b99baee8f265ad6cebf8fc6 The following tests failed: BOOT_FAILURE Commits since last successful test: 4dc9fb0 soc/intel/skylake: reduce postcar stack usage for fsp 2.0 ce9c883 arch/x86/assembly_entry: Align stack for car_stage_entry c35a1e8 google/butterfly: add function needed for MRC raminit See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE 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

Using Intel e3800 pcu spi to program flash
by Graham Perkins 13 Jul '17

13 Jul '17

Hi All, I feel I am going around in circles with this problem. The task at hand is to be able to upgrade coreboot/uefi image in a winbond W25Q64 flash chip from linux. This chip is connected to the PCU SPI interface on the Intel e3805 processor. I know coreboot is writing to this chip without problem from the log: SF: Got idcode: ef 60 17 00 00 SF: Detected W25Q64DW with sector size 0x1000, total 0x800000 Need to erase the MRC cache region of 65536 bytes at ffd10000 SF: erase 20 51 0 0 (511000) SPI: read 0080 from 0090 SPI: wrote 000c to 0090 SPI: wrote 06 to 0098 However linux is not detecting the flash device or the PCH SPI controller. Disassembling the dsdt table I can see e3800 soc devices such as the HPET and PIC but no PCH SPI. The only SPI device is part of the SIO: Device (SPI1) { Name (_HID, "80860F0E" /* Intel SPI Controller */) // _HID: Hardware ID Name (_UID, One) // _UID: Unique ID Name (_DDN, "SPI Controller #2") // _DDN: DOS Device Name My question is does coreboot need to include the PCU SPI controller in the acpi tables and if so how do I do that? The platform is a custom design but very similar to the Intel Minnow Turbot board. Many thanks, Graham Perkins. Vocality | Cubic Mission Solutions Graham Perkins Senior Software Engineer, Vocality | Cubic Mission Solutions T: +44 1483 813 120 x154 E: graham.perkins(a)vocality.com | W: www.vocality.com A: Lydling Barns, Lydling Farm, Puttenham Lane, Shackleford, Surrey, GU8 6AP

1 0

Re: [coreboot] ultimate VGABIOS extraction! +NEW working way for AMD laptop's discrete GPU
by Nico Huber 12 Jul '17

12 Jul '17

Hi, On 07.07.2017 20:03, Mike Banon wrote: > === ROM locations examples for 0x0 - 0x42F000000 dump made while 16GB RAM: > > 0x000512000 - broken integrated graphics ROM, first "ghost" > 0x3250D9020 - broken integrated graphics ROM, second "ghost" > 0x3578FB000 - broken integrated graphics ROM, third "ghost" > 0x36B22A01C - broken integrated graphics ROM, fourth "ghost" > 0x4122BD000 - broken integrated graphics ROM, fifth "ghost" > > 0x42D3B3000 - working integrated graphics ROM !!! > > 0x42D305020 - working discrete graphics ROM (first working copy, the same) > 0x42E40DCD0 - working discrete graphics ROM (second working copy, the same) nice work! If these are physical addresses, dumping from Linux should come easy: Boot with `iomem=relaxed` in the kernel command line and then as root execute: # dd bs=1 skip=$addr count=64K if=/dev/mem of=dumped.rom where $addr is the physical address. Would be interesting to know, if these lie within a reserved BIOS area of the RAM. If you can confirm that they are physical addresses, please append the output of `dmesg`. Nico

3 2

ASUS KFSN4-DRE Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 12 Jul '17

12 Jul '17

The ASUS KFSN4-DRE fails verification for branch master as of commit 3d384486190c37e8162543fed53da0a7040712d9 The following tests failed: BOOT_FAILURE Commits since last successful test: 3d38448 mb/google/soraka: Do not reset PMIC during sleep See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE 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

cbfstool without cloning the whole repository? Use script for <2M download
by Ivan Ivanov 12 Jul '17

12 Jul '17

Dear friends, sometimes you need to do a few operations with coreboot.rom (e.g. update its' payload) without changing coreboot.rom's main code. If you have bad Internet connection or just want to quickly get the latest version of cbfstool without cloning the whole coreboot/vboot repositories - my bash script below will really help you! It downloads only the files required for the successful compilation of cbfstool - whole ./util/cbfstool directory (93 files, ~1,3M size) and all the dependencies: ./src/commonlib - 20 files, ~152K ./src/vendorcode/intel/edk2/uefi_2.4/ - 26 files, 272K ./src/vendorcode/intel/fsp/fsp1_1/IntelFspPkg/Include/FspInfoHeader.h - ~4K ((( I don't understand what Intel is doing here, but I can't build without these files! ))) ./3rdparty/vboot/firmware/2lib/ - 17 files, 170K ./3rdparty/vboot/firmware/include/vb2_api.h - ~1K In total, its 158 files and just 1.9M - less than 2M ! And it builds OK. Hope it will be useful for you ;-) ### SCRIPT BEGIN ### wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/util/cbfstool/ wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/src/commonlib/ \ --exclude-directories=/cgit/coreboot.git/plain/src/commonlib/storage/ \ --reject=configstring.c,iobuf.c,cbmem_id.h,configstring.h,coreboot_tables.h,\ fmap_serialized.h,iobuf.h,sd_mmc_ctrlr.h,sdhci.h,stdlib.h,storage.h,\ timestamp_serialized.h wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/ed… wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off \ https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/fs… wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off --directory-prefix=./3rdparty/vboot/ \ https://review.coreboot.org/cgit/vboot.git/plain/firmware/2lib/ \ --reject=2api.c,2crc8.c,2hmac.c,2misc.c,2nvstorage.c,2rsa.c,2secdata.c,\ 2secdatak.c,2stub.c,2tpm_bootmode.c,2crc8.h,2hmac.h,2misc.h,\ 2nvstorage_fields.h,2nvstorage.h,2rsa.h,2secdata.h,2tpm_bootmode.h wget --recursive --no-parent --no-host-directories --cut-dirs=3 \ --user-agent="Mozilla/5.0" --execute robots=off --directory-prefix=./3rdparty/vboot/ \ https://review.coreboot.org/cgit/vboot.git/plain/firmware/include/vb2_api.h cd ./util/cbfstool/ make all ### SCRIPT END ###

1 0

USB, IDE and SATA inizialitation
by ingegneriaforense＠alice.it 11 Jul '17

11 Jul '17

Hello everybody, i'm new of this mailing list and is the first time i see the coreboot code (however I know the processors based on Intel Architecture and its language). However I apologize in advance with you if i commit some errors doing my questions. 1- My need is take a look at the coreboot code that set up (inizialize) the USB, IDE and SATA ports. Please, can you tell me in which files i can find the inizialization of the above mentioned interfaces ? My goal is to see if, during the inizialization phase, the coreboot code does, in some way, writing operations into the USB, IDE and SATA drives attached to the corresponding port . 2- If there are case where the coreboot bios communicates with the USB, IDE and SATA periferal drives during the normal user activity and, if so, in which cases this happens. Thanks very much in advance. Best Regards. Vincenzo Di Salvo Forensic Consultant Tribunale di Lecce Studio: Strada di Garibaldi - Contrada Paradisi 73010 Lequile (LE) cell: 339.7968555 skype: vincenzo.di_salvo

2 1

Lenovo Thinkpad X201: coreboot with me_cleaner
by Mono 10 Jul '17

10 Jul '17

Hallo I have tested coreboot with me_cleaner on a Thinkpad X201i but got stuck loading the payload. More precise, I've applied GNUtoo's patch [1] to coreboot master 25dbc17a. Actually I did not try without the patch. Building coreboot with the full 5MB ME extracted from vendor bios works ok (with a GRUB2 payload). But cleaning the rom image produced by coreboot or building a rom image with a cleaned ME file, both results in not loading the payload. The full coreboot console captured via EHCI is attached to this email. It seems RAM init passes. the log shows: ME: FW Partition Table : OK ME: Bringup Loader Failure : NO ME: Firmware Init Complete : NO ME: Manufacturing Mode : NO ME: Boot Options Present : NO ME: Update In Progress : NO ME: Current Working State : Recovery ME: Current Operation State : Bring up ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : BUP Phase ME: Power Management Event : Clean Moff->Mx wake ME: Progress Phase State : Sending DID Ack to BIOS So it seems that cleaning ME was successful, no? But coreboot finishes with the following output: BS: BS_WRITE_TABLES times (us): entry 28752 run 329595 exit 23 CBFS: 'Master Header Locator' located CBFS at [500100:7fffc0) CBFS: Locating 'fallback/payload' CBFS: Found @ offset 44940 size 479ea Loading segment from ROM address 0xffd44a78 code (compression=1) New segment dstaddr 0x8200 memsize 0x17844 srcaddr 0xffd44acc filesize 0x83ae Loading segment from ROM address 0xffd44a94 code (compression=1) New segment dstaddr 0x100000 memsize 0xebccc srcaddr 0xffd4ce7a filesize 0x3f5e8 Loading segment from ROM address 0xffd44ab0 Entry Point 0x00008200 Payload being loaded at below 1MiB without region being marked as RAM usable. SELF Payload doesn't target RAM: Failed Segment: 0x100000, 965836 bytes 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 00000000bf69e000-00000000bf7fffff: CONFIGURATION TABLES 2. 00000000d0000000-00000000dfffffff: RESERVED Payload not loaded. I expected it to load a GURB2 payload which worked before applying me_cleaner. Any idea why it does not and how I could fix it? greets Mono [1] https://mail.coreboot.org/pipermail/coreboot/2017-March/083798.html

1 0

Re: [coreboot] x86: best approach to debug consumer hardware?
by Nico Huber 09 Jul '17

09 Jul '17

On 08.07.2017 15:43, Andrey Korolyov wrote: >> From git logs it looks like configuring the clockgen was needed for the >> x60/t60 port for deeper c-states to work. I'd try to dump the clockgen >> configuration on smbus with block operations ('i2cdump #smbus 0x69 s') >> and configure it using block write operations either in romstage (look >> at thinkpad x201 romstage.c) or in ramstage like is done for the x60 >> (might need some tweaking). >> > > I see, thanks. Previously write to i2c-0/0x69 has been stuck at > romstage, so I kicked it out without looking at the log and therefore > not getting reasons why is was there at first place, Now it is obvious > that C3 is not working correctly without fixing up clock generator. > Previously, also, I blamed incorrect _CST package generation from > copy-paste from T60 for a moment - state descriptions has been > enumerated as 0x1/0x2/0x2 while vendor BIOS has sequentially > enumerated descriptions, still wondering what was the reason to do so. I'd expect the clockgen to be the culprit too. But this C-state number could be a typo and also be the reason for your trouble (though, I'd wonder why it works on the T60). This number is used to map ACPI C-state semantics to the states presented in _CST. ACPI knows three C states and those rarely match the actual C states of the hardware. Basically, a 3 instead of a 2 tells ACPI to flush caches before entering this state. Also, ACPI C3 is to be avoided if bus-master activity is expected. Nico

2 1

← Newer
1
...
6
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2017