coreboot March 2017

coreboot@coreboot.org

79 participants
267 discussions

Start a nNew thread

Recall: Maintain boot order for multiple EFI based OS
by Sibi.Rajasekaran＠dell.com 24 Mar '17

24 Mar '17

Rajasekaran, Sibi would like to recall the message, "[coreboot] Maintain boot order for multiple EFI based OS".

1 0

Re: [coreboot] Maintain boot order for multiple EFI based OS
by Sibi.Rajasekaran＠dell.com 24 Mar '17

24 Mar '17

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<mailto:Sibi.Rajasekaran@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.

1 0

Re: [coreboot] Disabling Auto-Refresh of DRAM Using Coreboot
by Peter Stuge 24 Mar '17

24 Mar '17

Zoran Stojsavljevic wrote: > I am not sure what are you really trying to do, Quantify data retention of unpowered memory. > and, mostly WHY you are trying to do what you are trying to do?! To challenge the assumption that data is lost without power. It is an interesting area of research because that assumption - or simplification - is so widespread, although not at all correct. //Peter

2 1

Fwd: Ethernet problem in x200
by serdar tunc 24 Mar '17

24 Mar '17

---------- Yönlendirilen ileti ---------- Gönderen: "serdar tunc" <serdarot5(a)gmail.com> Tarih: 22 Mar 2017 19:14 Konu: Ethernet problem in x200 Alıcı: <coreboot-request(a)coreboot.org> Cc: I have x200 installed coreboot inside But my ethernet doesnt work. How can i fix it? paste.debian.net/923338 journalctl -k message paste.debian.net/9233342 dmesg message

1 0

Re: [coreboot] Flash error - Board information not found
by Kory Maincent 24 Mar '17

24 Mar '17

Hi, Thanks for the answer. I saved a backup of the actual rom with the proprietary software which is a Fujitsu utility. I have tried with flashrom : - With internal programmer I have this error : Reading flash transaction error Read operation failed - With a ch341a spi programmer I have this other error : couldn't open device programmer initialization failed. I have ordered a Rasp. I will try with it. Kory 2017-03-23 18:22 GMT+01:00 Martin Roth <gaumless(a)gmail.com>: > Hi Kory, > I'm not sure what the proprietary software is, but you're going to > want to use flashrom or a hardware flash tool instead of the > proprietary software to flash the ROM. > https://www.flashrom.org/Flashrom > > And just since it always needs to be said: > > You need to make sure you have a backup of *YOUR* original ROM before > you flash to coreboot. Do NOT rely on the OEM's ROM file for > recovery, as there may be information specific to your board stored on > your ROM chip. Save this backup, as you may discover you needed > something from it at some later date. Using a hardware solution to > create this backup is the best method because the onboard SPI > controller may not be able to read from the entire chip. > > Updating your board to coreboot has a high chance of bricking your > board. It's recommended that you have a sure way of recovering - Get > a spare ROM chip if the chip is socketed. If it's not, get a hardware > flash solution so you can re-flash the chip even if the board is dead. > The Raspberry-pi or BeagleBone Black are two popular solutions. You > can search for information about how to do this. > > Martin > > > > On Thu, Mar 23, 2017 at 9:25 AM, Kory Maincent <kmaincent(a)gmail.com> > wrote: > > Hi everyone, > > > > I tried to flash Fujitsu D2990-A1 Board with winbound ROM with coreboot > and > > a coreinfo payload. > > No probleme in compiling and adding the blobs. > > But when I use the proprietary software with FreeDOS to flash the Bios I > > have this error : > > Error - No Board Information found in update file > > > > Is anybody has already seen this error? > > Is it possible to add a special file to the rom with the board > information. > > Or do I have to contact them to solve it because it is a verification > done > > by the software? > > > > I am new to coreboot > > > > Thanks, Kory > > > > -- > > 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 Matt DeVillier 24 Mar '17

24 Mar '17

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.

1 0

Re: [coreboot] Maintain boot order for multiple EFI based OS
by Sibi.Rajasekaran＠dell.com 24 Mar '17

24 Mar '17

Dell - Internal Use - Confidential Hello All, Thank you for the responses. Hello Zoran, For your question, takes around 26 seconds from power On till Tianocore execute completion. Looking at reducing this boot time. Thanks, Sibi From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] Sent: Wednesday, March 22, 2017 7:21 PM To: Rajasekaran, Sibi <Sibi_Rajasekaran(a)Dell.com> Cc: coreboot <coreboot(a)coreboot.org> Subject: Re: [coreboot] Maintain boot order for multiple EFI based OS Hello Sibi, The answer to your question lies outside of Coreboot domain. After bringing Tiano Core, you need to bring the next phase of booting: OS boot loader. The best for you is to use GRUB2. Then, from GRUB2 menu (/boot/efi/EFI/.../grub.cfg) you can choose your OS (either WIN8+, either any modern Linux distro). You can have up to 128 of them, as my best understanding is. So: Coreboot intermingled with FSP -> Coreboot -> Tiano Core -> GRUB2 -> Any UEFI compliant OS. I have here two questions: [1: For general Coreboot population] After having Tiano Core payload executed, how Tiano Core is linked with the next booting phase: GRUB2? [2: for Sibi] What are the fastest and average booting times from board Power On till post executing Tiano Core? Thank you, Zoran On Wed, Mar 22, 2017 at 2:20 PM, <Sibi.Rajasekaran(a)dell.com<mailto:Sibi.Rajasekaran@dell.com>> wrote: Dell - Internal Use - Confidential Hi, We are using the coreboot project with Intel fsp to boot the Intel Rangeley based Mohonpeak CPU. We have built the Tianocore EDK2 project and used it as the payload to bring UEFI services to this bootloader. With this payload, we are able to boot a EFI based OS successfully. As a next step, we are looking at installing multiple EFI OS and maintaining boot order among the OS. How is boot order maintained with UEFI payload? Is it through EFI NVRAM variables? If so, does coreboot support NVRAM variables? Can you please point us in the right direction. Thanks, Sibi -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Disabling Auto-Refresh of DRAM Using Coreboot
by Berj K Chilingirian 24 Mar '17

24 Mar '17

Hi, I was hoping to get some advice/guidance on how to disable the automatic refresh of the DRAM during the ROM stage of coreboot. I am booting an ASUS F2A85-M motherboard with a AMD A6-5400k processor (Trinity core) using coreboot. The processor is initialized via the AGESA bootstrap protocol. I would like to use the AGESA software<https://github.com/coreboot/coreboot/tree/master/src/vendorcode/amd/agesa/f…> in order to measure the retention time of DRAM cells (i.e. the time a DRAM cell holds its value with refresh shut off). To do this, I must (1) run my code in cache-as-RAM mode because DRAM becomes unreliable without refresh and (2) have a way to switch DRAM refresh on/off from software. (1) is accomplished by running my code in the cache-as-RAM phase of coreboot (i.e. the ROM stage). I am, however, unclear on how to accomplish (2) and I was hoping to receive some pointers/guidance on how to do this. The AGESA protocol seems to handle memory initialization in the AmdInitPost<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f…> phase, specifically in AmdMemAuto<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f…> In reading this code I discovered a call with which one could disable/enable the auto-refresh feature of the DRAM. Specifically, MemNSetBitFieldNb<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f…> (NBPtr, BFDisAutoRefresh, 1); where NBPtr is a pointer to a data structure representing the northbridge configuration and BFDisAutoRefresh<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f…> is a bit field which can be set to 1 in order to disable auto-refresh of the DRAM (see AMD BKDG<http://support.amd.com/TechDocs/42300_15h_Mod_10h-1Fh_BKDG.pdf>, page 344 on DisAutoRefresh). With this interface, I thought I could (1) write a value to memory (using movnti instruction to bypass the cache), (2) disable auto-refresh using MemNSetBitFieldNb, (3) wait some number of seconds, (4) enable auto-refresh using MemNSetBitFieldNb, and (5) check whether the value has persisted over the given period of time. Unfortunately, I discovered that even after waiting 3 minutes, the value in DRAM persisted (contrary to what seems to be expected by the literature<http://www.pdl.cmu.edu/PDL-FTP/NVM/dram-retention_isca13.pdf>). Note that I perform this procedure inside the AmdMemAuto<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f…> procedure of the AGESA code once all memory initialization tasks have completed and before teardown occurs. Worried that the processor may be caching the value, I decided to flush data at the address before disabling auto-refresh with the following interface provided by the AGESA codebase: MemUFlushPattern<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f…> (Addr, 1); where 1 simply represents the number of cache lines to flush from the address Addr. This, however, proved not to solve my issue. I am curious if anyone has dug into the AGESA vendor code and has any experience advice for how to approach the functionality I am trying to achieve. Thank you for all your help! Berj

4 3

Re: [coreboot] Disabling Auto-Refresh of DRAM Using Coreboot
by Berj K Chilingirian 24 Mar '17

24 Mar '17

Hi Kyösti, Yes, sorry about that! I’ve attached the patch against the source (last commit: 021ec2819b2200eabbaca5b6873f7024c2bd9434). As reference, I’ve also attached the output of the boot process (via the serial port). With regards to the address I am writing to, I am writing to the range 0x200000 - 0x300000. I guess this may be in the L2 cache-as-RAM and thus not demonstrate the behavior I’m expecting.. Thanks again for your help, Berj On Mar 23, 2017, at 10:53 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com<mailto:kyosti.malkki@gmail.com>> wrote: On Fri, Mar 24, 2017 at 2:15 AM, Berj K Chilingirian <berjc(a)mit.edu<mailto:berjc@mit.edu>> wrote: Hi, I was hoping to get some advice/guidance on how to disable the automatic refresh of the DRAM during the ROM stage of coreboot. I am booting an ASUS F2A85-M motherboard with a AMD A6-5400k processor (Trinity core) using coreboot. The processor is initialized via the AGESA bootstrap protocol. I would like to use the AGESA software<https://github.com/coreboot/coreboot/tree/master/src/vendorcode/amd/agesa/f…> in order to measure the retention time of DRAM cells (i.e. the time a DRAM cell holds its value with refresh shut off). To do this, I must (1) run my code in cache-as-RAM mode because DRAM becomes unreliable without refresh and (2) have a way to switch DRAM refresh on/off from software. (1) is accomplished by running my code in the cache-as-RAM phase of coreboot (i.e. the ROM stage). I am, however, unclear on how to accomplish (2) and I was hoping to receive some pointers/guidance on how to do this. The AGESA protocol seems to handle memory initialization in the AmdInitPost<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f…> phase, specifically in AmdMemAuto<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f…> In reading this code I discovered a call with which one could disable/enable the auto-refresh feature of the DRAM. Specifically, MemNSetBitFieldNb<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f…> (NBPtr, BFDisAutoRefresh, 1); where NBPtr is a pointer to a data structure representing the northbridge configuration and BFDisAutoRefresh<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f…> is a bit field which can be set to 1 in order to disable auto-refresh of the DRAM (see AMD BKDG<http://support.amd.com/TechDocs/42300_15h_Mod_10h-1Fh_BKDG.pdf>, page 344 on DisAutoRefresh). With this interface, I thought I could (1) write a value to memory (using movnti instruction to bypass the cache), (2) disable auto-refresh using MemNSetBitFieldNb, (3) wait some number of seconds, (4) enable auto-refresh using MemNSetBitFieldNb, and (5) check whether the value has persisted over the given period of time. Unfortunately, I discovered that even after waiting 3 minutes, the value in DRAM persisted (contrary to what seems to be expected by the literature<http://www.pdl.cmu.edu/PDL-FTP/NVM/dram-retention_isca13.pdf>). Note that I perform this procedure inside the AmdMemAuto<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f…> procedure of the AGESA code once all memory initialization tasks have completed and before teardown occurs. Worried that the processor may be caching the value, I decided to flush data at the address before disabling auto-refresh with the following interface provided by the AGESA codebase: Patch against the source is easier to diagnose for possible mistakes than verbal expression of what you believe you are doing. Eg. the address you write to makes a difference. Kyösti

1 0

Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2
by Arthur Heymans 24 Mar '17

24 Mar '17

Hi > > I tried again, this time with SeaBIOS instead of GRUB2 as the primary > payload, and with CoreInfo as a secondary payload. As above, I > selected "Use native graphics initialization" under "Devices" within > `make nconfig`. (See attached .config .) > > The result was the same as above: the backlight came on, but there was > nothing displayed on the screen. > I would not be too surprised if native graphic init is invalid for Nehalem, since looks like a rough copy of ivy/sandy bridge... (A quick look at the code tells me computing PLL divisors is too rough to be right in all cases. When it is too much out range for a display a lit up black screen is typically all you get...) > I do think you are probably right about this issue (i.e. nothing being > displayed on the screen) being due to a failure to initialise the > graphics properly, and I am open to further attempts to overcome the > issue, as my time allows. > One option is to extract the option rom from vendor bios and use that for init. Another is to fix up that native graphic init. Last option is hook up libgfxinit, an alternative Intel display init code written in ada/spark, which might set up display correctly... > Is there anyone on the list who has Coreboot working on an X201 who > would be willing to share their .config file, so that I might see how > they succeeded where I am failing? > > Thanks! Kind regards -- Arthur Heymans

2 1

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