coreboot September 2018

coreboot@coreboot.org

59 participants
160 discussions

Re: [coreboot] Flashing Coreboot on Lenovo G505s
by Nico Huber 23 Sep '18

23 Sep '18

On 9/23/18 7:26 PM, Matt B wrote: > Speaking of microcode, I've seen on other threads that the microcode has to > be manually updated for some boards, and for the g505s this is especially > complicate with many manual steps. Can anyone provide a more explicit > series of steps than the below? Is this something being worked on? I might be wrong on this (not experienced with AMD) but usually you can apply microcode updates much easier from the OS (e.g. firmware updates to a state sufficient to boot; OS updates to the final microcode with all current fixes). Nico

2 1

Flashing Coreboot on Lenovo G505s
by Anac 23 Sep '18

23 Sep '18

Greetings Following various recommendations on Lenovo G505s, I finally got myself a A10-5750M with dedicated GPU. At least I think it has dedicated graphics, due to the following output: # inxi -G Card-1: AMD Richland [Radeon HD 8650G] Card-2: AMD Sun Pro [Radeon HD 8570A/8570M] While waiting for some AliExpress deliveries, I'd like to ask a few questions that worry me. I have never flashed anything, but I'm used to Linux, the command line and soldering. A) According to http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate either a Bus Pirate or a CH341A programmer is needed for flashing CoreBoot. LibreBoot folks can just take a Raspberry Pi (or better a Beagle Bone Black) and a SOIC clip, while CoreBoot needs more equipment. Why is that? Somewhere it reads that the CH341A was faster than BusPirate. But is it faster than a Raspi or BeagleBone? Btw. Flashrom does in fact support RaspberryPi: https://www.flashrom.org/RaspberryPi The reason for asking is because I really don't want to brick anything and/or destroy the G505s. And I don't know how to operate a CH341A and feel that I'm not really in control of this whole undertaking. Hence, I'm trying to keep things as clear and easy as possible. B) The instructions on http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate#Fl… suggest the following order of operations: 1) receive a flashrom help 2) erase a flash chip 3) read from a flash chip 4) write to a flash chip 5) verify a flash chip against the file But should't the original content of the flash chip first got read and saved before erasing it? Just in case anything goes wrong and the original BIOS would be needed for some reason? So, step 2 and 3 are to be swapped, right? C) Which Coreboot version should I use? v4.6 or the newest v4.8.1 ? I remember @Taiidan mentioning that he used v4.6 and somewhere else it reads that there will be some major changes after v4.8. Should I avoid it? D) About flashing KB9012: Is it advisable to flash it with Origami-EC ? Getting rid of serial numbers sounds nice. But is it save to do? Or is there a risk of bricking the KB9012? http://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate E) This machine is going to be a Qubes workstation. Are there any special Coreboot options for Qubes OS that one should be aware of? Thank you! And thanks for all the work that the good folks from dangerousprototypes have done and shared!

4 4

Re: [coreboot] Flashing Coreboot on Lenovo G505s
by Matt B 23 Sep '18

23 Sep '18

Some additional origami info. A talk from last year: https://ecc2017.coreboot.org/uploads/talk/presentation/51/origami-ec-status… Some info in a thread from earlier this year: https://mail.coreboot.org/pipermail/coreboot/2018-February/086107.html The git repo: https://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary I haven't heard anything more up to date. It appears the author also has his hands full with some (pretty cool) replicant work. -Matt On Sun, Sep 23, 2018 at 1:26 PM Matt B <matthewwbradley6(a)gmail.com> wrote: > Hi, > I'm in basically the same situation, having just got a g505s. I'm looking > at chronicling my experience on an ifixit article as I go, though I don't > really have any time right now while in class. Right now the winter break > looks most likely for some serious coreboot fun. > > Sadly, the ebay seller sent me a G505s without discrete graphics chip when > one with a chip was advertised. All things considered though, the machine > is in really good condition and the discrete graphics chip afaik doesn't > work in coreboot (yet) and has to be disabled to boot successfully (that > and crossfire never caught on) so I'm not too broken up about it. Still if > it ever is supported properly, it might make a nice machine learning > accelerator even if crossfire graphics never gets good support. (and there > are tempting replacement boards for 60 bucks available should I get > adventurous.) > > As for your questions: > A) I would have thought pi would work, though I haven't looked at all into > the flashing procedure yet > B) I would back up the factory image SEVERAL times and compare them to > make sure they're the same before doing anything > C) See above answers. idk on this, haven't got there yet > D) Flash with factory EC firmware. Origami is an *amazing* project, but > it's still going to be a bit before even "just boots the board" is possible > E) There was something a long time ago about using HVM (hardware > virtualization) causing Qubes to freeze on the G505s under coreboot. I > don't know if it was ever resolved or could even be reproduced. I think at > the very least you want to have the most up-to-date microcode patch to fix > a RANGE of issues (irq privilege escalation, IOMMU bugs, proper spectre V2 > mitigation, ect.) with the stock microcode that's burned into the CPU. > > Speaking of microcode, I've seen on other threads that the microcode has > to be manually updated for some boards, and for the g505s this is > especially complicate with many manual steps. Can anyone provide a more > explicit series of steps than the below? Is this something being worked on? > > Regarding a NOTE from your last message: >> > For microcode embedding in coreboot to work you must check >> > both the "generate microcode update from tree" option and the >> > "use non-free blob repo" option - >> > doing the first but not the second will result in a silent fail. >> It works for KGPE-D16 but doesn't work for G505S and maybe some other >> AMD boards. Currently the only working way for those "other boards" to >> get the latest microcodes is to " xxd -i -c 8 " a microcode binary and >> then put this array of hex values into their .c file containing a >> microcode ( path like [1] ) . Tired of doing this manually, yesterday >> I wrote these microcode updating scripts : >> https://review.coreboot.org/c/coreboot/+/28425 >> AMD microcodes: scripts for applying the unofficial (not-merged-yet) >> updates >> Put those 4 files to your freshly cloned coreboot directory, >> run ./get_ucode_patches.sh , ./check... and ./apply... , >> and your fresh coreboot now has the latest microcodes ;-) >> But thats only for those "other boards" like G505S. To get the latest >> microcode for your KGPE-D16, you may also need to patch its' >> microcode_amd_fam15h.bin with a new 2018 microcode which sadly is not >> merged yet neither to linux-firmware nor to coreboot >> [1] example of a path to .c file with microcode - >> >> ./coreboot/src/vendorcode/amd/agesa/f16kb/Proc/CPU/Family/0x16/KB/F16KbId7001MicrocodePatch.c > > > That's from this thread here: > https://mail.coreboot.org/pipermail/coreboot/2018-August/087279.html > There are also instructions in this thread, that I can't make sense of: > https://mail.coreboot.org/pipermail/coreboot/2018-August/087150.html > > Sincerely, > -Matt > > On Sun, Sep 23, 2018 at 10:09 AM awokd via coreboot <coreboot(a)coreboot.org> > wrote: > >> Anac: >> > Greetings >> > >> > Following various recommendations on Lenovo G505s, I finally got myself >> > a A10-5750M with dedicated GPU. At least I think it has dedicated >> > graphics, due to the following output: >> > >> > # inxi -G >> > >> > Card-1: AMD Richland [Radeon HD 8650G] >> > Card-2: AMD Sun Pro [Radeon HD 8570A/8570M] >> > >> > While waiting for some AliExpress deliveries, I'd like to ask a few >> > questions that worry me. I have never flashed anything, but I'm used to >> > Linux, the command line and soldering. >> > >> > A) >> > According to >> > >> http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate >> > either a Bus Pirate or a CH341A programmer is needed for flashing >> > CoreBoot. LibreBoot folks can just take a Raspberry Pi (or better a >> > Beagle Bone Black) and a SOIC clip, while CoreBoot needs more >> equipment. >> > Why is that? >> > Somewhere it reads that the CH341A was faster than BusPirate. But is it >> > faster than a Raspi or BeagleBone? >> > Btw. Flashrom does in fact support RaspberryPi: >> > https://www.flashrom.org/RaspberryPi >> > >> > The reason for asking is because I really don't want to brick anything >> > and/or destroy the G505s. And I don't know how to operate a CH341A and >> > feel that I'm not really in control of this whole undertaking. Hence, >> > I'm trying to keep things as clear and easy as possible. >> >> No special hardware requirements for Coreboot vs. Libreboot. As long as >> Flashrom supports it, the Raspi should work fine. >> >> > B) >> > The instructions on >> > >> http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate#Fl… >> > suggest the following order of operations: >> > 1) receive a flashrom help >> > 2) erase a flash chip >> > 3) read from a flash chip >> > 4) write to a flash chip >> > 5) verify a flash chip against the file >> > >> > But should't the original content of the flash chip first got read and >> > saved before erasing it? Just in case anything goes wrong and the >> > original BIOS would be needed for some reason? So, step 2 and 3 are to >> > be swapped, right? >> >> Not sure what step #2 is for there. I'd make a backup image of the >> existing flash, then write the new one. >> >> > C) >> > Which Coreboot version should I use? v4.6 or the newest v4.8.1 ? I >> > remember @Taiidan mentioning that he used v4.6 and somewhere else it >> > reads that there will be some major changes after v4.8. Should I avoid >> it? >> >> Try newest, go back to older if problems. >> >> > D) >> > About flashing KB9012: Is it advisable to flash it with Origami-EC ? >> > Getting rid of serial numbers sounds nice. But is it save to do? Or is >> > there a risk of bricking the KB9012? >> > http://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary >> > http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate >> >> Have not attempted. If you want to, recommend getting Coreboot working >> first, then work on it separately. >> >> > E) >> > This machine is going to be a Qubes workstation. Are there any special >> > Coreboot options for Qubes OS that one should be aware of? >> >> See some further discussion here: >> http://dangerousprototypes.com/docs/Lenovo_G505S_hacking >> >> > Thank you! And thanks for all the work that the good folks from >> > dangerousprototypes have done and shared! >> > >> > >> > >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> >

1 0

Re: [coreboot] Loading Linux payloads on RISC-V
by ron minnich 23 Sep '18

23 Sep '18

ah sorry I forgot. I think selfboot could be reworked (and should be) to interpret "0" as "somewhere useful"? On Sat, Sep 22, 2018 at 10:47 PM ron minnich <rminnich(a)gmail.com> wrote: > shouldn't we fix the riscv kernel build process? it's producing bad elf > files? > > On Sat, Sep 22, 2018 at 4:40 PM Jonathan Neuschäfer <j.neuschaefer(a)gmx.net> > wrote: > >> Hi, >> >> we've discussed this briefly at OSFC: Linux's ELF file (vmlinux) >> currently has segments starting at 0x0 (if you look at the physical >> address field) and an entry point at 0xffffffe000000000: >> >> > $ readelf -l vmlinux >> > >> > Elf file type is EXEC (Executable file) >> > Entry point 0xffffffe000000000 >> > There are 3 program headers, starting at offset 64 >> > >> > Program Headers: >> > Type Offset VirtAddr PhysAddr >> > FileSiz MemSiz Flags Align >> > LOAD 0x0000000000001000 0xffffffe000000000 >> 0x0000000000000000 >> > 0x000000000000ffce 0x000000000000ffce R E 0x1000 >> > LOAD 0x0000000000011000 0xffffffe000010000 >> 0x0000000000010000 >> > 0x00000000002cda3c 0x00000000002cda3c RWE 0x1000 >> > NOTE 0x00000000002dea00 0xffffffe0002dda00 >> 0x00000000002dda00 >> > 0x000000000000003c 0x000000000000003c R 0x4 >> > >> > Section to Segment mapping: >> > Segment Sections... >> > 00 .init.text >> > 01 .init.data .exit.text .data..percpu .text .softirqentry.text >> .rodata __param __modver .srodata .data __bug_table .sdata .bss __ex_table >> .notes >> > 02 .notes >> >> >> coreboot's SELF loader rightly points out that 0x0 is not in RAM: >> >> > Loading segment from ROM address 0x00000000200287b8 >> > code (compression=0) >> > New segment dstaddr 0x0 memsize 0xffce srcaddr 0x2002880c filesize >> 0xffce >> > Loading segment from ROM address 0x00000000200287d4 >> > code (compression=0) >> > New segment dstaddr 0x10000 memsize 0x2cda3c srcaddr 0x200387da >> filesize 0x2cda3c >> > Loading segment from ROM address 0x00000000200287f0 >> > Entry Point 0xffffffe000000000 >> > SELF Payload doesn't target RAM: >> > Failed Segment: 0x0, 65486 bytes >> > 0. 0000000080000000-0000000080011fff: RAMSTAGE >> > 1. 0000000080012000-000000008003ffff: RAM >> > 2. 0000000080040000-0000000080044fff: RAMSTAGE >> > 3. 0000000080045000-00000000fffdbfff: RAM >> > 4. 00000000fffdc000-00000000ffffffff: CONFIGURATION TABLES >> > 5. 0000000100000000-000000027fffffff: RAM >> > Payload not loaded. >> >> >> How should we solve this? >> >> One option I see is to keep CONFIG_PAYLOAD_ELF as is, and add quirks to >> CONFIG_PAYLOAD_LINUX. >> >> >> Jonathan >> >

1 0

how users can control additional features?
by Alexander Couzens 23 Sep '18

23 Sep '18

Hi, I would like to merge https://review.coreboot.org/c/coreboot/+/12888 But how the user can control this feature (and all other "special features")? Should coreboot add an acpi function and the OS offer a UI (e.g. /sys/class/foo/feature)? Add a nvram option? (and set a acpi variable based on nvram, so we don't need SMM) Any other idea? Best, lynxis -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

3 2

Thinkpad H8 EC Registers
by Nathaniel Roach 23 Sep '18

23 Sep '18

Hi all, I'm trying to get the USB_ALWAYS_ON toggle between AC_ONLY and AC_AND_BATTERY working, so I'm asking if anyone has any notes on the EC registers (X220 specifically, but broader notes welcome). I've got some diffs from the Lenovo BIOS but I can't identify the flag. I think that the non-functional 0x0D flag in the original USB_ALWAYS_ON patch gets fed straight to the charge controller, and that might explain why it behaves a little weirdly. Alternatively any other ideas are welcome too! Cheers, Nathaniel.

1 0

Flashing Coreboot on Lenovo G505s
by Anac 23 Sep '18

23 Sep '18

1 0

Loading Linux payloads on RISC-V
by Jonathan Neuschäfer 22 Sep '18

22 Sep '18

Hi, we've discussed this briefly at OSFC: Linux's ELF file (vmlinux) currently has segments starting at 0x0 (if you look at the physical address field) and an entry point at 0xffffffe000000000: > $ readelf -l vmlinux > > Elf file type is EXEC (Executable file) > Entry point 0xffffffe000000000 > There are 3 program headers, starting at offset 64 > > Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > LOAD 0x0000000000001000 0xffffffe000000000 0x0000000000000000 > 0x000000000000ffce 0x000000000000ffce R E 0x1000 > LOAD 0x0000000000011000 0xffffffe000010000 0x0000000000010000 > 0x00000000002cda3c 0x00000000002cda3c RWE 0x1000 > NOTE 0x00000000002dea00 0xffffffe0002dda00 0x00000000002dda00 > 0x000000000000003c 0x000000000000003c R 0x4 > > Section to Segment mapping: > Segment Sections... > 00 .init.text > 01 .init.data .exit.text .data..percpu .text .softirqentry.text .rodata __param __modver .srodata .data __bug_table .sdata .bss __ex_table .notes > 02 .notes coreboot's SELF loader rightly points out that 0x0 is not in RAM: > Loading segment from ROM address 0x00000000200287b8 > code (compression=0) > New segment dstaddr 0x0 memsize 0xffce srcaddr 0x2002880c filesize 0xffce > Loading segment from ROM address 0x00000000200287d4 > code (compression=0) > New segment dstaddr 0x10000 memsize 0x2cda3c srcaddr 0x200387da filesize 0x2cda3c > Loading segment from ROM address 0x00000000200287f0 > Entry Point 0xffffffe000000000 > SELF Payload doesn't target RAM: > Failed Segment: 0x0, 65486 bytes > 0. 0000000080000000-0000000080011fff: RAMSTAGE > 1. 0000000080012000-000000008003ffff: RAM > 2. 0000000080040000-0000000080044fff: RAMSTAGE > 3. 0000000080045000-00000000fffdbfff: RAM > 4. 00000000fffdc000-00000000ffffffff: CONFIGURATION TABLES > 5. 0000000100000000-000000027fffffff: RAM > Payload not loaded. How should we solve this? One option I see is to keep CONFIG_PAYLOAD_ELF as is, and add quirks to CONFIG_PAYLOAD_LINUX. Jonathan

2 1

Re: [coreboot] Tianocore and TPM
by You, Benjamin 22 Sep '18

22 Sep '18

Hi Jorge, Could you please try setting gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid to the expected value (0x286bf ...) in your .dsc file? Since there has been a change of the Tmp2IntanceLib, this GUID setting has to be changed accordingly. Since these are generic UEFI / EDKII questions and not Coreboot payload specific, could you please try posting further questions to the EDKII mailing list (https://lists.01.org/mailman/listinfo/edk2-devel)? -- there are much more EDKII expertise there. Thanks, - ben From: Jorge Fernandez Monteagudo [mailto:jorgefm@cirsa.com] Sent: Friday, September 21, 2018 10:04 PM To: You, Benjamin <benjamin.you(a)intel.com>; coreboot(a)coreboot.org Subject: Re: [coreboot] Tianocore and TPM Hi Benjamin, Enabling debug messages I've found something: Loading driver FDFF263D-5F68-4591-87BA-B768F445A9AF InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 8F3EE7C0 PDB = /mnt/develop/bettong/coreboot/master/coreboot_tiano_master/payloads/external/tianocore/tianocore/Build/CorebootPayloadPkgX64/DEBUG_COREBOOT/X64/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe/DEBUG/Tcg2Dxe.dll Loading driver at 0x0008F3D2000 EntryPoint=0x0008F3D2240 Tcg2Dxe.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 8F3EEA18 ProtectUefiImageCommon - 0x8F3EE7C0 - 0x000000008F3D2000 - 0x000000000000D800 PROGRESS CODE: V03040002 I0 WARNING: Tpm2RegisterTpm2DeviceLib - does not support 286BF25A-C2C3-408C-B3B4-25E6758B7317 registration TPM2 not detected! Error: Image at 0008F3D2000 start failed: Unsupported PDB = /mnt/develop/bettong/coreboot/master/coreboot_tiano_master/payloads/external/tianocore/tianocore/Build/CorebootPayloadPkgX64/DEBUG_COREBOOT/X64/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe/DEBUG/Tcg2Dxe.dll PROGRESS CODE: V03040003 I0 I'll try to find more info about this warning and I'll try to see the code where the TPM2 is detected in the edk2-staging branch ________________________________________ De: coreboot <coreboot-bounces(a)coreboot.org> en nombre de Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com> Enviado: viernes, 21 de septiembre de 2018 13:01:23 Para: You, Benjamin; coreboot(a)coreboot.org Asunto: Re: [coreboot] Tianocore and TPM Hi, I'll try modifying the Setup/Miscs/Setup.ini from CustomizationSample/Boards/Qemu to enable ftpm and generate an external payload but when boot with this coreboot.rom flashed I only get a black screen once the tianocore is executed with the next traces: BS: BS_PAYLOAD_LOAD times (us): entry 0 run 101395 exit 0 Jumping to boot code at 006009a0(8fe0f000) CPU0: stack: 8ff20000 - 8ff21000, lowest used address 8ff205e0, stack used: 2592 bytes PROGRESS CODE: V03020003 I0 PROGRESS CODE: V03020002 I0 PROGRESS CODE: V03020003 I0 PROGRESS CODE: V03020002 I0 PROGRESS CODE: V03020003 I0 PROGRESS CODE: V03021001 I0 PROGRESS CODE: V03040003 I0 PROGRESS CODE: V03040002 I0 PROGRESS CODE: V03040003 I0 PROGRESS CODE: V03040002 I0 I've tried mixing the dsc, dec and fdf files from the edk2-staging and the CorebootPayloadPkg ones but no TPM menu in the device manager menu is shown. I'm using NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf instead of NULL|UefiPayloadPkg/Library/Tpm2InstanceLib/Tpm2InstanceLib.inf Is it correct? Or I have to integrate this library in the CorebootPayloadPkg? Now I'm trying with the tianocore master version instead of the stable one. Do you know if there is a TPM menu shown in the device manager menu once is detected? How the TPM2 is detected? Do you have a "generic" CustomizationSample/Board? I think it's more complicated that I expected! Any hint is welcome! Jorge ________________________________________ De: coreboot <coreboot-bounces(a)coreboot.org> en nombre de Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com> Enviado: jueves, 20 de septiembre de 2018 10:31:20 Para: You, Benjamin; coreboot(a)coreboot.org Asunto: Re: [coreboot] Tianocore and TPM Hi Ben, Adding the 'generic' board it's an interesting option as a starting point to develop/porting to new boards. I'll try your suggestion to incorporate the changes from dsc and fdf files to my current working Tianocore coreboot payload. I'll report back the results! Thanks! Jorge ________________________________________ De: You, Benjamin <benjamin.you(a)intel.com> Enviado: jueves, 20 de septiembre de 2018 10:21:55 Para: Jorge Fernandez Monteagudo; coreboot(a)coreboot.org Asunto: RE: [coreboot] Tianocore and TPM Hi Jorge, You could use UEFI Payload's .dsc and .fdf files as a reference and modify the TianoCore CorebootPayload's .dsc and .fdf files accordingly for those TPM related modules. UEFI Payload is under development (in staging area) and hasn't reached the quality standard required by EDKII master. On CustomizationSample/Boards, yes it is required. However, a board's content may be trivial (as in the Qemu folder). Per your suggestion, probably we can add a board named "generic" that has all the minimalized settings so user won't have to create a new one if the "generic" one meets the needs. Thanks! - ben From: Jorge Fernandez Monteagudo [mailto:jorgefm@cirsa.com] Sent: Thursday, September 20, 2018 3:24 PM To: You, Benjamin <benjamin.you(a)intel.com>; coreboot(a)coreboot.org Subject: Re: Tianocore and TPM Hi Ben! Thanks for the info! I have one question. Have I to implement a CustomizationSample/Boards for my board? With the current tianocore payload I don't have to implement nothing to have a working UEFI... Thanks! Jorge ________________________________________ De: You, Benjamin <benjamin.you(a)intel.com> Enviado: jueves, 20 de septiembre de 2018 3:42:33 Para: Jorge Fernandez Monteagudo; coreboot(a)coreboot.org Asunto: RE: Tianocore and TPM Hi, Another note is on the use of NULL|UefiPayloadPkg/Library/Tpm2InstanceLib/Tpm2InstanceLib.inf. This lib is not fully populated right now. Please consider using NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf depending on your needs. Thanks, - ben From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of You, Benjamin Sent: Thursday, September 20, 2018 8:44 AM To: Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com>; coreboot(a)coreboot.org Subject: Re: [coreboot] Tianocore and TPM Hi Jorge, The staging UEFI Payload project (https://github.com/tianocore/edk2-staging/tree/UEFIPayload) has TPM support (although turned off by default, and using "FTPM" as the name (which needs to be fixed)). Please have a look at UefiPayloadPkgIA32X64.dsc for the components under tag "$(FTPM_ENABLE)". These components mainly do the measuring of firmware components and log the results. Also there is parsing logic in Library/PlatformInfoParseLib/ParseLib.c that parses TPM info in ACPI table passed from Coreboot. (This logic hasn't been sufficiently verified as this is still a "staging" project). You might have a try. Please let us know if you see any bugs / problems in these. You might also use the EDKII mailing list for discussing issues with the UEFI Payload. Thanks, - ben From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Jorge Fernandez Monteagudo Sent: Wednesday, September 19, 2018 5:24 PM To: coreboot(a)coreboot.org Subject: [coreboot] Tianocore and TPM Hi all! I'm trying to enable the TPM2 support in the tianocore payload. The TPM2 device is working, because I've enabled the DEBUG_TPM and coreboot reports is up. I guess that I have to modify the 'CorebootPayloadPkgIa32X64.dsc' file to enable the TPM support but there are so many dependencies. Anybody has a working tianocore payload with TPM? Thanks!

1 0

Re: [coreboot] Tianocore and TPM
by Jorge Fernandez Monteagudo 21 Sep '18

21 Sep '18

Hi Benjamin, Enabling debug messages I've found something: Loading driver FDFF263D-5F68-4591-87BA-B768F445A9AF InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 8F3EE7C0 PDB = /mnt/develop/bettong/coreboot/master/coreboot_tiano_master/payloads/external/tianocore/tianocore/Build/CorebootPayloadPkgX64/DEBUG_COREBOOT/X64/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe/DEBUG/Tcg2Dxe.dll Loading driver at 0x0008F3D2000 EntryPoint=0x0008F3D2240 Tcg2Dxe.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 8F3EEA18 ProtectUefiImageCommon - 0x8F3EE7C0 - 0x000000008F3D2000 - 0x000000000000D800 PROGRESS CODE: V03040002 I0 WARNING: Tpm2RegisterTpm2DeviceLib - does not support 286BF25A-C2C3-408C-B3B4-25E6758B7317 registration TPM2 not detected! Error: Image at 0008F3D2000 start failed: Unsupported PDB = /mnt/develop/bettong/coreboot/master/coreboot_tiano_master/payloads/external/tianocore/tianocore/Build/CorebootPayloadPkgX64/DEBUG_COREBOOT/X64/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe/DEBUG/Tcg2Dxe.dll PROGRESS CODE: V03040003 I0 I'll try to find more info about this warning and I'll try to see the code where the TPM2 is detected in the edk2-staging branch ________________________________ De: coreboot <coreboot-bounces(a)coreboot.org> en nombre de Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com> Enviado: viernes, 21 de septiembre de 2018 13:01:23 Para: You, Benjamin; coreboot(a)coreboot.org Asunto: Re: [coreboot] Tianocore and TPM Hi, I'll try modifying the Setup/Miscs/Setup.ini from CustomizationSample/Boards/Qemu to enable ftpm and generate an external payload but when boot with this coreboot.rom flashed I only get a black screen once the tianocore is executed with the next traces: BS: BS_PAYLOAD_LOAD times (us): entry 0 run 101395 exit 0 Jumping to boot code at 006009a0(8fe0f000) CPU0: stack: 8ff20000 - 8ff21000, lowest used address 8ff205e0, stack used: 2592 bytes PROGRESS CODE: V03020003 I0 PROGRESS CODE: V03020002 I0 PROGRESS CODE: V03020003 I0 PROGRESS CODE: V03020002 I0 PROGRESS CODE: V03020003 I0 PROGRESS CODE: V03021001 I0 PROGRESS CODE: V03040003 I0 PROGRESS CODE: V03040002 I0 PROGRESS CODE: V03040003 I0 PROGRESS CODE: V03040002 I0 I've tried mixing the dsc, dec and fdf files from the edk2-staging and the CorebootPayloadPkg ones but no TPM menu in the device manager menu is shown. I'm using NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf instead of NULL|UefiPayloadPkg/Library/Tpm2InstanceLib/Tpm2InstanceLib.inf Is it correct? Or I have to integrate this library in the CorebootPayloadPkg? Now I'm trying with the tianocore master version instead of the stable one. Do you know if there is a TPM menu shown in the device manager menu once is detected? How the TPM2 is detected? Do you have a "generic" CustomizationSample/Board? I think it's more complicated that I expected! Any hint is welcome! Jorge ________________________________ De: coreboot <coreboot-bounces(a)coreboot.org> en nombre de Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com> Enviado: jueves, 20 de septiembre de 2018 10:31:20 Para: You, Benjamin; coreboot(a)coreboot.org Asunto: Re: [coreboot] Tianocore and TPM Hi Ben, Adding the 'generic' board it's an interesting option as a starting point to develop/porting to new boards. I'll try your suggestion to incorporate the changes from dsc and fdf files to my current working Tianocore coreboot payload. I'll report back the results! Thanks! Jorge ________________________________ De: You, Benjamin <benjamin.you(a)intel.com> Enviado: jueves, 20 de septiembre de 2018 10:21:55 Para: Jorge Fernandez Monteagudo; coreboot(a)coreboot.org Asunto: RE: [coreboot] Tianocore and TPM Hi Jorge, You could use UEFI Payload's .dsc and .fdf files as a reference and modify the TianoCore CorebootPayload's .dsc and .fdf files accordingly for those TPM related modules. UEFI Payload is under development (in staging area) and hasn't reached the quality standard required by EDKII master. On CustomizationSample/Boards, yes it is required. However, a board's content may be trivial (as in the Qemu folder). Per your suggestion, probably we can add a board named "generic" that has all the minimalized settings so user won't have to create a new one if the "generic" one meets the needs. Thanks! - ben From: Jorge Fernandez Monteagudo [mailto:jorgefm@cirsa.com] Sent: Thursday, September 20, 2018 3:24 PM To: You, Benjamin <benjamin.you(a)intel.com>; coreboot(a)coreboot.org Subject: Re: Tianocore and TPM Hi Ben! Thanks for the info! I have one question. Have I to implement a CustomizationSample/Boards for my board? With the current tianocore payload I don't have to implement nothing to have a working UEFI... Thanks! Jorge ________________________________________ De: You, Benjamin <benjamin.you(a)intel.com> Enviado: jueves, 20 de septiembre de 2018 3:42:33 Para: Jorge Fernandez Monteagudo; coreboot(a)coreboot.org Asunto: RE: Tianocore and TPM Hi, Another note is on the use of NULL|UefiPayloadPkg/Library/Tpm2InstanceLib/Tpm2InstanceLib.inf. This lib is not fully populated right now. Please consider using NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf depending on your needs. Thanks, - ben From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of You, Benjamin Sent: Thursday, September 20, 2018 8:44 AM To: Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com>; coreboot(a)coreboot.org Subject: Re: [coreboot] Tianocore and TPM Hi Jorge, The staging UEFI Payload project (https://github.com/tianocore/edk2-staging/tree/UEFIPayload) has TPM support (although turned off by default, and using "FTPM" as the name (which needs to be fixed)). Please have a look at UefiPayloadPkgIA32X64.dsc for the components under tag "$(FTPM_ENABLE)". These components mainly do the measuring of firmware components and log the results. Also there is parsing logic in Library/PlatformInfoParseLib/ParseLib.c that parses TPM info in ACPI table passed from Coreboot. (This logic hasn't been sufficiently verified as this is still a "staging" project). You might have a try. Please let us know if you see any bugs / problems in these. You might also use the EDKII mailing list for discussing issues with the UEFI Payload. Thanks, - ben From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Jorge Fernandez Monteagudo Sent: Wednesday, September 19, 2018 5:24 PM To: coreboot(a)coreboot.org Subject: [coreboot] Tianocore and TPM Hi all! I'm trying to enable the TPM2 support in the tianocore payload. The TPM2 device is working, because I've enabled the DEBUG_TPM and coreboot reports is up. I guess that I have to modify the 'CorebootPayloadPkgIa32X64.dsc' file to enable the TPM support but there are so many dependencies. Anybody has a working tianocore payload with TPM? Thanks!

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
16
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 September 2018