Skip to content
Libre Computer

ECE 320

Modern Computer: Embedded Systems

This section uses Das Frite. The labs are an embedded system: Linux from boot, through the device tree and the header buses, to a project. This course starts where ECE 210 stops. It does not collect that course's flash, shell, or sensor hand-ins. It stops before a required kernel driver, a power budget, a read-only root, a bad-update recovery, and a bootloader rebuild.

Each week has two lecture hours, a two-hour lab, and four homework hours. Week 3 has no Monday lecture, so that week has one lecture hour. The lab that week stays two hours.

In class is the lecture. The lab and the homework under it are different hand-ins. Read the module the week names, and stop where the week says to stop. The boot media on this section is a USB drive. Commands for a hand boot stay on the module the week links. These notes do not print a second command list.

All four courses. Modules and labs: education.libre.computer.

Week 1

In class

Six boot stages, in order, and what a quoted log line is. The order is the BootROM, the SRAM stage, DRAM, the bootloader, the kernel, and init. A quoted log line is a line you copy from your own capture and attach to one of those names. A login screenshot is not this week's work.

Capture one boot on the serial console from the section image. Mark the same six names on a second capture. The homework is one sentence of your own for each stage name, with no line copied from a log.

On the lab site: Module 0, First boot, ends at capturing the log. This week grades the six named stages.

Lab

  1. From the section image the TA wrote with the desktop imager, capture one boot log on the serial console.
  2. Mark six stages on it. Do not submit a login screenshot. Second pass: capture the log once more and mark the same six names.
  3. Assemble the lab hand-in: A stage map of one boot log naming the BootROM, the SRAM stage, DRAM, the bootloader, the kernel, and init, with one quoted line for each.

Hand in: A stage map of one boot log naming the BootROM, the SRAM stage, DRAM, the bootloader, the kernel, and init, with one quoted line for each.

Homework

Write one sentence of your own for each of the six stage names, with no line copied from a log. Turn in: Those six sentences.

Week 2

In class

Rail order on a supplied trace, and which regulator feeds the SoC. The trace is the one the section supplies. Mark the order the rails rise, and mark when reset releases. One regulator on that trace feeds the SoC. Name it from the labels on the trace. ECE 210's meter table is not this week's work.

The homework names two rails that must already be up before the SoC regulator can start, and why that order matters. Take the names from the lecture trace. These notes do not print a second rail list.

On the lab site: Module 2, First power-on and voltage rails, explains sequencing. This week hands in the marked trace and the SoC regulator.

Lab

  1. On the supplied power-up trace, mark the order the rails rise and when reset releases.
  2. Name the regulator that feeds the SoC. Do not submit ECE 210's two-row meter table. Second pass: mark the same trace in a second color and keep the first marking.
  3. Assemble the lab hand-in: The supplied power-up trace with the rail order marked, and the name of the regulator that feeds the SoC.

Hand in: The supplied power-up trace with the rail order marked, and the name of the regulator that feeds the SoC.

Homework

From the lecture, name two rails that must already be up before the SoC regulator can start. Turn in: Those two rail names and why the order matters.

Week 3

In class

No Monday lecture. One lecture hour remains: how to mark a stage line that is already in the week-1 log. The boot-source names are the labels on the switch.

Copy the source names on the switch before you flip it, and copy the week-1 log line you will watch. That copy is the homework. In the lab, flip the switch, record the order the sources are tried, and boot the TA's first-stage image over USB from the bench PC. Do not rebuild it. Flip the switch back on the second pass.

On the lab site: Module 3, The boot ROM, and Module 4, Loading the bootloader into SRAM. This week grades the observed order and the marked lines.

Lab

  1. No Monday lecture. Mark the BootROM lines on the week-1 log.
  2. Flip the boot switch, power on, and record the order the boot sources are tried. Boot the TA's first-stage image over USB from the bench PC and mark the lines that image prints. Do not rebuild it. Second pass: flip the switch back, boot once more, and keep that order in your notes.
  3. Assemble the lab hand-in: The boot-source order observed after flipping the boot switch, with the BootROM lines and the TA first-stage lines marked on the log.

Hand in: The boot-source order observed after flipping the boot switch, with the BootROM lines and the TA first-stage lines marked on the log.

Homework

From your week-1 boot log and the labels printed on the boot switch, copy the source names on the switch before you flip it. Turn in: The switch labels copied before the flip, and the week-1 log line you will watch.

Week 4

In class

A load address, and why the kernel and the device tree do not share one. A load address is the place in memory where an image sits before it starts. The kernel and the device tree are two images, so each needs its own place. Do not change the memory clock. Do not rebuild the bootloader.

The lab stops at the stock bootloader prompt, loads the two images by hand, and draws the two addresses. The commands are the ones the linked module shows for a hand boot. These notes do not print a second command list. The homework is a paragraph that defines a load address and says why the two images do not share one.

On the lab site: Module 5, Memory bring-up, and Module 6, Software in DRAM. This week grades the hand-boot transcript and the load map.

Lab

  1. Stop at the stock bootloader prompt. Load the kernel and the device tree by hand and boot them.
  2. Draw the load address of each image. Do not change the memory clock and do not rebuild. Second pass: stop at the prompt again and read the two addresses back without booting.
  3. Assemble the lab hand-in: The command transcript that loaded the kernel and the device tree by hand from the stock bootloader prompt, and a memory map of those load addresses.

Hand in: The command transcript that loaded the kernel and the device tree by hand from the stock bootloader prompt, and a memory map of those load addresses.

Homework

Write what a load address is, and why the kernel and the device tree need different ones. Turn in: A paragraph defining a load address and why the two images do not share one.

Week 5

In class

An EFI boot entry: what it names, and what it does not set. It names a file the firmware will start. It does not set a boot-time budget, a power limit, or the root filesystem's mount options. A boot-time budget is not this week's work.

Boot a generic arm64 image through UEFI from the bootloader in SPI NOR. Open one entry and name it. Name the kernel line and the init line on the log. A second entry stays in your notes and off the graded page.

On the lab site: Module 7, UEFI, and Module 8, Linux boots. This week grades the named lines and the entry you opened.

Lab

  1. Boot a generic arm64 image through UEFI from the bootloader in SPI NOR. Inspect one EFI boot entry.
  2. Name the kernel and init lines on the log. Do not submit a boot-time budget. Second pass: open a second entry, name it in your notes, and leave it off the graded page.
  3. Assemble the lab hand-in: The kernel and init lines named on the log, and the EFI boot entry you inspected.

Hand in: The kernel and init lines named on the log, and the EFI boot entry you inspected.

Homework

Write what an EFI boot entry names and what it does not set. Turn in: A paragraph on what an EFI boot entry names and what it leaves unset.

Week 6

In class

Three labels an overlay needs for a stock driver: the compatible string, the bus address, and the status. The lab binds the kernel's DS3231 driver. Show /sys before the overlay and after it. ECE 210's LED program is not this week's work.

The homework is those three labels and nothing else. No overlay source on the homework page. Disable the overlay on the second pass, confirm the earlier listing returns, and enable it again.

On the lab site: Module 9, Device tree and pin multiplexing. This week grades your overlay source and the two listings.

Lab

  1. Read the live device tree.
  2. Write an overlay that binds the kernel's DS3231 driver, and show `/sys` before and after. Do not submit ECE 210's Python LED program. Second pass: disable the overlay, confirm the before listing returns, and enable it again.
  3. Assemble the lab hand-in: The overlay source that binds the DS3231, and the `/sys` listing from before and after.

Hand in: The overlay source that binds the DS3231, and the `/sys` listing from before and after.

Homework

List the compatible string, the bus address, and the status as three labels, with no overlay source. Turn in: Those three labels.

Week 7

In class

How an I2C address byte differs from an SPI chip-select edge. An I2C address byte is a value on the wire that names a device. An SPI chip-select edge is a pin that selects a device before the bytes move. The project uses two of I2C, SPI, and UART.

The lab captures one I2C transaction to the DS3231 and one SPI transaction through the MCP3008. Label the address or the chip select, and the bytes. The proposal names the two buses the project will use. The homework is the comparison, with no capture attached.

On the lab site: Module 10, I/O. This week grades the two labeled captures and the proposal.

Lab

  1. On the logic analyser, capture one I2C transaction to the DS3231 and one SPI transaction through the MCP3008.
  2. Label the address or the chip select and the bytes. Write a one-page proposal that names the two buses the project will use. Second pass: capture each bus once more and keep the second files in your notes.
  3. Assemble the lab hand-in: One decoded I2C capture and one decoded SPI capture, each labeled with the address or the chip select and the bytes, and a one-page proposal that names the two buses the project will use.

Hand in: One decoded I2C capture and one decoded SPI capture, each labeled with the address or the chip select and the bytes, and a one-page proposal that names the two buses the project will use.

Homework

Write how you tell an I2C address byte from an SPI chip-select edge, with no capture attached. Turn in: That comparison.

Week 8

In class

A mocked bus returns a sample the library asked for. A mismatched baud scrambles a byte. A kernel module is not accepted. The mock lets the test run with no chip on the wires. The mismatched baud is a capture that is not the byte you sent. The library stays in userspace.

Loop a UART to the bench PC at two baud rates. Write the userspace library for the MCP3008 and the mock test. The homework is those two sentences: what the mock returns, and what the mismatched baud does to a byte.

On the lab site: Module 11, Drivers, introduces the driver model. This week grades the userspace library, the mock test, and the bad-baud capture. Stop before a kernel module.

Lab

  1. Loop a UART to the bench PC at two baud rates.
  2. Write a userspace driver library for the MCP3008, with a test on a mocked bus. A kernel module is not accepted. Second pass: run the mock test once more and keep the second result in your notes.
  3. Assemble the lab hand-in: The userspace driver library, its test on a mocked bus, and the UART capture at the mismatched baud.

Hand in: The userspace driver library, its test on a mocked bus, and the UART capture at the mismatched baud.

Homework

Write what a mocked bus returns when the library asks for one sample, and what a mismatched baud does to a byte. Turn in: Those two sentences.

Week 9

In class

Which of the two buses comes up first, and why. Bring up the bus you named in the week-7 proposal. Leave a design note for the bus that does not work yet. A recovery runbook is not this week's work.

The homework is a paragraph that names which bus comes up first, and why. That paragraph is not the design note. Power-cycle once on the second pass and show that the working bus still answers.

On the lab site: Module 12, A whole system, is the reading. This week grades the checkpoint of one bus and the note for the second. Stop before a recovery runbook.

Lab

  1. Build the project from the week-7 proposal until one of the two buses works.
  2. Update the design note for the bus that does not work yet. Do not write a recovery runbook. Second pass: power-cycle once and show the working bus still answers.
  3. Assemble the lab hand-in: A checkpoint note showing one project bus working and the design note for the second bus.

Hand in: A checkpoint note showing one project bus working and the design note for the second bus.

Homework

Write which of your two buses you will bring up first, and why, in a paragraph that is not the design note. Turn in: A paragraph naming which bus comes up first, and why, outside the design note.

Week 10

In class

The demo order: two buses, a service, and one question about your own capture or overlay. The project uses two of I2C, SPI, and UART, and it starts as a service. The README names those two buses. Restart the service on the second pass and show the same two buses again.

The homework is the question you will ask your partner about their overlay, and the answer you expect. Write it before the demo.

On the lab site: Module 12, A whole system, has no demo hand-in. This week grades the demo and the README that names the two buses.

Lab

  1. Demonstrate the project.
  2. It uses two of this course's buses and starts as a service. Answer one question about your own capture or overlay. Second pass: restart the service and show the same two buses again.
  3. Assemble the lab hand-in: The live demo of a project that uses two of the course's buses and starts as a service, and the repository README that names those two buses.

Hand in: The live demo of a project that uses two of the course's buses and starts as a service, and the repository README that names those two buses.

Homework

Write the one question you will ask your partner about their overlay, and the answer you expect. Turn in: The question and the expected answer.