coreboot March 2017

coreboot@coreboot.org

79 participants
267 discussions

Re: [coreboot] [coreboot-gerrit] Change in coreboot[master]: KBL: Update FSP headers - upgrade to FSP.2.0.0
by Aaron Durbin 28 Mar '17

28 Mar '17

Why can't I access this CL on gerrit, but I'm getting emails for it? On Tue, Mar 28, 2017 at 10:10 AM, Subrata Banik (Code Review) <gerrit(a)coreboot.org> wrote: > Subrata Banik has posted comments on this change. ( https://review.coreboot.org/19023 ) > > Change subject: KBL: Update FSP headers - upgrade to FSP.2.0.0 > ...................................................................... > > > Patch Set 3: > > (2 comments) > > https://review.coreboot.org/#/c/19023/3/src/vendorcode/intel/fsp/fsp2_0/sky… > File src/vendorcode/intel/fsp/fsp2_0/skykabylake/ConfigBlock/CpuConfigFspData.h: > > PS3, Line 66: } Bits; > : UINT32 Uint32[2]; > : } CPU_CONFIG_FSP_DATA; > why added space? don't we run clean up script? > > > https://review.coreboot.org/#/c/19023/3/src/vendorcode/intel/fsp/fsp2_0/sky… > File src/vendorcode/intel/fsp/fsp2_0/skykabylake/FspmUpd.h: > > PS3, Line 41: #include <MemInfoHob.h> > directory structure change > ?? > > > -- > To view, visit https://review.coreboot.org/19023 > To unsubscribe, visit https://review.coreboot.org/settings > > Gerrit-MessageType: comment > Gerrit-Change-Id: Id8ecea6fa5f4e7a72410f8da535ab9c4808b3482 > Gerrit-PatchSet: 3 > Gerrit-Project: coreboot > Gerrit-Branch: master > Gerrit-Owner: Balaji Manigandan <balaji.manigandan(a)intel.com> > Gerrit-Reviewer: Barnali Sarkar <barnali.sarkar(a)intel.com> > Gerrit-Reviewer: Naresh Solanki <naresh.solanki(a)intel.com> > Gerrit-Reviewer: Rizwan Qureshi <rizwan.qureshi(a)intel.com> > Gerrit-Reviewer: Subrata Banik <subrata.banik(a)intel.com> > Gerrit-HasComments: Yes > > -- > coreboot-gerrit mailing list: coreboot-gerrit(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot-gerrit

1 0

[PATCH] nb/intel/nehalem/raminit.c: Add timeouts when waiting for heci.
by Denis 'GNUtoo' Carikli 28 Mar '17

28 Mar '17

Since until now, the code running on the management engine is: - Signed by its manufacturer - Proprietary software, without corresponding source code It can desirable to run the least ammount possible of such code, which is what me_cleaner[1] enables. It does it by removing partitions of the management engine firmwares, however when doing so, the HECI interface might not be present anymore. So it is desirable not to have the RAM initialisation code wait forever for the HECI interface to appear. [1] https://github.com/corna/me_cleaner/ Change-Id: Iebafa353ecd8875395d6c3a986da6082772e2e18 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo(a)no-log.org> --- src/northbridge/intel/nehalem/raminit.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/src/northbridge/intel/nehalem/raminit.c b/src/northbridge/intel/nehalem/raminit.c index 122b8ac7cf..27065d139e 100644 --- a/src/northbridge/intel/nehalem/raminit.c +++ b/src/northbridge/intel/nehalem/raminit.c @@ -1753,23 +1753,27 @@ static const struct ram_training *get_cached_training(void) } #endif -/* FIXME: add timeout. */ static void wait_heci_ready(void) { - while (!(read32(DEFAULT_HECIBAR + 0xc) & 8)); // = 0x8000000c + int i = 1000*1000; + + while (i-- && !(read32(DEFAULT_HECIBAR + 0xc) & 8)) /* = 0x8000000c */ + udelay(1); write32((DEFAULT_HECIBAR + 0x4), (read32(DEFAULT_HECIBAR + 0x4) & ~0x10) | 0xc); } -/* FIXME: add timeout. */ static void wait_heci_cb_avail(int len) { + int i = 1000*1000; + union { struct mei_csr csr; u32 raw; } csr; - while (!(read32(DEFAULT_HECIBAR + 0xc) & 8)); + while (i-- && !(read32(DEFAULT_HECIBAR + 0xc) & 8)) + udelay(1); do csr.raw = read32(DEFAULT_HECIBAR + 0x4); -- 2.12.1

4 6

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

28 Mar '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 13 new defect(s) introduced to coreboot found with Coverity Scan. 481 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 13 of 13 defect(s) ** CID 1373089: Parse warnings (PARSE_ERROR) /tmp/temp.G4RJVF.c: 1 in () ________________________________________________________________________________________________________ *** CID 1373089: Parse warnings (PARSE_ERROR) /tmp/temp.G4RJVF.c: 1 in () >>> CID 1373089: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1373088: Parse warnings (PARSE_ERROR) /tmp/temp.B0H6w5.c: 1 in () ________________________________________________________________________________________________________ *** CID 1373088: Parse warnings (PARSE_ERROR) /tmp/temp.B0H6w5.c: 1 in () >>> CID 1373088: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1373087: Parse warnings (PARSE_ERROR) /tmp/temp.kpjccO.c: 1 in () ________________________________________________________________________________________________________ *** CID 1373087: Parse warnings (PARSE_ERROR) /tmp/temp.kpjccO.c: 1 in () >>> CID 1373087: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1373086: Parse warnings (PARSE_ERROR) /tmp/temp.bOx5yG.c: 1 in () ________________________________________________________________________________________________________ *** CID 1373086: Parse warnings (PARSE_ERROR) /tmp/temp.bOx5yG.c: 1 in () >>> CID 1373086: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1373085: Parse warnings (PARSE_ERROR) /tmp/temp.8DKWQb.c: 1 in () ________________________________________________________________________________________________________ *** CID 1373085: Parse warnings (PARSE_ERROR) /tmp/temp.8DKWQb.c: 1 in () >>> CID 1373085: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1373084: Parse warnings (PARSE_ERROR) /tmp/temp.3Lg4Jr.c: 1 in () ________________________________________________________________________________________________________ *** CID 1373084: Parse warnings (PARSE_ERROR) /tmp/temp.3Lg4Jr.c: 1 in () >>> CID 1373084: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1373083: Parse warnings (PARSE_ERROR) /tmp/temp.NUhGsE.c: 1 in () ________________________________________________________________________________________________________ *** CID 1373083: Parse warnings (PARSE_ERROR) /tmp/temp.NUhGsE.c: 1 in () >>> CID 1373083: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1373082: Parse warnings (PARSE_ERROR) /tmp/temp.8J3QKd.c: 1 in () ________________________________________________________________________________________________________ *** CID 1373082: Parse warnings (PARSE_ERROR) /tmp/temp.8J3QKd.c: 1 in () >>> CID 1373082: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1373081: Parse warnings (PARSE_ERROR) /tmp/temp.QvRa1H.c: 1 in () ________________________________________________________________________________________________________ *** CID 1373081: Parse warnings (PARSE_ERROR) /tmp/temp.QvRa1H.c: 1 in () >>> CID 1373081: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1373080: Parse warnings (PARSE_ERROR) /tmp/temp.sKsjDZ.c: 1 in () ________________________________________________________________________________________________________ *** CID 1373080: Parse warnings (PARSE_ERROR) /tmp/temp.sKsjDZ.c: 1 in () >>> CID 1373080: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1373079: Parse warnings (PARSE_ERROR) /tmp/temp.Ns1GBX.c: 1 in () ________________________________________________________________________________________________________ *** CID 1373079: Parse warnings (PARSE_ERROR) /tmp/temp.Ns1GBX.c: 1 in () >>> CID 1373079: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1373078: Parse warnings (PARSE_ERROR) /tmp/temp.fMs4K7.c: 1 in () ________________________________________________________________________________________________________ *** CID 1373078: Parse warnings (PARSE_ERROR) /tmp/temp.fMs4K7.c: 1 in () >>> CID 1373078: Parse warnings (PARSE_ERROR) >>> The Coverity compiler fails to compile this file. Please see the build output log for more information. ** CID 1373077: (MIXED_ENUMS) /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 388 in vb2_update_menu() /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 407 in vb2_update_menu() /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 410 in vb2_update_menu() /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 418 in vb2_update_menu() /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 422 in vb2_update_menu() ________________________________________________________________________________________________________ *** CID 1373077: (MIXED_ENUMS) /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 388 in vb2_update_menu() 382 { 383 VbError_t ret = VBERROR_SUCCESS; 384 VB_MENU next_menu_idx = current_menu_idx; 385 switch(current_menu) { 386 case VB_MENU_DEV_WARNING: 387 switch(current_menu_idx) { >>> CID 1373077: (MIXED_ENUMS) >>> But this case, "VB_WARN_OPTIONS", is of different type "enum _VB_DEV_WARNING_MENU". 388 case VB_WARN_OPTIONS: 389 switch(default_boot) { 390 case VBNV_DEV_DEFAULT_BOOT_DISK: 391 next_menu_idx = VB_DEV_DISK; 392 break; 393 case VBNV_DEV_DEFAULT_BOOT_USB: /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 407 in vb2_update_menu() 401 /* 402 * 1. Select dev menu 403 * 2. Default to dev boot device 404 */ 405 vb2_set_menu_items(VB_MENU_DEV, next_menu_idx); 406 break; >>> CID 1373077: (MIXED_ENUMS) >>> But this case, "VB_WARN_DBG_INFO", is of different type "enum _VB_DEV_WARNING_MENU". 407 case VB_WARN_DBG_INFO: 408 /* Show debug info */ 409 break; 410 case VB_WARN_ENABLE_VER: 411 /* 412 * 1. Enable boot verification /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 410 in vb2_update_menu() 404 */ 405 vb2_set_menu_items(VB_MENU_DEV, next_menu_idx); 406 break; 407 case VB_WARN_DBG_INFO: 408 /* Show debug info */ 409 break; >>> CID 1373077: (MIXED_ENUMS) >>> But this case, "VB_WARN_ENABLE_VER", is of different type "enum _VB_DEV_WARNING_MENU". 410 case VB_WARN_ENABLE_VER: 411 /* 412 * 1. Enable boot verification 413 * 2. Default to the power off option 414 */ 415 vb2_set_menu_items(VB_MENU_TO_NORM, /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 418 in vb2_update_menu() 412 * 1. Enable boot verification 413 * 2. Default to the power off option 414 */ 415 vb2_set_menu_items(VB_MENU_TO_NORM, 416 VB_TO_NORM_POWER_OFF); 417 break; >>> CID 1373077: (MIXED_ENUMS) >>> But this case, "VB_WARN_POWER_OFF", is of different type "enum _VB_DEV_WARNING_MENU". 418 case VB_WARN_POWER_OFF: 419 /* Power off machine */ 420 ret = VBERROR_SHUTDOWN_REQUESTED; 421 break; 422 case VB_WARN_LANGUAGE: 423 /* Languages */ /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 422 in vb2_update_menu() 416 VB_TO_NORM_POWER_OFF); 417 break; 418 case VB_WARN_POWER_OFF: 419 /* Power off machine */ 420 ret = VBERROR_SHUTDOWN_REQUESTED; 421 break; >>> CID 1373077: (MIXED_ENUMS) >>> But this case, "VB_WARN_LANGUAGE", is of different type "enum _VB_DEV_WARNING_MENU". 422 case VB_WARN_LANGUAGE: 423 /* Languages */ 424 // TODO: we'll have to figure out how to display this 425 vb2_set_menu_items(VB_MENU_LANGUAGES, 426 VB_LANGUAGES_EN_US); 427 break; ________________________________________________________________________________________________________ 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] Overheating on f2a85-m
by Rudolf Marek 27 Mar '17

27 Mar '17

Hi, > temporarily you could just wire your fan so that it will always work on the max speed instead of taking the fan control commands from the motherboard Yes it can be switched to max RPM of fan like this: ruik ruik # echo 1 > /sys/class/hwmon/hwmon1/device/pwm1_enable ruik ruik # echo 255 > /sys/class/hwmon/hwmon1/device/pwm1 Maybe you will have something else than hwmon1 Thanks Rudolf

1 0

Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2
by Denis 'GNUtoo' Carikli 27 Mar '17

27 Mar '17

On Wed, 22 Mar 2017 16:03:28 +0000 Sam Kuper <sam.kuper(a)uclmail.net> wrote: > Is my interpretation plausible? In any case, how would more > experienced Corebooters suggest I proceed? Here's my configuration for the I945 and GM45 thinkpads. It probably will not help you to find and/or fix the cause of the black screen, but it might be interesting to have some reference with recent coreboot+grub, and it might also help setting up GRUB configuration for using luks+lvm > # This image was built using coreboot 4.5-1391-g5a16282fa6 > CONFIG_COLLECT_TIMESTAMPS=y > CONFIG_VENDOR_LENOVO=y > CONFIG_ONBOARD_VGA_IS_PRIMARY=y > CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT=y > CONFIG_BOARD_LENOVO_X60=y > CONFIG_NO_POST=y > CONFIG_CPU_MICROCODE_CBFS_NONE=y > # CONFIG_ON_DEVICE_ROM_LOAD is not set > CONFIG_PCIEXP_COMMON_CLOCK=y > CONFIG_PCIEXP_ASPM=y > CONFIG_PCIEXP_CLK_PM=y > CONFIG_PCIEXP_L1_SUB_STATE=y > CONFIG_PAYLOAD_GRUB2=y > CONFIG_GRUB2_REVISION=y > CONFIG_GRUB2_REVISION_ID="c42cb97f0881a927b5039d830d1d007f2eaa5b50" > CONFIG_GRUB2_EXTRA_MODULES="acpi adler32 affs afs ahci all_video aout > archelp ata at_keyboard backtrace bfs bitmap bitmap_scale blocklist > boot boottime bsd bswap_test btrfs cat cbfs cbls cbmemc cbtime chain > cmdline_cat_test cmosdump cmostest cmp cmp_test configfile cpio_be > cpio cpuid crc64 cryptodisk crypto cs5536 ctz_test datehook date > datetime diskfilter disk div div_test dm_nv echo efiemu ehci elf eval > exfat exfctest ext2 extcmd fat file fshelp functional_test > gcry_arcfour gcry_blowfish gcry_camellia gcry_cast5 gcry_crc gcry_des > gcry_dsa gcry_idea gcry_md4 gcry_md5 gcry_rfc2268 gcry_rijndael > gcry_rmd160 gcry_rsa gcry_seed gcry_serpent gcry_sha1 gcry_sha256 > gcry_sha512 gcry_tiger gcry_twofish gcry_whirlpool gdb geli gettext > gfxmenu gfxterm_background gfxterm_menu gptsync gzio halt hashsum > hdparm hello help hexdump hfs hfspluscomp hfsplus http iorw iso9660 > jfs jpeg keylayouts keystatus ldm linux16 linux loadenv loopback > lsacpi lsmmap ls lspci luks lvm lzopio macbless macho mda_text > mdraid09_be mdraid09 mdraid1x memdisk memrw minicmd minix2_be minix2 > minix3_be minix3 minix_be minix mmap morse mpi msdospart mul_test > multiboot2 multiboot nativedisk net newc nilfs2 normal ntfscomp ntfs > odc offsetio ohci part_acorn part_amiga part_apple part_bsd part_dfly > part_dvh part_gpt part_msdos part_plan part_sun part_sunpc parttool > password password_pbkdf2 pata pbkdf2 pbkdf2_test pcidump pci play png > priority_queue probe procfs progress raid5rec raid6rec random read > reboot regexp reiserfs relocator romfs scsi search_fs_file > search_fs_uuid search_label search serial setjmp setjmp_test setpci > sfs shift_test signature_test sleep sleep_test spkmodem squash4 > syslinuxcfg tar terminal terminfo test_blockarg testload test > testspeed tftp tga time trig tr true udf ufs1_be ufs1 ufs2 uhci > usb_keyboard usb usbms usbserial_common usbserial_ftdi > usbserial_pl2303 usbserial_usbdebug usbtest verify video_bochs > video_cirrus video_colors videoinfo videotest_checksum videotest xfs > xnu xnu_uuid xnu_uuid_test xzio zfscrypt zfsinfo zfs" I've removed some unrelated configuration (for normal/fallback) and some debug stuff from that configuration. Here's what the git revision corresponds to: > $ git log --oneline > 5a16282fa6 [DO NOT MERGE] mainboard/lenovo/x60: Add TPM 1.2 mainboard > support 4cf7873412 payloads/external: GRUB2: Fix build error. > b45bbb253f nb/intel/i945: Fix SPD dumps Here's the relevant parts of my grub.cfg: > # /etc/grub.cfg in coreboot.rom cbfs image > set root=cbfsdisk > > # Make sure to load the apropriate modules > # This allow us to build and use coreboot's grub > insmod luks > insmod lvm > insmod password_pbkdf2 > insmod password > > # Serial port (For dock) > serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1 > terminal_input --append serial > terminal_output --append serial > > terminal_input --append at_keyboard # Internal keyboard: Keep it!!! > terminal_output --append cbmemc > [...] > menuentry '[...]' { > [...] > } Denis.

1 0

Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2
by Denis 'GNUtoo' Carikli 27 Mar '17

27 Mar '17

On Fri, 24 Mar 2017 03:16:27 +0000 Sam Kuper <sam.kuper(a)uclmail.net> wrote: > GNUtoo in 2013: > https://www.coreboot.org/index.php?title=Board:lenovo/x201&diff=prev&oldid=… > > GNUtoo in 2013: > https://www.coreboot.org/index.php?title=Board:lenovo/x201&diff=prev&oldid=… > > phcoder in 2013: > https://www.coreboot.org/index.php?title=Board:lenovo/x201&diff=prev&oldid=… > > phcoder in 2014: > https://www.coreboot.org/index.php?title=Board:lenovo/x201&diff=next&oldid=… I do not have a Lenovo Thinkpad X201 and never did. I based this change on indirect information. Phcoder however had and probably still has a Lenovo Thinkpad X201. I however use native GPU init on all the following laptops: - Thinkpad X60 - Thinkpad X60T - Thinkpad T60 - Thinkpad X200 I also tested it first hand on a Thinkpad T400. I'm not sure how up to date is my knowledge on native GPU init, but libreboot documentation points out that not all displays might be supported by it. I'm also not sure how up to date that documentation is. Denis.

1 0

Re: [coreboot] Fwd: Ethernet problem in x200
by Nico Huber 27 Mar '17

27 Mar '17

Hello Serdar, Zoran, On 27.03.2017 16:14, Zoran Stojsavljevic wrote: > [user@localhost projects]$ cat dmesg.txt | grep 00:19.0 > [ 0.151652] pci 0000:00:19.0: *[8086:294c*] type 00 class 0x020000 > [ 0.151694] pci 0000:00:19.0: reg 0x10: [mem 0xe1600000-0xe161ffff] > [ 0.151707] pci 0000:00:19.0: reg 0x14: [mem 0xe1624000-0xe1624fff] > [ 0.151721] pci 0000:00:19.0: reg 0x18: [io 0x3000-0x301f] > [ 0.151802] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold > [ 1.489719] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) > set to dynamic conservative mode > [ 1.611526] e1000e 0000:00:19.0: The NVM Checksum Is Not Valid I can't say for sure, but this looks much like the GbE and/or Firmware Descriptor regions of the BIOS flash are corrupted. If in doubt, you can generate a layout file for flashrom from the backup of the vendor BIOS with `ifdtool -f` (see util/ifdtool/ in the coreboot tree). And flash back these selected regions with `flashrom -l layoutfile -i fd -i gbe ...` from the backup. > *[ 1.635873] e1000e: probe of 0000:00:19.0 failed with error -5* > [user@localhost projects]$ Hope that helps, Nico

2 1

Re: [coreboot] Maintain boot order for multiple EFI based OS
by Martin Roth 27 Mar '17

27 Mar '17

I haven't looked at it, but it's entirely possible (probable?) that rangeley and the wasn't updated to support the MRC cache outside of cbfs when that option was added. I'd try unselecting the "Use MRC Cache in FMAP" option. Martin On Mon, Mar 27, 2017 at 7:03 AM, <Sibi.Rajasekaran(a)dell.com> wrote: > Yes. I have selected "Use MRC Cache in FMAP" in my config and yes I am working from upstream coreboot. > > The console log specifies MRC cache not present. > <snip> > FMAP: base = ff000000 size = 1000000 #areas = 3 > find_current_mrc_cache: could not find fast boot cache area > FSP MRC cache not present. > > Thanks, > Sibi > > -----Original Message----- > From: Martin Roth [mailto:gaumless@gmail.com] > Sent: Friday, March 24, 2017 9:13 PM > To: Rajasekaran, Sibi <Sibi_Rajasekaran(a)Dell.com> > Cc: Matt DeVillier <matt.devillier(a)gmail.com>; coreboot <coreboot(a)coreboot.org>; Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> > Subject: Re: [coreboot] Maintain boot order for multiple EFI based OS > > As I recall, the rangeley FSP actually *REQUIRES* the mrc cache. Not having it would be a definite problem. > > Did you select "Use MRC Cache in FMAP"? If you did, that puts it outside of cbfs, so it wouldn't show up in that list. > > Are you working from upstream coreboot, or a tree from somewhere else? > > Martin > > On Fri, Mar 24, 2017 at 7:00 AM, <Sibi.Rajasekaran(a)dell.com> wrote: >> Dell - Internal Use - Confidential >> >> Hi Matt, >> >> Thanks for the prompt response. >> >> I am using Rangeley FSP in my coreboot environment and I don’t see mrc >> cache in the coreboot region even though I chose to use MRC Cache in the config. >> >> Performing operation on 'COREBOOT' region... >> >> Name Offset Type Size >> >> cbfs master header 0x0 cbfs header 32 >> >> fallback/romstage 0x80 stage 27612 >> >> cpu_microcode_blob.bin 0x6cc0 microcode 167936 >> >> fallback/ramstage 0x2fd40 stage 121204 >> >> config 0x4d700 raw 539 >> >> revision 0x4d980 raw 588 >> >> cmos_layout.bin 0x4dc40 cmos_layout 1320 >> >> fallback/dsdt.aml 0x4e1c0 raw 8074 >> >> fallback/payload 0x501c0 payload 648600 >> >> img/memtest 0xee7c0 payload 180268 >> >> (empty) 0x11a840 null 415320 >> >> fsp.bin 0x17fec0 fsp 389120 >> >> (empty) 0x1def00 null 132504 >> >> bootblock 0x1ff4c0 bootblock 2560 >> >> >> >> I had built the tianocore long before(may be 6 months back) and I am >> pretty sure I chose release payload. >> >> >> >> Thanks, >> >> Sibi >> >> From: Matt DeVillier [mailto:matt.devillier@gmail.com] >> Sent: Friday, March 24, 2017 2:23 PM >> To: Rajasekaran, Sibi <Sibi_Rajasekaran(a)Dell.com> >> Cc: Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com>; coreboot >> <coreboot(a)coreboot.org> >> Subject: Re: [coreboot] Maintain boot order for multiple EFI based OS >> >> >> >> >> >> >> >> On Fri, Mar 24, 2017 at 6:26 PM, <Sibi.Rajasekaran(a)dell.com> wrote: >> >> >> >> For your question, takes around 26 seconds from power On till >> Tianocore execute completion. Looking at reducing this boot time. >> >> >> >> >> >> Sibi, if you're not using mrc cache for RAM training, that's likely >> contributing 10s or so at least. Have you enabled coreboot timestamps >> and used cbmem to examine time to payload execute? Also, building >> Tianocore in debug (vs release) mode adds a bit of time as well due to >> the volume of serial output. I use coreboot + Tianocore on Baytrail >> N28xx/29xx (though not with FSP) and normal boot (after RAM training) >> with a release payload is on the order of 2s, with coreboot taking about 6-700ms of that. >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Maintain boot order for multiple EFI based OS
by Ma, Maurice 27 Mar '17

27 Mar '17

Matt and Patrick, Yes, if coreboot can provide an abstracted flash read/write/erase interfaces for payload to consume, then UEFI payload can implement a generic variable driver on top of it. I know coreboot already has the flash driver to update MRC training data, however, as far as I know that interface is limited to be used inside coreboot only. Considering UEFI variable services need to be runtime available (potentially used inside UEFI OS environment), one possible solution I can think of is to use software SMI to provide the abstracted flash access services. This solution might raise some security concerns though. Other than this, it is also possible to implement a platform specific variable driver in UEFI payload. But as I mentioned, it needs to be ported for different platforms. Thanks Maurice From: Patrick Georgi [mailto:pgeorgi@google.com] Sent: Thursday, March 23, 2017 12:31 AM To: Matt DeVillier <matt.devillier(a)gmail.com> Cc: coreboot(a)coreboot.org; Agyeman, Prince <prince.agyeman(a)intel.com>; Ma, Maurice <maurice.ma(a)intel.com>; Leahy, Leroy P <leroy.p.leahy(a)intel.com>; Sibi.Rajasekaran(a)dell.com Subject: Re: [coreboot] Maintain boot order for multiple EFI based OS Am 23.03.2017 08:10 schrieb "Matt DeVillier" <matt.devillier(a)gmail.com<mailto:matt.devillier@gmail.com>>: that seems like the kind of functionality it would make sense to handle in an abstracted way (perhaps using libpayload?) How about importing flashrom for this purpose? It has drivers for pretty much everything under the sun as long as it's flash. Patrick

1 0

Re: [coreboot] Fwd: Ethernet problem in x200
by Nico Huber 27 Mar '17

27 Mar '17

Hi, please always keep the mailing list in CC. On 27.03.2017 16:48, serdar tunc wrote: > Should i change cbfs size? I tried doing that but my problem still occurs If my suspicion below is correct, your problem is not related to core- boot. It's about firmware parts that share the flash chip with coreboot. The first part is a descriptor that holds a table of regions, your CBFS should match the BIOS region in size. I advice you to never flash more than one (untested) region at once. It makes troubleshooting harder, since you won't know otherwise which re- gion causes problems. Nico > > > 27 Mar 2017 17:33 tarihinde "Nico Huber" <nico.huber(a)secunet.com> yazdı: > >> Hello Serdar, Zoran, >> >> On 27.03.2017 16:14, Zoran Stojsavljevic wrote: >>> [user@localhost projects]$ cat dmesg.txt | grep 00:19.0 >>> [ 0.151652] pci 0000:00:19.0: *[8086:294c*] type 00 class 0x020000 >>> [ 0.151694] pci 0000:00:19.0: reg 0x10: [mem 0xe1600000-0xe161ffff] >>> [ 0.151707] pci 0000:00:19.0: reg 0x14: [mem 0xe1624000-0xe1624fff] >>> [ 0.151721] pci 0000:00:19.0: reg 0x18: [io 0x3000-0x301f] >>> [ 0.151802] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold >>> [ 1.489719] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) >>> set to dynamic conservative mode >>> [ 1.611526] e1000e 0000:00:19.0: The NVM Checksum Is Not Valid >> >> I can't say for sure, but this looks much like the GbE and/or Firmware >> Descriptor regions of the BIOS flash are corrupted. If in doubt, you can >> generate a layout file for flashrom from the backup of the vendor BIOS >> with `ifdtool -f` (see util/ifdtool/ in the coreboot tree). And flash >> back these selected regions with `flashrom -l layoutfile -i fd -i gbe >> ...` from the backup. >> >>> *[ 1.635873] e1000e: probe of 0000:00:19.0 failed with error -5* >>> [user@localhost projects]$ >> >> Hope that helps, >> Nico >> >> >

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
27
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 March 2017