Use Cases and Examples

The following are typical use cases and examples for Bootgen. Some use cases are more complex and require explicit instruction. These typical use cases and examples have more definition when you reference the Attributes.

Zynq MPSoC Use Cases

Simple Application Boot on Different Cores

The following example shows how to create a boot image with applications running on different cores. The pmu_fw.elf is loaded by BootROM. The fsbl_a53.elf is the bootloader and loaded on to A53-0 core. The app_a53.elf is executed by A53-1 core, and app_r5.elf by r5-0 core.

the_ROM_image: 
{ 
	[pmufw_image] pmu_fw.elf 
	[bootloader, destination_cpu=a53-0] fsbl_a53.elf 
	[destination_cpu=a53-1] app_a53.elf 
	[destination_cpu=r5-0] app_r5.elf
}

PMU Firmware Load by BootROM

This example shows how to create a boot image with pmu_fw.elf loaded by BootROM.

the_ROM_image: 
{ 
	[pmufw_image] pmu_fw.elf 
	[bootloader, destination_cpu=a53-0] fsbl_a53.elf 
	[destination_cpu=r5-0] app_r5.elf
}

This example shows how to create a boot image with pmu_fw.elf loaded by BootROM. If PMU firmware is specified with attribute [pmufw_image], then PMU firmware is not treated as a separate partition. It is appended to the FSBL, and FSBL and PMU firmware together will be one single large partition. Hence, you cannot not see the PMU firmware in the bootgen log as well.

PMU Firmware Load by FSBL

This example shows how to create a boot image with pmu_fw.elf loaded by FSBL.

the_ROM_image:
{ 
	[bootloader, destination_cpu=a53-0] fsbl_a53.elf 
	[destination_cpu=pmu] pmu_fw.elf 
	[destination_cpu=r5-0] app_r5.elf
}
Note: Bootgen uses the options provided to [bootloader] for [pmufw_image] as well. The [pmufw_image] does not take any extra parameters.

Booting Linux

This example shows how to boot Linux on a Zynq® UltraScale+™ MPSoC device (arch=zynqmp).
  • The fsbl_a53.elf is the bootloader and runs on a53-0.
  • The pmu_fw.elf is loaded by FSBL.
  • The bl31.elf is the Arm® Trusted Firmware (ATF), which runs at el-3.
  • The U-Boot program, uboot, runs at el-2 on a53-0.
  • The Linux image, image.ub, is placed at offset 0x1E40000 and loaded at 0x10000000.
the_ROM_image: 
{ 
	[bootloader, destination_cpu = a53-0]fsbl_a53.elf 
	[destination_cpu=pmu]pmu_fw.elf 
	[destination_cpu=a53-0, exception_level=el-3, trustzone]bl31.elf  
	[destination_cpu=a53-0, exception_level=el-2] u-boot.elf 
	[offset=0x1E40000, load=0X10000000, destination_cpu=a53-0]image.ub 
}

Encryption Flow: BBRAM Red Key

This example shows how to create a boot image with the encryption enabled for FSBL and the application with the Red key stored in BBRAM:

the_ROM_image: 
{
	[keysrc_encryption] bbram_red_key 
	[
 	 bootloader, 
 	 encryption=aes, 
 	 aeskeyfile=aes0.nky, 
 	 destination_cpu=a53-0
	] ZynqMP_Fsbl.elf 
	[destination_cpu=a53-0, encryption=aes, aeskeyfile=aes1.nky]App_A53_0.elf 
}

Encryption Flow: Red Key Stored in eFUSE

This example shows how to create a boot image with encryption enabled for FSBL and application with the RED key stored in eFUSE.

the_ROM_image: 
{ 
	[keysrc_encryption] efuse_red_key 

	[
	  bootloader, 
	  encryption=aes, 
	  aeskeyfile=aes0.nky, 
	  destination_cpu=a53-0
	] ZynqMP_Fsbl.elf 

	[
	  destination_cpu = a53-0, 
	  encryption=aes, 
	  aeskeyfile=aes1.nky
	] App_A53_0.elf 
}

Encryption Flow: Black Key Stored in eFUSE

This example shows how to create a boot image with the encryption enabled for FSBL and an application with the efuse_blk_key stored in eFUSE. Authentication is also enabled for FSBL.

the_ROM_image: 
{ 
	[fsbl_config] puf4kmode, shutter=0x0100005E
	[auth_params] ppk_select=0; spk_id=0x5
	[pskfile] primary_4096.pem
	[sskfile] secondary_4096.pem
	[keysrc_encryption] efuse_blk_key 
	[bh_key_iv] bhkeyiv.txt
	[
	  bootloader,
	  encryption=aes,
	  aeskeyfile=aes0.nky,
	  authentication=rsa
	] fsbl.elf 
}
Note: Boot image authentication is compulsory for using black key encryption.

Encryption Flow: Black Key Stored in Boot Header

This example shows how to create a boot image with encryption enabled for FSBL and the application with the bh_blk_key stored in the Boot Header. Authentication is also enabled for FSBL.

the_ROM_image: 
{ 
	[pskfile] PSK.pem
	[sskfile] SSK.pem
	[fsbl_config] shutter=0x0100005E
	[auth_params] ppk_select=0
	[bh_keyfile] blackkey.txt
	[bh_key_iv] black_key_iv.txt
	[puf_file]helperdata4k.txt
	[keysrc_encryption] bh_blk_key 
	[
	  bootloader,
	  encryption=aes,
	  aeskeyfile=aes0.nky,
	  authentication=rsa,
	  destination_cpu=a53-0
	] ZynqMP_Fsbl.elf 

	[
	  destination_cpu = a53-0,
	  encryption=aes,
	  aeskeyfile=aes1.nky
	] App_A53_0.elf 
}
Note: Boot image Authentication is required when using black key Encryption.

Encryption Flow: Gray Key Stored in eFUSE

This example shows how to create a boot image with encryption enabled for FSBL and the application with the efuse_gry_key stored in eFUSE.

the_ROM_image: 
{ 
	[keysrc_encryption] efuse_gry_key
	[bh_key_iv] bh_key_iv.txt 
	
	[
	  bootloader,
	  encryption=aes,
	  aeskeyfile=aes0.nky,
	  destination_cpu=a53-0
	] ZynqMP_Fsbl.elf 
	
	[
	  destination_cpu=a53-0,
	  encryption=aes,
	  aeskeyfile=aes1.nky
	] App_A53_0.elf 
}

Encryption Flow: Gray Key Stored in Boot Header

This example shows how to create a boot image with encryption enabled for FSBL and the application with the bh_gry_key stored in the Boot Header.

the_ROM_image:
{ 
	[keysrc_encryption] bh_gry_key 
	[bh_keyfile] bhkey.txt
	[bh_key_iv] bh_key_iv.txt
	
	[
	  bootloader,
	  encryption=aes,
	  aeskeyfile=aes0.nky,
	  destination_cpu=a53-0
	] ZynqMP_Fsbl.elf 
	
	[
	  destination_cpu=a53-0,
	  encryption=aes,
	  aeskeyfile=aes1.nky
	] App_A53_0.elf 
}

Operational Key

This example shows how to create a boot image with encryption enabled for FSBL and application with the red key stored in eFUSE.

the_ROM_image:
{
	[fsbl_config] opt_key
	[keysrc_encryption] efuse_red_key

	[
	  bootloader,
	  encryption=aes,
	  aeskeyfile=aes0.nky,
	  destination_cpu=a53-0
	] ZynqMP_Fsbl.elf 

	[
	  destination_cpu=a53-0,
	  encryption=aes,
	  aeskeyfile=aes1.nky
	] App_A53_0.elf 
}

Using Op Key to Protect the Device Key in a Development Environment

The following steps provide a solution in a scenario where two development teams, Team-A (secure team), which manages the secret red key and Team-B, (Not so secure team), work collaboratively to build an encrypted image without sharing the secret red key. Team-A manages the secret red key. Team-B builds encrypted images for development and test. However, it does not have access to the secret red key.

Team-A encrypts the boot loader with the device key (using the Op_key option) - delivers the encrypted bootloader to Team-B. Team-B encrypts all the other partitions using the Op_key.

Team-B takes the encrypted partitions that they created, and the encrypted boot loader they received from the Team-A and uses bootgen to stitch everything together into a single boot.bin.

The following procedures describe the steps to build an image:

Procedure-1

In the initial step, Team-A encrypts the boot loader with the device Key using the opt_key option, delivers the encrypted boot loader to Team-B. Now, Team-B can create the complete image at a go with all the partitions and the encrypted boot loader using Operational Key as Device Key.

  1. Encrypt Bootloader with device key:
    bootgen -arch zynqmp -image stage1.bif -o fsbl_e.bin -w on -log error
    Example stage1.bif:
    stage1:
    {
    	[fsbl_config] opt_key
    	[keysrc_encryption] bbram_red_key
    	[
    	  bootloader,
    	  destination_cpu=a53-0,
    	  encryption=aes,aeskeyfile=aes.nky
    	] fsbl.elf
    }
    Example aes.nky for stage1:
    Device xc7z020clg484;
    Key 0 AD00C023E238AC9039EA984D49AA8C819456A98C124AE890ACEF002100128932;
    IV 0 F7F8FDE08674A28DC6ED8E37;
    Key Opt 229C993D1310DD27B6713749B6D07FCF8D3DCA01EC9C64778CBAF457D613508F;
  2. Attach the encrypted bootloader and rest of the partitions with Operational Key as device Key, to form a complete image:
    bootgen -arch zynqmp -image stage2a.bif -o final.bin -w on -log error
    Example of stage2.bif:
    stage2:
    {
    	[bootimage]fsbl_e.bin
    	
    	[
    	  destination_cpu=a53-0,
    	  encryption=aes,
    	  aeskeyfile=aes-opt.nky
    	] hello.elf
    	
    	[
    	  destination_cpu=a53-1,
    	  encryption=aes,
    	  aeskeyfile=aes-opt1.nky
    	] hello1.elf
    }
    Example aes-opt.nky for stage2:
    Device xc7z020clg484;
    Key 0 229C993D1310DD27B6713749B6D07FCF8D3DCA01EC9C64778CBAF457D613508F;
    IV 0 F7F8FDE08674A28DC6ED8E37;

Procedure-2

In the initial step, Team-A encrypts the boot loader with the device Key using the opt_key option, delivers the encrypted boot loader to Team-B. Now, Team-B can create encrypted images for each partition independently, using the Operational Key as Device Key. Finally, Team-B can use bootgen to stitch all the encrypted partitions and the encrypted boot loader, to get the complete image.

  1. Encrypt Bootloader with device key:
    bootgen -arch zynqmp -image stage1.bif -o fsbl_e.bin -w on -log error
    Example stage1.bif:
    stage1:
    {
    	[fsbl_config] opt_key
    	[keysrc_encryption] bbram_red_key
    	
    	[
    	  bootloader,
    	  destination_cpu=a53-0,
    	  encryption=aes,aeskeyfile=aes.nky
    	] fsbl.elf
    }
    Example aes.nky for stage1:
    Device xc7z020clg484;
    Key 0 AD00C023E238AC9039EA984D49AA8C819456A98C124AE890ACEF002100128932;
    IV 0 F7F8FDE08674A28DC6ED8E37;
    Key Opt 229C993D1310DD27B6713749B6D07FCF8D3DCA01EC9C64778CBAF457D613508F
  2. Encrypt the rest of the partitions with Operational Key as device key:
    bootgen -arch zynqmp -image stage2a.bif -o hello_e.bin -w on -log error
    Example of stage2a.bif:
    stage2a:
    {
    	[
    	  destination_cpu=a53-0,
    	  encryption=aes,
    	  aeskeyfile=aes-opt.nky
    	] hello.elf
    }
    bootgen -arch zynqmp -image stage2b.bif -o hello1_e.bin -w on -log error
    Example of stage2b.bif:
    stage2b:
    {
    	[aeskeyfile] aes-opt.nky
    	[
    	  destination_cpu=a53-1,
    	  encryption=aes,
    	  aeskeyfile=aes-opt.nky
    	] hello1.elf
    }
    Example of aes-opt.nky for stage2a and stage2b:
    Device xc7z020clg484;
    Key 0 229C993D1310DD27B6713749B6D07FCF8D3DCA01EC9C64778CBAF457D613508F;
    IV 0 F7F8FDE08674A28DC6ED8E37;
  3. Use Bootgen to stitch the above example to form a complete image:
    Use bootgen to stitch the above, to form a complete image.
    Example of stage3.bif:
    stage3:
    {
    	[bootimage]fsbl_e.bin
    	[bootimage]hello_e.bin
    	[bootimage]hello1_e.bin
    }
    Note: opt_key of aes.nky is same as Key 0 in aes-opt.nky and IV 0 must be same in both nky files.

Single Partition Image

This features provides support for authentication and/or decryption of single partition (non-bitstream) image created by Bootgen at U-Boot prompt.
Note: This feature does not support images with multiple partitions.

U-Boot Command for Loading Secure Images

zynqmp secure <srcaddr> <len> [key_addr] 

This command verifies secure images of $len bytes\ long at address $src. Optional key_addr can be specified if user key needs to be used for decryption.

Only Authentication Use Case

To use only authentication at U-Boot, create the authenticated image using bif as shown in the following example.

  1. Create a single partition image that is authenticated at U-Boot.
    Note: If you provide an elf file, it should not contain multiple loadable sections. If your elf file contains multiple loadable sections, you should convert the input to the .bin format and provide the .bin as input in bif. An example bif is as follows:
    the_ROM_image:
    {
    	[pskfile]rsa4096_private1.pem
    	[sskfile]rsa4096_private2.pem
    	[auth_params] ppk_select=1;spk_id=0x1
    	[authentication = rsa]Data.bin
    }
  2. When the image is generated, download the authenticated image to the DDR.
  3. Execute the U-Boot command to authenticate the secure image as shown in the following example.
    ZynqMP> zynqmp secure 100000 2d000
    Verified image at 0x102800
  4. U-Boot returns the start address of the actual partition after successful authentication. U-Boot prints an error code in the event of a failure. If RSA_EN eFUSE is programmed, image authentication is mandatory. Boot header authentication is not supported when eFUSE RSA enabled.

Only Encryption Use Case

In case the image is only encrypted, there is no support for device key. When authentication is not enabled, only KUP key decryption is supported.

Authentication Flow

This example shows how to create a boot image with authentication enabled for FSBL and application with Boot Header authentication enabled to bypass the PPK hash verification:

the_ROM_image: 
{ 
	[fsbl_config] bh_auth_enable
	[auth_params] ppk_select=0; spk_id=0x00000000 
	[pskfile] PSK.pem
	[sskfile] SSK.pem
	
	[
	  bootloader,
	  authentication=rsa,
	  destination_cpu=a53-0
	] ZynqMP_Fsbl.elf 
	
	[destination_cpu=a53-0, encryption=aes] App_A53_0.elf 
}

BIF File with SHA-3 eFUSE RSA Authentication and PPK0

This example shows how to create a boot image with authentication enabled for FSBL and the application with boot header authentication enabled to bypass the PPK hash verification:

the_ROM_image: 
{ 
	[auth_params] ppk_select=0; spk_id=0x00000000 
	[pskfile] PSK.pem
	[sskfile] SSK.pem
	
	[
	  bootloader,
	  authentication=rsa,
	  destination_cpu=a53-0
	] ZynqMP_Fsbl.elf 
	
	[destination_cpu=a53-0, authentication=aes] App_A53_0.elf 
}

XIP

This example shows how to create a boot image that executes in place for a zynqmp (Zynq® UltraScale+™ MPSoC:

the_ROM_image:
{
	[
	  bootloader,
	  destination_cpu=a53-0,
	  xip_mode
	] mpsoc_qspi_xip.elf
}

See xip_mode for more information about the command.

Split with "Offset" Attribute

This example helps to understand how split works with offset attribute.

the_ROM_image:
{    
  [split]mode=slaveboot,fmt=bin
  [bootloader, destination_cpu = a53-0] fsbl.elf   
  [destination_cpu = pmu, offset=0x3000000] pmufw.elf    
  [destination_device = pl, offset=0x4000000] design_1_wrapper.bit
  [destination_cpu = a53-0, exception_level = el-3, trustzone, offset=0x6000000]\ hello.elf 
}

When offset is specified to a partition, then the address of that partition in the boot image starts from the given offset. To cover any gap between the mentioned offset of the current partition and the previous partition, bootgen appends 0xFFs to the previous partition. So, now when split is tried on the same, the boot image is expected to be split based on the address of that partition, which is the mentioned offset in this case. So, you see the padded 0xFFs in the split partition outputs.

Versal ACAP Use Cases

For Versal™ ACAP, Vivado® generates a boot image known as programmable device image (PDI). This Vivado generated PDI contains the bootloader software executable – Platform Loader and Manager (PLM), along with PL related components, and supporting data files. Based on the project and the CIPS configuration, Vivado creates a BIF file and invokes Bootgen to create the PDI. This BIF is exported as part of XSA to software tools like Vitis™. The BIF can then be modified with required partitions and attributes. Ensure that the lines related to id_code and extended_id_code are retained as is in the BIF file. This information is mandatory for the PDI image generation by Bootgen.

If you want to write the BIF manually, refer to the BIF generated by Vivado for the same device and ensure that the lines related to id_code and extended_id_code are added to the BIF that you are writing manually. The sample BIF generated by Vivado is as follows:

new_bif:
{
	id_code = 0x04ca8093
	extended_id_code = 0x01
	id = 0x2
	image
	{
		name = pmc_subsys
		id = 0x1c000001
		partition
		{
			id = 0x01
			type = bootloader
			file = gen_files/executable.elf
		}
		partition
		{
			id = 0x09
			type = pmcdata, load = 0xf2000000
			file = topology_xcvc1902.v2.cdo
			file = gen_files/pmc_data.cdo
		}
	}
	image
	{
		name = lpd
		id = 0x4210002
		partition
		{
			id = 0x0C
			type = cdo
			file = gen_files/lpd_data.cdo
		}
		partition
		{
			id = 0x0B
			core = psm
			file = static_files/psm_fw.elf
		}
	}
	image
	{
		name = pl_cfi
		id = 0x18700000
		partition
		{
			id = 0x03
			type = cdo
			file = system.rcdo
		}
		partition
		{
			id = 0x05
			type = cdo
			file = system.rnpi
		}
	}
	image
	{
		name = fpd
		id = 0x420c003
		partition
		{
			id = 0x08
			type = cdo
			file = gen_files/fpd_data.cdo
		}
	}
}
Note: The executable.elf in Vivado generated BIF file is the firmware that executes of PLM. The BIF file generated in a Vivado project is located in <vivado_project>/<vivado_project>.runs/impl_1/<Vivado_project>_wrapper.pdi.bif.

Bootloader, PMC_CDO

This example shows how to use Bootloader with PMC_CDO.

all:
{
   id_code = 0x04ca8093
   extended_id_code = 0x01

    init = reginit.ini
    image
    {
        {type=bootloader, file=PLM.elf}
        {type=pmcdata, file=pmc_cdo.bin}
    }
}

Bootloader, PMC_CDO with Load Address

This example shows how to use Bootloader with PMC_CDO and load address.

all:
{
   id_code = 0x04ca8093
   extended_id_code = 0x01

    init = reginit.ini
    image
    {
        {type=bootloader, file=PLM.elf}
        {type=pmcdata, load=0xf0400000, file=pmc_cdo.bin}
    }
}

Enable Checksum for Bootloader

This example shows how to enable checksum while using bootloader.


all:
{
   id_code = 0x04ca8093
   extended_id_code = 0x01

    init = reginit.ini
    image
    {
        {type=bootloader, checksum=sha3, file=PLM.elf}
        {type=pmcdata, load=0xf0400000, file=pmc_cdo.bin}
    }
}

Bootloader, PMC_CDO, PL CDO, NPI

This example shows how to use bootloader with PMC_CDO and NPI.

new_bif:
{
	id_code = 0x04ca8093
	extended_id_code = 0x01
	id = 0x2
	image
	{
		name = pmc_subsys, id = 0x1c000001
		{ id = 0x01, type = bootloader, file = gen_files/executable.elf }
		{ id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = gen_files/pmc_data.cdo }
	}
	image
	{
		name = lpd, id = 0x4210002
		{ id = 0x0C, type = cdo, file = gen_files/lpd_data.cdo }
		{ id = 0x0B, core = psm, file = static_files/psm_fw.elf }
	}
	image
	{
		name = pl_cfi, id = 0x18700000
		{ id = 0x03, type = cdo, file = system.rcdo }
		{ id = 0x05, type = cdo, file = system.rnpi }
	}
	image
	{
		name = fpd, id = 0x420c003
		{ id = 0x08, type = cdo, file = gen_files/fpd_data.cdo }
	}
}

Bootloader, PMC_CDO, PL CDO, NPI, PS CDO, and PS ELFs

This example shows how to use bootloader with PMC_CDO, NPI, PS CDO, and PS ELFs.

new_bif:
{
	id_code = 0x04ca8093
	extended_id_code = 0x01
	id = 0x2
	image
	{
		name = pmc_subsys, id = 0x1c000001
		{ id = 0x01, type = bootloader, file = gen_files/executable.elf }
		{ id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = gen_files/pmc_data.cdo }
	}
	image
	{
		name = lpd, id = 0x4210002
		{ id = 0x0C, type = cdo, file = gen_files/lpd_data.cdo }
		{ id = 0x0B, core = psm, file = static_files/psm_fw.elf }
	}
	image
	{
		name = pl_cfi, id = 0x18700000
		{ id = 0x03, type = cdo, file = system.rcdo }
		{ id = 0x05, type = cdo, file = system.rnpi }
	}
	image
	{
		name = fpd, id = 0x420c003
		{ id = 0x08, type = cdo, file = gen_files/fpd_data.cdo }
	}
	image
	{
		name = apu_ss, id = 0x1c000000
		{ core = a72-0, file = apu.elf }
		{ core = r5-0, file = rpu.elf }
	}
}

AI Engine Configuration and AI Engine Partitions

This example shows how to configure an AI Engine boot image and AI Engine partitions.

all:
{
    image
    {
        { type=bootimage, file=base.pdi }
    }
    image
    {
        name=default_subsys, id=0x1c000000
        { type=cdo
          file = Work/ps/cdo/aie.cdo.reset.bin
          file = Work/ps/cdo/aie.cdo.clock.gating.bin
          file = Work/ps/cdo/aie.cdo.error.handling.bin
          file = Work/ps/cdo/aie.cdo.elfs.bin
          file = Work/ps/cdo/aie.cdo.init.bin
          file = Work/ps/cdo/aie.cdo.enable.bin
        }
    }
}
Note: The different CDOs are merged to form a single partition in the PDI.

Appending New Partitions to Existing PDI

This example shows how to append new partitions to an existing PDI.

  1. Take a Vivado generated PDI (base.pdi).
  2. Create a new PDI by appending the dtb, uboot, and bl31 applications.
new_bif:
{
	image
	{
		{ type = bootimage, file = base.pdi }
	}
	image
	{
		name = apu_ss, id = 0x1c000000
		{ load = 0x1000, file = system.dtb }
          { exception_level = el-2, file = u-boot.elf }
          { core = a72-0, exception_level = el-3, trustzone, file = bl31.elf }
	}
}

RSA Authentication

This example shows how to use RSA authentication.

all:
{
    id_code = 0x04CA8093
    extended_id_code = 0x01
    boot_config {bh_auth_enable}
    image
    {
        name = pmc_subsys, id = 0x1c000001
        {type = bootloader,
         authentication=rsa, pskfile = ./PSK.pem, sskfile = ./SSK2.pem, revoke_id = 0x2,
         file = ./plm.elf}
        {type = pmcdata, file = ./pmc_data.cdo}
    }
    metaheader
    {
         authentication=rsa,pskfile = ./PSK.pem, sskfile = ./SSK16.pem, revoke_id = 0x10,
    }
    image
    {
        id = 0x1c000002, name = ss_psm
        {type = cdo,
         authentication=rsa, pskfile = ./PSK1.pem, sskfile = ./SSK1.pem, revoke_id = 0x1,
         file = ./lpd_data.cdo}
        { core = psm, file = ./psm_fw.elf}
    }
    image
    {
        id = 0x1c000000, name = fpd
        {type = cdo,
         authentication=rsa, pskfile = ./PSK1.pem, sskfile = ./SSK5.pem, revoke_id = 0x5,
        file = ./fpd_data.cdo}
    }
    image
    {
        id = 0x1c000000, name = subsystem
        {type = cdo,file = ./subsystem.cdo}
    }
}

ECDSA Authentication

This example shows how to use ECDSA authentication.


all:
{
    id_code = 0x04CA8093
    extended_id_code = 0x01
    boot_config {bh_auth_enable}    
    image
    {
        name = pmc_subsys, id = 0x1c000001
        {type = bootloader,
         authentication = ecdsa-p384, pskfile = ./PSK.pem, sskfile = ./SSK2.pem, revoke_id = 0x2,
         file = ./plm.elf}
        {type = pmcdata, file = ./pmc_data.cdo}
    }
    metaheader
    {
         authentication = ecdsa-p384,pskfile = ./PSK.pem, sskfile = ./SSK16.pem, revoke_id = 0x10,
    }
    image
    {
        id = 0x1c000002, name = ss_psm
        {type = cdo,
         authentication = ecdsa-p521, pskfile = ./PSK1.pem, sskfile = ./SSK1.pem, revoke_id = 0x1,
         file = ./lpd_data.cdo}
        { core = psm, file = ./psm_fw.elf}
    }
    image
    {
        id = 0x1c000000, name = fpd
        {type = cdo,
         authentication = ecdsa-p384, pskfile = ./PSK1.pem, sskfile = ./SSK5.pem, revoke_id = 0x5,
        file = ./fpd_data.cdo}
    }
    image
    {
        id = 0x1c000000, name = subsystem
        {type = cdo,file = ./subsystem.cdo}
    }
}

AES Encryption

This example shows how to use AES Encryption.


all:
{
   id_code = 0x04ca8093
   extended_id_code = 0x01

    image
    {
        {type=bootloader, encryption=aes, keysrc=bbram_red_key, aeskeyfile=key1.nky, file=plm.elf}
        {type=pmcdata, load=0xf0400000, file=pmc_cdo.bin}
        {type=cdo, file=ps_cdo.bin}
        {core=a72-0, encryption=aes, keysrc=bbram_red_key, aeskeyfile=key2.nky, file=a72_app.elf}
    }
}

AES Encryption with Key Rolling

This example shows how to use AES Encryption with key rolling.


all:
{
  id_code = 0x04ca8093
  extended_id_code = 0x01

    image
    {
        {
            type=bootloader,
            encryption=aes,
            keysrc=bbram_red_key,
            aeskeyfile=key1.nky,
            blocks=65536;32768;16384;8192;4096;2048;1024;512,
            file=plm.elf
        }
        {
            type=pmcdata,
            load=0xf0400000,
            file=pmc_cdo.bin
        }
        {
            type=cdo,
            file=ps_cdo.bin
        }
        {
            core=a72-0,
            encryption=aes,
            keysrc=bbram_red_key,
            aeskeyfile=key2.nky,
            blocks=65536;32768;16384;8192;4096;2048;1024;512,
            file=a72_app.elf
        }
    }
}

AES Encryption with Multiple Key Sources

This example shows the usage of different key sources for different partitions.


all:
{
    bh_keyfile = ./PUF4K_KEY.txt
    puf_file = ./PUFHD_4K.txt
    bh_kek_iv = ./blk_iv.txt
    bbram_kek_iv = ./bbram_blkIv.txt
    efuse_kek_iv = ./efuse_blkIv.txt
    boot_config {puf4kmode , shutter=0x0100005E}
    id_code = 0x04CA8093
    extended_id_code = 0x01
    image
    {
        name = pmc_subsys, id = 0x1c000001
        {type = bootloader,
         encryption = aes, keysrc=bbram_blk_key, dpacm_enable,revoke_id = 0x5, aeskeyfile = ./plm.nky,
         file = ./plm.elf}
        {type = pmcdata,
         aeskeyfile = pmcCdo.nky,
         file = ./pmc_data.cdo}
    }
    metaheader
    {
         encryption = aes, keysrc=bbram_blk_key,dpacm_enable, revoke_id = 0x6,
         aeskeyfile = metaheader.nky
    }
    image
    {
        id = 0x1c000002, name = ss_psm
        {type = cdo,
        encryption = aes, keysrc = bh_blk_key, pufhd_bh, revoke_id = 0x8, aeskeyfile = ./psmfw.nky,
        file = ./lpd_data.cdo}
        { core = psm, file = ./psm_fw.elf}
    }
    image
    {
        id = 0x1c000000, name = fpd
        {type = cdo,
        encryption = aes, keysrc = efuse_blk_key, dpacm_enable, revoke_id = 0x10,aeskeyfile = ./fpdcdo.nky,/*Here PUF helper data is also on efuse */
        file = ./fpd_data.cdo}
    }
    image
    {
        id = 0x1c000000, name = subsystem
        {type = cdo,file = ./subsystem.cdo}
    }
}

AES Encryption and Authentication

This example shows how to use AES encryption and authentication.

all:
{
    bh_kek_iv = ./blkiv.txt
    bh_keyfile = ./blkkey.txt
    efuse_kek_iv = ./efuse_blkIv.txt
    boot_config {bh_auth_enable, puf4kmode , shutter=0x0100005E}
    id_code = 0x04CA8093
    extended_id_code = 0x01
    image
    {
        name = pmc_subsys, id = 0x1c000001
        {type = bootloader,
         encryption = aes, keysrc=bh_blk_key, dpacm_enable,revoke_id = 0x5, aeskeyfile = ./plm.nky,
         authentication = rsa, pskfile = ./PSK1.pem, sskfile = ./SSK5.pem,
         file = ./plm.elf}
        {type = pmcdata, aeskeyfile = ./pmc_data.nky, file = ./pmc_data.cdo}
    }
    metaheader
    {
         encryption = aes, keysrc=bh_blk_key, dpacm_enable, revoke_id = 0x6,
         aeskeyfile = metaheader.nky
    }
    image
    {
        id = 0x1c000002, name = ss_psm
        {type = cdo,
        encryption = aes, keysrc = bbram_red_key, revoke_id = 0x8, aeskeyfile = psmfw.nky,
        file = ./lpd_data.cdo}
        { core = psm, file = ./psm_fw.elf}
    }
    image
    {
        id = 0x1c000000, name = fpd
        {type = cdo,
        encryption = aes, keysrc = efuse_blk_key, dpacm_enable, revoke_id = 0x10, aeskeyfile = fpd.nky,
        authentication = ecdsa-p384, pskfile = ./PSK1.pem, sskfile = ./SSK5.pem,
        file = ./fpd_data.cdo}
    }
    image
    {
        id = 0x1c000000, name = subsystem
        {type = cdo,file = ./subsystem.cdo}
    }
}

Replacing PLM from an Existing PDI

This example shows the steps to replacing PLM from an existing PDI.

  1. Take a Vivado generated PDI (base.pdi).
  2. Create a new PDI by replacing the PLM (bootloader) from the base PDI.
    new_bif:
    {
    	image
    	{
    		{ type = bootimage, file = base.pdi }
    		{ type = bootloade, file = plm_v1.elf }
    	}
    }
    

Bootgen replaces the bootloader plm.elf with a new plm_v1.elf.

Example Bootgen Command to Create a PDI

Use the following command to create a PDI.

bootgen -arch versal -image {filename.bif} -w -o {boot.pdi}