[coreboot-gerrit] Change in coreboot[master]: Documentation: More markdown fixes after switching to sphinx
Patrick Rudolph (Code Review)
gerrit at coreboot.org
Fri May 25 13:42:27 CEST 2018
Patrick Rudolph has uploaded this change for review. ( https://review.coreboot.org/26544
Change subject: Documentation: More markdown fixes after switching to sphinx
......................................................................
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 at 9elements.com>
---
M Documentation/Intel/MultiProcessorInit/MultiProcessorInit.md
M Documentation/Intel/NativeRaminit/Sandybridge_freq.md
M Documentation/Intel/NativeRaminit/Sandybridge_read.md
3 files changed, 50 insertions(+), 39 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/44/26544/1
diff --git a/Documentation/Intel/MultiProcessorInit/MultiProcessorInit.md b/Documentation/Intel/MultiProcessorInit/MultiProcessorInit.md
index 477c559..ab0b513 100644
--- a/Documentation/Intel/MultiProcessorInit/MultiProcessorInit.md
+++ b/Documentation/Intel/MultiProcessorInit/MultiProcessorInit.md
@@ -10,15 +10,15 @@
The multi-processor initialization code has to take care of lots of duties:
-1 Bringing all cores out of reset
-2 Load latest microcode on all cores
-3 Sync latest MTRR snapshot between BSP and APs
-4 Perform sets of CPU feature programming
- * CPU Power & Thermal Management
- * Overclocking
- * Intel Trusted Execution Technology
- * Intel Software Guard Extensions
- * Intel Processor Trace etc.
+1. Bringing all cores out of reset
+2. Load latest microcode on all cores
+3. Sync latest MTRR snapshot between BSP and APs
+4. Perform sets of CPU feature programming
+ * CPU Power & Thermal Management
+ * Overclocking
+ * Intel Trusted Execution Technology
+ * Intel Software Guard Extensions
+ * Intel Processor Trace etc.
This above CPU feature programming lists are expected to grow with current and future
CPU complexity and there might be some cases where certain feature programming mightbe
@@ -39,30 +39,39 @@
Due to the fact that FSP is using EFI infrastructure and need to relying on install/locate
PPI to perform certain API call, hence coreboot has to created MP services APIs known as
EFI_MP_SERVICES_PPI as per PI specification volume 1, section 8.3.9.
-More details here: http://www.uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf
+More details here: [PI_Spec_1_6]
### coreboot to publish EFI_MP_SERVICES_PPI APIs
-| API | Description |
-|------------------------------|------------------------------------------------------------------|
-| PeiGetNumberOfProcessors | Get the number of CPU's. |
-| PeiGetProcessorInfo | Get information on a specific CPU. |
-| PeiStartupAllAPs | Activate all of the application processors. |
-| PeiStartupThisAP | Activate a specific application processor. |
-| PeiSwitchBSP | Switch the boot strap processor. |
-| PeiEnableDisableAP | Enable or disable an application processor. |
-| PeiWhoAmI | Identify the currently executing processor. |
-|------------------------------|------------------------------------------------------------------|
+```eval_rst
++------------------------------+------------------------------------------------------------------+
+| API | Description |
++==============================+==================================================================+
+| PeiGetNumberOfProcessors | Get the number of CPU's. |
++------------------------------+------------------------------------------------------------------+
+| PeiGetProcessorInfo | Get information on a specific CPU. |
++------------------------------+------------------------------------------------------------------+
+| PeiStartupAllAPs | Activate all of the application processors. |
++------------------------------+------------------------------------------------------------------+
+| PeiStartupThisAP | Activate a specific application processor. |
++------------------------------+------------------------------------------------------------------+
+| PeiSwitchBSP | Switch the boot strap processor. |
++------------------------------+------------------------------------------------------------------+
+| PeiEnableDisableAP | Enable or disable an application processor. |
++------------------------------+------------------------------------------------------------------+
+| PeiWhoAmI | Identify the currently executing processor. |
++------------------------------+------------------------------------------------------------------+
+```
## Code Flow
Here is proposed design flow with coreboot has implemented EFI_MP_SERVICES_PPI API and FSP will make
use of the same to perform some CPU feature programming.
-** coreboot-FSP MP init flow **
-![alt text][coreboot_publish_mp_service_api]
+**coreboot-FSP MP init flow**
+![coreboot-fsp mp init flow][coreboot_publish_mp_service_api]
-[coreboot_publish_mp_service_api]: coreboot_publish_mp_service_api.png "coreboot-fsp mp init flow"
+[coreboot_publish_mp_service_api]: coreboot_publish_mp_service_api.png
## Benefits
1. coreboot was using SkipMpInit=1 which will skip entire FSP CPU feature programming.
@@ -72,3 +81,5 @@
coreboot interfaces to execute those programming.
3. coreboot will have more control over running those feature programming as API optimization
handled by coreboot.
+
+[PI_Spec_1_6]: http://www.uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf
diff --git a/Documentation/Intel/NativeRaminit/Sandybridge_freq.md b/Documentation/Intel/NativeRaminit/Sandybridge_freq.md
index cf68d5e..d8b73b3 100644
--- a/Documentation/Intel/NativeRaminit/Sandybridge_freq.md
+++ b/Documentation/Intel/NativeRaminit/Sandybridge_freq.md
@@ -69,7 +69,7 @@
> **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 @@
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.
diff --git a/Documentation/Intel/NativeRaminit/Sandybridge_read.md b/Documentation/Intel/NativeRaminit/Sandybridge_read.md
index e58298a..0496657 100644
--- a/Documentation/Intel/NativeRaminit/Sandybridge_read.md
+++ b/Documentation/Intel/NativeRaminit/Sandybridge_read.md
@@ -78,20 +78,20 @@
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 @@
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 @@
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.
--
To view, visit https://review.coreboot.org/26544
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: I52014494dc2d09731fe14ab527073352ada860d1
Gerrit-Change-Number: 26544
Gerrit-PatchSet: 1
Gerrit-Owner: Patrick Rudolph <patrick.rudolph at 9elements.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot-gerrit/attachments/20180525/98376ebf/attachment-0001.html>
More information about the coreboot-gerrit
mailing list