With the release of the 2020.x tool chains, PetaLinux was updated to support Distro Boot. If you are not familiar with Distro Boot, its goal is to make Arm-based platforms boot more standardized. It achieves this by decoupling the discovery of the boot media from the boot loaders.
For example, on the Zynq-7000 and Zynq MPSoC platforms, following power on the boot mode is determined by the BootROM sampling the mode pins. This boot mode is then passed to the FSBL, which passes to the second stage boot loader U-Boot in a Linux system. It is in the hand off from U-Boot to the operating system that Distro Boot provides the framework to load the operating system reliably and predictably in a platform independent manner.
Within the Xilinx ecosystem, the Distro Boot functionality is used as an extension of the U-Boot bootcmd which executes once the boot countdown completes. The approach Xilinx uses to Distro Boot is the boot.scr file. This file contains a script that will be executed depending upon the boot mode and the location of the operating system image.
This is why with recent board releases like the Ultra96-V2, you see the Boot.bin Image.ub and the boot.scr in the boot partition of the SD Card. The Boot.scr is the file that informs U-Boot how to load the Linux operating system.
This is very useful because it also enables us to implement primary and secondary boot solutions very simply.
I have recently been working on SensorThink smart sensor IoT board software development, intended as an IoT training board. Its boot configuration is like one you might see in a production system.
The primary boot mechanism is QSPI while the SD Card is provided for secondary boot. This enables large Linux images and the root filesystem to be located on the SD Card. This split boot method is needed as the Linux image with the WiFi driver and additional applications makes the kernel image larger than what can be stored in the QSPI.
However, developing with a Distro Boot approach actually makes this much simpler because the only thing we need to change is the boot script (boot.scr) which tells U-Boot the actions to take to load the operating system.
When we build the PetaLinux project, a boot.scr is generated that uses the standard defaults as indicated above. For example, if the boot method is QSPI, the operating system is also contained within the QSPI.
However, we can program the QSPI with the Boot.bin and then direct the image to be loaded from the SD Card within the smart sensor IoT board thanks to the decoupling provided by the boot script.
To make changes to the behavior of the boot.scr when it is generated, we can change the file located in the meta-user layer under the recipes-bsp/u-boot/u-boot-zynq-scr/boot.cmd.default. There are three files under this location. Select the right one for your application.
For this application, I have changed the commands under the QSPI section to perform a fatload from the mmc 0 (SD Card 0) and then boot that fatload.
The remaining steps are to package the boot files to create the boot.bin file before writing the image and the boot.scr to flash using Vivado. Rename the boot.scr to booscr.bin to flash easily via Vivado.
I can then place the image.ub on the SD Card and boot the system. You will see the FSBL and U-Boot run from the QSPI and the Linux image boot from the SD Card as can be seen above!
Up Coming Book!
Do you want to know more about designing embedded systems from scratch? Check out our upcoming book on creating embedded systems. This book will walk you through all the stages of requirements, architecture, component selection, schematics, layout, and FPGA / software design.
We designed and manufactured the board at the heart of the book!
Learn more about the board (see previous blogs on Bring up, DDR validation, USB, Sensors) and view the schematics here.
See the schematics, the layout will be made available on a new website soon!
Comments