UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor ahussain
Visitor
424 Views
Registered: ‎05-08-2018

Multiboot recovery with bh_auth_enable, ZynqMP

Jump to solution

Hello,

We're using QSPI boot mode on our board, and trying to achieve Multiboot fallback along with Zynqmp Secure Boot.

We've successfully tested that if the boot.bin image is not found at flash address 0x00, then the backup image is used. However, if there's an image found at 0x00 but it fails authentication for any component (say FSBL), then the boot rom does boot the image, but FSBL stops at that partition header authentication, due to hash mismatch. Debug log from FSBL in this case is given below:

Xilinx Zynq MP First Stage Boot Loader 
Release 2018.2   Sep  6 2019  -  10:42:10
Reset Mode      :       System Reset
Platform: Silicon (4.0), Cluster ID 0x80000000
Running on A53-0 (64-bit) Processor, Device Name: XCZU3EG
Processor Initialization Done 
================= In Stage 2 ============ 
QSPI 32 bit Boot Mode 
QSPI is in Dual Parallel connection
QSPI is using 4 bit bus
FlashID=0x20 0xBB 0x20
MICRON 512M Bits
Multiboot Reg : 0x0 
QSPI Reading Src 0x0, Dest FFFF1C40, Length EC0
.Image Header Table Offset 0x8C0 
Authentication Enabled
QSPI Reading Src 0x8D0, Dest FFFDE6AC, Length 4
.QSPI Reading Src 0x1940, Dest FFFDB490, Length EC0
.QSPI Reading Src 0x8C0, Dest FFFF1C40, Length 1080
.Auth: Partition Offset FFFF1C40, PartitionLen 1F40, AcOffset FFFDB490, HashLen 30
Doing Partition Sign verification
Partition Verification done 
*****Image Header Table Details******** 
Boot Gen Ver: 0x1020000 
No of Partitions: 0x7 
Partition Header Address: 0x440 
Partition Present Device: 0x0 
Initialization Success 
======= In Stage 3, Partition No:1 ======= 
UnEncrypted data Length: 0x153E27 
Data word offset: 0x153E27 
Total Data word length: 0x1541E0 
Destination Load Address: 0xFFFFFFFF 
Execution Address: 0x0 
Data word offset: 0x7670 
Partition Attributes: 0x208026 
QSPI Reading Src 0x1D9C0, Dest 100000, Length 550780
.Destination Device is PL, changing LoadAddress
Authentication Enabled
Authenticated Bitstream download to start now
PL Configuration done successfully 
Partition 1 Load Success 
======= In Stage 3, Partition No:2 ======= 
UnEncrypted data Length: 0x4CB6 
Data word offset: 0x4CB6 
Total Data word length: 0x5070 
Destination Load Address: 0xFFDC0000 
Execution Address: 0xFFDC95C0 
Data word offset: 0x15B850 
Partition Attributes: 0x883E 
QSPI Reading Src 0x581440, Dest FFFDB490, Length EC0
.QSPI Reading Src 0x56E140, Dest FFDC0000, Length 13300
.Authentication Enabled
Auth: Partition Offset FFDC0000, PartitionLen 141C0, AcOffset FFFDB490, HashLen 30
Doing Partition Sign verification
Partition Verification done 
Calculated Partition Hash START
03 7F 73 1E 9B B4 7C D1 60 74 81 D8 9C 03 79 12 
79 2B 11 F3 CE 26 A8 94 96 E0 D2 1B FC AD 8C CE 
38 1C E2 28 2D 03 AA 8C A8 9F AF 27 CF 68 38 6F 

Calculated Partition Hash END
RSA decrypted Hash START
00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF 00 30 41 30 
0D 06 09 60 86 48 01 65 03 04 02 09 05 00 04 30 
68 71 DC 96 20 C9 04 8E 49 29 58 FD 5B 80 4B 7F 
1B B7 D8 4D A0 82 3D E0 EE 37 50 61 A7 0E C5 79 
20 09 95 B5 F5 EF 64 C1 95 AD 08 3E 86 EA 4A 25 

RSA decrypted Hash END
XFsbl_PartVer: XFSBL_ERROR_PART_SIGNATURE
Partition 2 Load Failed, 0x32
================= In Stage Err ============ 
Fsbl Error Status: 0x0

My question is that shouldn't the CSU ROM authenticate image headers before loading PMUFW or FSBL, so that multiboot recovery can kick-in if the FSBL itself is corrupt/un-authorized. In my case, the system is stuck and I've to manually reset it thus there's no recovery. Reading the ug1137 manual it does look like that is case; so does CSU recovery only happen if RSA_EN efuses are blown?

0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
385 Views
Registered: ‎10-11-2011

Re: Multiboot recovery with bh_auth_enable, ZynqMP

Jump to solution

With this .bif, the CSU ROM will only validate the FSBL since the PMUFW is loaded by the FSBL on a later stage.

You can still fallback in this case by forcing the FSBL to issue a SRST (with a change on the MULTIBOOT address) upon a validation error of the partititon.

11 Replies
Visitor ahussain
Visitor
418 Views
Registered: ‎05-08-2018

Re: Multiboot recovery with bh_auth_enable, ZynqMP

Jump to solution

BTW, here's my bif layout:

# the_ROM_image:                                                                      
# {                                                                                   
#      [auth_params] ppk_select = 0                                                   
#      [fsbl_config] bh_auth_enable                                                   
#      [pskfile] <primary secret key>                                                 
#      [sskfile] <secondary secret key>                                               
#      [bootloader,  destination_cpu=a53-0,  authentication=rsa] <FSBL elf>           
#      [destination_device=pl,  authentication=rsa ] <bitstream.bit to include in the ROM image>
#      [destination_cpu=pmu,  authentication=rsa ] <PMUFW elf>                  
#      [destination_cpu=a53-0,  exception_level=el-3,  trustzone=secure,  authentication=rsa] <ATF elf>  
#      [destination_cpu=a53-0,  exception_level=el-2,  authentication=rsa] <U-Boot elf>

and here's my boot.bin dump from bootgen_utility: https://pastebin.com/ExMFp82t

0 Kudos
Xilinx Employee
Xilinx Employee
386 Views
Registered: ‎10-11-2011

Re: Multiboot recovery with bh_auth_enable, ZynqMP

Jump to solution

With this .bif, the CSU ROM will only validate the FSBL since the PMUFW is loaded by the FSBL on a later stage.

You can still fallback in this case by forcing the FSBL to issue a SRST (with a change on the MULTIBOOT address) upon a validation error of the partititon.

Visitor ahussain
Visitor
352 Views
Registered: ‎05-08-2018

Re: Multiboot recovery with bh_auth_enable, ZynqMP

Jump to solution

Hi,

Makes sense, but what I tried was corrupting the FSBL itself (changing a single byte in 3rd partition data of boot.bin). I believe my partition layout using this .bif would be:

1. psk

2. ssk

3. fsbl

4. bitstream

5. PMUFW

6. ATF

7. U-Boot

 

Is there a way to confirm this from bootgen_utility image dump?

0 Kudos
Xilinx Employee
Xilinx Employee
316 Views
Registered: ‎10-11-2011

Re: Multiboot recovery with bh_auth_enable, ZynqMP

Jump to solution

I am still worried you are not corrupting the FSBL itself.

bootgen_utility should give you the exact offset of where all the partititons and headers are.

You can use that to go and corrupt very specific locations.

 

0 Kudos
Visitor ahussain
Visitor
311 Views
Registered: ‎05-08-2018

Re: Multiboot recovery with bh_auth_enable, ZynqMP

Jump to solution

Hello,

Thanks for your reply. I shared my boot.bin dump with you. There's information about partition headers and and partition data, but I can't make out what the partition actually is, from this. It only says the partition number.

0 Kudos
Xilinx Employee
Xilinx Employee
265 Views
Registered: ‎10-11-2011

Re: Multiboot recovery with bh_auth_enable, ZynqMP

Jump to solution

I didn't get the file. Can you resend it?

0 Kudos
Visitor ahussain
Visitor
251 Views
Registered: ‎05-08-2018

Re: Multiboot recovery with bh_auth_enable, ZynqMP

Jump to solution

I sent this link for bootgen_utility dump: https://pastebin.com/ExMFp82t

0 Kudos
Xilinx Employee
Xilinx Employee
236 Views
Registered: ‎10-11-2011

Re: Multiboot recovery with bh_auth_enable, ZynqMP

Jump to solution

In the bootgen_utility log you sent I see:

Partition 1 is the FSBL (actual location in BOOT.bin is 0x00002800)

Partition 2 is the bitstream (actual location in BOOT.bin is 0x0001D9C0)

Partition 3 is the PMUFW (actual location in BOOT.bin is 0x0056E140)

Which location (flash address) are you corrupting for you test?

I think you are corrupting partition # 3 which means the FSBL will fail loading the PMUFW. 

NOTE: The FSBL doesn't load itself so for it the bitstream is Partition # 1 and PMUFW is partititon # 2 but the flash offset stays the same.

0 Kudos
Visitor ahussain
Visitor
215 Views
Registered: ‎05-08-2018

Re: Multiboot recovery with bh_auth_enable, ZynqMP

Jump to solution

>The FSBL doesn't load itself so for it the bitstream is Partition # 1 and PMUFW is partititon # 2 but the flash offset stays the same.

That clears one of the ambiguity.

Other one is, how do you tell what the partition is from the log?

1. Did you consult the image headers?

2. In that case, do the header number correspond to the partition number?

3. Are there no image headers for partition #6 and #7 because those are the keys?

0 Kudos
Xilinx Employee
Xilinx Employee
197 Views
Registered: ‎10-11-2011

Re: Multiboot recovery with bh_auth_enable, ZynqMP

Jump to solution

I usually look at the "Image Headers". In your case you have 5 images. Remeber some images can be broken down into multiple partition. For more info look at  UG1283.

I like to look at the "Destination Load Address" to understand what partittion is it.

In your case:

#6 Destination Load Address is 0xfffea000 (which is ATF loaded in OCM)

#7 Destination Load Address is 0x8000000 (which is u-boot loaded in DDR)

0 Kudos
Visitor ahussain
Visitor
172 Views
Registered: ‎05-08-2018

Re: Multiboot recovery with bh_auth_enable, ZynqMP

Jump to solution

Thanks, that clears it for me.

0 Kudos