Documentation: More markdown fixes after switching to sphinx
Fix markdown code to work with sphinx. Change-Id: I52014494dc2d09731fe14ab527073352ada860d1 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/26544 Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit is contained in:
committed by
Philipp Deppenwiese
parent
facc08c47a
commit
90f515a14b
@@ -69,7 +69,7 @@ It is possible to override the soft fuses limit by using a board-specific
|
||||
|
||||
> **Note:** Ignoring max mem freq. fuses is supported since coreboot 4.7.
|
||||
|
||||
## <a name="hard_fuses"></a> Hard fuses
|
||||
## 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
|
||||
@@ -77,8 +77,8 @@ 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
|
||||
## Devicetree
|
||||
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.
|
||||
|
@@ -78,20 +78,20 @@ 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
|
||||
![alt text][timA_lane0-3_rt55]
|
||||
![timA for lane0 - lane3, roundtrip 55][timA_lane0-3_rt55]
|
||||
|
||||
[timA_lane0-3_rt55]: timA_lane0-3_rt55.png "timA for lane0 - lane3, roundtrip 55"
|
||||
[timA_lane0-3_rt55]: timA_lane0-3_rt55.png
|
||||
|
||||
#### roundtrip 54 DCKs
|
||||
![alt text][timA_lane0-3_rt54]
|
||||
![timA for lane0 - lane3, roundtrip 54][timA_lane0-3_rt54]
|
||||
|
||||
[timA_lane0-3_rt54]: timA_lane0-3_rt54.png "timA for lane0 - lane3, roundtrip 54"
|
||||
[timA_lane0-3_rt54]: timA_lane0-3_rt54.png
|
||||
|
||||
|
||||
#### roundtrip 53 DCKs
|
||||
![alt text][timA_lane0-3_rt53]
|
||||
![timA for lane0 - lane3, roundtrip 53][timA_lane0-3_rt53]
|
||||
|
||||
[timA_lane0-3_rt53]: timA_lane0-3_rt53.png "timA for lane0 - lane3, roundtrip 53"
|
||||
[timA_lane0-3_rt53]: timA_lane0-3_rt53.png
|
||||
|
||||
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
|
||||
@@ -128,13 +128,13 @@ If it's "high" we have found the preamble.
|
||||
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 **
|
||||
![alt text][timA_lane0-3_discover_420x]
|
||||
**roundtrip time: 49 DCKs, IO delay (at blue point): 6 DCKs**
|
||||
![timA for lane0 - lane3, finding minimum roundtrip time][timA_lane0-3_discover_420x]
|
||||
|
||||
[timA_lane0-3_discover_420x]: timA_lane0-3_discover_420x.png "timA for lane0 - lane3, finding minimum roundtrip time"
|
||||
[timA_lane0-3_discover_420x]: timA_lane0-3_discover_420x.png
|
||||
|
||||
** Note: The sampled data has been shifted by timA. The preamble is now
|
||||
in phase. **
|
||||
**Note: The sampled data has been shifted by timA. The preamble is now
|
||||
in phase.**
|
||||
|
||||
## Fine adjustment
|
||||
|
||||
@@ -146,8 +146,8 @@ 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]
|
||||
![timA for lane0 - lane3, fine adjustment][timA_lane0-3_adjust_fine]
|
||||
|
||||
[timA_lane0-3_adjust_fine]: timA_lane0-3_adjust_fine.png "timA for lane0 - lane3, fine adjustment"
|
||||
[timA_lane0-3_adjust_fine]: timA_lane0-3_adjust_fine.png
|
||||
|
||||
Lanes 0 - 2 will be adjusted by a phase of -10, while lane 3 is already correct.
|
||||
|
Reference in New Issue
Block a user