Re: [coreboot] Fwd: Ethernet problem in x200

On Mon, 27 Mar 2017 16:14:53 +0200 Zoran Stojsavljevic wrote: > [user@localhost projects]$ cat dmesg.txt | grep 00:19.0 > [0.151652] pci :00:19.0: *[8086:294c*] type 00 class 0x02 > [0.151694] pci :00:19.0: reg 0x10: [mem 0xe160-0xe161]

Re: [coreboot] [PATCH] nb/intel/nehalem/raminit.c: Add timeouts when waiting for heci.

Hi, On 03/27/2017 01:05 PM, Denis 'GNUtoo' Carikli wrote: 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

Re: [coreboot] [PATCH] nb/intel/nehalem/raminit.c: Add timeouts when waiting for heci.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2017 04:29 PM, Peter Stuge wrote: > Timothy Pearson wrote: >> In general static timeouts are not a good idea. > > In general infinite loops are a worse idea. Agreed. That being said, this sort of "quick fix" with timeouts is one way that

Re: [coreboot] [PATCH] nb/intel/nehalem/raminit.c: Add timeouts when waiting for heci.

Timothy Pearson wrote: > In general static timeouts are not a good idea. In general infinite loops are a worse idea. > can it parse the ME descriptor and not even search for the HECI > interface if the ME size is less than a certain value? That's a good idea! But put the timeout in to begin

Re: [coreboot] Fwd: Ethernet problem in x200

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

Re: [coreboot] [PATCH] nb/intel/nehalem/raminit.c: Add timeouts when waiting for heci.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2017 03:05 PM, Denis 'GNUtoo' Carikli wrote: > 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

[coreboot] [PATCH] nb/intel/nehalem/raminit.c: Add timeouts when waiting for heci.

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

Re: [coreboot] Lenovo Thinkpad X201: Coreboot incompatible with me_cleaner

On Tue, 21 Mar 2017 14:19:18 + Sam Kuper wrote: > Dear all, Hi, > Nicola Corna pointed out to me that adding a timeout at > https://github.com/coreboot/coreboot/blob/master/src/northbridge/intel/nehalem/raminit.c#L1756 > might solve this problem. > > (I guess the

Re: [coreboot] Overheating on f2a85-m

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

Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2

On Fri, 24 Mar 2017 03:16:27 + Sam Kuper wrote: > GNUtoo in 2013: > https://www.coreboot.org/index.php?title=Board:lenovo/x201=prev=11609 > > GNUtoo in 2013: > https://www.coreboot.org/index.php?title=Board:lenovo/x201=prev=11614 > > phcoder in 2013: >

Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2

On Wed, 22 Mar 2017 16:03:28 + Sam Kuper 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

Re: [coreboot] Fwd: Ethernet problem in x200

*> [1.611526] e1000e :00:19.0: The NVM Checksum Is Not Valid* I admit, I missed this one... But I'll improve, since, according to my expectations, my mind "blacklisted" possibility that GbE descriptor is corrupted. I am more on Linux/kernel side, and every day I read somebody's dmesg,

Re: [coreboot] Maintain boot order for multiple EFI based OS

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,

Re: [coreboot] Maintain boot order for multiple EFI based OS

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

Re: [coreboot] Fwd: Ethernet problem in x200

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

Re: [coreboot] Fwd: Ethernet problem in x200

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 :00:19.0: *[8086:294c*] type 00 class 0x02 > [0.151694] pci :00:19.0: reg 0x10: [mem 0xe160-0xe161] > [0.151707] pci

Re: [coreboot] Fwd: Ethernet problem in x200

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

Re: [coreboot] Maintain boot order for multiple EFI based OS

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. FMAP: base = ff00 size = 100 #areas = 3 find_current_mrc_cache: could not find fast boot cache area FSP MRC cache not present.

Re: [coreboot] Overheating on f2a85-m

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 wrote: > Before investigating the software methods, in this situation I would have > tried to: using some great thermal paste,

Re: [coreboot] Overheating on f2a85-m

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