Difference between revisions of "Boot"
(Created page with "== 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...") |
m |
||
Line 34: | Line 34: | ||
</pre> | </pre> | ||
− | 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. | + | 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. |
<pre> | <pre> | ||
image : { | image : { | ||
[bootloader] fsbl.elf | [bootloader] fsbl.elf | ||
+ | system.bit | ||
u-boot.elf | u-boot.elf | ||
} | } |
Revision as of 06:10, 25 February 2018
Contents
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