coreboot February 2017

coreboot@coreboot.org

66 participants
212 discussions

Re: [coreboot] How does SeaBIOS transition to Linux?
by Peter Stuge 13 Feb '17

13 Feb '17

Zoran Stojsavljevic wrote: > Did not understand... I must admit! As of my best interpretation > SeaBIOS has 5 functions which makes BIOS legacy: > > get and set variables, get and set real time clock, reset. > > Or maybe, something changed. SeaBIOS implements a whole bunch of legacy BIOS services, including option ROM processing and the BBS. > Where I see e820 table which is to be passed to OS, in order OS to > understand what memory it can use. But I did not find explicitly these > 5 functions. So I need a little help here. Where are these functions? I don't really know what you are refering to, but it doesn't matter.. > Now... How GRUB2 replaces all of these functionalities? It doesn't and is not supposed to. It is only used to load the operating system, not to create a BIOS environment. If you need a legacy BIOS or UEFI then you do not use GRUB2 as (only) payload. > who/what entity is replacing missing SeaBIOS functionalities? None. With GRUB2 as payload, no legacy BIOS environment is present, and that's a good thing. //Peter

1 0

Re: [coreboot] How does SeaBIOS transition to Linux?
by Peter Stuge 13 Feb '17

13 Feb '17

Zoran Stojsavljevic wrote: > crucial question from me: how Coreboot will work if instead SeaBIOS > GRUB2 is the payload chosen Instead of SeaBIOS reading MBR, GRUB2 will read its configuration file and operate accordingly. //Peter

2 1

Rowhammer protection via increased ecc scrub rate?
by Taiidan＠gmx.com 13 Feb '17

13 Feb '17

I am wondering if increasing the ECC scrub rate with nvramcui will improve rowhammer protection on the various coreboot fam15h boards, and if there is any downside to putting it at the fastest setting. Default is 640ns but it can go down to 40ns. I know that laptop memory is very vulnerable to this, but that desktop/server memory isn't as much due to the lower density however server RAM has high density assuming you have the elite 16 and 32gb sticks etc. At least there is this: “…Intel chips were 200x more likely to have bitflips than AMD processors, and the team wants to explore this further.” dat magny coars <3

2 1

Re: [coreboot] INTEL BCT tool fails to start!
by Zoran Stojsavljevic 12 Feb '17

12 Feb '17

Hey Ron, Here is (I executed bct on Fedora 25, on bare HW, not as F25 VM on VMWare player 12.5.2, as usually as I do) some traces from the BCT itself: strace is too prospective, INTEL did good job at least to cover debugging of their own tools. Here are some insides from debug messages (important in *RED*)! *BTW, I am running python installed version: Python 2.7.13 (default, Jan 12 2017, 17:59:37) [GCC 6.3.1 20161221 (Red Hat 6.3.1-1)] on linux2* Full report attached. ---- Notes ----# Please provide additional information about the crash below. #---- System Information ----# Binary Configuration Tool Version: 3.3.1 *Operating System: Linux 4.9.8-201.fc25.x86_64 x86_64* Python Version: 2.7.12 (default, Sep 2 2016, 14:46:00) [GCC 6.1.1 20160621 (Red Hat 6.1.1-3)] wxPython Version: 3.0.2.0 gtk3 (classic) wxPython Info: (__WXGTK__, wxGTK, unicode, gtk3, wx-assertions-on, SWIG-1.3.29) Python Encoding: Default=ascii File=None wxPython Encoding: UTF-8 System Architecture: 64bit x86_64 Byte order: little Frozen: True #---- End System Information ----# #---- Traceback Info ----# *** Sun Feb 12 23:32:43 2017 *** Traceback (most recent call last): File "<string>", line 605, in <module> File "<string>", line 601, in startBCT File "/mnt/hgfs/Fedora24ShareVMP/bct331release/bct/install/ fc14/64bit/build/pyi.linux2/bct/out00-PYZ.pyz/core.appmain", line 1375, in main File "/mnt/hgfs/Fedora24ShareVMP/bct331release/bct/install/ fc14/64bit/build/pyi.linux2/bct/out00-PYZ.pyz/core.appmain", line 114, in __init__ File "/mnt/hgfs/Fedora24ShareVMP/bct331release/bct/install/ fc14/64bit/build/pyi.linux2/bct/out00-PYZ.pyz/wx._core", line 8628, in __init__ File "/mnt/hgfs/Fedora24ShareVMP/bct331release/bct/install/ fc14/64bit/build/pyi.linux2/bct/out00-PYZ.pyz/wx._core", line 8196, in _BootstrapApp File "/mnt/hgfs/Fedora24ShareVMP/bct331release/bct/install/ fc14/64bit/build/pyi.linux2/bct/out00-PYZ.pyz/core.appmain", line 193, in OnInit File "/mnt/hgfs/Fedora24ShareVMP/bct331release/bct/install/ fc14/64bit/build/pyi.linux2/bct/out00-PYZ.pyz/core.licensecheck", line 67, in __init__ AttributeError: 'NoneType' object has no attribute 'SetBitmap' #---- End Traceback Info ----# _______ [user@localhost bct]$ ./bct *** Sun Feb 12 23:32:43 2017 *** Traceback (most recent call last): File "<string>", line 605, in <module> File "<string>", line 601, in startBCT File "/mnt/hgfs/Fedora24ShareVMP/bct331release/bct/install/ fc14/64bit/build/pyi.linux2/bct/out00-PYZ.pyz/core.appmain", line 1375, in main File "/mnt/hgfs/Fedora24ShareVMP/bct331release/bct/install/ fc14/64bit/build/pyi.linux2/bct/out00-PYZ.pyz/core.appmain", line 114, in __init__ File "/mnt/hgfs/Fedora24ShareVMP/bct331release/bct/install/ fc14/64bit/build/pyi.linux2/bct/out00-PYZ.pyz/wx._core", line 8628, in __init__ File "/mnt/hgfs/Fedora24ShareVMP/bct331release/bct/install/ fc14/64bit/build/pyi.linux2/bct/out00-PYZ.pyz/wx._core", line 8196, in _BootstrapApp File "/mnt/hgfs/Fedora24ShareVMP/bct331release/bct/install/ fc14/64bit/build/pyi.linux2/bct/out00-PYZ.pyz/core.appmain", line 193, in OnInit File "/mnt/hgfs/Fedora24ShareVMP/bct331release/bct/install/ fc14/64bit/build/pyi.linux2/bct/out00-PYZ.pyz/core.licensecheck", line 67, in __init__ AttributeError: 'NoneType' object has no attribute 'SetBitmap' ( *evolution:4633): e-data-server-WARNING **: build_categories_filename: Failed to rename '/home/user/.evolution/categories.xml' to '/home/user/.local/share/evolution/categories.xml': No such file or directorySegmentation fault (core dumped)[user@localhost bct]$ *** Error in `evolution': malloc(): memory corruption: 0x000055ef6e530f90 **** ======= Backtrace: ========= /lib64/libc.so.6(+0x791fb)[0x7f77f3e251fb] /lib64/libc.so.6(+0x8434e)[0x7f77f3e3034e] /lib64/libc.so.6(__libc_malloc+0x54)[0x7f77f3e31f14] /tmp/_MEICprnzd/libglib-2.0.so.0(g_malloc+0x19)[0x7f77f41c0e19] /tmp/_MEICprnzd/libglib-2.0.so.0(+0x8408d)[0x7f77f41f608d] /tmp/_MEICprnzd/libglib-2.0.so.0(g_variant_get_data+0x1f)[0x7f77f41f62ff] /tmp/_MEICprnzd/libglib-2.0.so.0(g_variant_get+0xda)[0x7f77f41f510a] /usr/lib64/gio/modules/libgioremote-volume-monitor. so(+0x8833)[0x7f77bc396833] /usr/lib64/gio/modules/libgioremote-volume-monitor. so(+0xc5de)[0x7f77bc39a5de] /usr/lib64/gio/modules/libgioremote-volume-monitor. so(+0xd44b)[0x7f77bc39b44b] /tmp/_MEICprnzd/libgobject-2.0.so.0(+0x14e48)[0x7f77f4494e48] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_object_newv+0x1dd)[0x7f77f44960ad] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_object_new+0x104)[0x7f77f4496864] /tmp/_MEICprnzd/libgio-2.0.so.0(g_volume_monitor_get+0x7c)[0x7f77f476456c] /tmp/_MEICprnzd/libgtk-3.so.0(+0x265bb5)[0x7f77f5d68bb5] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_type_create_instance+ 0x20b)[0x7f77f44b27fb] /tmp/_MEICprnzd/libgobject-2.0.so.0(+0x1469b)[0x7f77f449469b] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_object_newv+0x1dd)[0x7f77f44960ad] /tmp/_MEICprnzd/libgtk-3.so.0(+0x11c192)[0x7f77f5c1f192] /tmp/_MEICprnzd/libgtk-3.so.0(+0x11e8cf)[0x7f77f5c218cf] /tmp/_MEICprnzd/libglib-2.0.so.0(+0x4cc83)[0x7f77f41bec83] /tmp/_MEICprnzd/libglib-2.0.so.0(g_markup_parse_context_ parse+0xeeb)[0x7f77f41bfd6b] /tmp/_MEICprnzd/libgtk-3.so.0(+0x11f356)[0x7f77f5c22356] /tmp/_MEICprnzd/libgtk-3.so.0(gtk_builder_extend_with_template+0x190)[ 0x7f77f5c1d480] /tmp/_MEICprnzd/libgtk-3.so.0(gtk_widget_init_template+ 0x107)[0x7f77f5e75fe7] /tmp/_MEICprnzd/libgtk-3.so.0(+0x1b86d1)[0x7f77f5cbb6d1] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_type_create_instance+ 0x20b)[0x7f77f44b27fb] /tmp/_MEICprnzd/libgobject-2.0.so.0(+0x1469b)[0x7f77f449469b] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_object_newv+0x1dd)[0x7f77f44960ad] /tmp/_MEICprnzd/libgtk-3.so.0(+0x11c192)[0x7f77f5c1f192] /tmp/_MEICprnzd/libgtk-3.so.0(+0x11d595)[0x7f77f5c20595] /tmp/_MEICprnzd/libgtk-3.so.0(+0x11ef61)[0x7f77f5c21f61] /tmp/_MEICprnzd/libglib-2.0.so.0(+0x4cdb7)[0x7f77f41bedb7] /tmp/_MEICprnzd/libglib-2.0.so.0(g_markup_parse_context_ parse+0xd63)[0x7f77f41bfbe3] /tmp/_MEICprnzd/libgtk-3.so.0(+0x11f356)[0x7f77f5c22356] /tmp/_MEICprnzd/libgtk-3.so.0(gtk_builder_extend_with_template+0x190)[ 0x7f77f5c1d480] /tmp/_MEICprnzd/libgtk-3.so.0(gtk_widget_init_template+ 0x107)[0x7f77f5e75fe7] /tmp/_MEICprnzd/libgtk-3.so.0(+0x1b12ce)[0x7f77f5cb42ce] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_type_create_instance+ 0x20b)[0x7f77f44b27fb] /tmp/_MEICprnzd/libgobject-2.0.so.0(+0x1469b)[0x7f77f449469b] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_object_newv+0x1dd)[0x7f77f44960ad] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_object_new+0x104)[0x7f77f4496864] /tmp/_MEICprnzd/libgtk-3.so.0(+0x1b3535)[0x7f77f5cb6535] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_type_create_instance+ 0x20b)[0x7f77f44b27fb] /tmp/_MEICprnzd/libgobject-2.0.so.0(+0x1469b)[0x7f77f449469b] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_object_new_valist+ 0x44e)[0x7f77f44965ae] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_object_new+0xf1)[0x7f77f4496851] /tmp/_MEICprnzd/libgtk-3.so.0(gtk_file_chooser_native_new+ 0x58)[0x7f77f5cb6ee8] /tmp/_MEICprnzd/libgtk-3.so.0(+0x1b0d2e)[0x7f77f5cb3d2e] /tmp/_MEICprnzd/libgobject-2.0.so.0(+0x14c17)[0x7f77f4494c17] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_object_new_valist+ 0x44e)[0x7f77f44965ae] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_object_new+0xf1)[0x7f77f4496851] /usr/lib64/evolution/modules/module-mail-config.so(+0x4f05)[0x7f77c5999f05] /usr/lib64/evolution/libevolution-mail.so(e_mail_config_service_page_add_ scratch_source+0x337)[0x7f77d1612137] /usr/lib64/evolution/libevolution-mail.so(+0x4f63f)[0x7f77d160263f] /usr/lib64/evolution/modules/module-startup-wizard.so(+ 0x499b)[0x7f77beb6e99b] /tmp/_MEICprnzd/libgobject-2.0.so.0(+0x14c17)[0x7f77f4494c17] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_object_new_valist+ 0x44e)[0x7f77f44965ae] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_object_new+0xf1)[0x7f77f4496851] /usr/lib64/evolution/modules/module-startup-wizard.so(+ 0x44ca)[0x7f77beb6e4ca] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_closure_invoke+0x145)[0x7f77f448f3e5] /tmp/_MEICprnzd/libgobject-2.0.so.0(+0x21432)[0x7f77f44a1432] /tmp/_MEICprnzd/libgobject-2.0.so.0(g_signal_emit_valist+ 0xdbf)[0x7f77f44aa05f] _______ Zoran On Sun, Feb 12, 2017 at 6:51 PM, ron minnich <rminnich(a)gmail.com> wrote: > run it under strace. Though, I'm not at all surprised to see that a python > tool is fragile w.r.t. where it's run. > > > > On Sun, Feb 12, 2017 at 5:41 AM Zoran Stojsavljevic < > zoran.stojsavljevic(a)gmail.com> wrote: > >> Why I am not surprised??? ;-) >> >> BCT tool link (I downloaded it): *Download the from the Binary >> Configuration Tool from GitHub below*: >> >> https://github.com/IntelFsp/BCT >> I did exactly what documentation for BCT tool says (reading it with >> okular, using my UEFI dual boot HDD on bare HW: WIN10 64 PRO and Fedora 25 >> x86_64): >> >> *2.2 Linux Install* >> >> *1. Copy the BCT tar.gz file to a local directory.* >> * a. For 32-bit versions, choose bct-<current >> version>.i686.fc22.tar.gz* >> * b. For 64-bit versions, choose bct-<current >> version>.x86_64.fc22.tar.gz* >> *2. From the console terminal, navigate to the folder that contains the >> BCT tar.gz file and issue the following command:* >> * a. For 32-bit versions, >tar -xvf bct-3.0.2-1-i686.fc22.tar.gz* >> * b. For 64-bit versions, >tar -xvf bct-3.0.2-1-x86_64.fc22.tar.gz* >> *3. The installation extracts a binary executable, bct, and three >> folders: help, xrc, and documentation inside a folder named bct.* >> *4. Run the BCT program by issuing:* >> * >cd bct* >> * >./bct * >> _______ >> >> Let me see what I am using: >> >> [user@localhost bct]$ uname -r >> *4.9.8-201.fc25.x86_64* >> [user@localhost bct]$ >> >> Fedora 22? Even Fedora 23 is already obsolete... My God! :-(( >> >> [image: Inline image 1] >> >> Anybody else experience this problem? 😬 >> >> Thank you, >> Zoran >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot > >

1 0

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 12 Feb '17

12 Feb '17

The ASUS KGPE-D16 fails verification for branch master as of commit 85cfddb4b493004d7fe2073a9db96cade40c91f8 The following tests failed: BOOT_FAILURE Commits since last successful test: 85cfddb nb/i945/gma.c: Change name and type of mmiobase in functions argument See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] INTEL BCT tool fails to start!
by ron minnich 12 Feb '17

12 Feb '17

run it under strace. Though, I'm not at all surprised to see that a python tool is fragile w.r.t. where it's run. On Sun, Feb 12, 2017 at 5:41 AM Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > Why I am not surprised??? ;-) > > BCT tool link (I downloaded it): *Download the from the Binary > Configuration Tool from GitHub below*: > > https://github.com/IntelFsp/BCT > I did exactly what documentation for BCT tool says (reading it with > okular, using my UEFI dual boot HDD on bare HW: WIN10 64 PRO and Fedora 25 > x86_64): > > *2.2 Linux Install* > > *1. Copy the BCT tar.gz file to a local directory.* > * a. For 32-bit versions, choose bct-<current version>.i686.fc22.tar.gz* > * b. For 64-bit versions, choose bct-<current > version>.x86_64.fc22.tar.gz* > *2. From the console terminal, navigate to the folder that contains the > BCT tar.gz file and issue the following command:* > * a. For 32-bit versions, >tar -xvf bct-3.0.2-1-i686.fc22.tar.gz* > * b. For 64-bit versions, >tar -xvf bct-3.0.2-1-x86_64.fc22.tar.gz* > *3. The installation extracts a binary executable, bct, and three folders: > help, xrc, and documentation inside a folder named bct.* > *4. Run the BCT program by issuing:* > * >cd bct* > * >./bct * > _______ > > Let me see what I am using: > > [user@localhost bct]$ uname -r > *4.9.8-201.fc25.x86_64* > [user@localhost bct]$ > > Fedora 22? Even Fedora 23 is already obsolete... My God! :-(( > > [image: Inline image 1] > > Anybody else experience this problem? 😬 > > Thank you, > Zoran > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

INTEL BCT tool fails to start!
by Zoran Stojsavljevic 12 Feb '17

12 Feb '17

Why I am not surprised??? ;-) BCT tool link (I downloaded it): *Download the from the Binary Configuration Tool from GitHub below*: https://github.com/IntelFsp/BCT I did exactly what documentation for BCT tool says (reading it with okular, using my UEFI dual boot HDD on bare HW: WIN10 64 PRO and Fedora 25 x86_64): *2.2 Linux Install* *1. Copy the BCT tar.gz file to a local directory.* * a. For 32-bit versions, choose bct-<current version>.i686.fc22.tar.gz* * b. For 64-bit versions, choose bct-<current version>.x86_64.fc22.tar.gz* *2. From the console terminal, navigate to the folder that contains the BCT tar.gz file and issue the following command:* * a. For 32-bit versions, >tar -xvf bct-3.0.2-1-i686.fc22.tar.gz* * b. For 64-bit versions, >tar -xvf bct-3.0.2-1-x86_64.fc22.tar.gz* *3. The installation extracts a binary executable, bct, and three folders: help, xrc, and documentation inside a folder named bct.* *4. Run the BCT program by issuing:* * >cd bct* * >./bct * _______ Let me see what I am using: [user@localhost bct]$ uname -r *4.9.8-201.fc25.x86_64* [user@localhost bct]$ Fedora 22? Even Fedora 23 is already obsolete... My God! :-(( [image: Inline image 1] Anybody else experience this problem? 😬 Thank you, Zoran

1 0

Saving truncated preram CBMEM messages
by Paul Menzel 12 Feb '17

12 Feb '17

Dear coreboot folks, looking at the coreboot CBMEM console messages board status repository, you’ll find a lot of truncated preram CBMEM console messages. Currently the buffer size is 0xc00 – 3 kB, right –, which is too small for quite some boards. The mainboard *Kabylake LPDDR3 RVP3* overrides it to 0xd00. So I am thinking about increasing it [1], but it’s of course not that simple, especially as I don’t understand all the implications. > Increasing this buffer reduces amount of available CAR stack, and > apparently DDR3 raminit already struggles with the amount of > cachelines available on fam10/15 My first question is, what other downsides are there of increasing the buffer size? I assume it’s unrelated to resulting usable RAM size, as RAM sizes nowadays are much, much bigger? So would one megabyte be reasonable/possible as a goal on boards supporting that? So if their is consensus that it should be increased, what would a way be forward? I assume, overriding it per mainboard is not so useful, as these messages are mostly from the chipset, so it should be chipset dependent? Should that option be moved there? Thanks, Paul [1] https://review.coreboot.org/18049/ "arch/x86: Increase preram CBMEM console buffer size"

2 3

Working with flash emulator traces (Dediprog EM100Pro)
by Paul Menzel 12 Feb '17

12 Feb '17

Dear coreboot folks, At work, I have access to a Dediprog EM100Pro, and I am currently to use it to test coreboot on the Asus KGPE-D16. The utility em100 for the emulator [1], also provides the switch ` --trace`, and the output looks like below [2]. ``` Time: 000000.00000000 command # 1 : 0x03 - read 00fffff0 : e9 25 f4 ff Time: 000000.00000879 command # 2 : 0x03 - read 00ffffc0 : 00 00 00 00 Time: 000000.00001635 command # 3 : 0x03 - read 00ffffc4 : 00 00 00 00 Time: 000000.00002333 command # 4 : 0x03 - read 00ffffc8 : 00 00 Warning: EM100pro sends too much data. 00 00 Time: 000000.00003024 command # 5 : 0x03 - read 00ffffcc : 00 00 00 00 Time: 000000.00003780 command # 6 : 0x03 - read 00ffffd0 : 00 00 00 00 Time: 000000.00004471 command # 7 : 0x03 - read 00ffffd4 : 00 00 00 00 Time: 000000.00005227 command # 8 : 0x03 - read 00ffffd8 : 00 00 00 00 Time: 000000.00005918 command # 9 : 0x03 - read 00ffffdc : 00 00 00 00 Time: 000000.00006674 command # 10 : 0x03 - read 00ffffe0 : 00 00 00 00 Time: 000000.00007373 command # 11 : 0x03 - read 00ffffe4 : 00 00 00 00 Time: 000000.00008064 command # 12 : 0x03 - read 00ffffe8 : 00 00 00 00 Time: 000000.00008820 command # 13 : 0x03 - read 00ffffec : 00 00 00 00 Time: 000000.00009576 command # 14 : 0x03 - read 00fffff0 : e9 25 f4 ff Time: 000000.00010267 command # 15 : 0x03 - read 00fffff4 : ff 66 90 66 Time: 000000.00011023 command # 16 : 0x03 - read 00fffff8 : 90 66 90 66 Time: 000000.00011714 command # 17 : 0x03 - read 00fffffc : 38 01 00 ff Time: 000000.00012665 command # 18 : 0x03 - read 00fff400 : ff ff ff ff Time: 000000.00013421 command # 19 : 0x03 - read 00fff404 : ff ff ff ff Time: 000000.00014112 command # 20 : 0x03 - read 00fff408 : ff ff ff ff Time: 000000.00014868 command # 21 : 0x03 - read 00fff40c : ff ff ff ff Time: 000000.00015624 command # 22 : 0x03 - read 00fff410 : ff ff ff ff Time: 000000.00016315 command # 23 : 0x03 - read 00fff414 : ff ff ff ff […] ``` Are there tools available to analyze these traces? For example find out what parts take too long to read for example? Are there tools available to help work with these traces, and for example map certain areas to the corresponding code? Is documentation available for working with these traces? What to look for, how to use them to analyze the coreboot code? How do you use it efficiently? Thanks, Paul [1] https://www.coreboot.org/EM100pro [2] https://www.molgen.mpg.de/~pmenzel/20170210%E2%80%93coreboot/201702 10%E2%80%93kgpe-d16%E2%80%93em100%E2%80%93trace.txt

2 1

KGPE-D16 and Samsung DDR3L memory sticks
by Daniel Kulesz 12 Feb '17

12 Feb '17

Hi folks, I spent some time checking the available RAM options for the KGPE-D16. The current list in the wiki is not very comprehensive and the models listed there are not easy to find on the market. After some research, I identified two "promising" candidates: 1.) Samsung M393B1K70DH0-YK0 Type: DDR3 DIMM 240-Pin, reg ECC • Ranks/Banks: dual rank, x4 • Modules: 1x 8GB • JEDEC: PC3L-12800R • Voltage: 1.35V 2.) Samsung M393B1K70DH0-YH9 Type: DDR3 DIMM 240-Pin, reg ECC • Ranks/Banks: dual rank • Modules: 1x 8GB • JEDEC: PC3L-10667R • Voltage: 1.35V Does one of you have experience with any of these (especially on this board)? Cheers, Daniel

2 2

← Newer
1
...
12
13
14
15
16
17
18
...
22
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 February 2017