Memory and the bootloader

Modules this lab uses

• Module 5: Memory bring-up
• Module 6: Software in DRAM

What you need

• Your station's board, power supply, boot media and serial console, and your lab 1 log
• The bench PC with libretech-builder-simple and your lab 3 build
• The Amlogic USB boot tool on the bench PC, to start the board over USB with your build as in lab 3

Steps: memory

1. In your lab 1 log, annotate the memory lines: the size and clock the first stage reports.
2. In the open first stage's source, find where your board's memory clock, timings and training are set.
3. Change the memory clock in the build configuration, rebuild with libretech-builder-simple, start the board over USB with your build from the bench PC, and record what changes on the console and in the system that boots.
4. In Linux on the changed-clock boot, run a memory test with sudo memtester 128M 1, and note what it can and cannot prove.
5. Shut the board down with sudo poweroff, wait for the console to show it has halted, unplug it and plug it back in: it boots from its own firmware again, because your build was only ever in the board's RAM (SRAM, then DRAM) and nothing was written to its storage.

Steps: the bootloader by hand

1. On the running system from lab 1, read /proc/cmdline and save it: these are the arguments the normal boot gives the kernel, including where its root filesystem is.
2. Reboot with the console open and interrupt U-Boot's automatic boot from the console, to stop at its prompt.
3. Explore with bdinfo, printenv and md. help lists every command; help <command> explains one.
4. Find the kernel and the device tree on the boot media with U-Boot's ls, on the device your board's note above names.
5. Load each into memory at an address you choose with load, keeping the two apart, and set bootargs from the line you saved with setenv bootargs '…' (module 6 explains it).
6. Start the kernel with booti, giving it the kernel's address, - or an initramfs address, and the device tree's address (help booti). If your saved command line names the root filesystem by UUID= or LABEL=, the kernel needs the initramfs to find it: load it last, so U-Boot's filesize holds its size, and pass <address>:${filesize} instead of - (a raw initramfs needs its size as well as its address). Log in when it reaches the prompt.
7. Draw the memory map: where each image went, and where the stages before it ran.
8. Annotate the secure monitor's and U-Boot's lines in your lab 1 log.

What to measure

• The memory size and clock the first stage reports, before and after your change, and any other effect you see.
• The addresses you loaded the kernel and device tree at, and whether they overlap anything on your memory map.

The annotated boot log

An annotated boot log for each board is in preparation. Until it is published, annotate the memory, secure monitor and U-Boot lines from your own log and the two modules.

What you hand in

• The memory change you made and its effect.
• The exact commands that booted the kernel by hand.
• Your memory map.
• Your own short report: what you did, what you measured, and one problem you met and how you solved it.

If it goes wrong

A kernel that starts but cannot find its root filesystem usually means bootargs was not set, or that the root is named by UUID= or LABEL= and the initramfs was not loaded. A board that stops after your memory change needs only a power cycle. Otherwise work down when it will not boot on your bench page.