[coreboot] ThinkPad x220 - Status

[Patrick Rudolph]

On 2016-05-23 05:20 PM, Nuno Moreira wrote:
> Hi Iru, Arian and Alexander.
> Thanks a lot for your feedback :)
> 
> Trying to reply to your input and presenting some questions emerging
> from it:
> 
> [IRU] "X220 has been supported for years :)"
> [/ME] Indeed. My mistake. After a better Internet search, I can see
> support at least since 2013. Thanks for the correction, Iru ;)
> 
> [IRU] "To unlock RAM speed in coreboot, you can see my article, but I
> haven't tested it yet."
> [/ME] Thanks a lot for this. I think I'll take the "risk" ant try to
> get 1866Mhz speed (fingers crossed).
> 
> [IRU] "tp-smapi depends on the proprietary firmware, and you can set
> the battery threshold with ectool."
> [/ME] Oh, this is great. I was not aware of this tool. I was looking
> to tpacpi-bat as an alternative. Gotta check what fits me&scripts
> better.
> 
> [ARIAN] "If you had damaged the ME firmware, you would not reach
> coreboot or any other firmware - the blob is signed"
> [ARIAN] "If you had damaged the NIC firmware, ethernet would probably
> be broken, so that's clearly defined."
> [/ME] That's good to know. Everything should be ok then, since BIOS
> can boot and Ethernet is working fine :)
> 
> [ARIAN] "refining the wiki would be a good thing to do"
> [/ME] Indeed. I'll try to update the Wiki after I finished my testing.
> 
> [ARIAN] "That's RAM _clock_ not data rate which is double the clock
> rate (-> DDR) - you're not any worse off than with the original
> firmware."
> [/ME] Also good news. This means the current speed is the default
> maximum of 1333 MHz. The problem in dmidecode info presentation is
> probably related with the issue Alexander presents below then.
> 
Should we put the DDR frequency or real frequency here ?
>From users point of view DDR frequency does make more sense.
It looks like some vendors put DDR frequency and others the real
frequency here...

> [ALEXANDER] "we might written the wrong value into dmidata. (dmidecode
> reads a description written by the firmware, has nothing to do with
> the real values)."
> [/ME] This is the most "logical" possibility I think. DO YOU GUYS KNOW
> ABOUT ANY OTHER METHOD TO GET/READ THE "REAL" RAM CLOCK SPEED? I would
> like to apply the RAM speed unlock patch presented by Iru and check
> the speed with different RAM modules (2x4G 1333Mhz and 2x8GB 1866Mhz)
> in order to confirm if the max speed is really unlocked. But if
> dmidecode always presents 667MHz as RAM speed I will never know if it
> is working or not :(
> 
The "real" frequency is the value reported by dmidecode.
It is the frequency the ram is running at, it isn't hardcoded to 667Mhz.
You can use it to verify the current RAM speed.
I don't think there's another linux tool to get real values.

> [ALEXANDER] "tp smapi depends on lot of SMM/SMI code. So tp-smapi
> kernel module asked the Lenovo BIOS to tell the EC to do something.
> coreboot don't want to support SMM/SMI APIs, because they are quite
> dangerous. But there is another way to get those features back. We
> know how to enable it, but we haven't yet create a way to control this
> by the user. One thing could be a userspace tool executed as root or
> we add another CMOS configuration for it. Any idea?"
> [/ME] Thanks for the clarification, Alexander. Well, in my user
> perspective, I think a user-space tool will be better because it can
> be used to update the thresholds more easily. If we only rely on CMOS
> config we would need to re-flash it every time we want to change the
> thresholds. (AFAIK, x220 only supports HW flash. We cannot re-flash
> from OS).
> 
> [ALEXANDER] "It looks you're using the native graphics init instead of
> the binary blob VGABIOS. The last time I tried it, I had a lot of
> problems."
> [/ME] Yes, I'm using NGI. I did not suffer from the well-know "one
> color blur image" problem yet.
> 
> [ALEXANDER] "Thanks for your feedback. Feel free to create tickets or
> updating the x220 wiki page."
> [/ME] You're welcome and Thanks for your support. I'll definitely try
> to update the Wiki after I finished my testing.
> 
> --sigkill
> 
> On Mon, May 23, 2016 at 3:02 PM, Alexander Couzens <lynxis at fe80.eu>
> wrote:
> 
>> hey,
>>
>> nice you made it!
>>
>>> *3) Coreboot rocks but... Current Open issues:*
>>> ---------------------------------------------
>>> I decided to use coreboot-4.4 release instead of git-master.
>>> As payload I'm using SeaBIOS (booting Archlinux with Syslinux as
>>> bootloader).
>> That's ok.
>>
>>> Before, with dmidecode -t 17 the speed was 1333Mhz and now it is
>> just
>>> 667Mhz...
>> we might written the wrong value into dmidata. (dmidecode reads a
>> description written by the firmware, has nothing to do with the real
>> values).
>>
>>> *3.2) TP-SMAPI: *
>>> --------------
>> tp smapi depends on lot of SMM/SMI code. So tp-smapi kernel module
>> asked the Lenovo BIOS to tell the EC to do something. coreboot don't
>> want to support SMM/SMI APIs, because they are quite dangerous.
>> But there is another way to get those features back.
>> We know how to enable it, but we haven't yet create a way to control
>> this by the user.
>>
>> One thing could be a userspace tool executed as root or we add
>> another
>> CMOS configuration for it. Any idea?
>>
>>> *3.3) Config files:*
>>> ------------------
>>> coreboot - http://pastebin.com/9ymtxLBW
>> It looks you're using the native graphics init instead of the binary
>> blob VGABIOS. The last time I tried it, I had a lot of problems. [3]
>>
>> Thanks for your feedback. Feel free to create tickets or updating
>> the
>> x220 wiki page.
>>
>> Best,
>> lynxis
>>
>> [3] https://ticket.coreboot.org/issues/37
>> --
>> Alexander Couzens
>>
>> mail: lynxis at fe80.eu
>> jabber: lynxis at fe80.eu
>> mobile: +4915123277221 [1]
>> gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
> 
>  
> 
> Links:
> ------
> [1] tel:%2B4915123277221

Regards,
Patrick