ZYNQ Booting with STYNQ
ZYNQ Booting with STYNQ
STYNQ currently supports only ZYNQ booting from a microSD card. Almost all types of boards support this type of booting. Many require that switches be properly set to select this boot method.
The first requirement for microSD booting is that the microSD card be properly partitioned and formatted. It must have two partitions. The first partition can be a small one of no more than 1GB. It is formatted to Windows95 "VFAT" format. The second is a large one for a Linux operating system, using the rest of the microSD card. It is formatted to the EXT4 filesystem.
It is easiest to partition and format the microSD card from a Linux machine. Be careful: there is danger. The commands to do this must be run as root, and if they're run on the wrong drive, you can erase your operating system. First, the microSD card is formatted with the "fdisk" command. This creates the two partitions, which will be called the BOOT partition and the LINUX partition. The BOOT partition is then formatted to VFAT format with "mkfs.vfat". Finally, the LINUX partition is formatted with mkfs.ext4.
The BOOT partition gets the files that perform the initial booting. These are BOOT.BIN, BOOT.SCR, and image.ub. These three files are placed in the BOOT partition to get the Zynq to boot.
BOOT.BIN contains executable programs that initialize the ARM core in the Zynq. This initialization is a complicated process, involving multiple programs for multiple processors compiled with different compilers. BOOT.BIN is unique to the board, since part of the software initialization is to configure devices such as serial ports and ethernet, and these devices can be at a few different pin locations. Other devices such as the PSGTR transceivers used for USB, DisplayPort, and PCIe are also configured in BOOT.BIN. BOOT.BIN is also unique to the intended future PL configuration, since details of the AXI bus configuration are set up in BOOT.BIN. However, many boards use the same configurations for serial ports and other devices, and projects don't usually need to change AXI bus configurations. So BOOT.BIN can often be reused across boards and FPGAs and projects, even though it is nominally unique. Custom boards may need a unique BOOT.BIN, but even then generally BOOT.BIN needs only be built once for multiple projects on that board.
BOOT.SCR contains instructions to programs within BOOT.BIN. These instructions don't typically need changing, so BOOT.SCR is just generated with BOOT.BIN and follows it around as part of a matched set.
The image.ub file contains a Linux kernel and a device tree. BOOT.BIN loads the Linux kernel and starts it, passing to it the device tree. The device tree informs the Linux kernel of the available devices so it can properly configure the system and start device drivers for the serial ports, ethernet ports, USB, DisplayPort, etc.
BOOT.BIN, BOOT.SCR, and image.ub are created from a single "build.sh" script in the STYNQ_BASE directory. This also builds the Mainline Linux kernel. The primary input is an XSA file, which is put in the STYNQ_BASE/boot/inputs/XSA directory. The outputs are put in the STYNQ_BASE/boot/out directory.
The XSA file is produced from Vivado, using the "File->Export->Export Hardware" menu selection, if using the GUI. It is critical that the ZYNQMP processor block settings be correct, since they specify the correct pins and settings used on your board. If they are incorrect, the board may not boot, or it may boot with incorrect functionality. A guide to how to make those settings is here.
The Linux kernel is given command-line options when it boots, which are also part of image.ub. STYNQ is configured so that one of these options points it to the second partition on the microSD card for its root directory. This causes the Linux kernel to access Debian boot files on that drive, which bring up the complete Debian operating system.
STYNQ provides a directory "filesystem" with a "build.sh" script that fetches a Debian Linux filesystem from the Debian servers and configures it appropriately. This base filesystem is sufficient to boot the board and use "apt" to fetch additional Debian packages.
STYNQ also provides an example for the RFSoC4x2 board, with additional packages needed to run a complicated demo app. This is in the "STYNQ_RFSoC4x2_Example_1" directory. The "build.sh" file in that directory creates this augmented filesystem.
The base filesystem accepts logins from the debug serial port, which can be accessed via most boards USBSERIAL access. See the documentation for your board. The base STYNQ Linux also accepts logins from the ethernet via ssh.
To connect to the board via ssh, you will need to know its hostname or what IP address has been assigned to it. The board obtains an ethernet address via DHCP. When it does so, it requests the hostname that you selected when you built the Debian Linux filesystem. If your DHCP server honors that, "ssh hostname" will connect you to the board from another computer on the same local network, where "hostname" is replaced with the correct name. If the DHCP server doesn't honor the requested name, you will need to discover the IP address by some means. This can be via access to the DHCP server, or via network snooping, or via trying every possible IP address on the local network that the DHCP server might assign. For the RFSoC4x2 board, the IP address should appear on the built-in display once the board is booted. This is one of the extras for that board.
Once you have connected to the board, you can log in with userid and password that you selected when you built the Debian Linux filesystem. You can then run ordinary Debian Linux commands. Since very few commands are provided by default, one of the first commands typically run is "sudo apt install xyz", where xyz is some desired program or package. A list of packages is available with "apt list".
For the RFSoC4x2 board, there's a README.TXT file that tells how to build and run the example application.