-----BEGIN PGP SIGNED MESSAGE-----
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
I wanted to try caching of the MRC training data. As described in Timothy's post, I commented the following line:
> allow_config_restore = 0;
However, I was not able to measure any effects regarding boot time. Does this setting only work with cbfs enabled? And if so, is it necessary to set additionally any cbfs variables?
Hope this time I've set the Reply-To header correctly.
> On 03/02/2017 02:17 PM, Paul Menzel wrote:
> > Dear Arthur, dear Timothy,
> > Am Donnerstag, den 02.03.2017, 13:38 -0600 schrieb Timothy Pearson:
> >> On 03/02/2017 01:30 PM, Arthur Heymans wrote:
> >>> Paul Menzel writes:
> >>>> I think most of the time is spent in RAM initialization.
> >>>> 1. Do board owners with similar amount of memory (independent of the
> >>>> board) have similar numbers?
> >>>> 2. What are the ways to improve that? Is it possible? For example, can
> >>>> the modules be probed in parallel (if that isn?t done already)?
> >>> I'm not the right person to answer this since I don't know this
> >>> code/hardware that well, but on modern Intel hardware native code uses
> >>> the MRC cache to store dram training results and restore those on
> >>> next boots (and resume from suspend) if no change in dimm configuration
> >>> was detected.
> >>> Maybe something like this could also be applied here (or maybe it's already
> >>> the case since it includes code to access spi flash)?
> >> Yes, this is already implemented as an option, and it does a fairly
> >> decent job of reducing training overhead to almost nothing,
> > Interesting. What option is that?
> > Also, besides the file `s3nv` I don?t see anything else in CBFS. Where
> > is the training data cached?
> That's it. The cache is mandatory for S3 resume, and optional at boot.
> That being said, the pathways are present but are deactivated due to
> historical instability and are not tied in to an nvram variable at this
> time. If you want to test, you'll need to edit the source file
> "src/northbridge/amd/amdmct/mct_ddr3/mct_d.c"; near line 2730 you'll see
> a FIXME comment and this line:
> allow_config_restore = 0;
> Comment that line out and recompile to test. I strongly suggest running
> memtest across multiple warm and cold boots (and reboots) before
> determining the functionality is stable enough for use.
Does anyone know? I have checked everywhere
I can't find the accessories for the board family either (TPM etc)
I would just get another KGPE-D16 but I want to make a router with one
of the 35W C32 "EE" opterons and the retail price is a little cheaper.
And does anyone know how much longer they are making the KGPE-D16? I
wanna buy more before they stop (I could get arm or power, but I still
need x86 to play video games) I suppose it is possible to port to
another better available similar board like something from supermicro
(H8DGI-way, way better specs, first released 2014) but I have no idea
how complex that is.
On 05/31/2017 01:54 AM, Urs Ritzmann wrote:
> What flash type were you emulating? I require a 1.8 Volt device with >= 128Mbit size.
W25Q128FW, also 1.8v. What application do you use to drive em100?
Official one from Dediprog or the open linux one? Also, what em100
firmware# you have, perhaps yours is old?
Hi coreboot devs,
I'm seeking several people that wouldn't mind sharing a little about
themselves to interviewed for a fun and informative presentation at the
Denver conference. The ideal candidate is someone that has contributed to
coreboot and maybe isn't able to attend the conference. Please contact me
if you wouldn't mind answering a few questions, sending a selfie, and photo
of your development setup.
On Wed, May 31, 2017 at 08:06:16AM +0000, Alberto Bursi wrote:
> [...] (someone tried to create an acronym with a word used already)
Also quoting wikipedia (but real dictionaries will agree or have more
"A blob is a shapeless mass."
I think this definition transfers well to blobs in software, though.
Without intrusive tools (a disassembler, etc.) you can't make out the
structural details of a blob.
On 05/30/2017 12:36 AM, Urs Ritzmann wrote:
> Is there a way to disable Quad IO Read(0xEB) from the flash descriptor region?
please try clearing bits 3 (Quad I/O Read Enable) and 2 (Quad Output
Read Enable) at 0x108 offset.