[coreboot] Disabling Auto-Refresh of DRAM Using Coreboot

[Berj K Chilingirian]

Hi Kyösti,

Yes, sorry about that! I’ve attached the patch against the source (last commit: 021ec2819b2200eabbaca5b6873f7024c2bd9434). As reference, I’ve also attached the output of the boot process (via the serial port).

With regards to the address I am writing to, I am writing to the range 0x200000 - 0x300000. I guess this may be in the L2 cache-as-RAM and thus not demonstrate the behavior I’m expecting..

Thanks again for your help,
Berj

On Mar 23, 2017, at 10:53 PM, Kyösti Mälkki <kyosti.malkki at gmail.com<mailto:kyosti.malkki at gmail.com>> wrote:



On Fri, Mar 24, 2017 at 2:15 AM, Berj K Chilingirian <berjc at mit.edu<mailto:berjc at mit.edu>> wrote:
Hi,

I was hoping to get some advice/guidance on how to disable the automatic refresh of the DRAM during the ROM stage of coreboot.

I am booting an ASUS F2A85-M motherboard with a AMD A6-5400k processor (Trinity core) using coreboot. The processor is initialized via the AGESA bootstrap protocol.

I would like to use the AGESA software<https://github.com/coreboot/coreboot/tree/master/src/vendorcode/amd/agesa/f15tn> in order to measure the retention time of DRAM cells (i.e. the time a DRAM cell holds its value with refresh shut off). To do this, I must (1) run my code in cache-as-RAM mode because DRAM becomes unreliable without refresh and (2) have a way to switch DRAM refresh on/off from software. (1) is accomplished by running my code in the cache-as-RAM phase of coreboot (i.e. the ROM stage). I am, however, unclear on how to accomplish (2) and I was hoping to receive some pointers/guidance on how to do this.

The AGESA protocol seems to handle memory initialization in the AmdInitPost<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f15tn/Proc/Common/AmdInitPost.c#L223> phase, specifically in AmdMemAuto<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f15tn/Proc/Mem/Main/mmflow.c#L135>  In reading this code I discovered a call with which one could disable/enable the auto-refresh feature of the DRAM. Specifically,

MemNSetBitFieldNb<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f15tn/Proc/Mem/NB/mnreg.c#L218> (NBPtr, BFDisAutoRefresh, 1);

where NBPtr is a pointer to a data structure representing the northbridge configuration and BFDisAutoRefresh<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f15tn/Proc/Mem/mm.h#L365> is a bit field which can be set to 1 in order to disable auto-refresh of the DRAM (see AMD BKDG<http://support.amd.com/TechDocs/42300_15h_Mod_10h-1Fh_BKDG.pdf>, page 344 on DisAutoRefresh).

With this interface, I thought I could (1) write a value to memory (using movnti instruction to bypass the cache), (2) disable auto-refresh using MemNSetBitFieldNb, (3) wait some number of seconds, (4) enable auto-refresh using MemNSetBitFieldNb, and (5) check whether the value has persisted over the given period of time. Unfortunately, I discovered that even after waiting 3 minutes, the value in DRAM persisted (contrary to what seems to be expected by the literature<http://www.pdl.cmu.edu/PDL-FTP/NVM/dram-retention_isca13.pdf>). Note that I perform this procedure inside the AmdMemAuto<https://github.com/coreboot/coreboot/blob/master/src/vendorcode/amd/agesa/f15tn/Proc/Mem/Main/mmflow.c#L285> procedure of the AGESA code once all memory initialization tasks have completed and before teardown occurs.

Worried that the processor may be caching the value, I decided to flush data at the address before disabling auto-refresh with the following interface provided by the AGESA codebase:


Patch against the source is easier to diagnose for possible mistakes than verbal expression of what you believe you are doing. Eg. the address you write to makes a difference.

Kyösti


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170324/6775d911/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenlog.0
Type: application/octet-stream
Size: 223760 bytes
Desc: screenlog.0
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170324/6775d911/attachment-0001.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170324/6775d911/attachment-0001.txt>