Module 5 ยท Lab 4
Memory bring-up
DRAM is the reason the first stage exists. Before a single byte can be stored in it, the memory controller has to be told what memory is attached and how fast it runs, then tuned until reads and writes come back correct.
Where this stage sits
Key ideas
- DRAM stores each bit as charge in a tiny capacitor, which leaks; the controller has to refresh every row many times a second.
- The controller needs the memory's timings (how many clock cycles to open a row, read a column or close a row), its bus width, its size and its clock. The two course boards differ here: Das Frite has one DDR4 chip on a 16-bit bus, Solitude has LPDDR4 on a 32-bit bus, and each needs its own settings and training.
- At these speeds the data lines do not arrive in step. Training sweeps the delay on each lane, finds the window in which data is read correctly, and sets the delay to its centre.
- Size detection writes and reads at chosen addresses to find how much memory is really there.
- A failed bring-up usually stops the boot right here. A marginal one is worse: the board boots and corrupts data later, which is why boards are memory-tested.
On the bench
In short, what you do in lab 4, where the steps are given in full:
- Annotate the memory lines of the Lab 1 log: the size and clock the first stage reports.
- In the open first stage's source, find where your board's memory clock, timings and training are set.
- Change the memory clock in the build configuration, rebuild with libretech-builder-simple, start the board over USB with your build, and record what changes.
- Run a memory test (
memtester) on the changed-clock boot, and explain what it can and cannot prove.
Resources
| Resource | Use in this module |
|---|---|
| libretech-builder-simple | Builds the open first stage, memory bring-up included, for your board |
| boot.libre.computer | The published open-chain builds, to compare yours against |
| U-Boot documentation | The SPL and its memory initialisation |