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:
Patrick Rudolph
Philipp Deppenwiese
parent
facc08c47a
commit
90f515a14b
|
|
@ -10,10 +10,10 @@ Today coreboot is capable enough to handle multi-processor initialization on IA
|
|||
|
||||
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
|
||||
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
|
||||
|
|
@ -39,30 +39,39 @@ programming using coreboot published APIs.
|
|||
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 @@ Silicon recommended CPU programming.
|
|||
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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in New Issue