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.
*[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 :(
*[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@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@fe80.eu jabber: lynxis@fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604