[coreboot-gerrit] Change in coreboot[master]: Documentation/Intel/NativeRaminit: Remove trailing whitespaces

Elyes HAOUAS (Code Review) gerrit at coreboot.org
Wed Apr 25 21:46:41 CEST 2018


Elyes HAOUAS has uploaded this change for review. ( https://review.coreboot.org/25831


Change subject: Documentation/Intel/NativeRaminit: Remove trailing whitespaces
......................................................................

Documentation/Intel/NativeRaminit: Remove trailing whitespaces

Change-Id: I1d38aea07e2d9ffb89115410603a5beac5e4d44d
Signed-off-by: Elyes HAOUAS <ehaouas at noos.fr>
---
M Documentation/Intel/NativeRaminit/SandyBridge_registers.md
M Documentation/Intel/NativeRaminit/Sandybridge_freq.md
M Documentation/Intel/NativeRaminit/Sandybridge_read.md
3 files changed, 70 insertions(+), 70 deletions(-)



  git pull ssh://review.coreboot.org:29418/coreboot refs/changes/31/25831/1

diff --git a/Documentation/Intel/NativeRaminit/SandyBridge_registers.md b/Documentation/Intel/NativeRaminit/SandyBridge_registers.md
index c961890..ace3e9a 100644
--- a/Documentation/Intel/NativeRaminit/SandyBridge_registers.md
+++ b/Documentation/Intel/NativeRaminit/SandyBridge_registers.md
@@ -2,7 +2,7 @@
 
 The MCHBAR can be enabled by using register 0x48 of PCI(0:0:0) device.
 
-This documentation is incomplete and might be incorrect. 
+This documentation is incomplete and might be incorrect.
 Please handle with care !
 
 **MCHBAR + 0x4**
diff --git a/Documentation/Intel/NativeRaminit/Sandybridge_freq.md b/Documentation/Intel/NativeRaminit/Sandybridge_freq.md
index af88086..50c6362 100644
--- a/Documentation/Intel/NativeRaminit/Sandybridge_freq.md
+++ b/Documentation/Intel/NativeRaminit/Sandybridge_freq.md
@@ -15,15 +15,15 @@
 | XMP     | Extreme Memory Profiles                                           | -          | -            |
 
 ## SPD
-The [SPD](https://de.wikipedia.org/wiki/Serial_Presence_Detect "Serial Presence Detect") 
-located on every DIMM is factory program with various timings. One of them 
-specifies the maximum clock frequency the DIMM should be used with. The 
-operating frequency is stores as fixed point value (tCK), rounded to the next 
-smallest supported operating frequency. Some 
-[SPD](https://de.wikipedia.org/wiki/Serial_Presence_Detect "Serial Presence Detect") 
-contains additional and optional 
-[XMP](https://de.wikipedia.org/wiki/Extreme_Memory_Profile "Extreme Memory Profile") 
-data, that stores so called "performance" modes, that advertises higher clock 
+The [SPD](https://de.wikipedia.org/wiki/Serial_Presence_Detect "Serial Presence Detect")
+located on every DIMM is factory program with various timings. One of them
+specifies the maximum clock frequency the DIMM should be used with. The
+operating frequency is stores as fixed point value (tCK), rounded to the next
+smallest supported operating frequency. Some
+[SPD](https://de.wikipedia.org/wiki/Serial_Presence_Detect "Serial Presence Detect")
+contains additional and optional
+[XMP](https://de.wikipedia.org/wiki/Extreme_Memory_Profile "Extreme Memory Profile")
+data, that stores so called "performance" modes, that advertises higher clock
 frequencies.
 
 ## XMP profiles
@@ -32,51 +32,51 @@
 * 1.5V operating voltage
 * The channel's installed DIMM count doesn't exceed the XMP coded limit
 
-In case the XMP profile doesn't fullfill those limits, the regular SPD will be 
+In case the XMP profile doesn't fullfill those limits, the regular SPD will be
 used.
 > **Note:** XMP Profiles are supported since coreboot 4.4.
 
 It is possible to ignore the max DIMM count limit set by XMP profiles.
-By activating Kconfig option `NATIVE_RAMINIT_IGNORE_XMP_MAX_DIMMS` it is 
+By activating Kconfig option `NATIVE_RAMINIT_IGNORE_XMP_MAX_DIMMS` it is
 possible to install two DIMMs per channel, even if XMP tells you not to do.
 
 > **Note:** Ignoring XMP Profiles limit is supported since coreboot 4.7.
 
 ## Soft fuses
-Every board manufacturer does program "soft" fuses to indicate the maximum 
-DRAM frequency supported. However, those fuses don't set a limit in hardware 
+Every board manufacturer does program "soft" fuses to indicate the maximum
+DRAM frequency supported. However, those fuses don't set a limit in hardware
 and thus are called "soft" fuses, as it is possible to ignore them.
 
 > **Note:** Ignoring the fuses might cause system instability !
 
-On Sandy Bride *CAPID0_A* is being read, and on Ivybridge *CAPID0_B* is being 
-read. coreboot reads those registers and honors the limit in case the Kconfig 
+On Sandy Bride *CAPID0_A* is being read, and on Ivybridge *CAPID0_B* is being
+read. coreboot reads those registers and honors the limit in case the Kconfig
 option `CONFIG_NATIVE_RAMINIT_IGNORE_MAX_MEM_FUSES` wasn't set.
-Power users that want to let their RAM run at DRAM's "stock" frequency need to 
+Power users that want to let their RAM run at DRAM's "stock" frequency need to
 enable the Kconfig symbol.
 
-It is possible to override the soft fuses limit by using a board-specific 
+It is possible to override the soft fuses limit by using a board-specific
 [devicetree](#devicetree) setting.
 
 > **Note:** Ignoring max mem freq. fuses is supported since coreboot 4.7.
 
 ## <a name="hard_fuses"></a> Hard fuses
-"Hard" fuses are programmed by Intel and limit the maximum frequency that can 
-be used on a given CPU/board/chipset. At time of writing there's no register 
-to read this limit, before trying to set a given DRAM frequency. The memory PLL 
-won't lock, indicating that the chosen memory multiplier isn't available. In 
-this case coreboot tries the next smaller memory multiplier until the PLL will 
+"Hard" fuses are programmed by Intel and limit the maximum frequency that can
+be used on a given CPU/board/chipset. At time of writing there's no register
+to read this limit, before trying to set a given DRAM frequency. The memory PLL
+won't lock, indicating that the chosen memory multiplier isn't available. In
+this case coreboot tries the next smaller memory multiplier until the PLL will
 lock.
 
 ## <a name="devicetree"></a> Devicetree
-The devicetree register ```max_mem_clock_mhz``` overrides the "soft" fuses set 
+The devicetree register ```max_mem_clock_mhz``` overrides the "soft" fuses set
 by the board manufacturer.
 
 By using this register it's possible to force a minimum operating frequency.
 
 ## Reference clock
-While Sandybride supports 133 MHz reference clock (REFCK), Ivy Bridge also 
-supports 100 MHz reference clock. The reference clock is multiplied by the DRAM 
+While Sandybride supports 133 MHz reference clock (REFCK), Ivy Bridge also
+supports 100 MHz reference clock. The reference clock is multiplied by the DRAM
 multiplier to select the DRAM frequency (SCK) by the following formula:
 
  REFCK * MULT = 1 / DCK
@@ -122,11 +122,11 @@
 for i in SPDs:
      freq_max := MIN(freq_max, ddr_spd_max_mhz[i])```
 
-As you can see, by using DIMMs with different maximum DRAM frequencies, the 
+As you can see, by using DIMMs with different maximum DRAM frequencies, the
 slowest DIMMs' frequency will be selected, to prevent over-clocking it.
 
-The selected frequency gives the PLL multiplier to operate at. In case the PLL 
-locks (see Take me to [Hard fuses](#hard_fuses)) the frequency will be used for 
-all DIMMs. At this point it's not possible to change the multiplier again, 
-until the system has been powered off. In case the PLL doesn't lock, the next 
+The selected frequency gives the PLL multiplier to operate at. In case the PLL
+locks (see Take me to [Hard fuses](#hard_fuses)) the frequency will be used for
+all DIMMs. At this point it's not possible to change the multiplier again,
+until the system has been powered off. In case the PLL doesn't lock, the next
 smaller multiplier will be used until a working multiplier will be found.
diff --git a/Documentation/Intel/NativeRaminit/Sandybridge_read.md b/Documentation/Intel/NativeRaminit/Sandybridge_read.md
index d43f931..5a5aa18 100644
--- a/Documentation/Intel/NativeRaminit/Sandybridge_read.md
+++ b/Documentation/Intel/NativeRaminit/Sandybridge_read.md
@@ -2,22 +2,22 @@
 
 ## Introduction
 
-This chapter explains the read training sequence done on Sandy Bride and 
+This chapter explains the read training sequence done on Sandy Bride and
 Ivy Bridge memory initialization.
 
-Read training is done to compensate the skew between DQS and SCK and to find 
+Read training is done to compensate the skew between DQS and SCK and to find
 the smallest supported roundtrip delay.
 
-Every board does have a vendor depended routing topology, and can be equip 
-with any combination of DDR3 memory modules, that introduces different 
-skew between the memory lanes. With DDR3 a "Fly-By" routing topology 
-has been introduced, that makes the biggest part of DQS-SCK skew. 
-The memory code measures the actual skew and actives delay gates, 
+Every board does have a vendor depended routing topology, and can be equip
+with any combination of DDR3 memory modules, that introduces different
+skew between the memory lanes. With DDR3 a "Fly-By" routing topology
+has been introduced, that makes the biggest part of DQS-SCK skew.
+The memory code measures the actual skew and actives delay gates,
 that will "compensate" the skew.
 
-When in read training the DRAM and the controller are placed in a special mode. 
-On every read instruction the DRAM outputs a predefined pattern and the memory 
-controller samples the DQS after a given delay. As the pattern is known, the 
+When in read training the DRAM and the controller are placed in a special mode.
+On every read instruction the DRAM outputs a predefined pattern and the memory
+controller samples the DQS after a given delay. As the pattern is known, the
 actual delay of every lane can be measured.
 
 The values programmed in read training effect DRAM-to-MC transfers only !
@@ -36,34 +36,34 @@
 | DQS     | Data Strobe signal used to sample all lane's DQ signals           | -          | -            |
 
 ## Hardware
-The hardware does have delay logic blocks that can delay the DQ / DQS of a 
-lane/rank by one or multiple clock cylces and it does have delay logic blocks 
+The hardware does have delay logic blocks that can delay the DQ / DQS of a
+lane/rank by one or multiple clock cylces and it does have delay logic blocks
 that can delay the signal by a multiple of 1/64th DCK per lane.
 
-All delay values can be controlled via software by writing registers in the 
+All delay values can be controlled via software by writing registers in the
 MCHBAR.
 
 ## IO phase
 
-The IO phase can be adjusted in [0-512) * 1/64th DCK. Incrementing it by 64 is 
+The IO phase can be adjusted in [0-512) * 1/64th DCK. Incrementing it by 64 is
 the same as Incrementing IO delay by 1.
 
 ## IO delay
 Delays the DQ / DQS signal by one or multiple clock cycles.
 
 ### Roundtrip time
-The roundtrip time is the time the memory controller waits for data arraving 
-after a read has been issued. Due to clock-domain crossings, multiple 
-delay instances and phase interpolators, the signal runtime to DRAM and back 
-to memory controller defaults to 55 DCKs. The real roundtrip time has to be 
+The roundtrip time is the time the memory controller waits for data arraving
+after a read has been issued. Due to clock-domain crossings, multiple
+delay instances and phase interpolators, the signal runtime to DRAM and back
+to memory controller defaults to 55 DCKs. The real roundtrip time has to be
 measured.
 
-After a read command has been issued, a counter counts down until zero has been 
+After a read command has been issued, a counter counts down until zero has been
 reached and activates the input buffers.
 
-The following pictures shows the relationship between those three values. 
+The following pictures shows the relationship between those three values.
 The picture was generated from 16 IO delay values times 64 timA values.
-The highest IO delay was set on the right-hand side, while the last block 
+The highest IO delay was set on the right-hand side, while the last block
 on the left-hand side has zero IO delay.
 
 ** roundtrip 55 DCKs **
@@ -82,39 +82,39 @@
 
 [timA_lane0-3_rt53]: timA_lane0-3_rt53.png "timA for lane0 - lane3, roundtrip 53"
 
-As you can see the signal has some jitter as every sample was taken in a 
-different loop iteration. The result register only contains a single bit per 
+As you can see the signal has some jitter as every sample was taken in a
+different loop iteration. The result register only contains a single bit per
 lane.
 
 ## Algorithm
 ### Steps
-The algorithm finds the roundtrip time, IO delay and IO phase. The IO phase 
+The algorithm finds the roundtrip time, IO delay and IO phase. The IO phase
 will be adjusted to match the falling edge of the preamble of each lane.
-The roundtrip time is adjusted to an minimal value, that still includes the 
+The roundtrip time is adjusted to an minimal value, that still includes the
 preamble.
 
 ### Synchronize to data phase
 
-The first measurement done in read-leveling samples all DQS values for one 
-phase [0-64) * 1/64th DCK. It then searches for the middle of the low data 
-symbol and adjusts timA to the found phase and thus the following measurements 
+The first measurement done in read-leveling samples all DQS values for one
+phase [0-64) * 1/64th DCK. It then searches for the middle of the low data
+symbol and adjusts timA to the found phase and thus the following measurements
 will be aligned to the low data symbol.
-The code assumes that the initial roundtrip time causes the measurement to be 
+The code assumes that the initial roundtrip time causes the measurement to be
 in the alternating pattern data phase.
 
 ### Finding the preamble
-After adjusting the IO phase to the middle of one data symbol the preamble will 
-be located. Unlike the data phase, which is an alternating pattern (010101...), 
+After adjusting the IO phase to the middle of one data symbol the preamble will
+be located. Unlike the data phase, which is an alternating pattern (010101...),
 the preamble consists of two high data cycles.
 
-The code decrements the IO delay/RTT and samples the DQS signal with timA 
-untouched. As it has been positioned in the middle of the data symbol, it'll 
+The code decrements the IO delay/RTT and samples the DQS signal with timA
+untouched. As it has been positioned in the middle of the data symbol, it'll
 read as either "low" or "high".
 
 If it's "low" we are still in the data phase.
 If it's "high" we have found the preamble.
 
-The roundtrip time and IO delay will be adjusted until all lanes are aligned. 
+The roundtrip time and IO delay will be adjusted until all lanes are aligned.
 The resulting IO delay is visible in the picture below.
 
 ** roundtrip time: 49 DCKs, IO delay (at blue point): 6 DCKs **
@@ -122,17 +122,17 @@
 
 [timA_lane0-3_discover_420x]: timA_lane0-3_discover_420x.png "timA for lane0 - lane3, finding minimum roundtrip time"
 
-** Note: The sampled data has been shifted by timA. The preamble is now 
+** Note: The sampled data has been shifted by timA. The preamble is now
 in phase. **
 
 ## Fine adjustment
 
 As timA still points the middle of the data symbol an offset of 32 is added.
 It now points the falling edge of the preamble.
-The fine adjustment is to reduce errors introduced by jitter. The phase is 
-adjusted from `timA - 25` to `timA + 25` and the DQS signal is sampled 100 
-times. The fine adjustment finds the middle of each rising edge (it's actual 
-the falling edge of the preamble) to get the final IO phase. You can see the 
+The fine adjustment is to reduce errors introduced by jitter. The phase is
+adjusted from `timA - 25` to `timA + 25` and the DQS signal is sampled 100
+times. The fine adjustment finds the middle of each rising edge (it's actual
+the falling edge of the preamble) to get the final IO phase. You can see the
 result in the picture below.
 
 ![alt text][timA_lane0-3_adjust_fine]

-- 
To view, visit https://review.coreboot.org/25831
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings

Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I1d38aea07e2d9ffb89115410603a5beac5e4d44d
Gerrit-Change-Number: 25831
Gerrit-PatchSet: 1
Gerrit-Owner: Elyes HAOUAS <ehaouas at noos.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot-gerrit/attachments/20180425/3f19a594/attachment-0001.html>


More information about the coreboot-gerrit mailing list