From krtkl wiki
Jump to: navigation, search

Boot Image


Load Images Using FSBL

Images can be configured to be loaded into memory by FSBL before execution is handed off to the user application or secondary boot loader (U-Boot).

image : {
        [bootloader] fsbl.elf
        [load=0x2a00000] devicetree.dtb
        [load=0x2000000] uramdisk.image.gz
        [load=0x3000000] uImage.bin

Load Images from Partitions

The .bif can be defined to produce a boot image with the components located at specific offsets within the boot image.

image : {
        [bootloader] fsbl.elf
        [offset=0xe0000] uenv.bin
        [offset=0x100000] devicetree.dtb
        [offset=0x120000] uImage.bin
        [offset=0x720000] uramdisk.image.gz
        [offset=0xc00000] system.bit

Will produce an image that includes the components specified in the .bif at the offset locations within the resulting boot image file. This is useful for generating images that are intended to be loaded onto QSPI flash. The offsets specified in the .bif should match the desired memory locations of the components within the flash memory. This method can be used alongside Linux MTD partition specifications for the QSPI flash in the device tree which will allow ease of access to the image components for updating.

Simple System Bootloader

A simple modular bootloader with an included bitstream provides a fully defined programmable logic system along with all the necessary processing system initialization data and U-Boot's mechanisms for loading an booting operating system images. Execution of this system begins with initialization of the processing system with the FSBL before loading the bitstream to the PL. FSBL then hands off execution to U-Boot which has the capability to load a variety of application or operating system images.

image : {
        [bootloader] fsbl.elf

Build Boot Image

The BootGen utility can be invoked from within a directory containing the boot image format file and the components specified within. The boot image format file is specified by the option argument of -image and the output filename specified by the final argument.

$ bootgen -image bootimage.bif -o i boot.bin

Alternatively, an MCS file can be generated by calling BootGen win an output file with the .mcs extension. An MCS file contains an ASCII text representation of the binary data image with each pair of characters representing a single byte in the corresponding binary image.

Build QSPI Image Partitions

To build an image that can be written to the QSPI flash, the boot image format which specifies fixed offsets for the system components. By aligning the offsets with the flash partitions specified in the device tree, images that can be updated using a single binary or individually with component images. The -split option can be used when invoking the BootGen utility to generate separate component binaries for each file in the .bif. These binaries can then be used to update the components from U-Boot or Linux.

$ bootgen -split -image bootimage.bif -o i boot.bin

Boot Process


Loads FSBL into OCM and begins execution


Loads application image into DDR memory and hands off execution to the application.

Secondary Boot Loader (U-Boot)

U-Boot is a secondary bootloader that can be used to load a variety of application or Linux system images.

Boot Source

microSD Card Boot

The microSD card via the SDIO0 interface is the default boot source.

QSPI Flash Boot

The QSPI flash can be set as the boot source by pressing and holding the snickerdoodle RESET button before powering the board. The Zynq BootROM will immediately load the bootgen wrapped header from the start of the QSPI flash memory. The BootROM will then load the FSBL into OCM and begin execution of the bootloader. For Linux systems, U-Boot will be loaded from the QSPI by the FSBL and handed execution. The default environment uses the QSPI $modeboot to load the kernel, device tree and RAMdisk image from the flash memory.

Loading Images

Loading Images from FSBL

The FSBL will load images into memory as specified by the boot image format. After loading the images, the FSBL hands off execution to the specified application (typically U-Boot). This process is entirely dictated by the boot image format.

Load Images from U-Boot

snickerdoodle> sf probe 0 0 0
snickerdoodle> sf read ${kernel_load_address} 0x120000 ${kernel_size}
snickerdoodle> sf read ${devicetree_load_address} 0x100000 ${devicetree_size}
snickerdoodle> sf read ${ramdisk_load_address} 0x720000 ${ramdisk_size}
snickerdoodle> bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}


The JTAG can be set as the boot source by pressing and holding the snickerdoodle SELECT button before powering the board.

% connect
% targets 2
% rst
% source ps7_init.tcl
% ps7_init
% ps7_post_config
% dow u-boot.elf
% con

The default environment uses the JTAG $modeboot variable to load the system images from a TFTP server.

snickerdoodle> tftpboot ${kernel_load_address} ${kernel_image}
snickerdoodle> tftpboot ${devicetree_load_address} ${devicetree_image}
snickerdoodle> tftpboot ${ramdisk_load_address} ${ramdisk_image}
snickerdoodle> bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}

If a TFTP server with the system images does not exist, U-Boot will fall back to the a command prompt. System images can be loaded into memory over JTAG, to be then booted by U-Boot. Before loading images into memory, execution of U-Boot should be halted using stp.

% stp
% dow -data uImage 0x2080000
% dow -data uramdisk.image.gz 0x4000000
% dow -data devicetree.dtb 0x2000000
% con

After resuming execution of U-Boot, the system can be booted from the memory addresses of the loaded images.

snickerdoodle> bootm 0x2080000 0x4000000 0x2000000