Hello, Patrick. Thanks for your input.
*[Patrick]* "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..." *[/me]* I think dmidata *should present the DDR frequency*. A user (without much knowledge) wants to see the value he bought :) if "DDR3 - 1866 MHz" then dmidecode = 1866Mhz (not 933 MHz, since this value could lead to misunderstanding). *[AFAIK, this can also be tricky if we are not in dual channel mode, right? I understand that we need to have 2 modules in order to get the DDR speed = 2 x REAL_FREQ. Anyway, with my basic knowledge, it seems to be possible to add the correct DDR frequency written into dmidata if we validate the channel mode...]*
*[Patrick]* "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. *[/me]* Before coreboot (With custom BIOS), dmidecode reported 1333Mhz (even with the 1866Mhz modules). Possibly the firmware was writing 1333Mhz to dmidata also. Lenovo BIOS used the DDR Freq and not the Real Freq, apparently. This takes me to the following question:* If coreboot is not hard-coded (and it is prepared to write any real RAM clock to dmidata) then, if I patch coreboot to unlock 1866Mhz (2x933Mhz) DDR frequency, it is expected to have 933MHz written into dmidata? (if this happens, then yes. We can test and check with the usage of different modules)* Any idea in which (source .c) this value is being set to be written?
Thanks in advance. --sigkill
On Mon, May 23, 2016 at 4:42 PM, Patrick Rudolph siro@das-labor.org wrote:
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@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 [1] gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
Links:
[1] tel:%2B4915123277221
Regards, Patrick