Boot

Boot Image

boot.bin

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
        system.bit
        u-boot.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
        u-boot.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.

image : {
        [bootloader] fsbl.elf
        system.bit
        u-boot.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

BootROM

Loads FSBL into OCM and begins execution

FSBL

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.

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.

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}

JTAG Boot

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