For instructors and TAs
Teach embedded Linux from power-on up
A lab course that follows a single-board computer from the moment power reaches it to a finished product, in thirteen modules and ten labs. Students learn each stage of the boot on their own board, then use the system they understand to drive real parts on the 40-pin header.
The student pages are the course text: the modules, the labs and their bench. This section is what you need to run it.
How it is ordered
The course follows the electrons. Each module is one stage of what a board does after power-on and depends only on the stages before it, so a student can always say what the board has done so far and what it needs next.
In week 1 every pair captures the full boot log of their own board, unexplained. Each module then explains the lines its stage prints; by week 5 every boot stage is accounted for, and the second half of the course builds on a system the students understand from the first instruction up.
Prerequisites
| Prerequisite | Required? | Why |
|---|---|---|
| One programming course in C, C++ or Python | Required | Most labs write programs; the driver lab's userspace library can be in any of the three, and the stretch kernel module is in C |
| Basic digital logic and circuits: voltage, current, pull-ups, logic levels | Required | Labs measure rails and wire parts to a 3.3 V header |
| A microcontroller course | Recommended | Gives the contrast the course is built on; for students without one, week 1 and module 0 introduce it |
| Prior Linux use | Not assumed | Week 1 teaches the shell and the Linux tools the labs need |
How the course runs
A typical week has two lectures and one three-hour lab. Students work in pairs at one station, and each student submits their own report. Pick one platform, Das Frite or Solitude, for a section: the student pages show either, but one board per section keeps the bench simple.
Assessment
| Component | Weight | How it is judged |
|---|---|---|
| Labs 1–8 | 40% | 5% each: it works (50%), measurements and analysis (30%), write-up (20%) |
| Two quizzes (quarter weeks 4 and 8; semester weeks 6 and 11) | 10% | Short, in lecture: concepts and datasheet reading. Instructors write them, drawing on each week's check questions in the lecture outlines |
| Practical midterm (quarter week 7; semester week 10) | 15% | Individually at a station: boot a board, enable a header bus with an overlay and drive a GPIO circuit from the pinout, with no notes beyond the datasheets, man pages and --help output, and the printed 40-pin header map (rubric) |
| Final project | 30% | Proposal 3%, checkpoint 5%, demo 12%, report and repository 10% |
| Participation and lab conduct | 5% | Attendance, bench safety, helping other pairs |
In the 14-week semester the labs keep their 40%, shared equally across its 12 labs; a topic's second lab is graded with that topic's rubric.
A board that will not boot is never a reason to lose marks: recovering one is a skill the course teaches.
Teaching materials
A lecture outline for every week of the 10-week quarter, the ten lab handouts, a grading rubric, a TA guide and a station sheet are on the materials page, with what is still in preparation. The semester's extra labs (semester outline) have no handouts of their own yet.
Questions
Can it run on a semester as well as a quarter?
Yes. The schedule has a 10-week quarter and a 14-week semester. The semester covers the same modules and gives the hardest topics a second lab.
Is writing a kernel module required?
In the quarter it is a stretch goal in the driver lab. In the semester it is required.
Which board should my section use?
Either. Das Frite is compact and low cost; Solitude has more memory and I/O. The comparison is on the departments' page, and the student pages follow whichever board each student picks.
Do students overwrite the boards' firmware?
No. They build their own first stage and start the board with it over USB, which leaves the firmware in SPI flash untouched. Restoring firmware is the TA's job; see when a board will not boot.