coreboot May 2018

coreboot@coreboot.org

51 participants
137 discussions

Re: [coreboot] SPI TPM question
by Jorge Fernandez Monteagudo 20 May '18

20 May '18

Hi Julius! Thanks for the report! It seems it will not be easy to add SPI TPM support... I'm waiting for some TPMs 1.2 and 2.0 over LPC and the demoboard (AMD Bettong) I'm using has the LPC connector available to test.. In the meantime I'll try to find any solution. Regards Jorge ________________________________ De: Julius Werner <jwerner(a)chromium.org> Enviado: sábado, 19 de mayo de 2018 2:05:42 Para: Jorge Fernandez Monteagudo Cc: zaolin(a)das-labor.org; Coreboot Asunto: Re: [coreboot] SPI TPM question > build/romstage/drivers/spi/spi-generic.o: In function `spi_setup_slave': /mnt/develop/bettong/coreboot/master/coreboot/src/drivers/spi/spi-generic.c:129: undefined reference to `spi_ctrlr_bus_map' /mnt/develop/bettong/coreboot/master/coreboot/src/drivers/spi/spi-generic.c:131: undefined reference to `spi_ctrlr_bus_map_count' /mnt/develop/bettong/coreboot/master/coreboot/src/drivers/spi/spi-generic.c:134: undefined reference to `spi_ctrlr_bus_map' This indicates that your chipset does not support the SPI API. Even if the generic TPM SPI driver would work with your TPM, you still need chipset code that tells it how to work with your particular SPI controller. This would usually be part of the southbridge code (e.g. compare src/southbridge/intel/common/spi.c, which defines the spi_ctrlr_bus_map array for some Intel chipsets... although that particular controller would not work for TPMs either). > build/romstage/drivers/spi/tpm/tpm.o: In function `stopwatch_tick': > /mnt/develop/bettong/coreboot/master/coreboot/src/include/timer.h:155: undefined reference to `timer_monotonic_get' > build/romstage/drivers/spi/tpm/tpm.o: In function `stopwatch_init': > /mnt/develop/bettong/coreboot/master/coreboot/src/include/timer.h:131: undefined reference to `timer_monotonic_get' > /mnt/develop/bettong/coreboot/master/coreboot/src/include/timer.h:131: undefined reference to `timer_monotonic_get' > /mnt/develop/bettong/coreboot/master/coreboot/src/include/timer.h:131: undefined reference to `timer_monotonic_get' This indicates that your chipset does not support the monotonic timer API. Without timers the stopwatch API doesn't work that's used by the TPM drivers to measure certain transfer timeouts. Looks like some older AMD CPUs have that support (see src/cpu/amd/family_10h-family_15h/monotonic_timer.c), not sure why yours doesn't (probably nobody ever bothered to add it). > The SPI tpm driver was written for tpm 2.0 only. It's even worse than that... I think the current SPI TPM driver only supports Cr50, which is a special TPM 2.0 with a bunch of custom quirks that is only used in Chromebooks. Patches to expand it to support other TPMs are welcome, of course, but I don't think anybody has worked on that for now.

1 0

Re: [coreboot] SPI TPM question
by Taiidan＠gmx.com 20 May '18

20 May '18

On 05/15/2018 01:53 PM, Jorge Fernandez Monteagudo wrote: > Hi all! > > > This is my first message to the list. Welcome sir! we are always pleased to see new users and companies using coreboot - please feel free to ask any and all questions. Coreboot will be a secure and affordable choice for what I presume is your application. if you wish to use coreboot in a production environment it might be a good idea to inquire with your board vendor as to if you can save money by purchasing "raw" boards without the usual AMI/Phoenix firmware/licenses. > I would like to know if the TPM1.2 is supported through SPI? > > Enabling SPI_TPM and TPM in my board configuration throw an error. From src/drivers/spi/tpm/Kconfig If your company permits I would suggest posting the board model, .config file, etc whenever you have an issue as the wiki advises - remember sure to remove identifiers such as MAC address and serials. > Any options to get TPM1.2 SPI support? I would suggest emailing the people behind the HEADS project such as Trammel Hudson - AFAIK they are the only ones currently doing major coreboot related TPM work and would probably be willing to provide some assistance... https://trmm.net/About and https://github.com/osresearch/heads https://github.com/osresearch/heads/issues/287 - interesting thread

2 1

Re: [coreboot] Exception on Skylake after enabling ACPI timer emulation
by Piotr Król 20 May '18

20 May '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/18/2018 07:53 PM, Youness Alaoui wrote: > Hi Piotr, Hi Youness, > Here's my librem13v2 info as reported by coreboot : CPU: Intel(R) > Core(TM) i7-6500U CPU @ 2.50GHz CPU: ID 406e3, Skylake D0, ucode: > 000000c1 CPU: AES supported, TXT NOT supported, VT supported MCH: > device id 1904 (rev 08) is Skylake-U PCH: device id 9d48 (rev 21) > is Skylake-U Premium IGD: device id 1916 (rev 07) is Skylake ULT > GT2 > > So I can see that we have the exact same CPU, MCH, PCH and IGD, > but there is one difference that I noticed, your line said : CPU: > ID 406e3, Skylake D0, ucode: 00000000 Good catch. I'm not sure why I can't include microcode that I obtained using get_blobs.sh. I marked: CONFIG_CPU_UCODE_BINARIES="cpu_microcode_blob.bin" But my results is: Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 47588 none fallback/ramstage 0xbb00 stage 84189 none vgaroms/seavgabios.bin 0x20440 raw 28672 none config 0x274c0 raw 457 none revision 0x27700 raw 580 none payload_revision 0x27980 raw 239 none (empty) 0x27ac0 null 1240 none fspm.bin 0x27fc0 fsp 389120 none payload_config 0x87000 raw 1682 none (empty) 0x87700 null 2200 none fsps.bin 0x87fc0 fsp 188416 none fallback/postcar 0xb6000 stage 31352 none fallback/dsdt.aml 0xbdac0 raw 12879 none fallback/payload 0xc0d80 simple elf 73920 none (empty) 0xd2e80 null 2877080 none cpu_microcode_blob.bin 0x391540 microcode 0 none (empty) 0x3915c0 null 1976792 none bootblock 0x573fc0 bootblock 49152 none So something wrong with size. I added microcode manually and things look better right now. Thank you. What is correct way to include binary microcode? In PC Engines we had to create our own method [1]. I wonder what would be correct way for tha t. [1] https://github.com/pcengines/coreboot/pull/132/files Best Regards, - -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAlsCA90ACgkQsu5x6Weq nkwJGQ//e5ujrAgQUyV97vEG92kz/nCv8qYKRAUUvjkeq2htz6RMy/FK74HxbOPM ITZvVc14ecWscpNyKCwWeWSAkf9UIxYR4MdN5D7CVsxP1/V3+H0uKi9JbrjPa4qe RVbPTpZC0vvadQ797KbVbj/i/i9B1j06LugAMF+utU0bB8oTb0bl2fliD62G7jbp JJTgX0cXyVQdfKV8593Wiy2lsrIi7nev701Yynpx4Qap+DBMLfQqFB6QEcCVopH0 gNIMnLgkK8PKlwfgj4+puAWnObpKkzaXZY1avoxCVzFllYF9Z9UoiNB8ZFjFEJ6P GkfNe/gxw8Rnh09eZH2z4peE2Ja0MFiBqyfbyiKMj7f1VYK+qEDhBZoV7NM2agZR iExXCINvLvBu8WTkaJ83dKjQwZ+NHqpfngqwdwW9kthMyHLyt0amSyYaJbsHJhAQ CDHaXCNFjvFA7BFSKiBuG4FLc+XMHEFSxP3EGfcWq3aPZ2LmjS/GrwRRHYjDvbBR JxNkppaWXrPRJ7XOmy94g9gL4hmcWD3QX40lqRGyQt0ZWDpG0FgjsoX6GBxhGSCL LH3SGTwYoXKGqUp39YaPPACq0nJtxkTtCMK+ZH0D9Q173lngGewc5BtASgQIGWl6 UW6G8A/EmDmpCFA3xe3Rlj+PWm46w3cBWEizx4pPSYoycMYlSBk= =mfsi -----END PGP SIGNATURE-----

2 1

Re: [coreboot] Proposing a change to Coding Style
by Paul Menzel 19 May '18

19 May '18

Dear Patrick, Am Mittwoch, den 16.05.2018, 17:15 +0200 schrieb Patrick Georgi: > after just running into an issue on the EC code base, I hereby propose that > going forward, we should always wrap conditional blocks in braces, even > one-liners. > That is: > > if (foo) { > bar(); > } > > instead of > > if (foo) > bar(); > > It doesn't hurt too much but saves us from accidentally adding baz() after > bar(), forgetting to add the - now required - braces. If we get rough > consensus over this, I'd change Coding_Style to match. > > Thoughts? Just to clarify, as it is *should* both styles are allowed, or the new style *must* be used going forward? The reason I ask is, that being compatible with the Linux kernel is a good goal to be able to copy code around. Kind regards, Paul

1 0

Re: [coreboot] Building coreboot for Apollo Lake: missing 'IFWI' region
by Julius Werner 18 May '18

18 May '18

I'm not an x86 guy so I don't really know the details here, but I think this might just not work for non-Chrome OS builds yet. The error you get suggests that the problem is about you not having an IFWI section in your FMAP. The FMAP describes the high-level layout of the ROM. Chrome OS has a bunch of custom requirements about what goes into its ROM, so Chrome OS boards usually have a custom "chromeos.fmd" file to supply the FMAP. For normal x86 builds, the build system uses util/cbfstool/default-x86.fmd where a bunch of values get filled in by the toplevel Makefile.inc. This mechanism was designed for the old-style Intel flash layout where the reset vector was at the end of the ROM. Apollolake looks quite different, and I don't really know all the details, but somehow the reset vector is interwoven with that IFWI thing near the front of the ROM. You can see an example Chrome OS Apollolake FMAP in src/mainboard/google/reef/chromeos.fmd, and compare it to a normal Chrome OS x86 FMAP like src/mainboard/google/glados/chromeos.fmd . The Apollolake support was added by Chrome OS folks, so maybe they didn't bother adapting the default-x86.fmd mechanism to work with it because all the Chrome OS boards have their own FMAP anyway. You may be able to get further in your build if you copy the reef/chromeos.fmd file, adapt it to your mainboard if necessary, and then point to it with CONFIG_FMDFILE. On Thu, May 10, 2018 at 11:33 PM Hal Martin <hal.martin(a)gmail.com> wrote: > Hi all, > I am trying to build coreboot for an Apollo Lake platform. I've read the coreboot presentation on Apollo Lake, and some of the threads about the IFWI on the coreboot mailing list: > https://www.coreboot.org/images/2/23/Apollolake_SoC.pdf > https://mail.coreboot.org/pipermail/coreboot/2017-November/085482.html > https://mail.coreboot.org/pipermail/coreboot/2017-September/085217.html > After reading this and digesting the information for a week, I'm still no closer to understanding how the build process is supposed to work. > I have extracted the descriptor from the SPI image, and put the entire 16MB image in the 3rdparty directory. When I try to build coreboot, I'm getting the following error: > Image written successfully to build/cbfs/fallback/ifwi.bin.tmp. > Image does not contain sub-partition OBBP(6). > Sub-partition IBBP(4) entry IBBL replaced from file build/cbfs/fallback/bootblock.bin. > Image written successfully to build/cbfs/fallback/ifwi.bin.tmp. > E: Image is missing 'IFWI' region > E: The image will be left unmodified. > src/soc/intel/apollolake/Makefile.inc:137: recipe for target 'files_added' failed > make: *** [files_added] Error 1 > Attached is the output of ifdtool and ifwitool for the SPI dump of the vendor firmware for platform I'm working on. > A few interesting observations (from my perspective): > - There doesn't seem to be an OBBP in this image. > - My ifwitool output seems to match the output of others (e.g. https://mail.coreboot.org/pipermail/coreboot/2017-September/085210.html ) > - This platform (CompuLab Fitlet 2) only has SPI flash, no EMMC. My understanding is that IFWI is the same whether it's on EMMC or SPI. > Some open questions I have: > - Is it possible to build a flashable image using only coreboot and a dump of the vendor firmware, or does one need to use the Intel FSP and FIT tools and some "stitching" to get a flashable image with a coreboot payload? > - Is there any public documentation available describing the FSP 2.0/IFWI flash layout? > - Is it possible to obtain FIT for Apollo Lake without having an NDA or corporate account with Intel? It seems that absolutely everything about Apollo Lake is classified as "confidential" on Intel's website: https://www.intel.com/content/www/us/en/design/products-and-solutions/proce… > Can anyone who was working on an FSP 2.0 platform (e.g. Cameron Craig, Paul Penz, Morris) follow up on how they managed to build a flashable image? > Thanks, > Hal > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] SPI TPM question
by Julius Werner 18 May '18

18 May '18

> build/romstage/drivers/spi/spi-generic.o: In function `spi_setup_slave': /mnt/develop/bettong/coreboot/master/coreboot/src/drivers/spi/spi-generic.c:129: undefined reference to `spi_ctrlr_bus_map' /mnt/develop/bettong/coreboot/master/coreboot/src/drivers/spi/spi-generic.c:131: undefined reference to `spi_ctrlr_bus_map_count' /mnt/develop/bettong/coreboot/master/coreboot/src/drivers/spi/spi-generic.c:134: undefined reference to `spi_ctrlr_bus_map' This indicates that your chipset does not support the SPI API. Even if the generic TPM SPI driver would work with your TPM, you still need chipset code that tells it how to work with your particular SPI controller. This would usually be part of the southbridge code (e.g. compare src/southbridge/intel/common/spi.c, which defines the spi_ctrlr_bus_map array for some Intel chipsets... although that particular controller would not work for TPMs either). > build/romstage/drivers/spi/tpm/tpm.o: In function `stopwatch_tick': > /mnt/develop/bettong/coreboot/master/coreboot/src/include/timer.h:155: undefined reference to `timer_monotonic_get' > build/romstage/drivers/spi/tpm/tpm.o: In function `stopwatch_init': > /mnt/develop/bettong/coreboot/master/coreboot/src/include/timer.h:131: undefined reference to `timer_monotonic_get' > /mnt/develop/bettong/coreboot/master/coreboot/src/include/timer.h:131: undefined reference to `timer_monotonic_get' > /mnt/develop/bettong/coreboot/master/coreboot/src/include/timer.h:131: undefined reference to `timer_monotonic_get' This indicates that your chipset does not support the monotonic timer API. Without timers the stopwatch API doesn't work that's used by the TPM drivers to measure certain transfer timeouts. Looks like some older AMD CPUs have that support (see src/cpu/amd/family_10h-family_15h/monotonic_timer.c), not sure why yours doesn't (probably nobody ever bothered to add it). > The SPI tpm driver was written for tpm 2.0 only. It's even worse than that... I think the current SPI TPM driver only supports Cr50, which is a special TPM 2.0 with a bunch of custom quirks that is only used in Chromebooks. Patches to expand it to support other TPMs are welcome, of course, but I don't think anybody has worked on that for now.

1 0

Re: [coreboot] Exception on Skylake after enabling ACPI timer emulation
by Banik, Subrata 18 May '18

18 May '18

Great Youness. I guess you got the point it might be ucode. Sent from my iPhone > On 18-May-2018, at 11:23 PM, Youness Alaoui <kakaroto(a)kakaroto.homelinux.net> wrote: > > coreboot :

1 0

Re: [coreboot] [RFH] Status of the Lenovo X201
by qtux 18 May '18

18 May '18

I uploaded a status report for the X201 and it contains the smashed stack message. Since then I booted several times but was not able to reproduce this stack smashing issue. It seems like that this kind of error occurs only once after flashing. Please find attached a diff of the notable differences of a new console log compared to the one I pushed to board-status. It supports that there is an issue with the initial raminit. Cheers, Matthias On 02/05/18 20:12, ron minnich wrote: > Yeah I think you want to hunt this stack smash error down, it's not > something you want to ignore. > > On Wed, May 2, 2018 at 11:09 AM Kyösti Mälkki <kyosti.malkki(a)gmail.com> > wrote: > >> On Wed, May 2, 2018 at 8:53 PM, Nico Huber <nico.h(a)gmx.de> wrote: >>> On 02.05.2018 18:37, qtux wrote: >>>> Thanks for your detailed explanation. So in essence shall I ignore the >>>> messages or blacklist lpc_ich? >>> >>> Yes, either ;) >>> >>>> >>>> Besides, while preparing the status report, I sometimes find a "Smashed >>>> stack detected in romstage!" message in the console log, just before >>>> ramstage is starting. Is there something to worry about there? >>> >>> Um, yes. I think that's not good. But I wonder why it's not happening >>> consistently. >> >> I commented about that earlier in this thread. Seemed like actual >> raminit eats a lot of stack, but loading from MRC cache or equivalent >> does not. One could find that struct and move it to BSS, declared with >> CAR_GLOBAL. I would rather not extend the boundary for stack-smashing >> detection. >> >> Kyösti >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >

1 1

Non-working PS/2 on KGPE-D16
by Piotr Kubaj 18 May '18

18 May '18

Hi, I'd like to use PS/2 ports in my KGPE-D16. That's why I want to connect my mouse and keyboard to it (and free USB ports). Both mouse and keyboard have USB plugs (I use adapters), but I have also old PS/2 keyboard used for tests. The problem is that neither mouse nor keyboard work with coreboot (both work with stock BIOS). I set CONFIG_SEABIOS_PS2_TIMEOUT=3000 in coreboot config. I use SeaBIOS with default config and verified that it contains CONFIG_PS2PORT=y (both configs extracted from rom are attached). I use coreboot tag 4.8.1. I also attach serial log with debug_level Spew and SeaBIOS debug level 7 (which adds PS/2 related entries). Could anyone help me trace this issue? -- _______________________________________ / We can predict everything, except the \ \ future. / --------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||

1 0

Re: [coreboot] Proposing a change to Coding Style
by Julius Werner 18 May '18

18 May '18

Looks like I'm a little too late and outnumbered here, but I really don't like this. It moves us away from kernel style unnecessarily, which both makes importing code more cumbersome and adds cognitive load to the many of us that regularly work on both coreboot and Linux. I also agree with the vertical space issue Vadim mentioned -- source code lines aren't free (in your brain). The "danger" of this should be an absolute non-issue if we have checkpatch, because it will just catch that. I also have to admit I saw a problem with this maybe once in 5 years, I'm really surprised that everyone thinks this is a big deal.

1 0

← Newer
1
2
3
4
5
6
7
8
...
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 May 2018