# Board intake for emv9.3, ipots, and other boards

Do not build or erase QSPI until the following facts are backed by a schematic, Vivado report, vendor board definition, or direct measurement.

## Required identity

- board name, PCB revision, serial/asset identity, SoC/FPGA exact part;
- Vivado hardware handoff and its tool version;
- expected PetaLinux/SDK version and whether migration is authorized;
- intended role of the transition system and later production storage.

## Boot and QSPI

- boot-mode strap/switch mapping, active levels, currently selected setting, and when it is sampled;
- flash manufacturer/part, single/dual, stacked/parallel/cascade topology, bus width, total bytes, page and erase sizes;
- PS/PL controller, chip-selects, MIO/pin mapping, voltage, reset and power dependencies;
- recovery method if the boot region becomes invalid;
- required BOOT.BIN contents: FSBL, U-Boot, optional bitstream/PMUFW/ATF, and why.

## Console and networking

- UART instance, pin routing, baud rate and physical COM adapter;
- Ethernet controller, PHY model/address/interface/reset/clock;
- live host/VM/board subnet, route, firewall and TFTP binding. Discover these each run; do not copy old addresses.

## Later storage

- storage type (removable SD, soldered eMMC, NAND, USB, other), controller instance, pin/MIO mapping and bus width;
- card-detect/write-protect/power-enable wiring and polarity;
- voltage switching capability and maximum safe frequency;
- expected Linux block-device evidence; never assume numbering before enumeration.

## Acceptance decisions

- exact QSPI layout with non-overlap and erase alignment;
- maximum image sizes and RAM load addresses;
- cold-boot count, network checks, storage checks, and whether blank-media formatting is part of this request;
- board-specific hazards and the stop/recovery threshold.

Create `references/<board-name>.md` only after these facts are verified. Mark every unverified item explicitly; placeholders are not deployment permission.