BIF Attribute Reference - 18luck交流吧

aarch32_mode

Syntax

For Zynq® UltraScale+™ MPSoC:
```
[aarch32_mode] <partition>
```
For Versal™ ACAP:
```
{aarch32_mode, file=<partition>}
```

Description

To specify the binary file is to be executed in 32-bit mode.

Note: Bootgen automatically detects the execution mode of the processors from the .elf files. This is valid only for binary files.

Arguments

Specified partition.

Example

For Zynq UltraScale+ MPSoC:

the_ROM_image:
{
	[bootloader, destination_cpu=a53-0] zynqmp_fsbl.elf
	[destination_cpu=a53-0, aarch32_mode] hello.bin
	[destination_cpu=r5-0] hello_world.elf
}

For Versal ACAP:

new_bif:
{
	image
	{
		{ type = bootimage, file = base.pdi }
	}
	image
	{
		name = apu_ss, id = 0x1c000000
		{ core = a72-0, aarch32_mode, file = apu.bin }
	}
}

Note: *base.pdi is the PDI generated by Vivado.

aeskeyfile

Syntax

For Zynq devices and FPGAs:
```
[aeskeyfile] <key filename>
```

For Zynq UltraScale+ MPSoC:

[aeskeyfile = <keyfile name>] <partition>

For Versal ACAP:

{ aeskeyfile = <keyfile name>, file = <filename> }

Description

The path to the AES keyfile. The keyfile contains the AES key used to encrypt the partitions. The contents of the key file must be written to eFUSE or BBRAM. If the key file is not present in the path specified, a new key is generated by Bootgen, which is used for encryption.

Note: For Zynq UltraScale+ MPSoC only: Multiple key files need to be specified in the BIF file. Key0, IV0 and Key Opt should be the same across all nky files that will be used. For cases where multiple partitions are generated for an ELF file, each partition can be encrypted using keys from a unique key file. Refer to the following examples.

Arguments

Specified file name.

Return Value

None

Zynq-7000 SoC Example

The partitions fsbl.elf and hello.elf are encrypted using keys in test.nky.

all:                                                          
{                                                             
     [keysrc_encryption] bbram_red_key                        
     [aeskeyfile] test.nky                                    
     [bootloader, encryption=aes] fsbl.elf                    
     [encryption=aes] hello.elf                               
}

Sample key (.nky) file - test.nky

Device       xc7z020clg484;                                  
  Key 0        8177B12032A7DEEE35D0F71A7FC399027BF....D608C58; 
  Key StartCBC 952FD2DF1DA543C46CDDE4F811506228;               
  Key HMAC     123177B12032A7DEEE35D0F71A7FC3990BF....127BD89;

Zynq UltraScale+ MPSoC Example

Example 1:

The partition fsbl.elf is encrypted with keys in test.nky, hello.elf using keys in test1.nky and app.elf using keys in test2.nky. Sample BIF - test_multipl.bif.

all:                                                           
{                                                              
     [keysrc_encryption] bbram_red_key                         
     [bootloader,encryption=aes,aeskeyfile=test.nky] fsbl.elf  
     [encryption=aes,aeskeyfile=test1.nky] hello.elf           
     [encryption=aes,aeskeyfile=test2.nky] app.elf             
}

Example 2:

Consider Bootgen creates three partitions for hello.elf, called hello.elf.0, hello.elf.1, and hello.elf.2. Sample BIF - test_mulitple.bif

all:                                                           
{                                                              
     [keysrc_encryption] bbram_red_key                         
     [bootloader,encryption=aes,aeskeyfile=test.nky] fsbl.elf  
     [encryption=aes,aeskeyfile=test1.nky] hello.elf           
}

Additional information:

The partition fsbl.elf is encrypted with keys in test.nky. All hello.elf partitions are encrypted using keys in test1.nky.
You can have unique key files for each hello partition by having key files named test1.1.nky and test1.2.nky in the same path as test1.nky.
hello.elf.0 uses test1.nky
hello.elf.1 uses test1.1.nky
hello.elf.2 uses test1.2.nky
If any of the key files (test1.1.nky or test1.2.nky) is not present, Bootgen generates the key file.
aeskeyfile format:
An .nky file accepts the following fields.

Device

The name of the device for which the nky file is being used. Valid for both Zynq device and Zynq UltraScale+ MPSoC.

Keyx, IVx

Here 'x' refers to an integer, that corresponds to the Key/IV number, for example, Key0, Key1, Key2 ..., IV0,IV1,IV2... An AES key must be 256 bits long while an IV key must be 12 bytes long. Keyx is valid for both Zynq devices and Zynq UltraScale+ MPSoC but IVx is valid only for Zynq UltraScale+ MPSoC.

Key Opt

An optional key that user wants to use to encrypt the first block of boot loader. Valid only for Zynq UltraScale+ MPSoC.

StartCBC - CBC Key

An CBC key must be 128 bits long. Valid for Zynq devices only.

HMAC - HMAC Key

An HMAC key must be 128 bits long. Valid for Zynq devices only.

Seed

An initial seed that should be used to generate the Key/IV pairs needed to encrypt a partition. An AES Seed must be 256 bits long. Valid only for Zynq UltraScale+ MPSoC.

FixedInputData

The data that is used as input to Counter Mode KDF, along with the Seed. An AES Fixed Input Data must be 60 Bytes long. Valid only for Zynq UltraScale+ MPSoC.
Note:
- Seed must be specified along with FixedInputData.
- Seed is not expected with multiple key/iv pairs.

Versal ACAP Example

all:                                                         
{                                                            
   image                                                     
   {                                                         
      name = pmc_subsys, id = 0x1c000001                     
      {                                                      
         type = bootloader, encryption = aes,                
         keysrc = bbram_red_key, aeskeyfile = key1.nky,      
         file = plm.elf                                      
      }                                                      
      {                                                      
         type = pmcdata, load = 0xf2000000,                  
         aeskeyfile = key2.nky, file = pmc_cdo.bin           
      }                                                      
      {                                                      
         type=cdo, encryption = aes,                         
         keysrc = efuse_red_key, aeskeyfile = key3.nky,      
         file=fpd_data.cdo                                   
      }                                                      
   }                                                         
}

alignment

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[alignment= <value>] <partition>
```
For Versal ACAP:
```
{ alignment=<value>, file=<partition> }
```

Sets the byte alignment. The partition will be padded to be aligned to a multiple of this value. This attribute cannot be used with offset.

Arguments

Number of bytes to be aligned.

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:
{
	[bootloader]fsbl.elf
	[alignment=64] u-boot.elf
}

For Versal ACAP:

new_bif:
{
	image
	{
		{ type = bootimage, file = base.pdi }
	}
	image
	{
		name = apu_ss, id = 0x1c000000
		{ core = a72-0, alignment=64, file = apu.elf }
	}
}

Note: *base.pdi is the PDI generated by Vivado.

auth_params

Syntax

[auth_params] ppk_select=<0|1>; spk_id <32-bit spk id>;/
 spk_select=<spk-efuse/user-efuse>; auth_header

Description

Authentication parameters specify additional configuration such as which PPK, SPK to use for authentication of the partitions in the boot image. Arguments for this bif parameter are:

ppk_select: Selects which PPK to use. Options are 0 (default) or 1.
spk_id: Specifies which SPK can be used or revoked. See User eFUSE Support with Enhanced RSA Key Revocation. The default value is 0x00.
spk_select: To differentiate spk and user efuses. Options are spk-efuse (default) and user_efuse.
header_auth: To authenticate headers when no partition is authenticated.

Note:

ppk_select is unique for each image.
Each partition can have its own spk_select and spk_id.
spk-efuse id is unique across the image, but user-efuse id can vary between partitions.
spk_select/spk_id outside the partition scope will be used for headers and any other partition that does not have these specifications as partition attributes.

Example

Sample BIF 1 - test.bif

all:
{
	[auth_params]ppk_select=0;spk_id=0x4
	[pskfile] primary.pem
	[sskfile]secondary.pem 
	[bootloader, authentication=rsa]fsbl.elf
}

Sample BIF 2 - test.bif

all:                                                          
{                                                             
	[auth_params] ppk_select=0;spk_select=user-efuse;spk_id=0x22
	[pskfile]     primary.pem                                   
	[sskfile]     secondary.pem                                 
	[bootloader, authentication = rsa] fsbl.elf                                                  
}

Sample BIF 3 - test.bif

all:                                                      
{                                                         
  	[auth_params] ppk_select=1; spk_select= user-efuse; spk_id=0x22; header_auth   
  	[pskfile]     primary.pem                               
  	[sskfile]     secondary.pem                             
  	[destination_cpu=a53-0] test.elf                        
}

Sample BIF 4 - test.bif

all:                                                           
{                                                              
  	[auth_params]  ppk_select=1;spk_select=user-efuse;spk_id=0x22
  	[pskfile]      primary.pem                                   
  	[sskfile]      secondary0.pem                                
                                                               
  /* FSBL - Partition-0) */                                     
   [                                                            
	bootloader,                                                
	destination_cpu   = a53-0,                                 
	authentication    = rsa,                                   
	spk_id            = 0x3,                            
	spk_select        = spk-efuse,                             
	sskfile           = secondary1.pem                         
   ] fsbla53.elf                                                 
                                                               
  /* Partition-1 */                                             
   [                                                            
     destination_cpu    = a53-1,                                
     authentication     = rsa,                                  
     spk_id             = 0x24,                                 
     spk_select         = user-efuse,                           
     sskfile            = secondary2.pem                        
   ] hello.elf                                                   
}

authentication

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:

[authenication = <options>] <partition>

For Versal ACAP:

{authentication=<options>, file=<partition>}

Description

This specifies the partition to be authenticated.

Arguments

none: Partition not authenticated. This is the default value.
rsa: Partition authenticated using RSA algorithm.
ecdsa-p384 : Partition authenticated using ECDSA p384 curve
ecdsa-p521 : Partition authenticated using ECDSA p521 curve

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:                                                          
{                                                             
    [ppkfile] ppk.txt                                         
    [spkfile] spk.txt                                         
    [bootloader, authentication=rsa] fsbl.elf                 
    [authentication=rsa] hello.elf                            
}

For Versal ACAP:

all:
{
	id_code = 0x04ca8093
	extended_id_code = 0x01
	id = 0x2
	boot_config {bh_auth_enable}

	metaheader
	{
		authentication = rsa,
		pskfile = PSK2.pem,
		sskfile = SSK2.pem
	}

	image
	{
		name = pmc_subsys, id = 0x1c000001
		partition
		{
			id = 0x01, type = bootloader,
			authentication = rsa,
			pskfile =PSK1.pem,
			sskfile =SSK1.pem,
			file = executable.elf
		}
		partition
		{
			id = 0x09, type = pmcdata, load = 0xf2000000,
			file = topology_xcvc1902.v1.cdo,
			file = pmc_data.cdo
		}
	}

	image
	{
		name = lpd, id = 0x4210002
		partition
		{
			id = 0x0C, type = cdo,
			authentication = rsa,
			pskfile = PSK3.pem,
			sskfile = SSK3.pem,
			file = lpd_data.cdo
		}
		partition
		{
			id = 0x0B, core = psm,
			authentication = rsa,
			pskfile = PSK1.pem,
			sskfile = SSK1.pem,
			file = psm_fw.elf
		}
	}

	image
	{
		name = fpd, id = 0x420c003
		partition
		{
			id = 0x08, type = cdo,
			authentication = rsa,
			pskfile = PSK3.pem,
			sskfile = SSK3.pem,
			file = fpd_data.cdo
		}
	}
}

big_endian

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[big_endian] <partition>
```
For Versal ACAP:
```
{ big_endian, file=<partition> }
```

Description

To specify the binary file is in big endian format.

Note: Bootgen automatically detects the endianness of .elf files. This is valid only for binary files.

Arguments

Specified partition.

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

the_ROM_image:
{
	[bootloader, destination_cpu=a53-0] zynqmp_fsbl.elf
	[destination_cpu=a53-0, big_endian] hello.bin
	[destination_cpu=r5-0] hello_world.elf
}

For Versal ACAP:

new_bif:
{
	image
	{
		{ type = bootimage, file = base.pdi }
	}
	image
	{
		name = apu_ss, id = 0x1c000000
		{ core = a72-0, big_endian, file = apu.bin }
	}
}

Note: *base.pdi is the PDI generated by Vivado

bbram_kek_iv

Syntax

bbram_kek_iv = <iv file path>

Description

This attribute specifies the IV that is used to encrypt the bbram black key. bbram_kek_iv is valid with keysrc=bbram_blk_key.

Example

See AES Encryption with Multiple Key Sources Example for examples.

bh_kek_iv

Syntax

bh_kek_iv = <iv file path>

Description

This attribute specifies the IV that is used to encrypt the boot header black key. bh_kek_iv is valid with keysrc=bh_blk_key.

Example

See AES Encryption with Multiple Key Sources Example for examples.

bh_keyfile

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[bh_keyfile] <key file path>
```
For Versal ACAP:
```
bh_keyfile = <key file path>
```

Description

256-bit obfuscated key or black key to be stored in boot header. This is only valid when the encryption key source is either obfuscated key or black key.

Note: Obfuscated key not supported for Versal devices.

Arguments

Path to the obfuscated key or black key, based on which source is selected.

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:                                                       
{                                                          
   [keysrc_encryption] bh_gry_key                          
   [bh_keyfile] obfuscated_key.txt                         
   [bh_key_iv] obfuscated_iv.txt                           
   [bootloader, encryption=aes, aeskeyfile = encr.nky,  destination_cpu=a53-0]fsbl.elf    
}

For Versal ACAP:

all:                                                       
{                                                          
   bh_keyfile = bh_key1.txt                                
   bh_kek_iv = blk_iv.txt                                  
   image                                                   
   {                                                       
      name = pmc_subsys, id = 0x1c000001                   
      {                                                    
         type = bootloader, encryption = aes,              
         keysrc = bbram_red_key, aeskeyfile = key1.nky,  file = plm.elf   
      }                                                    
      {                                                    
         type = pmcdata, load = 0xf2000000,                
         aeskeyfile = key2.nky, file = pmc_cdo.bin         
      }                                                    
      {                                                    
         type=cdo, encryption = aes,                       
         keysrc = bh_blk_key, aeskeyfile = key3.nky,       
         file=fpd_data.cdo                                 
      }                                                    
   }                                                       
}

bh_key_iv

Syntax

[bh_key_iv] <iv file path>

Description

Initialization vector used when decrypting the black key.

Arguments

Path to file.

Example

Sample BIF - test.bif                                          
all:
{
	[keysrc_encryption] bh_blk_key
	[bh_keyfile] bh_black_key.txt
	[bh_key_iv] bh_black_iv.txt
	[bootloader, encryption=aes, aeskeyfile=encr.nky, destination_cpu=a53-0]fsbl.elf
}

bhsignature

Syntax

[bhsignature] <signature-file>

Description

Imports Boot Header signature into authentication certificate. This can be used if you do not want to share the secret key PSK. You can create a signature and provide it to Bootgen.

Example

all:                                                           
{
	[ppkfile] ppk.txt
	[spkfile] spk.txt
	[spksignature] spk.txt.sha384.sig
	[bhsignature] bootheader.sha384.sig
	[bootloader,authentication=rsa] fsbl.elf
}

blocks

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:

                                                  
[blocks = <size><num>;<size><num>;...;<size><*>] <partition>

For Versal ACAP:

{ blocks = <size><num>;...;<size><*>, file=<partition> }

Description

Specify block sizes for key-rolling feature in encryption. Each module is encrypted using its own unique key. The initial key is stored at the key source on the device, while keys for each successive module are encrypted (wrapped) in the previous module.

Arguments

The <size> mentioned is taken in Bytes. If the size is specified as X(*), then all the remaining blocks will be of the size 'X'.

Example

For Zynq® UltraScale+™ MPSoC:

Sample BIF - test.bif                                          
all:
{
	[keysrc_encryption] bbram_red_key
	[bootloader,encryption=aes, aeskeyfile=encr.nky, 
	destination_cpu=a53-0,blocks=4096(2);1024;2048(2);4096(*)]
	fsbl.elf
}

For Versal ACAP:

all:
{
	id_code = 0x04ca8093
	extended_id_code = 0x01
	id = 0x2

	metaheader
	{
		encryption = aes,
		keysrc = bbram_red_key,
		aeskeyfile = efuse_red_metaheader_key.nky,
		dpacm_enable
	}

	image
	{
		name = pmc_subsys, id = 0x1c000001
		partition
		{
			id = 0x01, type = bootloader,
			encryption = aes,
			keysrc = bbram_red_key,
			aeskeyfile = bbram_red_key.nky,
			dpacm_enable,
			blocks = 4096(2);1024;2048(2);4096(*),
			file = executable.elf
		}
		partition
		{
			id = 0x09, type = pmcdata, load = 0xf2000000,
			aeskeyfile = pmcdata.nky,
			file = topology_xcvc1902.v1.cdo,
			file = pmc_data.cdo
		}
	}

	image
	{
		name = lpd, id = 0x4210002
		partition
		{
			id = 0x0C, type = cdo,
			encryption = aes,
			keysrc = bbram_red_key,
			aeskeyfile = key1.nky,
			dpacm_enable,
			blocks = 8192(20);4096(*),
			file = lpd_data.cdo
		}
		partition
		{
			id = 0x0B, core = psm,
			encryption = aes,
			keysrc = bbram_red_key,
			aeskeyfile = key2.nky,
			dpacm_enable,
			blocks = 4096(2);1024;2048(2);4096(*),
			file = psm_fw.elf
		}
	}

	image
	{
		name = fpd, id = 0x420c003
		partition
		{
			id = 0x08, type = cdo,
			encryption = aes,
			keysrc = bbram_red_key,
			aeskeyfile = key5.nky,
			dpacm_enable,
			blocks = 8192(20);4096(*),
			file = fpd_data.cdo
		}
	}
}

Note: In the above example, the first two blocks are of 4096 bytes, the second block is of 1024 bytes, and the next two blocks are of 2048 bytes. The rest of the blocks are of 4096 bytes.

boot_device

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[boot_device] <options>
```

For Versal™ ACAP:

boot_device { <options>, address=<address> }

Description

Specifies the secondary boot device. Indicates the device on which the partition is present.

Arguments

Options for Zynq devices and Zynq UltraScale+ MPSoC:

qspi32
qspi24
nand
sd0
sd1
sd-ls
mmc
usb
ethernet
pcie
sata

Options for Versal ACAP:

qspi32
qspi24
nand
sd0
sd1
sd-ls (SD0 (3.0) or SD1 (3.0))
mmc
usb
ethernet
pcie
sata
ospi
smap
sbi
sd0-raw
sd1-raw
sd-ls-raw
mmc1-raw
mmc0
mmc0-raw

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:
{
	[boot_device]sd0
	[bootloader,destination_cpu=a53-0]fsbl.elf
}

For Versal™ ACAP:

new_bif:
{
	id_code = 0x04ca8093
	extended_id_code = 0x01
	id = 0x2
	boot_device { qspi32, address=0x10000 }
	image
	{
		name = pmc_subsys, id = 0x1c000001
		{ id = 0x01, type = bootloader, file = executable.elf }
		{ id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = pmc_data.cdo }
	}
	image
	{
		name = lpd, id = 0x4210002
		{ id = 0x0C, type = cdo, file = lpd_data.cdo }
		{ id = 0x0B, core = psm, file = 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 = fpd_data.cdo }
	}
}

bootimage

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[bootimage] <partition>
```
For Versal™ ACAP:
```
{ type=bootimage, file=<partition> }
```

Description

This specifies that the following file specification is a boot image that was created by Bootgen, being reused as input.

Arguments

Specified file name.

Example

For FSBL:

all:
{
	[bootimage]fsbl.bin
	[bootimage]system.bin
}

In the above example, the fsbl.bin and system.bin are images generated using Bootgen.

For fsbl.bin generation:

image: 
{ 
	[pskfile] primary.pem 
	[sskfile] secondary.pem 
	[bootloader, authentication=rsa, aeskeyfile=encr_key.nky, encryption=aes] fsbl.elf 
 }

Use the following command:

bootgen -image fsbl.bif -o fsbl.bin -encrypt efuse

For system.bin generation:

image: 
{ 
	[pskfile] primary.pem 
	[sskfile] secondary.pem 
	[authentication=rsa] system.bit 
}

Use the following command:

bootgen -image system.bif -o system.bin

For Versal™ ACAP:

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 }
	}
}

Note: *base.pdi is the PDI generated by Vivado.

bootloader

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[bootloader] <partition>
```
For Versal™ ACAP:
```
{ type=bootloader, file=<partition> }
```

Description

Identifies an ELF file as the FSBL or the PLM.

Only ELF files can have this attribute.
Only one file can be designated as the bootloader.
The program header of this ELF file must have only one LOAD section with filesz >0, and this section must be executable (x flag must be set).

Arguments

Specified file name.

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:
{
	[bootloader] fsbl.elf 
	hello.elf
}

For Versal™ ACAP:

new_bif:
{
	id_code = 0x04ca8093
	extended_id_code = 0x01
	id = 0x2
	image
	{
		name = pmc_subsys, id = 0x1c000001
		{ id = 0x01, type = bootloader, file = executable.elf }
		{ id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = pmc_data.cdo }
	}
}

bootvectors

Syntax

[bootvectors] <values>

Description

This attribute specifies the vector table for eXecute in Place (XIP).

Example

all:
{
 [bootvectors]0x14000000,0x14000000,0x14000000,0x14000000,0x14000000,0x14000000,0x14000000,0x14000000
 [bootloader,destination_cpu=a53-0]fsbl.elf
}

boot_config

Syntax

boot_config { <options> }

Description

This attribute specifies the parameters that are used to configure the bootimage. The options are:

bh_auth_enable: Boot Header authentication enable, authentication of the bootimage will be done excluding the verification of PPK hash and SPK ID.
pufhd_bh: PUF helper data is stored in boot header (Default is efuse). PUF helper data file is passed to Bootgen using the option puf_file.
puf4kmode: PUF is tuned to use in 4k bit syndrome configuration (Default is 12k bit).
shutter = <value>: 32 bit PUF_SHUT register value to configure PUF for shutter offset time and shutter open time.
smap_width = <value>: Defines the SMAP bus width. Options are 8, 16, 32 (Default is 32-bit).
dpacm_enable: DPA Counter Measure Enable
a_hwrot: Asymmetric hardware root of trust (A-HWRoT) boot mode. Bootgen checks against the design rules for A-HWRoT boot mode. Valid only for production PDIs.
s_hwrot: Asymmetric hardware root of trust (S-HWRoT) boot mode. Bootgen checks against the design rules for S-HWRoT boot mode. Valid only for production PDIs.

Examples

example_1:
{
    boot_config {bh_auth_enable, smap_width=16 }
    pskfile = primary0.pem
    sskfile = secondary0.pem
    image
    {
        {type=bootloader, authentication=rsa, file=plm.elf}
        {type=pmcdata, load=0xf2000000, file=pmc_cdo.bin}
    }
}

checksum

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[checksum = <options>] <partition>
```

For Versal™ ACAP:

{ checksum = <options>, file=<partition> }

Description

This specifies the partition needs to be checksummed. This is not supported along with more secure features like authentication and encryption.

Arguments

none: No checksum operation.
MD5: MD5 checksum operation for Zynq®-7000 SoC devices. In these devices, checksum operations are not supported for bootloaders.
SHA3: Checksum operation for Zynq® UltraScale+™ MPSoC devices and Versal ACAP.

Examples

For Zynq devices and Zynq UltraScale+ MPSoC:

all:                                                     
{                                                        
    [bootloader] fsbl.elf                                
    [checksum=md5] hello.elf                             
}

For Versal™ ACAP:

all:                                               
{                                                        
   image                                                 
   {                                                     
     name = image1, id = 0x1c000001                      
     { type=bootloader, checksum=sha3, file=plm.elf }    
     { type=pmcdata, file=pmc_cdo.bin }                  
   }                                                     
}

copy

Syntax

{ copy = <addr> }

Description

This attribute specifies that the image is to be copied to memory at specified address.

Example

test:
{
    image
    {
		{ type = bootimage, file = base.pdi }
    }    
    image
    {
        name=subsys_1, id=0x1c000000, copy = 0x30000
        { core=psm, file=psm.elf }
        { type=cdo, file=ps_data.cdo }
        { core=a72-0, file=a72_app.elf }
    }
}

core

Syntax

{ core = <options> }

Description

This attributes specifies which core executes the partition.

Arguments

*a72-0
a72-1
r5-0
r5-1
psm
aie
r5-lockstep

Example

new_bif:
{
	image
	{
		{ type = bootimage, file = base.pdi }
	}
	image
	{
		name = apu_ss, id = 0x1c000000
		{ core = a72-0, file = apu.elf }
	}
}

Note: *base.pdi is the PDI generated by Vivado.

delay_handoff

Syntax

{ delay_handoff }

Description

This attribute specifies that the hand-off to the subsystem is delayed.

Example

test:
{
    image
    {
		{ type = bootimage, file = base.pdi }
    }    
    image
    {
        name=subsys_1, id=0x1c000000, delay_handoff
        { core=psm, file=psm.elf }
        { type=cdo, file=ps_data.cdo }
        { core=a72-0, file=a72_app.elf }
    }
}

delay_load

Syntax

{ delay_load }

Description

This attribute specifies that the loading of subsystem is delayed.

Example

test:
{
    image
    {
		{ type = bootimage, file = base.pdi }	
    }    
    image
    {
        name=subsys_1, id=0x1c000000, delay_load
        { core=psm, file=psm.elf }
        { type=cdo, file=ps_data.cdo }
        { core=a72-0, file=a72_app.elf }
    }
}

destination_cpu

Syntax

[destination_cpu <options>] <partition>

Description

Specifies which core will execute the partition. The following example specifies that FSBL will be executed on A53-0 core and application on R5-0 core.

Note:

FSBL can only run on either A53-0 or R5-0.
PMU loaded by FSBL: [destination_cpu=pmu] pmu.elf In this flow, BootROM loads FSBL first, and then FSBL loads the PMU firmware.
PMU loaded by BootROM: [pmufw_image] pmu.elf. In this flow, BootROM loads PMU first and then the FSBL so PMU does the power management tasks, before the FSBL comes up.

Arguments

a53-0 (default)
a53-1
a53-2
a53-3
r5-0
r5-1
r5-lockstep
pmu

Example

all:
{
	[bootloader,destination_cpu=a53-0]fsbl.elf
	[destination_cpu=r5-0] app.elf
}

destination_device

Syntax

[destination_device <options>] <partition>

Description

Specifies whether the partition is targeted for PS or PL.

Arguments

ps: The partition is targeted for PS. This is the default value.
pl: The partition is targeted for PL, for bitstreams.

Example

all:
{
	[bootloader,destination_cpu=a53-0]fsbl.elf
	[destination_device=pl]system.bit
	[destination_cpu=r5-1]app.elf
}

early_handoff

Syntax

[early_handoff] <partition>

Description

This flag ensures that the handoff to applications that are critical immediately after the partition is loaded; otherwise, all the partitions are loaded sequentially and handoff also happens in a sequential fashion.

Note: In the following scenario, the FSBL loads app1, then app2, and immediately hands off the control to app2 before app1.

Example

all:
{
	[bootloader, destination_cpu=a53_0]fsbl.el
	[destination_cpu=r5-0]app1.elf
	[destination_cpu=r5-1,early_handoff]app2.elf
}

efuse_kek_iv

Syntax

efuse_kek_iv = <iv file path>

Description

This attribute specifies the IV that is used to encrypt the efuse black key. So, 'efuse_kek_iv' is valid with 'keysrc=efuse_blk_key'.

Example

See AES Encryption with Multiple Key Sources Example for examples.

efuse_user_kek0_iv

Syntax

efuse_user_kek0_iv = <iv file path>

Description

This attribute specifies the IV that is used to encrypt the efuse user black key0. So, 'efuse_user_kek0_iv' is valid with 'keysrc=efuse_user_blk_key0'.

Example

See AES Encryption with Multiple Key Sources Example for examples.

efuse_user_kek1_iv

Syntax

efuse_user_kek1_iv = <iv file path>

Description

This attribute specifies the IV that is used to encrypt the efuse user black key1. So, 'efuse_user_kek1_iv' is valid with 'keysrc=efuse_user_blk_key1'.

Example

See AES Encryption with Multiple Key Sources Example for examples.

encryption

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[encryption = <options>] <partition>
```

For Versal™ ACAP:

{ encryption = <options>, file = <filename> }

Description

This specifies the partition needs to be encrypted. Encryption algorithms are:

Arguments

none: Partition not encrypted. This is the default value.
aes: Partition encrypted using AES algorithm.

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

                                         
all:                                                     
{                                                        
     [aeskeyfile] test.nky                               
     [bootloader, encryption=aes] fsbl.elf               
     [encryption=aes] hello.elf                          
}

For Versal™ ACAP:

all:
{
	id_code = 0x04ca8093
	extended_id_code = 0x01
	id = 0x2

	metaheader
	{
		encryption = aes,
		keysrc = bbram_red_key,
		aeskeyfile = efuse_red_metaheader_key.nky,
	}

	image
	{
		name = pmc_subsys, id = 0x1c000001
		partition
		{
			id = 0x01, type = bootloader,
			encryption = aes,
			keysrc = bbram_red_key,
			aeskeyfile = bbram_red_key.nky,
			file = executable.elf
		}
		partition
		{
			id = 0x09, type = pmcdata, load = 0xf2000000,
			aeskeyfile = pmcdata.nky,
			file = topology_xcvc1902.v1.cdo,
			file = pmc_data.cdo
		}
	}

	image
	{
		name = lpd, id = 0x4210002
		partition
		{
			id = 0x0C, type = cdo,
			encryption = aes,
			keysrc = bbram_red_key,
			aeskeyfile = key1.nky,
			file = lpd_data.cdo
		}
		partition
		{
			id = 0x0B, core = psm,
			encryption = aes,
			keysrc = bbram_red_key,
			aeskeyfile = key2.nky,
			file = psm_fw.elf
		}
	}

	image
	{
		name = fpd, id = 0x420c003
		partition
		{
			id = 0x08, type = cdo,
			encryption = aes,
			keysrc = bbram_red_key,
			aeskeyfile = key5.nky,
			file = fpd_data.cdo
		}
	}
}

exception_level

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[exception_level=<options>] <partition>
```

For Versal™ ACAP:

{ exception_level=<options>, file=<partition> }

Description

Exception level for which the core should be configured.

Arguments

el-0
el-1
el-2
el-3 (default)

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:
{
	[bootloader, destination_cpu=a53-0]fsbl.elf
	[destination_cpu=a53-0, exception_level=el-3] bl31.elf
	[destination_cpu=a53-0, exception_level=el-2] u-boot.elf
}

For Versal™ ACAP:

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 }
	}
}

Note: *base.pdi is the PDI generated by Vivado.

familykey

Syntax

[familykey] <key file path>

Description

Specify Family Key. To obtain family key, contact a Xilinx® representative at secure.solutions@xilinx.com.

Arguments

Path to file.

Example

all:
{
	[aeskeyfile] encr.nky
	[bh_key_iv] bh_iv.txt
	[familykey] familykey.cfg
}

file

Syntax

{ file = <path/to/file> }

Description

This attribute specifies the file for creating the partition.

Example

new_bif:
{
	image
	{
		{ type = bootimage, file = base.pdi }
	}
	image
	{
		name = apu_ss, id = 0x1c000000
		{ core = a72-0, file = apu.elf }
	}
}

Note: *base.pdi is the PDI generated by Vivado.

fsbl_config

Syntax

[fsbl_config <options>] <partition>

Description

This option specifies the parameters used to configure the boot image. FSBL, which should run on A53 in 64-bit mode in Boot Header authentication mode.

Arguments

bh_auth_enable: Boot Header Authentication Enable: RSA authentication of the bootimage will be done excluding the verification of PPK hash and SPK ID.
auth_only: Boot image is only RSA signed. FSBL should not be decrypted. See this link in the Zynq UltraScale+ Device Technical Reference Manual (UG1085) for more information.
opt_key: Operational key is used for block-0 decryption. Secure Header has the opt key.
pufhd_bh: PUF helper data is stored in Boot Header (Default is efuse). PUF helper data file is passed to Bootgen using the [puf_file] option.
puf4kmode: PUF is tuned to use in 4k bit configuration (Default is 12k bit).
shutter = <value>: 32 bit PUF_SHUT register value to configure PUF for shutter offset time and shutter open time.
Note: This shutter value must match the shutter value that was used during PUF registration.

Example

all:
{
	[fsbl_config] bh_auth_enable
	[pskfile] primary.pem
	[sskfile]secondary.pem
	[bootloader,destination_cpu=a53-0,authentication=rsa] fsbl.elf
}

headersignature

Syntax

For Zynq UltraScale+ MPSoC:

[headersignature] <signature file>

For Versal:

headersignature = <signature file>

Description

Imports the header signature into the authentication certificate. This can be used if you do not plan to share the secret key. You can create a signature and provide it to Bootgen.

Arguments

<signature_file>

Example

For Zynq UltraScale+ MPSoC:

all:
{
	[ppkfile] ppk.txt
	[spkfile] spk.txt
	[headersignature] headers.sha256.sig
	[spksignature] spk.txt.sha256.sig
	[bootloader, authentication=rsa] fsbl.elf
}

For Versal ACAP:

stage5:
{
      bhsignature = bootheader.sha384.sig
     
      image
      {
            name = pmc_subsys, id = 0x1c000001
            {
                  type = bootimage,
                  authentication=rsa,
                  ppkfile = rsa-keys/PSK1.pub,
                  spkfile = rsa-keys/SSK1.pub,
                  spksignature = SSK1.pub.sha384.sig,
                  file = pmc_subsys_e.bin
            }
      }
}

hivec

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[hivec] <partition>
```
For Versal™ ACAP:
```
{ hivec, file=<partition> } 
```

Description

To specify the location of Exception Vector Table as hivec. This is applicable with a53 (32 bit) and r5 cores only.

hivec: exception vector table at 0xFFFF0000.
lovec: exception vector table at 0x00000000. This is the default value.

Arguments

None

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:                                              
{                                                 
    [bootloader, destination_cpu=a53_0] fsbl.elf  
    [destination_cpu=r5-0,hivec] app1.elf         
}

For Versal™ ACAP:

all:                                              
{                                                 
   image                                          
   {                                              
     name = image1, id = 0x1c000001               
     { type=bootloader, file=plm.elf }            
     { type=pmcdata, file=pmc_cdo.bin }           
     { type=cdo, file=fpd_data.cdo }              
     { core=psm, file=psm.elf }                   
     { core=r5-0, hivec, file=hello.elf }         
   }                                              
}

id

Syntax

id = <id>

Description

This attribute specifies the following IDs based on the place it is defined:

pdi id - within the outermost/PDI parenthesis
image id - within the image parenthesis
partition id - within the partition parenthesis

Image IDs are fixed for a given image. Refer to the following table for the image IDs defined by Xilinx for Versal ACAP devices.

Table 1. Image IDs (Fixed for a Given Partition)
Partition	Subsystem/Domain	Image ID Value	Description
PMC	Subsystem	0x1C000001	PMC subsystem ID
PLD	Domain	0x18700000	PLD0 Device ID (because PLD0 represents the entire PLD domain)
LPD	Domain	0x04210002	LPD Power Node ID
FPD	Domain	0x0420C003	FPD Power Node ID
Default Subsystem	Subsystem	0x1C000000	Default Subsystem ID
CPD	Domain	0x04218007	CPM Power Node ID
AIE	Domain	0x0421C005	AIE Power Node ID

Note: Partition IDs are used for identifying a partition. These IDs are not used by PLM for processing. You can randomly select these numbers according to your own scheme.

Note: For AI Engine partitions and PS partitions, such as A72 and R5 ELF, use the default subsystem ID.

Example

new_bif:
{
	id_code = 0x04ca8093
	extended_id_code = 0x01
	id = 0x2						// PDI ID
	image
	{
		name = pmc_subsys,
		id = 0x1c000001				// Image ID			
		partition
		{ 
			id = 0x01, 				// Partition ID
			type = bootloader, 
			file = executable.elf 
		}
		{ 
			id = 0x09, 
			type = pmcdata, 
			load = 0xf2000000, 
			file = topology_xcvc1902.v2.cdo, 
			file = pmc_data.cdo 
		}
	}
}

image

Syntax

image 
{ 

}

Description

This attribute is used to define a subsystem/image.

Example

test:
{
    image                                  
    {   
        name = pmc_subsys, id = 0x1c000001                         
        { type = bootloader, file = plm.elf }
        { type=pmcdata, load=0xf2000000, file=pmc_cdo.bin}
    }
    image                                                 
    {                                                     
        name = PL_SS, id = 0x18700000                     
        { id = 0x3, type = cdo, file = bitstream.rcdo }                
        { id = 0x4, file = bitstream.rnpi }               
    }                                                     
}

init

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[init] <filename>
```
For Versal™ ACAP:
```
init = <filename>
```

Description

Register initialization block at the end of the bootloader, built by parsing the .int file specification. Maximum of 256 address-value init pairs are allowed. The .int files have a specific format.

Example

A sample BIF file is shown below:

For Zynq devices and Zynq UltraScale+ MPSoC:

all:                                                     
 {                                                        
    [init] test.int                                       
 }

For Versal™ ACAP:

all:                                                     
 {                                                        
    init = reginit.int                                    
    image                                                 
    {                                                     
      name = image1, id = 0x1c000001                      
      { type=bootloader, file=plm.elf }                   
      { type=pmcdata, file=pmc_cdo.bin }                  
    }                                                     
 }

keysrc

Syntax

keysrc = <options>

Description

This specifies the Key source for encryption.

Arguments

The valid key sources for boot loader, meta header and partitions are:

efuse_red_key
efuse_blk_key
bbram_red_key
bbram_blk_key
bh_blk_key

There are few more key sources which are valid for partitions only:

user_key0
user_key1
user_key2
user_key3
user_key4
user_key5
user_key6
user_key7
efuse_user_key0
efuse_user_blk_key0

Example

all:                                                       
 {                                                          
    image                                                   
    {                                                       
       name = pmc_subsys, id = 0x1c000001                   
       {                                                    
          type = bootloader, encryption = aes,              
          keysrc = bbram_red_key, aeskeyfile = key1.nky,    
          file = plm.elf                                    
       }                                                    
       {                                                    
          type = pmcdata, load = 0xf2000000,                
          aeskeyfile = key2.nky, file = pmc_cdo.bin         
       }                                                    
    }                                                       
 }

keysrc_encryption

Syntax

[keysrc_encryption] <options> <partition>

Description

This specifies the Key source for encryption.

Arguments

bbram_red_key: RED key stored in BBRAM
efuse_red_key: RED key stored in efuse
efuse_gry_key: Grey (Obfuscated) Key stored in eFUSE.
bh_gry_key: Grey (Obfuscated) Key stored in boot header.
bh_blk_key: Black Key stored in boot header.
efuse_blk_key: Black Key stored in eFUSE.
kup_key: User Key.

Example

all:
{
	[keysrc_encryption]efuse_gry_key
	[bootloader,encryption=aes, aeskeyfile=encr.nky, destination_cpu=a53-0]fsbl.elf
}

FSBL is encrypted using the key encr.nky, which is stored in the efuse for decryption purpose.

load

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[load = <value>] <partition>
```
For Versal™ ACAP:
```
{ load = <value> , file=<partition> }
```

Description

Sets the load address for the partition in memory.

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:                                                      
{                                                         
     [bootloader] fsbl.elf                                
     u-boot.elf                                           
     [load=0x3000000, offset=0x500000] uImage.bin         
     [load=0x2A00000, offset=0xa00000] devicetree.dtb     
     [load=0x2000000, offset=0xc00000] uramdisk.image.gz  
}

For Versal™ ACAP:

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 }
	}
}

Note: *base.pdi is the PDI generated by Vivado.

metaheader

Syntax

metaheader { }

Description

Note: All the security attributes are supported for metaheader.

This attribute is used to define encryption, authentication attributes for metaheaders such as keys, key sources, and so on.

Example

test:
{
    metaheader
    {   
        encryption = aes,
        keysrc = bbram_red_key,
        aeskeyfile = headerkey.nky,
        authentication = rsa
    }
    image
    {
        name = pmc_subsys, id = 0x1c000001
        {
            type = bootloader,
            encryption = aes,
            keysrc = bbram_red_key,
            aeskeyfile = key1.nky,
            blocks = 8192(*),
            file = plm.elf
        }
        {
            type=pmcdata,
            load=0xf2000000,
            aeskeyfile=key2.nky,
            file=pmc_cdo.bin
        }
    }
}

name

Syntax

name = <name>

Description

This attribute specifies the name of the image/subsystem.

Example

new_bif:
{
	id_code = 0x04ca8093
	extended_id_code = 0x01
	id = 0x2				
	image
	{
		name = pmc_subsys, id = 0x1c000001
		{ id = 0x01, type = bootloader, file = executable.elf }
		{ id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = pmc_data.cdo }
	}
	image
	{
		name = lpd, id = 0x4210002
		{ id = 0x0C, type = cdo, file = lpd_data.cdo }
		{ id = 0x0B, core = psm, file = 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 = fpd_data.cdo }
	}
}

offset

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[offset = <value>] <filename>
```
For Versal™ ACAP:
```
{ offset = <value>, file=<filename> }
```

Description

Sets the absolute offset of the partition in the boot image.

Arguments

Specified value and partition.

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:                                                     
{                                                        
     [bootloader] fsbl.elf                               
     u-boot.elf                                          
     [load=0x3000000, offset=0x500000] uImage.bin        
     [load=0x2A00000, offset=0xa00000] devicetree.dtb    
     [load=0x2000000, offset=0xc00000] uramdisk.image.gz 
}

For Versal™ ACAP:

new_bif:
{
	image
	{
		{ type = bootimage, file = base.pdi }
	}
	image
	{
		name = apu_ss, id = 0x1c000000
		{ offset = 0x8000, file = data.bin }
	}
}

Note: *base.pdi is the PDI generated by Vivado.

parent_id

Syntax

parent_id = <id>

Description

This attribute specifies the ID for the parent PDI. This is used to identify the relationship between a partial PDI and its corresponding boot PDI.

Example

new_bif:
{
	id = 0x22
     parent_id = 0x2

	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 }
	}
}

partition

Syntax

partition 
{ 

}

Description

This attribute is used to define a partition. It is an optional attribute to make the BIF short and readable.

Example

new_bif:
{
	id_code = 0x04ca8093
	extended_id_code = 0x01
	id = 0x2												
	image
	{
		name = pmc_subsys, id = 0x1c000001
		partition
		{ 
			id = 0x01, 
			type = bootloader, 
			file = executable.elf 
		}
		partition
		{ 
			id = 0x09, 
			type = pmcdata, 
			load = 0xf2000000, 
			file = topology_xcvc1902.v2.cdo, 
			file = pmc_data.cdo 
		}
	}
}

Note: The partition attribute is optional and the BIF file can be written without the attribute too.

The above BIF can be written without the partition attribute as follows:

new_bif:
{
	id_code = 0x04ca8093
	extended_id_code = 0x01
	id = 0x2												
	
	image
	{
		name = pmc_subsys, id = 0x1c000001
		{ id = 0x01, type = bootloader, file = executable.elf }
		{ id = 0x09, type = pmcdata, load = 0xf2000000, file = topology_xcvc1902.v2.cdo, file = pmc_data.cdo }
	}
}

partition_owner, owner

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[partition_owner = <options>] <filename>
```
For Versal™ ACAP:
```
{ owner = <options>, file=<filename> }
```

Description

Owner of the partition which is responsible to load the partition.

Arguments

For Zynq devices and Zynq UltraScale+ MPSoC:
- fsbl: FSBL loads this partition
- uboot: U-Boot loads this partition
For Versal™ ACAP:
- plm: PLM loads this partition
- non-plm: PLM ignores this partition and it is loaded in a alternative way

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:                                              
 {                                                 
     [bootloader] fsbl.elf                         
     uboot.elf                                     
     [partition_owner=uboot] hello.elf             
 }

For Versal™ ACAP:

all:                                              
 {                                                 
     image                                         
     {                                             
         { type = bootimage, file = base.pdi }                                       
     }                                             
     image                                         
     {                                             
         name = apu_subsys,  id = 0x1c000003       
         {                                         
              id = 0x00000000,                     
              core = a72-0,                        
              owner = non-plm,                     
              file = /path/to/image.ub             
         }                                         
     }                                             
 }

pid

Syntax

 [pid = <id_no>] <partition>

Description

This specifies the partition id. The default value is 0.

Example

all:
{
	[encryption=aes, aeskeyfile=test.nky, pid=1] hello.elf
}

pmufw_image

Syntax

[pmufw_image] <PMU ELF file>

Description

PMU Firmware image to be loaded by BootROM, before loading the FSBL. The options for the pmufw_image are inline with the bootloader partition. Bootgen does not consider any extra attributes given along with the pmufw_image option.

Arguments

Filename

Example

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
}

ppkfile

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[ppkfile] <key filename>
```
For Versal™ ACAP:
```
ppkfile = <filename>
```

Description

The Primary Public Key (PPK) key is used to authenticate partitions in the boot image.

See Using Authentication.

Arguments

Specified file name.

Note: The secret key file contains the public key component of the key. You need not specify the public key (PPK) when the secret key (PSK) is mentioned.

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:
{
   [ppkfile] primarykey.pub
   [pskfile] primarykey.pem
   [sskfile] secondarykey.pem
   [bootloader, authentication=rsa]fsbl.elf
   [authentication=rsa] hello.elf
}

For Versal™ ACAP:

all:                                                         
{                                                            
   boot_config {bh_auth_enable}                              
   image                                                     
   {                                                         
      name = pmc_ss, id = 0x1c000001                         
      { type=bootloader, authentication=rsa, file=plm.elf, ppkfile=primary0.pub, pskfile=primary0.pem, sskfile=secondary0.pem }       
      { type = pmcdata, load = 0xf2000000, file=pmc_cdo.bin }
      { type=cdo, authentication=rsa, file=fpd_cdo.bin, ppkfile=primary1.pub, pskfile = primary1.pem, sskfile = secondary1.pem  }  
   }                                                         
}

presign

Syntax

For Zynq-7000 and Zynq UltraScale+ MPSoC devices:

[presign = <signature_file>] <partition>

For Versal ACAP:

presign = <signature file>

Description

Imports partition signature into partition authentication certificate. Use this if you do not want to share the secret key (SSK). You can create a signature and provide it to Bootgen.

<signature_file>: Specifies the signature file.
<partition>: Lists the partition to which to apply to the <signature_file>.

Example

For Zynq-7000 and Zynq UltraScale+ MPSoC devices:

all:
{
	[ppkfile] ppk.txt
	[spkfile] spk.txt
	[headsignature] headers.sha256.sig
	[spksignature] spk.txt.sha256.sig
	[bootloader, authentication=rsa, presign=fsbl.sig]fsbl.elf
}

pskfile

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[pskfile] <key filename>
```
For Versal™ ACAP:
```
pskfile = <filename>
```

Description

This Primary Secret Key (PSK) is used to authenticate partitions in the boot image. For more information, see Using Authentication.

Arguments

Specified file name.

Note: The secret key file contains the public key component of the key. You need not specify the public key (PPK) when the secret key (PSK) is mentioned.

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:
{
   [pskfile] primarykey.pem
   [sskfile] secondarykey.pem
   [bootloader, authentication=rsa]fsbl.elf
   [authentication=rsa] hello.elf
}

For Versal™ ACAP:

all:                                                         
{                                                            
   boot_config {bh_auth_enable}                              
   image                                                     
   {                                                         
      name = pmc_ss, id = 0x1c000001                         
      { type=bootloader, authentication=rsa, file=plm.elf,   
        pskfile=primary0.pem, sskfile=secondary0.pem }       
      { type = pmcdata, load = 0xf2000000, file=pmc_cdo.bin }
      { type=cdo, authentication=rsa, file=fpd_cdo.bin,    
        pskfile = primary1.pem, sskfile = secondary1.pem  }  
   }                                                         
}

puf_file

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[puf_file] <puf data file>
```
For Versal ACAP:
```
puf_file = <puf data file>
```

Description

PUF helper data file.

PUF is used with black key as encryption key source.
PUF helper data is of 1544 bytes.
1536 bytes of PUF HD + 4 bytes of CHASH + 3 bytes of AUX + 1 byte alignment.

See Black/PUF Keys for more information.

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:                                                        
{                                                           
   [fsbl_config] pufhd_bh                                   
   [puf_file] pufhelperdata.txt                             
   [bh_keyfile] black_key.txt                               
   [bh_key_iv] bhkeyiv.txt                                  
   [bootloader,destination_cpu=a53-0,encryption=aes]fsbl.elf
}

For Versal™ ACAP:

all:                                                        
{                                                           
   boot_config {puf4kmode}                                  
   puf_file = pufhd_file_4K.txt                             
   bh_kek_iv = bh_black_key-iv.txt
   image                                                    
   {                                                        
      name = pmc_subsys, id = 0x1c000001                    
      {                                                     
         type = bootloader, encryption = aes,               
         keysrc = bh_black_key, aeskeyfile = key1.nky,     
         file = plm.elf                                     
      }                                                     
      {                                                     
         type = pmcdata, load = 0xf2000000,                 
         aeskeyfile = key2.nky, file = pmc_cdo.bin          
      }                                                     
      {                                                     
         type=cdo, encryption = aes,                        
         keysrc = efuse_red_key, aeskeyfile = key3.nky,     
         file=fpd_data.cdo                                  
      }                                                     
   }                                                        
}

reserve

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[reserve = <value>] <filename>
```
For Versal™ ACAP:
```
{ reserve = <value>, file=<filename> }
```

Description

Reserves the memory and padded after the partition. The value specified for reserving the memory is in bytes.

Arguments

Specified partition

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:                                                
{                                                   
     [bootloader] fsbl.elf                          
     [reserve=0x1000] test.bin                      
}

For Versal™ ACAP:

new_bif:
{
	image
	{
		{ type = bootimage, file = base.pdi }
	}
	image
	{
		name = apu_ss, id = 0x1c000000
		{ reserve = 0x1000, file = data.bin }
	}
}

Note: *base.pdi is the PDI generated by Vivado.

split

Syntax

[split] mode = <mode-options>, fmt=<format>

Description

Splits the image into parts based on mode. Slaveboot mode splits as follows:

Boot Header + Bootloader
Image and Partition Headers
Rest of the partitions

Normal mode splits as follows:

Bootheader + Image Headers + Partition Headers + Bootloader
Partition1
Partition2 and so on

Slaveboot is supported only for Zynq UltraScale+ MPSoC, and normal is supported for both Zynq-7000 and Zynq UltraScale+ MPSoC. Along with the split mode, output format can also be specified as bin or mcs.

Options

The available options for argument mode are:

slaveboot
normal
bin
mcs

Example

all:
{
	[split]mode=slaveboot,fmt=bin
	[bootloader,destination_cpu=a53-0]fsbl.elf
	[destination_device=pl]system.bit
	[destination_cpu=r5-1]app.elf
}

Note: The option split mode normal is same as the command line option split. This command line option is schedule to be deprecated.

Note: Split slaveboot mode is not supported for Versal ACAP.

spkfile

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[spkfile] <key filename>
```
For Versal™ ACAP:
```
spkfile = <filename>
```

Description

The Secondary Public Key (SPK) is used to authenticate partitions in the boot image. For more information, see Using Authentication.

Arguments

Specified file name.

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:
{
   [pskfile] primarykey.pem
   [spkfile] secondarykey.pub
   [sskfile] secondarykey.pem
   [bootloader, authentication=rsa]fsbl.elf
   [authentication=rsa] hello.elf
}

For Versal™ ACAP:

all:                                                         
{                                                            
   boot_config {bh_auth_enable}            
   pskfile=primary0.pem,                  
   image                                                     
   {                                                         
      name = pmc_ss, id = 0x1c000001                         
      { type=bootloader, authentication=rsa, file=plm.elf, spkfile=secondary0.pub,
         sskfile=secondary0.pem }       
      { type = pmcdata, load = 0xf2000000, file=pmc_cdo.bin }
      { type=cdo, authentication=rsa, file=fpd_cdo.bin}      
        spkfile=secondary1.pub, sskfile = secondary1.pem  }  
   }                                                         
}

Note: The secret key file contains the public key component of the key. You need not specify public key (SPK) when the secret key (SSK) is mentioned.

spksignature

Syntax

For Zynq and Zynq UltraScale+ MPSoC devices:

[spksignature] <Signature file>

For Versal ACAP:

spksignature = <signature file>

Description

Imports SPK signature into the authentication certificate. This can be when the user does not want to share the secret key PSK, the user can create a signature and provide it to Bootgen.

Arguments

Specified file name.

Example

For Zynq and Zynq UltraScale+ MPSoC devices:

all:
{
	[ppkfile] ppk.txt
	[spkfile] spk.txt
	[headersignature]headers.sha256.sig
	[spksignature] spk.txt.sha256.sig
	[bootloader, authentication=rsa] fsbl.elf
}

For Versal ACAP:

stage7c:
{
    image
    {
      id = 0x1c000000, name = fpd
      { type = bootimage,       
        authentication=rsa,
        ppkfile = PSK3.pub,
        spkfile = SSK3.pub,
        spksignature = SSK3.pub.sha384.sig,
        presign = fpd_data.cdo.0.sha384.sig,
        file = fpd_e.bin  
      }
    }
}

spk_select

Syntax

[spk_select = <options>]

or


[auth_params] spk_select = <options>

Description

Options are:

spk-efuse: Indicates that spk_id eFUSE is used for that partition. This is the default value.
user-efuse: Indicates that user eFUSE is used for that partition.

Partitions loaded by CSU ROM will always use spk_efuse.

Note: The spk_id eFUSE specifies which key is valid. Hence, the ROM checks the entire field of spk_id eFUSE against the SPK ID to make sure its a bit for bit match.

The user eFUSE specifies which key ID is not valid (has been revoked). Hence, the firmware (non-ROM) checks to see if a given user eFUSE that represents the SPK ID has been programmed. spk_select = user-efuse indicates that user eFUSE will be used for that partition.

Example

the_ROM_image:
{
	[auth_params]ppk_select = 0
	[pskfile]psk.pem
	[sskfile]ssk1.pem

	[
	  bootloader,
	  authentication = rsa,
	  spk_select = spk-efuse,
	   spk_id = 0x5,
	  sskfile = ssk2.pem
	] zynqmp_fsbl.elf

	[
	  destination_cpu =a53-0,
	  authentication = rsa,
	  spk_select = user-efuse,
	  spk_id = 0xF, 
	  sskfile = ssk3.pem
	] application1.elf

	[
	  destination_cpu =a53-0,
	  authentication = rsa,
	  spk_select = spk-efuse,
	  spk_id =0x5,
	  sskfile = ssk4.pem
	] application2.elf
}

sskfile

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[sskfile] <key filename>
```
For Versal™ ACAP:
```
sskfile = <filename>
```

Description

The secondary secret key (SSK) is used to authenticate partitions in the boot image. For more information, see Using Authentication.

Arguments

Specified file name.

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:
{
   [pskfile] primarykey.pem
   [sskfile] secondarykey.pem
   [bootloader, authentication=rsa]fsbl.elf
   [authentication=rsa] hello.elf
}

For Versal™ ACAP:

all:                                                         
{                                                            
   boot_config {bh_auth_enable}                              
   image                                                     
   {                                                         
      name = pmc_ss, id = 0x1c000001                         
      { type=bootloader, authentication=rsa, file=plm.elf, pskfile=primary0.pem, sskfile=secondary0.pem }       
      { type = pmcdata, load = 0xf2000000, file=pmc_cdo.bin }
      { type=cdo, authentication=rsa, file=fpd_cdo.bin, pskfile = primary1.pem, sskfile = secondary1.pem  }  
   }                                                         
}

Note: The secret key file contains the public key component of the key. You need not specify the public key (PPK) when the secret key (PSK) is mentioned.

startup

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[startup = <value>] <filename>
```

For Versal™ ACAP:

{ startup = <value>, file = <filename> }

Description

This option sets the entry address for the partition, after it is loaded. This is ignored for partitions that do not execute. This is valid only for binary partitions.

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:                                                           
 {                                                              
      [bootloader] fsbl.elf                                     
      [startup=0x1000000] app.bin                               
 }

For Versal™ ACAP:

new_bif:
{
	image
	{
		{ type = bootimage, file = base.pdi }
	}
	image
	{
		name = apu_ss, id = 0x1c000000
		{ core=a72-0, load=0x1000, startup = 0x1000, file = apu.bin }
	}
}

Note: *base.pdi is the PDI generated by Vivado.

trustzone

Syntax

For Zynq devices and Zynq UltraScale+ MPSoC:
```
[trustzone = <options> ] <filename>
```

For Versal™ ACAP:

{ trustzone = <options>, file = <filename> }

Description

Configures the core to be TrustZone secure or non-secure. Options are:

secure
nonsecure (default)

Example

For Zynq devices and Zynq UltraScale+ MPSoC:

all:                                                     
{                                                        
    [bootloader, destination_cpu=a53-0] fsbl.elf         
    [exception_level=el-3, trustzone = secure] bl31.elf  
}

For Versal™ ACAP:

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 }
	}
}

Note: *base.pdi is the PDI generated by Vivado.

type

Syntax

{ type = <options> }

Description

This attribute specifies the type of partition. The options are as follows.

bootloader
pmcdata
cdo
bootimage

Example

new_bif:
{
	image
	{
		{ type = bootimage, file = base.pdi }
	}
	image
	{
		name = apu_ss, id = 0x1c000000
		{ core = a72-0, file = apu.elf }
	}
}

Note: *base.pdi is the PDI generated by Vivado.

udf_bh

Syntax

[udf_bh] <filename>

Description

Imports a file of data to be copied to the user defined field (UDF) of the Boot Header. The input user defined data is provided through a text file in the form of a hex string. Total number of bytes in UDF in Xilinx® SoCs:

zynq: 76 bytes
zynqmp: 40 bytes

Arguments

Specified file name.

Example

all:
{
	[udf_bh]test.txt
	[bootloader]fsbl.elf 
	hello.elf
}

The following is an example of the input file for udf_bh:

Sample input file for udf_bh - test.txt

 
123456789abcdef85072696e636530300301440408706d616c6c6164000508 
266431530102030405060708090a0b0c0d0e0f101112131415161718191a1b 
1c1d1

udf_data

Syntax

[udf_data=<filename>] <partition>

Description

Imports a file containing up to 56 bytes of data into user defined field (UDF) of the Authentication Certificate. For more information, see Authentication for more information about authentication certificates.

Arguments

Specified file name.

Example

all:
{
	[pskfile] primary0.pem
	[sskfile]secondary0.pem
	[bootloader, destination_cpu=a53-0, authentication=rsa,udf_data=udf.txt]fsbl.elf
	[destination_cpu=a53-0,authentication=rsa] hello.elf
}

userkeys

Syntax

userkeys = <filename>

File Format

user_key0 <userkey0 value>                                     
user_key1 <userkey1 value>                                     
user_key2 <userkey2 value>                                     
user_key3 <userkey3 value>                                      
user_key4 <userkey4 value>                                      
user_key5 <userkey5 value>                                    
user_key6 <userkey6 value>                                     
user_key7 <userkey7 value>

Description

The path to the user keyfile. The keyfile contains user keys used to encrypt the partitions. The size of user key can be 128 or 256 bits. The 128-bit key can be used only for run-time loaded partitions.

Example

In the following example, FPD partition uses the key source as user_key2, so the .nky file for this partition must have the user_key2 from the userkeys file as the key0. This key0 from the .nky file is then used by Bootgen for encryption. The PLM uses the user_key2 programmed by pmc_data during decryption.

new_bif:
{
 userkeys = userkeyfile.txt
 id_code = 0x14ca8093
 extended_id_code = 0x01
 id = 0x2
 image
 {
  name = pmc_subsys
  id = 0x1c000001
  partition
  {
   id = 0x01
   type = bootloader
   encryption = aes
   keysrc=bbram_red_key
   aeskeyfile = inputs/keys/enc/bbram_red_key.nky
   dpacm_enable
   file = gen_files/plm.elf
  }
  partition
  {
   id = 0x09
   type = pmcdata, load = 0xf2000000
   file = static_files/topology_xcvc1902.v3.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 = design_1_wrapper.rcdo
  }
  partition
  {
   id = 0x05
   type = cdo
   file = design_1_wrapper.rnpi
  }
 }
 image
 {
  name = fpd
  id = 0x420c003
  partition
  {
   id = 0x08
   type = cdo
   file = gen_files/fpd_data.cdo
   encryption = aes
   keysrc=user_key2
   aeskeyfile = userkey2.nky
  }
 }
 image
 {
  name = ss_apu
  id = 0x1c000000
  partition
  { 
   id = 0x61
   core = a72-0
   file = ./wrk_a72_r5/perip_a72/Debug/perip_a72.elf 
  }
 }
}

xip_mode

Syntax

[xip_mode] <partition>

Description

Indicates 'eXecute In Place' for FSBL to be executed directly from QSPI flash.

Note: This attribute is only applicable for an FSBL/Bootloader partition.

Arguments

Specified partition.

Example

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

all:
{
	[bootloader, xip_mode] fsbl.elf 
	application.elf
}