coreboot March 2017

coreboot@coreboot.org

79 participants
267 discussions

Re: [coreboot] Fwd: Ethernet problem in x200
by Zoran Stojsavljevic 27 Mar '17

27 Mar '17

Hello Serdar, I have looked in your dmesg log: paste.debian.net/924457 dmesg. Did not look into paste.debian.net/924458 journalctl -k . I had some comparison to do, trying to understand what is going on with your Coreboot FW versus, for example, BIOS one. Few interesting things cot my eye, but I'll keep it for later... ;-) I can see that you are actually using (my best guess) 4GB of memory (probably 2 banks of DDR2 x 2GB), since we have here Code Name Penryn: http://ark.intel.com/products/35569/Intel-Core2-Duo-Processo r-P8400-3M-Cache-2_26-GHz-1066-MHz-FSB CPUID: 0x10676, paired with ICH9 PCH, if I am not mistaken. Also, you are probably (almost for sure) using SeaBIOS as payload. The thing which really confuses me is Debian Kernel command line: I am used 99% to RHEL/Fedora logs, so this command like is really confusing, since I could not determine too much about your GRUB2. Here it is (too simplictic for me, should have much more in it): *Command line: BOOT_IMAGE=(ahci0,msdos1)/vmlinuz root=/dev/sda1* And, after carefully examining PCIe bus, I found the ETH controller: 00:19.0 [VID=0x8086, DID=0x294C]: https://pci-ids.ucw.cz/read/PC/8086/294c [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 *[ 1.635873] e1000e: probe of 0000:00:19.0 failed with error -5* [user@localhost projects]$ Now, I need from you the following: ifconfig -a (to see if your wired ETH controller is present there). You can try to do the following (as root): service network restart . If it does not help, you need to read the following page, and try to navigate through it: http://unix.stackexchange.com/questions/182600/how-do-i-trou bleshoot-networking-on-debian Since you are using the very recent Coreboot: 4.5-1094-ga154a91 03/01/2017, I'll ask Coreboot people to tell you what INTEL board and what ETH controller you should set up for your (Lenovo) x200, since I could not find right mapping?! Martin, Patrick, What INTEL board (name) in Coreboot terminology maps to Lenovo x200 notebook, and which generic ETH driver should be enabled there (maybe Serdar did not enable the right ETH one, most likely seems from the dmesg logs)? Thank you, Zoran _______ On Fri, Mar 24, 2017 at 10:11 AM, serdar tunc <serdarot5(a)gmail.com> wrote: > ---------- 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 > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Fwd: Ethernet problem in x200
by Zoran Stojsavljevic 27 Mar '17

27 Mar '17

Hello Serdar, I have looked in your dmesg log: paste.debian.net/924457 dmesg. Did not look into paste.debian.net/924458 journalctl -k . I had some comparison to do, trying to understand what is going on with your Coreboot FW versus, for example, BIOS one. Few interesting things cot my eye, but I'll keep it for later... ;-) I can see that you are actually using (my best guess) 4GB of memory (probably 2 banks of DDR2 x 2GB), since we have here Code Name Penryn: http://ark.intel.com/products/35569/Intel-Core2-Duo- Processor-P8400-3M-Cache-2_26-GHz-1066-MHz-FSB CPUID: 0x10676, paired with ICH9 PCH, if I am not mistaken. Also, you are probably (almost for sure) using SeaBIOS as payload. The thing which really confuses me is Debian Kernel command line: I am used 99% to RHEL/Fedora logs, so this command like is really confusing, since I could not determine too much about your GRUB2. Here it is (too simplictic for me, should have much more in it): *Command line: BOOT_IMAGE=(ahci0,msdos1)/vmlinuz root=/dev/sda1* And, after carefully examining PCIe bus, I found the ETH controller: 00:19.0 [VID=0x8086, DID=0x294C]: https://pci-ids.ucw.cz/read/PC/8086/294c [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 *[ 1.635873] e1000e: probe of 0000:00:19.0 failed with error -5* [user@localhost projects]$ Now, I need from you the following: ifconfig -a (to see if your wired ETH controller is present there). You can try to do the following (as root): service network restart . If it does not help, you need to read the following page, and try to navigate through it: http://unix.stackexchange.com/questions/182600/how-do-i- troubleshoot-networking-on-debian Since you are using the very recent Coreboot: 4.5-1094-ga154a91 03/01/2017, I'll ask Coreboot people to tell you what INTEL board and what ETH controller you should set up for your (Lenovo) x200, since I could not find right mapping?! Martin, Patrick, What INTEL board (name) in Coreboot terminology maps to Lenovo x200 notebook, and which generic ETH driver should be enabled there (maybe Serdar did not enable the right ETH one, most likely seems from the dmesg logs)? Thank you, Zoran _______ On Sun, Mar 26, 2017 at 7:58 PM, serdar tunc <serdarot5(a)gmail.com> wrote: > paste.debian.net/924457 dmesg > paste.debian.net/924458 journalctl -k > Thank you > > On Sat, Mar 25, 2017 at 11:57 AM, Zoran Stojsavljevic > <zoran.stojsavljevic(a)gmail.com> wrote: > > I need these journalctl -k and dmesg logs (to trace the problem). > > > > Thank you, > > Zoran > > > > On Fri, Mar 24, 2017 at 10:11 AM, serdar tunc <serdarot5(a)gmail.com> > wrote: > >> > >> ---------- 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 > >> > >> -- > >> 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 Sibi.Rajasekaran＠dell.com 27 Mar '17

27 Mar '17

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] Overheating on f2a85-m
by Zoran Stojsavljevic 27 Mar '17

27 Mar '17

Courtesy Fedora forum... http://www.forums.fedoraforum.org/showthread.php?t=313425 Good Luck! Zoran On Mon, Mar 27, 2017 at 12:38 PM, qma ster <qmastery16(a)gmail.com> wrote: > Before investigating the software methods, in this situation I would have > tried to: using some great thermal paste, cleaning the dust, and - most > likely - switching to a manual fan control: there are the hardware fan > control adapters, and if you don't have those - 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 > > 2017-03-26 22:35 GMT+03:00 Rudolf Marek <r.marek(a)assembler.cz>: > >> Hi again, >> >> Sorry, I pasted wrong dump. Before I installed right /etc/sensors3.conf >> >> radeon-pci-0008 >> Adapter: PCI adapter >> temp1: +35.0°C (crit = +120.0°C, hyst = +90.0°C) >> >> it8603-isa-0290 >> Adapter: ISA adapter >> Vcore: +1.27 V (min = +1.12 V, max = +2.96 V) ALARM >> in1: +1.66 V (min = +2.69 V, max = +0.08 V) ALARM >> +12V: +12.38 V (min = +14.98 V, max = +0.00 V) ALARM >> +5V: +5.07 V (min = +3.96 V, max = +0.12 V) ALARM >> in4: +1.20 V (min = +1.92 V, max = +0.12 V) ALARM >> 3VSB: +3.31 V (min = +0.79 V, max = +2.88 V) ALARM >> Vbat: +3.14 V >> +3.3V: +3.36 V >> CPU Fan: 2824 RPM (min = 200 RPM) >> CHA Fan: 0 RPM (min = 600 RPM) ALARM >> CPU Temp: +64.0°C (low = +50.0°C, high = -126.0°C) ALARM sensor = >> thermistor >> M/B Temp: +38.0°C (low = +100.0°C, high = +122.0°C) sensor = >> thermistor >> temp3: -128.0°C (low = -24.0°C, high = +0.0°C) sensor = >> thermistor >> intrusion0: OK >> >> k10temp-pci-00c3 >> Adapter: PCI adapter >> temp1: +48.9°C (high = +70.0°C) >> (crit = +70.0°C, hyst = +69.0°C) >> >> Thanks >> Rudolf >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Pls unsubscribe !
by Alvaro G [andor] 25 Mar '17

25 Mar '17

Hi PG W, You can click on the link on the footer of every email and manage your subscription, including unsubscribe yourself. El 25 de marzo de 2017 16:51:56 CET, PG W <wmorris102668(a)gmail.com> escribió: >Pls unsubscribe ! > >Thanks!! -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

1 0

Pls unsubscribe !
by PG W 25 Mar '17

25 Mar '17

Pls unsubscribe ! Thanks!!

1 0

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

25 Mar '17

Hi Zoran and Peter, I’m actually interested in the retention time of DRAM cells for fingerprinting purposes (i.e. not for any kind of performance tuning). It turns out that retention time information (such as the distribution of retention times across the cells of DRAM) can be used to identify the manufacturer of that DRAM (see here<http://www.pdl.cmu.edu/PDL-FTP/NVM/dram-retention_isca13.pdf>, especially Figure 8, for details). The paper cited uses an FPGA implementation to measure the retention time. In contrast, I’m interested in seeing whether this relationship holds under a traditional setup and how it may then be leveraged to build secure systems that make their hardware (e.g. DRAM) transparent to the user without relying on static information like the SPD. For instance, the CPU may convey to the user during boot: “Your DRAM claims it is made by manufacturer A but it is acting like it is made by manufacturer B. Manufacturer B is known to be susceptible to these hardware trojans, defects, etc.” This is, of course, a very research oriented project with many strong assumptions, but I’m hoping that it will lead to some interesting results (it is part of my master’s thesis). Thus, that is why I need to figure out a way to disable the auto-refresh of DRAM ;) Best, Berj On Mar 24, 2017, at 8:01 AM, Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com<mailto:zoran.stojsavljevic@gmail.com>> wrote: > Quantify data retention of unpowered memory. Let us asses/investigate what is the technology of C (capacitor) in the presented diagram<https://upload.wikimedia.org/wikipedia/commons/b/bd/DRAM_Cell_Structure_%28…> in my previous email! The capacitor in the stacked capacitor scheme is constructed above the surface of the substrate. The capacitor is constructed from an oxide-nitride-oxide (ONO) dielectric sandwiched in between two layers of polysilicon plates (the top plate is shared by all DRAM cells in an IC), and its shape can be a rectangle, a cylinder, or some other more complex shape. There are two basic variations of the stacked capacitor, based on its location relative to the bitline—capacitor-over-bitline (COB) and capacitor-under-bitline (CUB). In a former variation, the capacitor is underneath the bitline, which is usually made of metal, and the bitline has a polysilicon contact that extends downwards to connect it to the access transistor's source terminal. Well, let us search more (on the ONO - Oxide-Nitride-Oxide dielectric material): The commonly used technology for non-volatile Flash memory application consists of a stacked-gate transistor with dual gates. The Oxide-Nitride-Oxide (ONO) stacks constitute the inter-poly dielectric layer between those gates. These top and bottom polycrystalline silicon plates are also known as the control gate (CG) and the floating gate (FG) respectively. During read and write operation of a flash memory device, a high electrical bias needs to be applied through the control gate in order for electrons to be tunneled through the thin tunnel oxide towards the floating gate which is surrounded by dielectric material. Although the same material is used in DRAMs and FLASHes (as in one case for dielectric in Cs, in other channel material for the FETs with dual gates), the design of DRAMs and FLASHes are essentially very different, as I see. It seems to me that in case of C, ONO is dielectric which holds the capacitor charge, and leaks it through dielectric, in the case of dual gate FETs we have here The Tunnel Effect, which captures some number of free electrons inside the ONO. Well... I am also curious (as you, Peter), what will be the retention time, but, as a difference to you, I think that after maximum of 7.8us x 2 some bits (maybe 5% of them, even less, but certainly more than 0.1%) will be corrupted. Now, after the quick analysis/assessment I made, now I understand why all the DRAM companies are trying to pack future DDRs as FLASHes. Never came to me before to investigate this... But there is always the first time (courtesy of Mr, Chilingirian, Massachusetts Institute of Technology). ;-) Zoran _______ On Fri, Mar 24, 2017 at 12:19 PM, Peter Stuge <peter(a)stuge.se<mailto:peter@stuge.se>> wrote: 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 -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot

2 1

Re: [coreboot] Fwd: Ethernet problem in x200
by Zoran Stojsavljevic 25 Mar '17

25 Mar '17

I need these journalctl -k and dmesg logs (to trace the problem). Thank you, Zoran On Fri, Mar 24, 2017 at 10:11 AM, serdar tunc <serdarot5(a)gmail.com> wrote: > ---------- 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 > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Group demographics
by tturne＠codeaurora.org 25 Mar '17

25 Mar '17

On 2017-03-24 08:23, ron minnich wrote: > On Fri, Mar 24, 2017 at 8:14 AM <tturne(a)codeaurora.org> wrote: > >> Q.1) Are questions related to Coreboot + Payload that boots a >> Chromebook >> appropriate for this list or a ChromiumOS list? > > of course! First the question and then the background. Q) Are there any shipping commercial chromebooks that use depthcharge as a payload? Background... * coreboot tree only list 4 payload config files: nyan, oak, purin, veyron * chromium tree .../src/third_party/chromiumos-overlay/sys-boot/coreboot/files/configs/ all have CONFIG_PAYLOAD_NONE=y * Google's recovery manifest (from linux_recovery.sh) can pull a recovery image for a specific product, I have yet to find depthcharge as a payload * Obviously I haven't pulled all of the recovery images, but have looked at ~10 * those interested in recovery image, /usr/sbin/chromeos_firmwareupdate --sb_extract yields a bios.bin file that cbfstool can parse (i.e. is a coreboot.rom file) At this point I would be interested in any chromebook (even x86) that ships with depthcharge as a payload. Cheers, T.mike

3 2

Re: [coreboot] Recall: Maintain boot order for multiple EFI based OS
by Zoran Stojsavljevic 24 Mar '17

24 Mar '17

Hey, Ron, We do understand that Sibi did not violate any policy here, neither Coreboot, neither Dell? It simply happened that Sibi used Dell official email to ask legitimate technical questions on behalf of Dell. This is how I perceive people who are contributing to Coreboot from official companies' emails. The only exclusion is INTEL. You MUST (have to have) permission to contribute from INTEL officials. Well (how good it is, or how bad it is, on your own perils). :-( Zoran On Fri, Mar 24, 2017 at 4:24 PM, ron minnich <rminnich(a)gmail.com> wrote: > There's really no way to recall a post to a list that is global. > > On Fri, Mar 24, 2017 at 7:02 AM Zoran Stojsavljevic < > zoran.stojsavljevic(a)gmail.com> wrote: > >> About this... This, we'll do on the common ground that GOOGLE people do >> understand you, and me (after all)!? >> >> Do you, Google people? (I need mandatory reply/Re: -> Better be, so... if >> you do NOT agree, I 'll take the appropriate Legal Action)! ; -) >> >> Zoran >> >> On Fri, Mar 24, 2017 at 2:43 PM, <Sibi.Rajasekaran(a)dell.com> wrote: >> >> >> >> *Dell - Internal Use - Confidential * >> >> Hi, >> >> >> >> Just the two of you in the email. >> >> I am trying to remove the Dell Internal folly that my outlook attaches to >> my emails which someone already commented not to do so. >> >> No other reason for recalling. >> >> >> >> Thanks, >> >> Sibi >> >> *From:* Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] >> *Sent:* Friday, March 24, 2017 6:54 PM >> *To:* Rajasekaran, Sibi <Sibi_Rajasekaran(a)Dell.com> >> *Cc:* Matt DeVillier <matt.devillier(a)gmail.com>; coreboot < >> coreboot(a)coreboot.org> >> *Subject:* Re: Recall: [coreboot] Maintain boot order for multiple EFI >> based OS >> >> >> >> OK, Sibi, I read you... As I understand, you would like to recall the >> complete thread. >> >> >> >> Your decision... You are free man, and I value that... I have here only >> ONE Question? Why? >> >> >> >> Thank you, >> >> Zoran >> >> >> >> On Fri, Mar 24, 2017 at 2:02 PM, <Sibi.Rajasekaran(a)dell.com> wrote: >> >> Rajasekaran, Sibi would like to recall the message, "[coreboot] Maintain >> boot order for multiple EFI based OS". >> >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot > >

1 0

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