Recommonmark has been deprecated since 2021 [1] and the last release was over 3 years ago [2]. As per their announcement, Markedly Structured Text (MyST) Parser [3] is the recommended replacement. For the most part, the existing documentation is compatible with MyST, as both parsers are built around the CommonMark flavor of Markdown. The main difference that affects coreboot is how the Sphinx toctree is generated. Recommonmark has a feature called auto_toc_tree, which converts single level lists of references into a toctree: * [Part 1: Starting from scratch](part1.md) * [Part 2: Submitting a patch to coreboot.org](part2.md) * [Part 3: Writing unit tests](part3.md) * [Managing local additions](managing_local_additions.md) * [Flashing firmware](flashing_firmware/index.md) MyST Parser does not provide a replacement for this feature, meaning the toctree must be defined manually. This is done using MyST's syntax for Sphinx directives: ```{toctree} :maxdepth: 1 Part 1: Starting from scratch <part1.md> Part 2: Submitting a patch to coreboot.org <part2.md> Part 3: Writing unit tests <part3.md> Managing local additions <managing_local_additions.md> Flashing firmware <flashing_firmware/index.md> ``` Internally, auto_toc_tree essentially converts lists of references into the Sphinx toctree structure that the MyST syntax above more directly represents. The toctrees were converted to the MyST syntax using the following command and Python script: `find ./ -iname "*.md" | xargs -n 1 python conv_toctree.py` ``` import re import sys in_list = False f = open(sys.argv[1]) lines = f.readlines() f.close() with open(sys.argv[1], "w") as f: for line in lines: match = re.match(r"^[-*+] \[(.*)\]\((.*)\)$", line) if match is not None: if not in_list: in_list = True f.write("```{toctree}\n") f.write(":maxdepth: 1\n\n") f.write(match.group(1) + " <" + match.group(2) + ">\n") else: if in_list: f.write("```\n") f.write(line) in_list = False if in_list: f.write("```\n") ``` While this does add a little more work for creating the toctree, this does give more control over exactly what goes into the toctree. For instance, lists of links to external resources currently end up in the toctree, but we may want to limit it to pages within coreboot. This change does break rendering and navigation of the documentation in applications that can render Markdown, such as Okular, Gitiles, or the GitHub mirror. Assuming the docs are mainly intended to be viewed after being rendered to doc.coreboot.org, this is probably not an issue in practice. Another difference is that MyST natively supports Markdown tables, whereas with Recommonmark, tables had to be written in embedded rST [4]. However, MyST also supports embedded rST, so the existing tables can be easily converted as the syntax is nearly identical. These were converted using `find ./ -iname "*.md" | xargs -n 1 sed -i "s/eval_rst/{eval-rst}/"` Makefile.sphinx and conf.py were regenerated from scratch by running `sphinx-quickstart` using the updated version of Sphinx, which removes a lot of old commented out boilerplate. Any relevant changes coreboot had made on top of the previous autogenerated versions of these files were ported over to the newly generated file. From some initial testing the generated webpages appear and function identically to the existing documentation built with Recommonmark. TEST: `make -C util/docker docker-build-docs` builds the documentation successfully and the generated output renders properly when viewed in a web browser. [1] https://github.com/readthedocs/recommonmark/issues/221 [2] https://pypi.org/project/recommonmark/ [3] https://myst-parser.readthedocs.io/en/latest/ [4] https://doc.coreboot.org/getting_started/writing_documentation.html Change-Id: I0837c1722fa56d25c9441ea218e943d8f3d9b804 Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73158 Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
6.2 KiB
Sandy Bridge Raminit
Introduction
This documentation is intended to document the closed source memory controller hardware for Intel 2nd Gen (Sandy Bridge) and 3rd Gen (Ivy Bridge) core-i CPUs.
The memory initialization code has to take care of lots of duties:
- Selection of operating frequency
- Selection of common timings
- Applying frequency specific compensation values
- Read training of all populated channels
- Write training of all populated channels
- Adjusting delay networks of address and command signals
- DQS training of all populated channels
- Programming memory map
- Report DRAM configuration
- Error handling
Definitions
+---------+-------------------------------------------------------------------+------------+--------------+
| Symbol | Description | Units | Valid region |
+=========+===================================================================+============+==============+
| SCK | DRAM system clock cycle time | s | |
+---------+-------------------------------------------------------------------+------------+--------------+
| tCK | DRAM system clock cycle time | 1/256th ns | |
+---------+-------------------------------------------------------------------+------------+--------------+
| DCK | Data clock cycle time: The time between two SCK clock edges | s | |
+---------+-------------------------------------------------------------------+------------+--------------+
| timA | IO phase: The phase delay of the IO signals | 1/64th DCK | [0-512) |
+---------+-------------------------------------------------------------------+------------+--------------+
| SPD | Manufacturer set memory timings located on an EEPROM on every DIMM| bytes | |
+---------+-------------------------------------------------------------------+------------+--------------+
| REFCK | Reference clock, either 100 or 133 | Mhz | 100, 133 |
+---------+-------------------------------------------------------------------+------------+--------------+
| MULT | DRAM PLL multiplier | | [3-12] |
+---------+-------------------------------------------------------------------+------------+--------------+
| XMP | Extreme Memory Profiles | | |
+---------+-------------------------------------------------------------------+------------+--------------+
(Unofficial) register documentation
:maxdepth: 1
Sandy Bridge - Register documentation <nri_registers.md>
Frequency selection
:maxdepth: 1
Sandy Bridge - Frequency selection <nri_freq.md>
Read training
:maxdepth: 1
Sandy Bridge - Read training <nri_read.md>
SMBIOS type 17
The SMBIOS specification allows to report the memory configuration in use.
On GNU/Linux you can run # dmidecode -t 17
to view it.
Example output of dmidecode:
Handle 0x0045, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x0042
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: ChannelB-DIMM0
Bank Locator: BANK 2
Type: DDR3
Type Detail: Synchronous
Speed: 933 MHz
Manufacturer: 0420
Serial Number: 00000000
Asset Tag: 9876543210
Part Number: F3-1866C9-8GSR
Rank: 2
Configured Clock Speed: 933 MHz
The memory frequency printed by dmidecode is the active memory frequency. It's not the double datarate and it's not the one encoded maximum frequency in each DIMM's SPD.
Note: This feature is available since coreboot 4.4
MRC cache
The name MRC cache might be misleading as in case of Native RAM init there's no MRC, but for historical reasons it's still named MRC cache. The MRC cache is part of flash memory that is writeable by coreboot. At the end of the boot process coreboot will write the RAM training results to flash for future use, as RAM training is time intensive. Storing the results allows to boot faster on normal boot and allows to support S3 resume, as the RAM training results can't be stored in RAM (you need to configure the memory controller first to access RAM).
The MRC cache needs to be invalidated in case the memory configuration has been changed. To detect a changed memory configuration the CRC16 of each DIMM is stored to MRC cache.
Note: This feature is available since coreboot 4.4
Error handling
As of writing the only supported error handling is to disable the failing channel and restart the memory training sequence. It's very likely to succeed, as memory channels operate independent of each other. In case no DIMM could be initialized coreboot will halt. The screen will stay black until you power of your device. On some platforms there's additional feedback to indicate such an event.
If you find dmidecode -t 17
to report only half of the memory installed,
it's likely that a fatal memory init failure had happened.
It is assumed, that a working board with less physical memory, is much better,
than a board that doesn't boot at all.
Note: This feature is available since coreboot 4.5
Try to swap memory modules and or try to use a different vendor. If nothing helps you could have a look at chapter [Debugging] or report a ticket at [ticket.coreboot.org]. Please provide a full RAM init log, that has been captured using EHCI debug.
To enable extensive RAM training logging enable the Kconfig option
DEBUG_RAM_SETUP
Lenovo Thinkpads
Lenovo Thinkpads do have an additional feature to indicate that RAM init has
failed and coreboot has died (it calls die() on fatal error, thus the name).
The Kconfig options
H8_BEEP_ON_DEATH
H8_FLASH_LEDS_ON_DEATH
enable blinking LEDs and enable a beep to indicate death.
Note: This feature is available since coreboot 4.7
Debugging
It's recommended to use an external debugger, such as serial or EHCI debug dongle. In case of failing memory init the board might not boot at all, preventing you from using CBMEM.