coreboot October 2017

coreboot@coreboot.org

66 participants
140 discussions

Re: [coreboot] KGPE-D16/KCMA-D8 TPM support?
by Taiidan＠gmx.com 07 Oct '17

07 Oct '17

On 10/07/2017 11:14 AM, Thierry Laurion wrote: > Any input on TPM since that post? I am planning on beginning to work on > heads KGPE-D16 heads support, server/workstation on which Qubes v4 actually > works. Initialisation of TPM throws errors on from Qubes, but it isn't > owned yet, and haven't played with it yet. I found this. http://anzwix.com/a/Coreboot/Mbasuskgped16AddTPMSupport So yeah it seems it works, with the appropriate module. From the reviews on that it seems it doesn't work on older motherboards as it is a TPM 2.0 - I would ask asus as to which version the boards support. > > Bought this <https://www.amazon.ca/dp/B01EU542SG/>. > Thierry FYI there are a lot of independent small retailers that have better prices than amazon when it comes to this board family and accessories, next time you buy something input the model number in your favorite search engine. (ex: amazon has kcma-d8 for $280, other places have it for $250 - and you don't have to support AI research if you buy from them) Also thanks for doing heads for this, it would be nice for it to support some actually libre boards - and it is good to promote these boards for qubes as well as they are truly great for it (lots of cores, ram and expansion slots) > > Le mer. 23 août 2017 à 11:27, Peter Stuge <peter(a)stuge.se> a écrit : > >> Taiidan(a)gmx.com wrote: >>> Does anyone know what TPM's are compatible? >> Sorry, can't help with that. >> >> >>> I also want to know what coreboot's tpm support is like these days, such >>> as how can you perform an erase/reset like one could with a standard OEM >>> bios. >> Is that in the realm of the BIOS? SeaBIOS does have some TPM support >> upstream, and there have been one or two patchsets hanging around for >> quite a while. They make a fairly complete impression - they may all >> be upstream already..? >> >> >> //Peter >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > >

1 0

KGPE-D16/KCMA-D8 TPM support?
by Taiidan＠gmx.com 07 Oct '17

07 Oct '17

Does anyone know what TPM's are compatible? I also want to know what coreboot's tpm support is like these days, such as how can you perform an erase/reset like one could with a standard OEM bios. - Thanks in advance

3 2

SMM save area in MSRs on newer intel CPUs
by ron minnich 07 Oct '17

07 Oct '17

can someone point me at the documents that describe how this works? thanks ron

1 0

Re: [coreboot] [RFC] Successful build with GCC 7.2 and IASL 20170831 for coreboot 4.7
by Paul Menzel 07 Oct '17

07 Oct '17

Dear Patrick, Am Freitag, den 06.10.2017, 15:03 +0200 schrieb Patrick Georgi: > 2017-10-06 9:43 GMT+02:00 Paul Menzel: > > Having the code base compatible with future toolchains is quite > > important and convenient in my opinion. > > That's a great argument to switch out the toolchain 4 months before a release. > Which means 3.5 months ago. > > > Especially for bisecting an issue, people don’t rebuild the toolchain > > in each step. > > Which means that no matter what we do to crossgcc, there's no reproducibility. > That's not a good argument for doing something or anything at all. > > > The good side is, that most warnings and errors of newer toolchains > > actually point out real problems – most of them don’t affect anything > > though –, so fixing those would be a good thing. > > Fixing real issues? Yes, please. > Swapping out the entire code optimizer phase, potentially introducing > regressions through no code change at all in coreboot itself? Not at > this time. Just to make sure, that there is no misunderstanding. I am not proposing to updating to GCC 7.2 and the latest IASL in the coreboot toolchain for the coreboot 4.7 release. My proposal is, that all the boards are made compatible with these new versions, and that these patches are added to the coreboot 4.7 release. Thanks, Paul

1 0

Re: [coreboot] Ability to remotely debug the grub menu in case of boot failure
by ron minnich 06 Oct '17

06 Oct '17

On Fri, Oct 6, 2017 at 6:54 AM Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > > as always, your other other choice is to use linux in flash as a > bootstrap, and then have the full spectrum of x-over-network solutions that > you get from that. That's my new (old) approach nowadays. > > Hello Ron, > > As my best understanding, Ron, you would like to have Linux kernel with > initramfs as payload, and then to pass execution thread to GRUB2. > > you added a step we don't need :-) linux starts, and starts our u-root userland (u-root.tk). u-root does a dhclient, wget, gpgv, kexec (all this is written in Go). You kexec linux. There's no grub used in this setup. 2 weeks ago I started an OCP winterfell node booting this way. This was NERF with linux and u-root in flash. it was about 20 seconds for a full cycle of linux in flash, dhclient, wget, kexec. I ran it 10,000 times, got bored, turned it off. It works really, really well. ron

1 0

Re: [coreboot] Ability to remotely debug the grub menu in case of boot failure
by ron minnich 06 Oct '17

06 Oct '17

On Fri, Oct 6, 2017 at 3:22 AM Anshuman Aggarwal < anshuman.aggarwal(a)gmail.com> wrote: > Ron, > Do you have any link to point me towards developing this solution. I > get at a high level what you are suggesting but would like to reuse > whatever work has already been done towards this. If the technique is > widely used, what do I google or look around for? > > > I see several options. I should also mention that one company, coraid, used an ethernet console for years in their products. This has been done before, starting decades ago. You can look at the NETCONSOLE in the linux kernel and see if that will work. I used it for years at los alamos. You can see about porting the cec code to linux. It is available here, https://github.com/Harvey-OS/harvey/blob/master/sys/src/9/port/devcec.c, and it has been reworked to compiled with gcc or clang, so it's matter of shimming it in. For best results, put it into linux as a vfs, not a device. If you do want to do that port to linux, and do it as a VFS, I'm interested in helping. Note that in plan 9 devices look like a linux vfs so it's not a huge stretch. Further, when we ported the capabiltiy device from plan 9 to linux, it became an fs in linux, so there's precedent. I think putting an IP stack into firmware is an endless task, and it won't be fun. Just put linux in firmware and use all the goodness, including working IP6 stack, that comes with it. I'm back to doing that in both UEFI (via NERF) and coreboot and it works just fine. ron

1 0

Re: [coreboot] Intel Leaf Hill Coreboot Trouble
by Cameron Craig 06 Oct '17

06 Oct '17

Hi Tahnia, > I am unfortunately not able to help you, since I myself am still new to coreboot (and to BIOS development in general). No worries, we'll get there eventually :) > When you ran the Intel-provided version (stitched with the Windows tool), did you experience any similar problems with the USB controller in U-Boot? If so, did you manage to solve it? We are looking at this at the moment. Early investigation suggests that U-Boot needs a device tree for Leaf Hill. Without that, U-Boot isn't aware of ant USB controllers, SPI Flash, PCI devices or anything. That's all I know at the moment, you might be better asking in the U-Boot mailing list. Unfortunately it looks like Intel don't bother providing a device tree for Leafhill. So we may end up writing our own, which I hear is a bit pernickety. 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

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

06 Oct '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 new defect(s) introduced to coreboot found with Coverity Scan. 4 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 3 of 3 defect(s) ** CID 1381621: Code maintainability issues (UNUSED_VALUE) /src/soc/intel/common/block/smm/smitraphandler.c: 110 in smihandler_southbridge_monitor() ________________________________________________________________________________________________________ *** CID 1381621: Code maintainability issues (UNUSED_VALUE) /src/soc/intel/common/block/smm/smitraphandler.c: 110 in smihandler_southbridge_monitor() 104 /* IOTRAP(0) SMIC */ 105 if (IOTRAP(0)) { 106 if (!(trap_cycle & (1 << 24))) { /* It's a write */ 107 printk(BIOS_DEBUG, "SMI1 command\n"); 108 /* Trapped write data */ 109 data = pcr_read32(PID_PSTH, PCR_PSTH_TRPD); >>> CID 1381621: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "data & mask" to "data" here, but that stored value is overwritten before it can be used. 110 data &= mask; 111 } 112 } 113 114 printk(BIOS_DEBUG, " trapped io address = 0x%x\n", 115 trap_cycle & 0xfffc); ** CID 1379849: Null pointer dereferences (FORWARD_NULL) /src/soc/intel/skylake/pmutil.c: 220 in soc_get_gpe_configs() ________________________________________________________________________________________________________ *** CID 1379849: Null pointer dereferences (FORWARD_NULL) /src/soc/intel/skylake/pmutil.c: 220 in soc_get_gpe_configs() 214 215 /* Look up the device in devicetree */ 216 DEVTREE_CONST struct device *dev = dev_find_slot(0, PCH_DEVFN_PMC); 217 if (!dev || !dev->chip_info) { 218 printk(BIOS_ERR, "BUG! Could not find SOC devicetree config\n"); 219 } >>> CID 1379849: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "dev". 220 config = dev->chip_info; 221 222 /* Assign to out variable */ 223 *dw0 = config->gpe0_dw0; 224 *dw1 = config->gpe0_dw1; 225 *dw2 = config->gpe0_dw2; ** CID 1379848: Null pointer dereferences (FORWARD_NULL) /src/soc/intel/skylake/pmutil.c: 223 in soc_get_gpe_configs() ________________________________________________________________________________________________________ *** CID 1379848: Null pointer dereferences (FORWARD_NULL) /src/soc/intel/skylake/pmutil.c: 223 in soc_get_gpe_configs() 217 if (!dev || !dev->chip_info) { 218 printk(BIOS_ERR, "BUG! Could not find SOC devicetree config\n"); 219 } 220 config = dev->chip_info; 221 222 /* Assign to out variable */ >>> CID 1379848: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "config". 223 *dw0 = config->gpe0_dw0; 224 *dw1 = config->gpe0_dw1; 225 *dw2 = config->gpe0_dw2; 226 } 227 228 int rtc_failure(void) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] Ability to remotely debug the grub menu in case of boot failure
by Zoran Stojsavljevic 06 Oct '17

06 Oct '17

> as always, your other other choice is to use linux in flash as a bootstrap, and then have the full spectrum of x-over-network solutions that you get from that. That's my new (old) approach nowadays. Hello Ron, As my best understanding, Ron, you would like to have Linux kernel with initramfs as payload, and then to pass execution thread to GRUB2. [1] Am I correct? [2] If [1] is Y, how you'll pass thread of execution to grub2? [A] in UEFI case, how you'll execute grubx64.efi (this case is anyhow impossible to do), since payload MUST be Tiano Core/EDK2??? [B] How you'll pass it in the legacy case? How you will from Linux access MBR and transfer thread of execution there (to boot core.img with modules at the address 0000:7c00)?! Or maybe, I am not getting something here? Thank you, Zoran _______ On Wed, Oct 4, 2017 at 5:29 PM, ron minnich <rminnich(a)gmail.com> wrote: > as always, your other other choice is to use linux in flash as a > bootstrap, and then have the full spectrum of x-over-network solutions that > you get from that. That's my new (old) approach nowadays. > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Intel Leaf Hill Coreboot Trouble
by Tahnia Lichtenstein 06 Oct '17

06 Oct '17

Hi Cameron, I am unfortunately not able to help you, since I myself am still new to coreboot (and to BIOS development in general). However, I have also tried to produce a bootable image with the outdated Intel provided release of coreboot and U-Boot for Leafhill. The image does run, but U-Boot cannot start the USB controller, so I cannot load an OS (Yocto, in this case) via USB. When I run the U-Boot "usb start" command, it says "No controllers found". When you ran the Intel-provided version (stitched with the Windows tool), did you experience any similar problems with the USB controller in U-Boot? If so, did you manage to solve it? I am not sure where to start debugging this problem! I tried to build U-Boot myself and changed the U-Boot configuration to include USB controllers (which is disabled in the config provided by the Intel patch), but this produced a lot of "redeclaration of symbols" warnings and made no difference to what I see in run-time. (Modified config attached). Like Peter said earlier... "Firmware development is lots of fun! :)" Best regards, Tahnia On Wed, Sep 27, 2017 at 2:01 PM, Cameron Craig <Cameron.Craig(a)exterity.com> wrote: > Hi All, > > > > I’m currently trying to get coreboot working on an Intel Leaf Hill > development board, we are using U-Boot as a payload. > > > > I have managed to create a bootable image using an out of date copy of > coreboot and U-Boot, provided by Intel under NDA. > > The stitching process used to generate the image is a little ugly: a set > of Windows tools are provided (or pointed at) by Intel to stitch the > various blobs together to create an 8MB image. > > We would like to move away from this process. Using the cbfs tool it looks > like we are getting a legacy image composed entirely of a single CBFS. > > > > However, as far as I understand, the latest coreboot release (v4.6) should > be capable of producing a 16MB working image without the use of external > tools. > > This is of course dependent on the provision of the correct binary blobs > such as the FSP, flash descriptor and IFWI. > > I have attached the descriptor of the IFWI image being used. > > > > This is the process I have followed in order to generate a coreboot image: > > 1. Clone coreboot (v4.6) > > 2. Obtain Apollo Lake FSP from Intel (https://github.com/IntelFSP/ > FSP) > > 3. Split FSP into its constituent parts (https://raw. > githubusercontent.com/tianocore/edk2/master/IntelFsp2Pkg/Tools/ > SplitFspBin.py) > > 4. Extract Flash Descriptor from an existing Leaf Hill UEFI image > (./ifdtool --extract leaf_hill_ref_board_uefi.bin) > > 5. Obtain IFWI image from Intel (Apollo Lake Technical Library) > > 6. make menuconfig (config file is attached) > > a. Mainboard > > i. Mainboard > vendor (Intel) > > ii. Mainboard > model (Leafhill) > > iii. [*] > Use IFWI Stitching > > iv. (IFWI) > section in .fmd file to place IFWI blob > > v. (IFWI_SPI.bin) > Path to image coming from FIT Tool > > vi. (descriptor.bin) > path to descriptor.bin > > vii. (Fsp_M.fd) > path to FSP-M.Fv blob > > viii. (Fsp_S.fd) > path to FSP-S.Fv > > b. Payload > > i. Add > a payload (U-Boot (Experimental)) > > ii. U-Boot > version (v2016.1) > > iii. (coreboot-x86_defconfig) > U-Boot config file > > c. The rest are at Leaf Hill defaults. > > 7. make > > 8. Flash image to Leaf Hill SPI flash > > > > As far as I can tell, this process should produce a working image. > > However it does not. My most recent attempt has managed to blink the > PWR_OK LED, suggesting the PMIC/PMC is working, but no serial messages. > > Other than that, I currently have no working theories as to what the root > cause is L > > > > Is there anything obviously wrong with this process? > > Are there any bugs that I should be aware of relating to coreboot on an > Apollo Lake platform? > > I haven’t found a lot of documentation online to describe the exact > configuration and blob usage, are there any relevant sources of > documentation you could point me towards? > > > > Any help to answer the above, or any other advice would be greatly > appreciated. > > > > Cheers, > > Cameron > > > > Cameron Craig | Graduate Software Engineer | Exterity Limited > tel: +44 1383 828 250 <+44%201383%20828250> | fax: > e: Cameron.Craig(a)exterity.com | w: www.exterity.com > > <http://www.exterity.com> > [image: ISO9001] <http://www.exterity.com/iso9001> [image: LinkedIn] > <http://www.linkedin.com/company/exterity> [image: Twitter] > <http://www.twitter.com/exterity> [image: YouTube] > <http://www.youtube.com/user/exterityiptv> > Exterity is a leading provider of IP Video and Digital Signage solutions > that helps organizations to harness the power of video to communicate, > educate and entertain. Our end-to-end solutions enable you to take TV and > video content directly from any source and manage its delivery, live or on > demand, to any connected device via your existing network. For more > information or to schedule a product demonstration, contact Exterity on +44(0)1383 > 828 250 <+44%201383%20828250> or visit www.exterity.com > > Legal Notice > Unless expressly stated otherwise, this message is confidential and may be > privileged. It is intended for the addressee(s) only. Access to this e-mail > by anyone else is unauthorized. If you are not an addressee, any disclosure > or copying of the contents of this e-mail or any action taken (or not > taken) in reliance on it is unauthorized and may be unlawful. If you are > not an addressee, please inform the sender immediately. > > Exterity Limited is registered in Scotland under No. 225313 with its > registered office at St Davids House, St Davids Drive, Dalgety Bay, KY11 9NB > > > ______________________________________________________________________ > 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

← Newer
1
...
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 October 2017