coreboot September 2018

coreboot@coreboot.org

59 participants
160 discussions

Re: [coreboot] Loading Linux payloads on RISC-V
by Patrick Rudolph 25 Sep '18

25 Sep '18

Can you make use of the uImage/FIT [1] mechanism coreboot supports ? It just needs some architecture specific code. Can you provide a ling to the Linux calling conventions for riscv ? [1] https://doc.coreboot.org/lib/payloads/fit.html Regards, Patrick On 2018-09-23 04:59 PM, ron minnich wrote: > 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

3 2

Re: [coreboot] Loading Linux payloads on RISC-V
by Jonathan Neuschäfer 25 Sep '18

25 Sep '18

On Mon, Sep 24, 2018 at 09:45:40AM -0600, Aaron Durbin via coreboot wrote: > On Sun, Sep 23, 2018 at 9:00 AM ron minnich <rminnich(a)gmail.com> wrote: > > > > ah sorry I forgot. > > > > I think selfboot could be reworked (and should be) to interpret "0" as "somewhere useful"? Seems like a good idea. And then the entry point also needs to be fixed somehow: Jumping to 0xffffffe000000000 without pagetables won't work. > > Why is the kernel being loaded at 0? As far as I understand it, it's because Linux's linker script[0] doesn't set a physical address. (It sets the virtual address to PAGE_OFFSET, which is 0xffffffe000000000 in the kernels that I have built.) Jonathan [0]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc…

1 0

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
by Jose Trujillo 25 Sep '18

25 Sep '18

Zvika: Sorry I Forgot: "CB_baytrail.bin" is just a renamed copy of "BYT_orig.bin". After that command a new file will be named: "BYT_orig.bin.new" Jose. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, September 25, 2018 10:16 AM, Jose Trujillo <ce.autom(a)protonmail.com> wrote: > Hello Zvika: > > First get the correct original full 8MB FW from the manufacturer or dump it from the board with the command in EFI: > "ftp -d BYT_orig.bin" and double save it. > > 2.- in coreboot/util/ifdtool do make and sudo make install. > 3.- in terminal go to the FW directory and do: "ifdtool BYT_orig.bin -f fw_layout.txt" > a).- in "fw_layout.txt" you will get the BIOS area size from the original FW (just substract). > b).- if the size of the original BIOS is bigger or equal than coreboot build you are good to go ahead. > 4.- copy/move "BYT_orig.bin" in the directory which resides the coreboot folder (not inside the coreboot folder) and do: > ifdtool -i BIOS:./coreboot/build/coreboot.rom CB_baytrail.bin > 5.- flash it: "fpt -f CB_baytrail.bin" booting from UEFI. > > If the build was correctly done and followed accurately those steps the system should boot. > > Good luck, > Jose Trujillo. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Monday, September 24, 2018 10:18 PM, Zvi Vered <veredz72(a)gmail.com> wrote: > >> Hello, >> >> I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: >> >> CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 >> Northbridge: 8086:0f00 (Bay Trail) >> Southbridge: 8086:0f1c (Bay Trail) >> IGD: 8086:0f31 (unknown) >> >> In coreboot configuration I selected: >> Mainboard -> Mainboard model -> Bayley Bay FSP-based CRB >> The default ROM chip size is 2MB. >> This is also the size of coreboot.rom created after "make" >> >> The board has 8MB BIOS flash. >> It's delivered with a BIOS programming utility that runs under EFI shell. >> >> The original BIOS has 2 versions: rom (5MB) and bin (8MB) >> I tried to burn the 2MB coreboot.rom with the vendor's BIOS utlity. >> >> I got: >> 3 - Error: ROM file size does not match existing BIOS size. >> Should I convert coreboot.rom to coreboot.bin ? How ? >> If not, how can I program coreboot.rom ? >> >> Thank you, >> Zvika

1 0

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
by Nico Huber 25 Sep '18

25 Sep '18

Hello Zvika, On 9/24/18 9:18 PM, Zvi Vered wrote: > I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: > > CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 > Northbridge: 8086:0f00 (Bay Trail) > Southbridge: 8086:0f1c (Bay Trail) > IGD: 8086:0f31 (unknown) > > In coreboot configuration I selected: > Mainboard -> Mainboard model -> Bayley Bay FSP-based CRB > The default ROM chip size is 2MB. > This is also the size of coreboot.rom created after "make" > > The board has 8MB BIOS flash. > It's delivered with a BIOS programming utility that runs under EFI shell. is your board related to the Bayley Bay CRB? or is it just a random new Bay Trail board? I'm not sure how much Bay Trail boards differ, but usually you have to adapt a lot settings in coreboot for a new board (like the ROM size). I always advice to check the GPIO and other pin settings first, before trying to boot a new board. > The original BIOS has 2 versions: rom (5MB) and bin (8MB) > I tried to burn the 2MB coreboot.rom with the vendor's BIOS utlity. That's not a good idea. In case the board doesn't boot anymore after- wards (which is likely for a first shot), you need an external flash programmer anyway. Nico

1 0

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

25 Sep '18

Hi Ben, Thanks for your answer! I've been able to trace the 'DxeTpm2MeasureBootHandler' calls and it's called for each loaded driver, the GPT table parsing and PeImage loading. Making a full coreboot and tianocore recompiling has changed the extended values. The tianocore uses PCRs 1, 4, 5 and 7. Changing the boot media from USB device to SATA device changes the PCR5 value. I think it's all working ok. Relating to the TPM device not sufficiently initialized and your side note, maybe is related to the message I get in dmesg: [ 0.390995] tpm_tis 00:02: 2.0 TPM (device-id 0x1A, rev-id 16) [ 0.399957] tpm tpm0: A TPM error (2314) occurred attempting the self test The ACPI table from dmesg is: [ 0.000000] Secure boot could not be determined [ 0.000000] RAMDISK: [mem 0x373bf000-0x379d6fff] [ 0.000000] ACPI: Early table checksum verification disabled [ 0.000000] ACPI: RSDP 0x000000008FDE9000 000024 (v02 CORE ) [ 0.000000] ACPI: XSDT 0x000000008FDE90E0 00006C (v01 CORE COREBOOT 00000000 CORE 00000000) [ 0.000000] ACPI: FACP 0x000000008FDEACA0 0000F4 (v04 CORE COREBOOT 00000000 CORE 00000000) [ 0.000000] ACPI: DSDT 0x000000008FDE9280 001A11 (v02 AMD COREBOOT 00010001 INTL 20161222) [ 0.000000] ACPI: FACS 0x000000008FDE9240 000040 [ 0.000000] ACPI: SSDT 0x000000008FDEADA0 0001E1 (v02 CORE COREBOOT 0000002A CORE 0000002A) [ 0.000000] ACPI: TCPA 0x000000008FDEAF90 000032 (v02 CORE COREBOOT 00000000 CORE 00000000) [ 0.000000] ACPI: APIC 0x000000008FDEAFD0 00007E (v01 CORE COREBOOT 00000000 CORE 00000000) [ 0.000000] ACPI: VFCT 0x000000008FDEB050 00FC69 (v01 CORE COREBOOT 00000000 CORE 00000000) [ 0.000000] ACPI: HPET 0x000000008FDFACC0 000038 (v01 CORE COREBOOT 00000000 CORE 00000000) [ 0.000000] ACPI: HEST 0x000000008FDFAD00 000028 (v01 CORE COREBOOT 00000000 CORE 00000000) [ 0.000000] ACPI: SSDT 0x000000008FDFAD30 00873A (v02 AMD AGESA 00000002 MSFT 04000000) [ 0.000000] ACPI: SSDT 0x000000008FE03470 000854 (v01 AMD AGESA 00000001 AMD 00000001) [ 0.000000] ACPI: Local APIC address 0xfee00000 The ACPI table I get from a different board with closed source BIOS/UEFI but the same processor: [ 0.000000] Secure boot could not be determined [ 0.000000] RAMDISK: [mem 0x373bf000-0x379d6fff] [ 0.000000] ACPI: Early table checksum verification disabled [ 0.000000] ACPI: RSDP 0x00000000E4620000 000024 (v02 ALASKA) [ 0.000000] ACPI: XSDT 0x00000000E4620088 00008C (v01 ALASKA A M I 01072009 AMI 00010013) [ 0.000000] ACPI: FACP 0x00000000E46282F8 000114 (v06 ALASKA A M I 01072009 AMI 00010013) [ 0.000000] ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x0000000000000000/0x1 (20180313/tbfadt-624 ) [ 0.000000] ACPI: DSDT 0x00000000E46201A8 008149 (v02 ALASKA A M I 01072009 INTL 20120913) [ 0.000000] ACPI: FACS 0x00000000E594EF00 000040 [ 0.000000] ACPI: APIC 0x00000000E4628410 00007E (v03 ALASKA A M I 01072009 AMI 00010013) [ 0.000000] ACPI: FPDT 0x00000000E4628490 000044 (v01 ALASKA A M I 01072009 AMI 00010013) [ 0.000000] ACPI: FIDT 0x00000000E46284D8 00009C (v01 ALASKA A M I 01072009 AMI 00010013) [ 0.000000] ACPI: MCFG 0x00000000E4628578 00003C (v01 ALASKA A M I 01072009 MSFT 00010013) [ 0.000000] ACPI: HPET 0x00000000E46285B8 000038 (v01 ALASKA A M I 01072009 AMI 00000005) [ 0.000000] ACPI: UEFI 0x00000000E46285F0 000042 (v01 00000000 00000000) [ 0.000000] ACPI: TPM2 0x00000000E4628638 000034 (v03 ALASKA A M I 00000001 AMI 00000000) [ 0.000000] ACPI: SSDT 0x00000000E4628670 000614 (v01 AMD AGESA 00000001 AMD 00000001) [ 0.000000] ACPI: SSDT 0x00000000E4628C88 004B5B (v02 AMD AGESA 00000002 MSFT 04000000) [ 0.000000] ACPI: CRAT 0x00000000E462D7E8 0002E8 (v01 AMD AGESA 00000001 AMD 00000001) [ 0.000000] ACPI: SSDT 0x00000000E462DAD0 00165E (v01 AMD CPMCMN 00000001 INTL 20120913) [ 0.000000] ACPI: WSMT 0x00000000E462F130 000028 (v01 ALASKA A M I 01072009 AMI 00010013) [ 0.000000] ACPI: Local APIC address 0xfee00000 ... [ 0.557556] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1A, rev-id 16) Where you can see an entry related to TPM2 [ 0.000000] ACPI: TPM2 0x00000000E4628638 000034 (v03 ALASKA A M I 00000001 AMI 00000000) and no error related to TPM2 initialization... It seems all is working ok, but I'll take a look to your side note. Thanks! Jorge ________________________________ De: You, Benjamin <benjamin.you(a)intel.com> Enviado: martes, 25 de septiembre de 2018 8:29:39 Para: Jorge Fernandez Monteagudo; coreboot(a)coreboot.org Asunto: RE: [coreboot] Tianocore and TPM Hi Jorge, Not sure what caused the issue with PCR values ... I am not an expert in TPM. I guess following might be looked at: - Is it possible that the TPM device is not sufficiently initialized? - I noticed SecurityPkg/Library/DxeTpm2MeasureBootLib contains a function DxeTpm2MeasureBootHandler() that measures EDK II drivers. You might trace this function to see if it runs correctly and PCRs are extended successfully for each loaded driver. A side note (not related to this issue) is on parsing TPM info from ACPI tables produced by Coreboot: - The Coreboot Module Package in edk2 repo does *NOT* have the TPM parsing logic. You might refer to ParseTpmTable() in UEFI Payload in edk2-staging repo for codes that do this. Thanks, - ben From: Jorge Fernandez Monteagudo [mailto:jorgefm@cirsa.com] Sent: Monday, September 24, 2018 5:36 PM To: You, Benjamin <benjamin.you(a)intel.com>; coreboot(a)coreboot.org Subject: Re: [coreboot] Tianocore and TPM Hi Ben, Changing gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid do the trick! Now when I boot my system I can see the PCRs 0 to 9 populated. I have some questions regarding the values I see in the PCRs (different versions of coreboot+tianocore populate the PCRs0-7 with the same values) but I'll ask in the UEFI/EDKII mailing list. Attached are the changes I've imported into the tianocore master branch to make it works, if someone else wants to play with it... Thanks for your help! Jorge ________________________________________ De: You, Benjamin <benjamin.you(a)intel.com> Enviado: sábado, 22 de septiembre de 2018 5:33:30 Para: Jorge Fernandez Monteagudo; coreboot(a)coreboot.org Asunto: RE: [coreboot] Tianocore and TPM 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] Burn 2MB coreboot.rom on 8MB flash chip
by Jose Trujillo 25 Sep '18

25 Sep '18

Hello Zvika: First get the correct original full 8MB FW from the manufacturer or dump it from the board with the command in EFI: "ftp -d BYT_orig.bin" and double save it. 2.- in coreboot/util/ifdtool do make and sudo make install. 3.- in terminal go to the FW directory and do: "ifdtool BYT_orig.bin -f fw_layout.txt" a).- in "fw_layout.txt" you will get the BIOS area size from the original FW (just substract). b).- if the size of the original BIOS is bigger or equal than coreboot build you are good to go ahead. 4.- copy/move "BYT_orig.bin" in the directory which resides the coreboot folder (not inside the coreboot folder) and do: ifdtool -i BIOS:./coreboot/build/coreboot.rom CB_baytrail.bin 5.- flash it: "fpt -f CB_baytrail.bin" booting from UEFI. If the build was correctly done and followed accurately those steps the system should boot. Good luck, Jose Trujillo. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, September 24, 2018 10:18 PM, Zvi Vered <veredz72(a)gmail.com> wrote: > Hello, > > I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: > > CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 > Northbridge: 8086:0f00 (Bay Trail) > Southbridge: 8086:0f1c (Bay Trail) > IGD: 8086:0f31 (unknown) > > In coreboot configuration I selected: > Mainboard -> Mainboard model -> Bayley Bay FSP-based CRB > The default ROM chip size is 2MB. > This is also the size of coreboot.rom created after "make" > > The board has 8MB BIOS flash. > It's delivered with a BIOS programming utility that runs under EFI shell. > > The original BIOS has 2 versions: rom (5MB) and bin (8MB) > I tried to burn the 2MB coreboot.rom with the vendor's BIOS utlity. > > I got: > 3 - Error: ROM file size does not match existing BIOS size. > Should I convert coreboot.rom to coreboot.bin ? How ? > If not, how can I program coreboot.rom ? > > Thank you, > Zvika

1 0

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

24 Sep '18

Hi Jorge, Not sure what caused the issue with PCR values ... I am not an expert in TPM. I guess following might be looked at: - Is it possible that the TPM device is not sufficiently initialized? - I noticed SecurityPkg/Library/DxeTpm2MeasureBootLib contains a function DxeTpm2MeasureBootHandler() that measures EDK II drivers. You might trace this function to see if it runs correctly and PCRs are extended successfully for each loaded driver. A side note (not related to this issue) is on parsing TPM info from ACPI tables produced by Coreboot: - The Coreboot Module Package in edk2 repo does *NOT* have the TPM parsing logic. You might refer to ParseTpmTable() in UEFI Payload in edk2-staging repo for codes that do this. Thanks, - ben From: Jorge Fernandez Monteagudo [mailto:jorgefm@cirsa.com] Sent: Monday, September 24, 2018 5:36 PM To: You, Benjamin <benjamin.you(a)intel.com>; coreboot(a)coreboot.org Subject: Re: [coreboot] Tianocore and TPM Hi Ben, Changing gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid do the trick! Now when I boot my system I can see the PCRs 0 to 9 populated. I have some questions regarding the values I see in the PCRs (different versions of coreboot+tianocore populate the PCRs0-7 with the same values) but I'll ask in the UEFI/EDKII mailing list. Attached are the changes I've imported into the tianocore master branch to make it works, if someone else wants to play with it... Thanks for your help! Jorge ________________________________________ De: You, Benjamin <benjamin.you(a)intel.com> Enviado: sábado, 22 de septiembre de 2018 5:33:30 Para: Jorge Fernandez Monteagudo; coreboot(a)coreboot.org Asunto: RE: [coreboot] Tianocore and TPM 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

Burn 2MB coreboot.rom on 8MB flash chip
by Zvi Vered 24 Sep '18

24 Sep '18

Hello, I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 Northbridge: 8086:0f00 (Bay Trail) Southbridge: 8086:0f1c (Bay Trail) IGD: 8086:0f31 (unknown) In coreboot configuration I selected: Mainboard -> Mainboard model -> Bayley Bay FSP-based CRB The default ROM chip size is 2MB. This is also the size of coreboot.rom created after "make" The board has 8MB BIOS flash. It's delivered with a BIOS programming utility that runs under EFI shell. The original BIOS has 2 versions: rom (5MB) and bin (8MB) I tried to burn the 2MB coreboot.rom with the vendor's BIOS utlity. I got: 3 - Error: ROM file size does not match existing BIOS size. Should I convert coreboot.rom to coreboot.bin ? How ? If not, how can I program coreboot.rom ? Thank you, Zvika

1 0

(no subject)
by Zvi Vered 24 Sep '18

24 Sep '18

1 0

Re: [coreboot] Loading Linux payloads on RISC-V
by Aaron Durbin 24 Sep '18

24 Sep '18

On Sun, Sep 23, 2018 at 9:00 AM ron minnich <rminnich(a)gmail.com> wrote: > > ah sorry I forgot. > > I think selfboot could be reworked (and should be) to interpret "0" as "somewhere useful"? Why is the kernel being loaded at 0? > > 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 > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
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