coreboot November 2017

coreboot@coreboot.org

61 participants
110 discussions

Re: [coreboot] Who has experience with the Intel RVP7 (or RVP15) CRB?
by Nico Huber 04 Nov '17

04 Nov '17

Hi Matt, Jay, On 04.11.2017 03:25, Matt DeVillier wrote: > Hi Jay, > > the SKL/KBL FSP blob published on Github is compatible with the headers > currently in coreboot, with the exception of the MEMORY_INFO_DATA_HOB - as > is, coreboot will not be able to parse the HOB and populate the SMBIOS > tables (minor adjustment needed, see: https://pastebin.com/Um9m7X43), but > otherwise it should boot and run without issue (at least it does on the > handful of SKL devices I've used it with, using both DDR3 and DDR4). The > FSP signatures absolutely should match, so I'm not sure why you're seeing > otherwise I'm not sure what versions you are comparing, I see many more diffe- rences between Kabylake FSP from github (54b6a31) and upstream sky- kabylake in coreboot (b2b2015, see attachment). Also in UPD values (SpiFlashCfgLockDown and ThreeStrikeCounterDisable were added to FSPS UPD, the former is used in coreboot). Do I miss something? Is there another more recent published binary? Nico > > -Matt > > On Fri, Nov 3, 2017 at 7:26 PM, Jay Talbott <JayTalbott(a)sysproconsulting.com >> wrote: > >> I’m trying to get coreboot up and running on an Intel RVP15 CRB, which is >> the same as the RVP7 except that the RVP15 has DDR4 memory instead of DDR3. >> >> >> >> There is a mainboard solution for the RVP7 in coreboot. However, the >> current KabyLake FSP published on GitHub doesn’t seem like it’s the right >> FSP for the SkyLake-U/KabyLake-U. If nothing else, there’s a problem with >> that FSP such that the signature in the FSP-M UPD header does not match the >> signature in the corresponding header files, so when the FSP 2.0 driver in >> coreboot goes to check that they are a match, execution dies right there. >> >> >> >> if (upd->FspUpdHeader.Signature != FSPM_UPD_SIGNATURE) >> >> die("Invalid FSPM signature!\n"); >> >> >> >> (coreboot/src/drivers/intel/fsp2_0/memory_init.c, in function >> do_fsp_memory_init) >> >> >> >> I don’t want to bypass that check in the code in case the FSP posted to >> GitHub isn’t the right FSP for this particular SoC… >> >> >> >> Obviously, somebody at Intel has the right FSP that works for these boards >> in order to validate that the coreboot implementation worked prior to >> upstreaming it to the repo. I’m just not sure how to get the right one so >> that I can get this booting. >> >> >> >> Furthermore, I have yet to get the serial console working on the DB-9 >> serial port. I have the jumpers on the board configured to connect it to >> UART #2, and configured in coreboot accordingly, but I get nothing for >> console output. >> >> >> >> Any help would be most appreciated! >> >> >> >> Thanks, >> >> >> >> - Jay >>

2 1

Re: [coreboot] BayTrail PCIe problems (hangup) in FSP (in U-Boot)
by Wolfgang Denk 04 Nov '17

04 Nov '17

Hallo Zoran, In message <CAGAf8LzBUfqdWN74Kh3SGdSOPiLa4GUKT+Gr-kEN_A9NQShnZQ(a)mail.gmail.com> you wrote: > > Let us involve in this discussion Mr Denk (father of U-Boot, I know Mr Denk > personally)), and Mr Glass (option [B] here mentioned below)... For the > (targeted by me) purposes (History involved)! You drop me here into some thread, and even though you write "History involved", your quoting style does not really make clear who i writing what in response to which statements by whom :-( Read: I don't know what you want. > > peter(a)stuge.se writes: > > I think you are actively hurting the overall ecosystem by working on a > different > > project (FSP in U-Boot) which overlaps with Coreboot efforts. > > Peter (Stuge), > > This is VERY correct statement... You already mentioned: It is NOT INTEL > FSP, per say? I don't understand either of this. Multiple implementations of the same feature / multiple solutions for the same problem have never been a bad thing per se. On contrary, in masy cases they have been an essential requisite to enable technical progress. Of course, it is always possible to step on someone's toes, but I am not sure above statement is a result of this. So without deeper understanding I disagree with both statemen't - with Peter's, as different projects for the same thing are not necessarily bad, and with your's that this was true. > It is something I am fighting for years for/in the STRONG interests of > U-Boot/Open Source: to have consistent strategy with INTEL IOTG management > which they ignored/have dominant/aggressive strategy to walk over the Open > Source people, people at all (please, INTEL Legal, try to oppose me.. Be my > guests, make my day, I know U R watching)?! No Intel address is on Cc: - so who do you suspect to be reporting to Intel legal? > *> peter(a)stuge.se <peter(a)stuge.se> writes:* > > *> The only thing that makes sense is for U-Boot to focus on being a > payload that is started by coreboot (this has already been done) and for > your issues to be solved within the coreboot frame.* I can imagine a bunch of other scenarios which use vanilla U-Boot without coreboot at all. I can see no technical reason why x86 must be different from all other architectures where U-Boot boots directly. > Peter (Stuge), > > Although I DO 100% agree with you what you did write (about U-Boot > politics) in your very first email about DENX Systems (surprising, isn't > it), with the *last statement* presented here do NOT agree at all!? > > This is a (mild per say denial) noise, my dear friend. "BS" (sorry)... To > start Coreboot FSP and then to have U-Boot payload as third stage boot > loader??? > > GOOGLE would like to have this as concept, don't you agree (huge > controlling interests involved)? > > NOPE! NO GO. Please. Please?! ;-) > > Peter... Zoran - It is totally impossible here to tell who wrote wich part of this. From your context, I would guess this was Peter, but from the working it looks more like yourself. Please do yourself and all of us the favour and use clean, unmistablable quoting, so it is definitely clear who wrote what. Otherwise you are just feeding sparks of a potential flame war by (mis-) attributing text. > > On Fri, Nov 3, 2017 at 4:32 AM, Alexander Couzens <lynxis(a)fe80.eu> wrote: > > Do you tried to use coreboot (w/o FSP) + u-boot instead? Or is this out > of scope? > > This is complete nonsense, and you all know it... Forced by INTEL to > protect their own interests, in very cruel/selfich way! NO GO! Please! I don't think this is the way to further a constructive discussion. > I did NOT want to offend anybody in this list (if anybody, after all, feels > offended), At The End of The Day, I do NOT care... But you all should think > what I really wrote here... So, you use a flame thrower, and then you don't care? Such behaviour is usually called trolling... Thanks, but no. Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de "Once they go up, who cares where they come down? That's not my department." - Werner von Braun

3 2

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building
by Zoran Stojsavljevic 04 Nov '17

04 Nov '17

> Zoran, and others, > > I wanted to build coreboot for APL CRP too. Tried to compile but failed at last command I think. First email thread to read ([coreboot] Intel Leaf Hill Coreboot Trouble): https://mail.coreboot.org/pipermail/coreboot/2017-September/085210.html Second community thread to read (to get the idea about APL-I IFWI): https://embedded.communities.intel.com/thread/13129 Please, let us know if these threads are helpful! Zoran On Fri, Nov 3, 2017 at 2:14 AM, ahW@n via coreboot <coreboot(a)coreboot.org> wrote: > Zoran, > > and others, > > > > I wanted to build coreboot for APL CRP too. > > Tried to compile but failed at last command I think. > > > > *Image written successfully to build/cbfs/fallback/ifwi.bin.tmp.* > > *INFO: Performing operation on 'IFWI' region...* > > *E: Image is missing 'IFWI' region* > > *E: The image will be left unmodified.* > > *src/soc/intel/apollolake/Makefile.inc:128: recipe for target > 'files_added' failed* > > *make: *** [files_added] Error 1* > > > > Have been searching around for solution and correct steps to do so but > still no luck... > > Have you get your APL coreboot working? > > > > I tried CONFIG_IFWI_FILE_NAME pointed to an original UEFI BIOS file > (direct SPI flashable binary, tested). > > Also tried use FIT to regenerate new file with changes below:- > > Platform Protection/Platform Integrity OOEM Public Key Hash => 00..00 > > Platform Protection/Boot Guard Configuration/ Boot profile 2 => 0 > > > > I am not sure I have the correct .config > > Anyone here can advise what I am doing wrong or am I missing anything? > > Thank you. > > > > user@localhost:~/coreboot$ build/util/cbfstool/cbfstool > build/coreboot.rom print > > Name Offset Type Size Comp > > cbfs master header 0x0 cbfs header 32 none > > fallback/romstage 0x80 stage 26852 none > > cpu_microcode_blob.bin 0x69c0 microcode 0 none > > fallback/ramstage 0x6a40 stage 67533 none > > vgaroms/seavgabios.bin 0x17280 raw 26624 none > > config 0x1db00 raw 424 none > > revision 0x1dd00 raw 576 none > > fallback/postcar 0x1df80 stage 16464 none > > fallback/dsdt.aml 0x22040 raw 99 none > > fallback/payload 0x22100 payload 63073 none > > payload_config 0x317c0 raw 1632 none > > payload_revision 0x31e80 raw 239 none > > (empty) 0x31fc0 null 8052440 none > > mrc.cache 0x7dfec0 mrc_cache 65536 none > > (empty) 0x7eff00 null 32664 none > > bootblock 0x7f7ec0 bootblock 32768 none > > > > user@localhost:~/coreboot$ build/util/cbfstool/ifwitool > ./build/cbfs/fallback/ifwi.bin.tmp print > > Header BPDT > > Signature 0x000055aa > > Descriptor count 13 > > BPDT Version 1 > > XOR checksum 0x0 > > IFWI Version 0x0 > > FIT Tool Version 0x472000c00000003 > > BPDT entries > > Entry # Sub-Partition Name > Type Flags > Offset Size File Offset > > ============================================================ > ============================================================ > ============================================================ > ===================== > > 1 DLMP CSE_IDLM > 9 0x00000000 0x0 > 0x0 0x0 > > 2 IFP_OVERRIDE IFP_OVERRIDE > 10 0x00000000 0x200 > 0x10 0x200 > > 3 S_BPDT S-BPDT > 5 0x00000000 0xe9000 > 0x149000 0xe9000 > > 4 RBEP CSE_RBE > 1 0x00000000 0x69000 > 0xa000 0x69000 > > 5 UFS_PHY UFS Phy > 12 0x00000000 0x0 > 0x0 0x0 > > 6 UFS_GPP UFS GPP > 13 0x00000000 > 0x0 0x0 0x0 > > 7 UEP UEP > 17 0x00000000 0x210 > 0x108 0x210 > > 8 IBBP Bootblock > 4 0x00000000 0x1000 > 0x64000 0x1000 > > 9 SMIP SMIP > 0 0x00000000 0x65000 > 0x4000 0x65000 > > 10 PMCP PMC firmware > 14 0x00000000 0x73000 > 0x10000 0x73000 > > 11 FTPR CSE_BUP > 2 0x00000000 0x83000 > 0x5c000 0x83000 > > 12 UCOD Microcode > 3 0x00000000 0xdf000 > 0x8000 0xdf000 > > 13 DEBUG_TOKENS Debug Tokens > 11 0x00000000 0xe7000 > 0x2000 0xe7000 > > ============================================================ > ============================================================ > ============================================================ > ===================== > > Header S-BPDT > > Signature 0x000055aa > > Descriptor count 3 > > BPDT Version 1 > > XOR checksum 0x0 > > IFWI Version 0x0 > > FIT Tool Version 0x472000c00000003 > > S-BPDT entries > > Entry # Sub-Partition Name > Type Flags Offset > Size File Offset > > ============================================================ > ============================================================ > ============================================================ > ===================== > > 1 IUNP > IUNIT 15 0x00000000 > 0xea000 0x2000 0xea000 > > 2 NFTP CSE_MAIN > 7 0x00000000 > 0xec000 0x106000 0xec000 > > 3 ISHP ISH > 8 0x00000000 0x1f2000 > 0x40000 0x1f2000 > > ============================================================ > ============================================================ > ========================================================== > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

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

03 Nov '17

The ASUS KFSN4-DRE fails verification for branch master as of commit 5bb0d755669765f93d8f3483667476ca14b96585 The following tests failed: BOOT_FAILURE Commits since last successful test: 5bb0d75 amd/stoneyridge: Clarify SPD structure in chip.h 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

Re: [coreboot] BayTrail PCIe problems (hangup) in FSP (in U-Boot)
by Zoran Stojsavljevic 03 Nov '17

03 Nov '17

> I don't understand your note at all Zoran, but I am not alone it seems. I am not one who is asking for help here. It is U-Boot creators, not knowing how to solve (particular) INTEL mess. But if you all agree with this, I have not at all problem with this mess. You asked for it, didn't you, all??? And... You all do the particular solutions. Today reverse engineering, tomorrow some partial SW from who-ever-supplies-this, after tomorrow with the binary blobs. Whatever works better/best for anybody... Today one API, tomorrow another... After tomorrow something completely different! Redesigned APIs, completely. ;-) It seems that I cleared it all, didn't I? Good Luck with the sporadic solutions (whatever works the best/at all in particular cases)! Zoran On Fri, Nov 3, 2017 at 2:48 PM, ron minnich <rminnich(a)gmail.com> wrote: > > > On Fri, Nov 3, 2017 at 5:54 AM Zoran Stojsavljevic < > zoran.stojsavljevic(a)gmail.com> wrote: > >> >> >> Your guy Stefan is here, asking for a help. Stefan got the straight >> answer: FSP/Coreboot (intermingled), then U_Boot as payload... You got that? >> >> >> > > Stefan got a suggestion from me that running u-boot as a coreboot payload > might be easier, as it insulates u-boot from having to deal with FSP. I > also commented that I had no complaint with them running without coreboot, > since the more open source firmware we have the better. Either path is > fine, whatever works best for u-boot. > > I don't understand your note at all Zoran, but I am not alone it seems. > > ron >

1 0

Re: [coreboot] X230 coreboot potential issues?
by Klemens Nanni 03 Nov '17

03 Nov '17

On Thu, Nov 02, 2017 at 09:34:13PM -0400, [799] via coreboot wrote: > Hello Hans, > > On 27.10.2017 22:10, Hans Fritz wrote: > > Hi, I installed coreboot on my X230, > > it works very well > > Would you mind sharing the configuration setting you have chosen? > I am still struggling getting a good Coreboot Config for my X230 which will support Linux and Windows (SeaBIOS). > Currently Resume is not working and I can't switch of my laptop by software. FWIW, see https://mail.coreboot.org/pipermail/coreboot/2017-September/085175.html

1 0

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Cameron Craig 03 Nov '17

03 Nov '17

Hi Tahnia, >* I have all the blobs around coreboot, except the VBIOS... I have tried >all the options in https://www.coreboot.org/VGA_support ><https://www.coreboot.org/VGA_support> , but I suspect the reference >bootloader images provided by Intel does not use a VBIOS file. I also cannot >find a suitable VBIOS on Intel's website. (By the way, thanks for the FIT >decomposition tip, I did not know this was possible... I took great pains to find >the correct blobs on Intel's website, would have been much easier to just use >FIT!) Where did you obtain a VBIOS file? I did manage to get something that *could* be the right vbios blob by using the instructions in the link you just provided. I used UEFITool to open the UEFI BIOS that came with the Leafhill CRB and searched for "VGA Compatible BIOS". I could then extract the blob to a file. As far as I can tell the file that Mario used (vbt.dat) is from the Coreboot package available from Intel. Mario will be able to correct me if I'm wrong. The exact location to download this package escapes me :) Now that I think of it, if anyone does know the Intel website to download the coreboot package (Apollo_Lake_CB_MR3), a reminder of the link would be greatly appreciated. Cheers, Cameron Cameron Craig | Graduate Software Engineer | Exterity Limited tel: +44 1383 828 250 | fax: | mobile: e: Cameron.Craig(a)exterity.com | w: www.exterity.com ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________

1 0

Denverton NS dependency on Harcuvar Board
by Julien Viard de Galbert 03 Nov '17

03 Nov '17

Hello coreboot developers and Denverton Maintainers, As the Denverton support has been integrated, I tried to port our changes over it and see what can be contributed... The first thing I noticed was that there is a hard dependency from the chip to the harcuvar board which looked really wrong and prevented me to add our board. (see bellow for the details) So I propose some changes to fix this in [1] and [2]. [1] https://review.coreboot.org/22309/ [2] https://review.coreboot.org/22310/ I also did a quick port of the Cormorant Lake CRB in [3] and [4]; but as Paul Menzel commented it should probably be a variant instead of a full board. [3] https://review.coreboot.org/22309/ [4] https://review.coreboot.org/22311/ However it serve to demonstrate the issue as Jenkins caught it at [5]: The file "harcuvar_boardid.h" is located in "src/mainboard/intel/harcuvar" but is included from "src/soc/intel/denverton_ns" in "romstage.c" and "chip.c". [5] https://qa.coreboot.org/job/coreboot-gerrit/62870/testReport/(root)/board/I… For the record, the log ends with: | src/soc/intel/denverton_ns/romstage.c:19:30: fatal error: harcuvar_boardid.h: No such file or directory | #include <harcuvar_boardid.h> To conclude, I think the current Cormorant Lake CRB patches can be dropped however I'd like to keep them around until a solution is found (either by merging the patches in [1] and [2]; or any other solutions) Best Regards, Julien VdG P.S.: I'm still learning to use gerrit

1 0

Re: [coreboot] BayTrail PCIe problems (hangup) in FSP (in U-Boot)
by ron minnich 03 Nov '17

03 Nov '17

On Fri, Nov 3, 2017 at 5:54 AM Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > > > Your guy Stefan is here, asking for a help. Stefan got the straight > answer: FSP/Coreboot (intermingled), then U_Boot as payload... You got that? > > > Stefan got a suggestion from me that running u-boot as a coreboot payload might be easier, as it insulates u-boot from having to deal with FSP. I also commented that I had no complaint with them running without coreboot, since the more open source firmware we have the better. Either path is fine, whatever works best for u-boot. I don't understand your note at all Zoran, but I am not alone it seems. ron

1 0

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Tahnia Lichtenstein 03 Nov '17

03 Nov '17

Hi Mario, Thank you very much for sharing, that already helps a lot!! I can spot quite a lot of differences to my own build settings. I've been pursuing a Grub2 payload in the meantime (no success so far), will now return to SeaBIOS and try and incorporate the necessary changes you suggested. Just a couple of questions so far: - Are you able to boot Yocto with the current combination you have? - I have all the blobs around coreboot, except the VBIOS... I have tried all the options in https://www.coreboot.org/VGA_support, but I suspect the reference bootloader images provided by Intel does not use a VBIOS file. I also cannot find a suitable VBIOS on Intel's website. (By the way, thanks for the FIT decomposition tip, I did not know this was possible... I took great pains to find the correct blobs on Intel's website, would have been much easier to just use FIT!) Where did you obtain a VBIOS file? - Is it specifically VBIOS, or is it a VBT.dat file? Or are you running SeaVGABIOS? Many thanks again! Best regards, Tahnia On Fri, Nov 3, 2017 at 2:01 PM, Scheithauer, Mario < Mario.Scheithauer(a)siemens.com> wrote: > > Hi Cameron, > > > Did you modify the FSP blobs at all? > Yes, we made some adjustments for our mainboard (mc_apl1). > But they shouldn’t play a decisive role (power states, PCIe settings). > > > The reason I ask is that my coreboot build hangs in the FspSiliconInit(). > Then you will get pretty far. > We are currently still using the MR2 FSP package for APL-I. > As IFWI template we use the BIOS version v178.10 for the CRBs. > These components are provided by Intel. > That’s it. The CRB should boot with this combination. > > Mario > > > -----Ursprüngliche Nachricht----- > > Von: Cameron Craig [mailto:Cameron.Craig@exterity.com] > > Gesendet: Freitag, 3. November 2017 11:51 > > An: Scheithauer, Mario (DF MC MTS R&D SWRT 4); ahW@n > > Cc: coreboot(a)coreboot.org > > Betreff: Re: [coreboot] Problems changing payload on Intel Leaf Hill > > > > Hi Mario, > > > > I've been attempting to build coreboot(master) for the Leaf Hill CRB, > with no > > success so far. > > > > Did you modify the FSP blobs at all? > > I had a look at your config, the filenames "FSP_MR2_M_ECC_MOD" caught my > > eye. > > > > The reason I ask is that my coreboot build hangs in the FspSiliconInit(). > > > > Cheers, > > Cameron > > > > > > > > Cameron Craig | Graduate Software Engineer | Exterity Limited > > tel: +44 1383 828 250 | fax: | mobile: > > e: Cameron.Craig(a)exterity.com | w: www.exterity.com > > > > > > > > ____________________________________________________________________ > > __ > > This email has been scanned by the Symantec Email Security.cloud service. > > For more information please visit http://www.symanteccloud.com > > ____________________________________________________________________ > > __ > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2017