muir↗CADR PRESERVED.
QUUX EVOLVED.

muir-fpga · booting

How a board
comes up.

Four sequences, two for the Arty Z7-20 and two for the DE25-Nano: from the board’s own card, which is how anybody else’s board boots, and with TFTP, which is how this project’s own boards boot while they are being worked on.

The Arty Z7-20 is a Zynq-7000 board, and its two sequences are the first two below.

The DE25-Nano has a pair of its own, because it boots differently enough to need one. Its boot crosses two storage devices rather than one, and its fabric is configured in the middle of the sequence rather than by the loader’s first stage.

On either board the two paths differ only in where the files come from. The loader itself is read the same way on both, and the same last step ends both.

The Kria KR260 boots by its own loader, in its flash, which this project leaves alone: it reads the card, which it sees as a USB disk, or a server on the network, and loads Linux and then the bitstream from there (its page).

01 / A ZYNQ-7000 BOARD, FROM ITS CARD

A Zynq-7000 board
on its own.

This is how a board boots for anybody who is not this project: the loader, the CADR’s bitstream, Linux with its root filesystem, and the disk packs are all on the microSD card.

The card’s one partition. The four files the loader reads next sit in a folder named for the board, as they do on the server:

BOOT.BIN      fixed name  the boot ROM reads it here and nowhere else
u-boot.img    fixed name  the first stage asks for it by this name
uEnv.txt      fixed name  imported before any board name is known
<board>/     cadr.bit, the tree, zImage, rootfs.cpio.uboot

Everything the board needs is on its card. No network is used and none is needed.

FIG. 01 — A ZYNQ-7000 BOARD, FROM ITS CARDMUIR-FPGA
how a Zynq board boots on its own everything from the microSD card; no network needed microSD card processing system fabric boot ROM boot-mode jumper: SD U-Boot’s first stage (SPL) ps7_init, DDR3 up U-Boot Linux the CADR, its boot PROM, out of DDR3 the band off the pack reset BOOT.BIN — U-Boot’s first stage u-boot.img — U-Boot proper uEnv.txt, if there is one — names no server <board>/cadr.bit — the CADR fpga loadb: program cadr.bit into the fabric <board>/ the device tree — the CADR’s 17.125 MB reserved <board>/zImage — the kernel <board>/rootfs.cpio.uboot bootz S80: the card mounted read-write S80: --no-auto-boot, if fpgarc asks — the machine held, RUN clear S80: --debug-cable-connect, if fpgarc asks — this board takes Pmod JA S80: the drive comes present — a pack in the bay is the CADR’s disk S84 ozd, S85 the screen over RFB, S86 the serial line, S87 Chaosnet, S88 a USB keyboard and mouse where there is a USB host login on the serial console Linux 493,976 kB — 0x1B000000 to 0x1C11FFFF is the CADR’s on failure: another try every ten seconds
The card holds everything, the CADR is in the fabric before the kernel is fetched, and the machine’s own boot PROM waits in its no-drive loop until Linux presents it a disk. The Arty Z7-20 has booted this way with no network at all.

02 / A ZYNQ-7000 BOARD, FOR DEVELOPMENT

A Zynq-7000 board
with TFTP.

This project’s own boards take the same five files from a TFTP server instead.

A change to any of the board’s five files is a copy on the server and a reset. Its card is never rewritten.

The card’s uEnv.txt decides between the two paths, by whether it names a server, and one U-Boot environment carries both. Each board’s five files sit in a directory named for the board, and the network path never falls back to the card’s own copies.

FIG. 02 — A ZYNQ-7000 BOARD, WITH TFTPMUIR-FPGA
how a Zynq board boots with TFTP the microSD card holds the loader; the rest comes from a TFTP server microSD card processing system DHCP server TFTP server fabric boot ROM boot-mode jumper: SD U-Boot’s first stage (SPL) ps7_init, DDR3 up U-Boot Linux the CADR, its boot PROM, out of DDR3 the band off the pack reset, or rst -srst over JTAG BOOT.BIN — U-Boot’s first stage u-boot.img — U-Boot proper uEnv.txt — names the TFTP server DHCP discover <IP> TFTP: <board>/uEnv.net — the boot command TFTP: <board>/cadr.bit — the CADR’s bitstream fpga loadb: program cadr.bit into the fabric TFTP: <board>/ the device tree TFTP: <board>/zImage — the kernel TFTP: <board>/rootfs.cpio.uboot DHCP, again — Linux’s own <IP> S80: the card mounted read-write S80: --no-auto-boot, if fpgarc asks — the machine held, RUN clear S80: --debug-cable-connect, if fpgarc asks — this board takes Pmod JA S80: the drive comes present — a pack in the bay is the CADR’s disk S84 ozd, S85 the screen over RFB, S86 the serial line, S87 Chaosnet, S88 a USB keyboard and mouse where there is a USB host login on the serial console Linux 493,976 kB; the CADR’s from 0x1B000000 on any failure: another try every ten seconds, and never the card’s own copies 0 s 2 s 9 s 10 s 16 s the times down the left are the Arty Z7-20’s, measured
The two paths differ only in where the bytes come from: both put the CADR in the fabric before the kernel, and both end in the same bootz.

03 / THE DE25-NANO, FROM ITS CARD

The DE25-Nano
on its own.

This board takes the same two paths as the Arty Z7-20, and reaches them differently. There is no BOOT.BIN, because the first-stage loader is in the QSPI flash; and the fabric is empty until U-Boot fills it.

The card’s one partition. Two names are not this project’s to move, and the rest sit in a folder named for the board:

u-boot.itb    fixed name  the first stage asks for it by this name
uEnv.txt      fixed name  imported before any board name is known
de25-nano/    cadr.core.rbf, the tree, Image, rootfs.cpio.uboot

The board’s first phase is in the flash and everything after it is on the card. Its fabric is filled by the loader, not before it.

FIG. 03 — THE DE25-NANO, FROM ITS CARDMUIR-FPGA
how the DE25-Nano boots on its own the flash carries the first phase; the card carries everything after it QSPI flash microSD card processing system fabric U-Boot’s first stage (SPL) LPDDR4 calibrated, 1 GiB U-Boot Linux the CADR, its boot PROM, out of LPDDR4 the band off the pack power on the first phase, over Active Serial — MSEL 001 u-boot.itb — BL31, then U-Boot proper uEnv.txt — names no server, so the card path the fabric’s turn — four steps, all before the kernel de25-nano/cadr.core.rbf — the CADR, 2,125,824 B 1 mw.l gpo 0 — h2f_gp_out low, the gate shut 2 fpga load — the CADR enters the fabric 3 bridge enable — H2F, LWH2F and F2SDRAM released 4 mw.l gpo 1 — h2f_gp_out high, the gate open de25-nano/ the device tree — 17.125 MB reserved at 0xB3000000 de25-nano/Image — the kernel, 41,921,024 B de25-nano/rootfs.cpio.uboot booti S80: the card mounted read-write, clock back from the bay S80: --no-auto-boot, if fpgarc asks — the machine held, RUN clear S80: the drive comes present — a labeled pack is the CADR’s disk S84 ozd, S85 the screen over RFB, S86 the serial line, S87 Chaosnet, S88 a USB keyboard and mouse login on the serial console Linux 938,276 kB — 0xB3000000 to 0xB411FFFF is the CADR’s on failure: another try every ten seconds the flash is written, and this sequence has run from power with no cable attached 0 s 4 s 6 s 14 s 25 s the times down the left are this board’s, measured
The four steps of the fabric’s turn are in the order the boot environment runs them: the image is read, the gate is shut, the CADR is configured, the bridges are released, and only then is the gate opened. The kernel is fetched after all four, so the machine’s first memory cycle cannot meet a bridge still in reset.

04 / THE DE25-NANO, FOR DEVELOPMENT

The DE25-Nano
with TFTP.

A change to any of the five served files is then a copy and a reset, and the card is never rewritten. This path has run on the board: 48,691,884 bytes over the network, and 28 seconds from the reset to the login prompt, against 25 off the card.

The board’s flash and card still carry its loader. Only the five files after it come from the server.

The first-stage loader is in the QSPI flash, and it asks for u-boot.itb by that name at the root of the card, so neither of them comes from the server: the first stage reads the card, and it is U-Boot that speaks TFTP here. uEnv.txt is read off the card on this path too, and it is the file that chose the path. The four steps of the fabric’s turn are the card path’s own, and only the fetch before them changes.

FIG. 04 — THE DE25-NANO, WITH TFTPMUIR-FPGA
how the DE25-Nano boots with TFTP the flash and the card carry the loader; the rest comes from a TFTP server QSPI flash microSD card processing system DHCP server TFTP server fabric U-Boot’s first stage (SPL) LPDDR4 calibrated, 1 GiB U-Boot Linux the CADR, its boot PROM, out of LPDDR4 the band off the pack power on the first phase, over Active Serial — MSEL 001 u-boot.itb — BL31, then U-Boot proper uEnv.txt — names a server, so the network path DHCP discover <IP> uEnv.txt again: the card’s server, not the lease’s TFTP: de25-nano/uEnv.net — the boot command, 1,568 B the fabric’s turn — the card path’s four steps, unchanged TFTP: de25-nano/cadr.core.rbf — the CADR, 2,125,824 B 1 mw.l gpo 0 — h2f_gp_out low, the gate shut 2 fpga load — the CADR enters the fabric 3 bridge enable — H2F, LWH2F and F2SDRAM released 4 mw.l gpo 1 — h2f_gp_out high, the gate open TFTP: de25-nano/ the device tree — 17.125 MB reserved TFTP: de25-nano/Image — the kernel, 41,921,024 B TFTP: de25-nano/rootfs.cpio.uboot booti DHCP, again — Linux’s own <IP> S80: the card mounted read-write, the clock back from the bay S80: --no-auto-boot, if fpgarc asks — the machine held, RUN clear S80: the drive comes present — a labeled pack is the CADR’s disk S84 ozd, S85 the screen over RFB, S86 the serial line, S87 Chaosnet, S88 a USB keyboard and mouse serial console login Linux 938,276 kB — 0xB3000000 to 0xB411FFFF is the CADR’s on any failure: another try every ten seconds, and never the card’s own copies 0 s 4 s 10 s 17 s 28 s the times down the left are this board’s, measured; the same boot off the card reached the prompt at 25 s
The same board, the same flash and the same card, with a server in the middle. What the network changes is where the five files come from, and nothing else: the loader is still read off the card, and the boot ends in the same booti.