LS1046A Secure boot ERROR_HASH_COMPARE_EM

stadium_aquino · ‎04-25-2022

I am trying to get secure boot working with ATF. The board boots fine, but SCRATCHRW2 contains 0x341, which is ERROR_HASH_COMPARE_EM. In this thread, it is suggested to use ARCH=arm when compiling the CST. However, this variable was removed in 6caf90f ("New CST Tools added").

I am using the latest atf from codeaurora on the qoriq/github.com/master branch. I am compiling ATF using the following command:

CROSS_COMPILE=aarch64-linux-gnu- make PLAT=ls1046ardb pbl BOOT_MODE=sd BL33=/path/to/u-boot.img RCW=/path/to/rcw/ls1046ardb/RR_FFSSPPPH_1133_5559/rcw_1800_sdboot.bin TRUSTED_BOARD_BOOT=1 CST_DIR=/path/to/cst

I am using the regular RCW with SB_EN=1 because if BOOT_HO=1 (such as in the sec RCW) then the board does not boot at all.

yipingwang · ‎04-26-2022

1. I recommend you to use source code from LSDK 21.08 to verify your procedure first.

atf:
url: https://source.codeaurora.org/external/qoriq/qoriq-components/atf.git
tag: LSDK-21.08

uboot:
url: https://source.codeaurora.org/external/qoriq/qoriq-components/u-boot.git
tag: LSDK-21.08

cst:
url: https://source.codeaurora.org/external/qoriq/qoriq-components/cst.git

2. Please refer to the following atf build command.

make -s -j2 fip pbl PLAT=ls1046ardb BOOT_MODE=sd RCW=/home/nxa22585/data/flexbuild_lsdk2108/build/firmware/rcw/ls1046ardb/RR_FFSSPPPH_1133_5559/rcw_1800_sdboot_sben.bin BL33=/home/nxa22585/data/flexbuild_lsdk2108/build/firmware/u-boot/ls1046ardb/uboot_ls1046ardb_tfa_SECURE_BOOT.bin TRUSTED_BOARD_BOOT=1 CST_DIR=/home/nxa22585/data/flexbuild_lsdk2108/components/apps/security/cst

3. Did you blow SRKH and OPTMK fuse array on your target board?

stadium_aquino · ‎04-26-2022

1. Same error when using the LSDK-21.08 tag. I am already using the codaurora cst.

2. Same error. I don't think this will have an effect anyway, since as far as I can tell you just need the pbl target to build the signed ATF.

3. Yes. The board did not boot at all with SB_EN=1 when I did not have the OTPMK programmed. The SRKH is also programmed. I believe it is correct because there is a separate error code 0x340 "ERROR_HASH_COMPARE_KEY" for when the SRKH does not match.

yipingwang · ‎04-26-2022

Please build u-boot with configuration file ls1046ardb_tfa_SECURE_BOOT_defconfig.

Please build atf to generate pbl and fip image with options "CSF_HEADER_PREPENDED=1 TRUSTED_BOARD_BOOT=1".

Please deploy atf pbl image at 0x00008 and fip image at 0x00800 on SD card.

stadium_aquino · ‎04-28-2022

> Please build u-boot with configuration file ls1046ardb_tfa_SECURE_BOOT_defconfig.

The target U-Boot doesn't matter here. As I understand it, this error is generated by the ISBC before any user code is run. Similarly, the FIP used does not matter.

> Please build atf to generate pbl and fip image with options "CSF_HEADER_PREPENDED=1 TRUSTED_BOARD_BOOT=1".

Same error.

> Please deploy atf pbl image at 0x00008 and fip image at 0x00800 on SD card.

I have been programming my SD card with the following command

dd if=build/ls1046ardb/release/bl2_sd_sec.pbl of=/dev/sdd seek=8 conv=fsync

yipingwang · ‎04-28-2022

Please also program fip image on the target board, then check the result.

I will discuss this error with the AE team, will provide more feedback later.

yipingwang · ‎05-04-2022

Please refer to the following feedback from the AE team.

How does customer provided the SRKH, burn the fuse OR thru CWTap CCS script?
If is in the fuse, can the customer provided SFP register dump? i.e. 0x1e80200 to 0x1e80300.
If customer is using CCS, can they provide the CCS console log?
Lastly, what is the SRKH value generated from the LSDK?

At this point we suspect it is the endianness of SRKH customer provided caused the error code.

stadium_aquino · ‎05-05-2022

> How does customer provided the SRKH, burn the fuse OR thru CWTap CCS script?

I followed the "Program SRKH mirror registers in U-Boot Environment" instructions.

https://docs.nxp.com/bundle/GUID-487B2E69-BB19-42CB-AC38-7EF18C0FE3AE/page/GUID-2CF1D60F-C79F-4A35-8...

> If is in the fuse, can the customer provided SFP register dump? i.e. 0x1e80200 to 0x1e80300.

=> md.l 1e80200 33
01e80200: 00000000 00000000 00000000 00000000  ................
01e80210: ffffffff ffffffff 09000000 59f0babd  ...............Y
01e80220: 6c1aab0e 00000000 00000000 00000000  ...l............
01e80230: 00000000 ffffffff ffffffff ffffffff  ................
01e80240: ffffffff ffffffff ffffffff ffffffff  ................
01e80250: ffffffff de136529 06e3bfd5 dd27ce97  ....)e........'.
01e80260: aac73bb3 19839214 c897e894 7eb9de30  .;..........0..~
01e80270: a3a9b765 00000000 00000000 00000000  e...............
01e80280: 00000000 00000000 ffffffff ffffffff  ................
01e80290: ffffffff ffffffff ffffffff ffffffff  ................
01e802a0: ffffffff ffffffff 00000000 00000000  ................
01e802b0: 00000000 00000000 00000000 00000000  ................
01e802c0: 00000000 00000000 00000000           ............

> Lastly, what is the SRKH value generated from the LSDK?

SRK (Public Key) Hash:
296513ded5bfe30697ce27ddb33bc7aa1492831994e897c830deb97e65b7a9a3
	 SFP SRKHR0 = 296513de
	 SFP SRKHR1 = d5bfe306
	 SFP SRKHR2 = 97ce27dd
	 SFP SRKHR3 = b33bc7aa
	 SFP SRKHR4 = 14928319
	 SFP SRKHR5 = 94e897c8
	 SFP SRKHR6 = 30deb97e
	 SFP SRKHR7 = 65b7a9a3

In the above link, the example shows "SFP SRKHR0 = fdc2fed4" and "01e80254: d4fec2fd" (e.g. it is byte-swapped). My fuses are also byte-swapped when compared to the output of the CST, so I think this should be correct.

yipingwang · ‎05-10-2022

The log and the endianness for SRKH looks correct.

So the reason for getting "0x341 ERROR_HASH_COMPARE_EM" is most likely the key(s) to sign image being loaded/booted is different from the SRKH.
Can you try to build it with LSDK flex-builder to generate the image? We tested the LSDK automated build process and not running into x341.
If you are using codeaurora version. it may miss some steps.
In particular, LSDK cst tool use input_files to specify the srk.pub and srk.pri, and which key to use in case customer has multiple keys specified.

Here is an example of LSDK build log section that customer can find all the "input_file" to specify the "key" to use for sign and calculate the SRKH.
#####
#----------------------------------------------------#
#------- -------- -------- -------#
#------- CST (Code Signing Tool) Version 2.0 -------#
#------- -------- -------- -------#
#----------------------------------------------------#

==========================================================
This tool includes software developed by OpenSSL Project
for use in the OpenSSL Toolkit (http://www.openssl.org/)
This product includes cryptographic software written by
Eric Young (eay@cryptsoft.com)
==========================================================

Input File is input_files/uni_sign/lx2160/input_bootscript_secure

-----------------------------------------------
- Dumping the Header Fields
-----------------------------------------------
- SRK Information
- SRK Offset : 200
- Number of Keys : 1
- Key Select : 1
- Key List :
- Key1 srk.pub(100)
- UID Information
- UID Flags = 00
- FSL UID = 00000000_00000000
- OEM UID0 = 00000000
- OEM UID1 = 00000000
- OEM UID2 = 00000000
- OEM UID3 = 00000000
- OEM UID4 = 00000000
- FLAGS Information
- MISC Flags = 00
- Image Information
- bootscript (Size = 000003d4 SRC = 00000000_80000000)
- RSA Signature Information
- RSA Offset : 800
- RSA Size : 80
-----------------------------------------------

Image Hash:
f5652edb1e7a01306c36181339bd21d73d0cf08a1ba8565005d7e631822bdefc

************************************************
* Header File is with Signature appended
************************************************
#####

In the input_file, looks for
e.g.
cat ./components/apps/security/cst/input_files/uni_sign/ls104x_1012/ie_keys/qspi/input_bootscript_secure
...
# PRI_KEY (Default private key :srk.pri) - [Optional]
PRI_KEY=iekey1k_1.pri
# PUB_KEY (Default public key :srk.pub) - [Optional]
PUB_KEY=iekey1k_1.pub
# Please provide KEY_SELECT(between 1 to 4) (Required for 1040/C290/9164/4240 only) - [Optional]
KEY_SELECT=1
...

and make sure all the key(s) in different input_files for ls104x match in the customer build environment. If the key(s) are different, then it will affect the built output of:
Image Hash:
f5652edb1e7a01306c36181339bd21d73d0cf08a1ba8565005d7e631822bdefc

stadium_aquino · ‎05-12-2022

I built ATF using

$ flex-builder -c atf -m ls1046ardb -b sd -s -B uboot

I also modified configs/sdk.yml and changed SECURE_PRI_KEY and SECURE_PUB_KEY to point to my keys. The built ATF did not boot (as far as I could tell). There was no console output at all. Additionally, there was no error in SCRATCHRW2. However, when I modified components/firmware/rcw/ls1046ardb/RR_FFSSPPPH_1133_5559/rcw_1800_sdboot_sben.rcw and changed BOOT_HO=0, the built ATF booted successfully. Despite this (because of this?), error 0x341 was present in SCRATCHRW2 again.

So how is the secure boot process supposed to work? What is supposed to release the boot core when BOOT_HO=1? Why does setting BOOT_HO=0 cause secure boot to fail? Am I missing some kind of pin configuration?

stadium_aquino · ‎05-24-2022

Any updates on this? https://docs.nxp.com/bundle/GUID-1B480175-7E30-4237-A58E-3F0AD1C61250/page/GUID-F54AA72B-FC4B-4F9A-8... says that BOOT_HO is only enabled to allow programming the SRKH, and that

> If SRKH fuse is already blown, then set BOOT_HO = 0 in rcw file in flexbuild

So it seems like disabling BOOT_HO is the way to go. So why do I get an error when I run this code?

yipingwang · ‎05-26-2022

Please refer to the following update from the AE team.

First of all, when customer does "flex-builder -c atf -m ls1046ardb -b sd -s -B uboot", it sign the ATF with secure boot process, and set the RCW SB_EN and BOOT_HO bit. This does two things, it tell the system during boot to use the secure bootrom AND put the CPU on hold so customer can put a temporary SRKH value for testing. (p.s. This trick to put temporary SRKH does not work for production system with Intent To Secure (ITS) fuse blown). In order to temporary overwrite the SRKH value, please refers to LSDKUG_Rev21.08 (or equivalent), section 6.1.1.5.2.4.1 Program SRKH mirror registers in CodeWarrior environment ##### 1. Platforms LS1021A, LS1012A, LS1043A, LS1046A (TA 2.x) a. After copying images to flash, select the boot source by changing the switch settings, then boot the board.

When the flexbuild command is executed with -s option, the command uses secure RCW, with RCW[BOOT_HO] =

1 and RCW[SB_EN]=1, for building images.

After booting the board, core would stop at its first instruction. This is done to allow the user to write SRKH in the register. When using pre-built images, use the SRKH present in srk_hash.txt from GitHub.

If SRKH fuse is already blown, then set RCW[BOOT_HO] = 0 in RCW file in flexbuild, else write the SRKH value (displayed while signing images) in SFP mirror registers and then release the core out of boot hold off by writing to Boot Release Register in DCFG using the below commands:

ccs::config_server 0 10000

ccs::config_chain {<platform> dap sap2}

display ccs::get_config_chain

# Check Initial SNVS State and Value in SCRATCH Registers ccs::display_mem <dap position> 0x1e90014 4 0 4 ccs::display_mem <dap position> 0x1ee0200 4 0 4 #Write the SRK Hash Value in Mirror Registers ccs::write_mem <dap position> 0x1e80254 4 0 <SRKH0> ccs::write_mem <dap position> 0x1e80258 4 0 <SRKH1> ccs::write_mem <dap position> 0x1e8025c 4 0 <SRKH2> ccs::write_mem <dap position> 0x1e80260 4 0 <SRKH3> ccs::write_mem <dap position> 0x1e80264 4 0 <SRKH4> ccs::write_mem <dap position> 0x1e80268 4 0 <SRKH5> ccs::write_mem <dap position> 0x1e8026c 4 0 <SRKH6> ccs::write_mem <dap position> 0x1e80270 4 0 <SRKH7> #Get the Core Out of Boot Hold-Off ccs::write_mem <dap position> 0x1ee00e4 4 0 0x00000001 #####

In the above, when you issue:

#Get the Core Out of Boot Hold-Off

ccs::write_mem <dap position> 0x1ee00e4 4 0 0x00000001

You release the CPU from boot_ho and it will continues to boot with secure bootrom, etc. You will get the console and you will get "error 0x341 was present in SCRATCHRW2 again"

Therefore "BOOT_HO=0" does not cause secure boot to fail, it just allow the temporary SRKH to be overwritten and continue the secure boot process.

Since you already have SRKH burn into the fuse. You don't really need the BOOT_HO trick to overwritten the SRKH value. You will need this "trick" if you use different srk.pri/srk.pub pair to sign the image.

Get back to your original issue with secure boot.

The error 0x341 is

#####

RSA signature check failure. Signature provided by you in the header doesn’t match with the signature of the ESBC image generated by ISBC. The ESBC image loaded by you may be different than the image used while generating the signature(using CST) ##### There is one of two cause for this error. 1) Key signed is not the same as key use to sign the software image. 2) SRKH in the SFP register is corrupted.

Have you run:

$ flex-builder -i clean-firmware

flex-builder -i mkfw -m ls1046ardb -b sd -s flex-builder -c atf -m ls1046ardb -b sd -s flex-installer -m ls1046ardb -d /dev/mmcblk0 or flex-installer -b build/images/bootpartition_LS_arm64_lts_5.4_202011171428.tgz -r build/images/rootfs_lsdk2012_ubuntu_main_arm64_202011171437.tgz -f build/images/firmware_ls1046a rdb_uboot_sdboot_secure.img -d /dev/mmcblk0

If customer still have problem. Please provide the flex-builder and complete flex-installer log.

stadium_aquino · ‎05-27-2022

I ran the following commands:

$ flex-builder -i clean-firmware

$ flex-builder -i mkfw -m ls1046ardb -b sd -s

$ flex-builder -c atf -m ls1046ardb -b sd

The flex-installer command you provided did not result in a bootable image. However, running

# dd if=build/images/firmware_ls1046ardb_sdboot_secure.img of=/dev/sdd seek=8 conv=fsync

worked. The build and boot logs are attached. I still see this error in SCRATCHRW2.

yipingwang · ‎05-31-2022

Just notice from your build.log,

#####

-----------------------------------------------

- Dumping the Header Fields

-----------------------------------------------

- SRK Information

- SRK Offset : 200

- SRK Flag = 1

- Number of Keys : 1

- Key Select : 1

- Key List :

- Key1 srk.pub(200)

- UID Information

- UID Flags = 00

- FSL UID = 00000000_00000000

- OEM UID = 00000000_00000000

- Image Information

- kernel.itb (Size = 023faeef src=00000000_a0000000)

- RSA Signature Information

- RSA Offset : 800

- RSA Size : 100

####

I am getting from my test

#####

-----------------------------------------------

- Dumping the Header Fields

-----------------------------------------------

- SRK Information

- SRK Offset : 200

- SRK Flag = 1

- Number of Keys : 1

- Key Select : 1

- Key List :

- Key1 srk.pub(100)

- UID Information

- UID Flags = 00

- FSL UID = 00000000_00000000

- OEM UID = 00000000_00000000

- Image Information

- pfe.itb (Size = 00013ee4 src=00000000_40a00000)

- RSA Signature Information

- RSA Offset : 800

- RSA Size : 80

#####

The main difference is RSA Size : 80 vs 100.

Can you share more information on how your RSA key is define/generated? If you modify one of the default LSDK CST input files, please share what you modified.

"RSA Size : 80" is from the default LSDK option, i.e. RSA key is 1K and generated by LSDK flex-builder. I just wonder if you use the default setup(may be re-install LSDK and just follow the examples in LSDK to use default srk.pri and srk.pub, you will get the same error or not.

stadium_aquino · ‎06-02-2022

> Can you share more information on how your RSA key is define/generated? If you modify one of the default LSDK CST input files, please share what you modified.

I used "gen_keys 2048", which is documented as supported. This should account for the discrepancy in length.

Here is the current header generated by cst: https://paste.debian.net/plainh/a126a400

The RSA signature length is set to 0x100, which is correct. The srk table offset (offset 0x4) is 0x200. From the table, the Key 1 length is 0x200. This is twice as large, but it appears that cst uses the extra space for the exponent. For reference, my public key is https://paste.debian.net/plainh/6bb823ca

> I just wonder if you use the default setup(may be re-install LSDK and just follow the examples in LSDK to use default srk.pri and srk.pub, you will get the same error or not.

I don't think I can do this because the key is already programmed into the fuses. Is it possible to override the SRKH even when it is already programmed?

yipingwang · ‎06-06-2022

Please refer to the following update from the AE team.

Yes, even you burn the SRKH fuse, you still can use JTAG to temporary over-write the SRHK mirror register for testing (i.e. this only work when you use RCW SB_EN and boot_ho bit). This does not work for production system (i.e. when ITS fuse is burn).
Please refers to LSDKUG_rev21.08, section 6.1.1.5.2.4.1 Program SRKH mirror registers in CodeWarrior environment.
...
ccs::config_server 0 10000
ccs::config_chain {<platform> dap sap2}
display ccs::get_config_chain
# Check Initial SNVS State and Value in SCRATCH Registers
ccs::display_mem <dap position> 0x1e90014 4 0 4
ccs::display_mem <dap position> 0x1ee0200 4 0 4
#Write the SRK Hash Value in Mirror Registers
ccs::write_mem <dap position> 0x1e80254 4 0 <SRKH0>
ccs::write_mem <dap position> 0x1e80258 4 0 <SRKH1>
ccs::write_mem <dap position> 0x1e8025c 4 0 <SRKH2>
ccs::write_mem <dap position> 0x1e80260 4 0 <SRKH3>
ccs::write_mem <dap position> 0x1e80264 4 0 <SRKH4>
ccs::write_mem <dap position> 0x1e80268 4 0 <SRKH5>
ccs::write_mem <dap position> 0x1e8026c 4 0 <SRKH6>
ccs::write_mem <dap position> 0x1e80270 4 0 <SRKH7>
#Get the Core Out of Boot Hold-Off
ccs::write_mem <dap position> 0x1ee00e4 4 0 0x00000001
...

If you do not have access to CWTap JTAG debugger, you need to find an equivalent command for your JTAG debugger.

Testing out the 1024bit srk.pri and skh.pub (or srk1k.pub/srk1k.pub) will confirm your build environment and procedure is correct. i.e. the flex_builder uses the correct configuration/files. After the confirmation, then you should simply swap the srk1k.pub and skl1.pri with srk2k.pub and skl2.pri keys.

Also, can customer do the hexdump for the "firmware_ls1046ardb_sdboot_secure.img" as well. I like to confirm it has the same/similar layout as "components/firmware/atf/build/ls1046ardb/release/hdr_bl2". i.e.
> hexdump -C ./build/images/firmware_ls1046ardb_sdboot_secure.img | grep "68 39 27 81"
0000f300 68 39 27 81 00 02 00 00 01 01 01 00 00 0a 00 00 |h9'.............|
000ff0b0 68 39 27 81 00 02 00 00 01 01 01 00 00 08 00 00 |h9'.............|
005ff000 68 39 27 81 00 02 00 00 01 01 01 00 00 08 00 00 |h9'.............|
...

stadium_aquino · ‎06-09-2022

I can't seem to write to the mirror registers when BOOT_HO=1.

> # example to show writes are working
> mdw 0x1570600 4
0x01570600: 00000000 10000000 00000000 00000000 

> mww 0x1570600 0xd00dfeed
> mdw 0x1570600 4         
0x01570600: d00dfeed 10000000 00000000 00000000 

> # now try to write the mirror registers
> mww 0x1e80254 0x09b4a77b               
> mdw 0x1e80254           
0x01e80254: 296513de

When BOOT_HO=0, this same write succeeds.

With regard to the layout of firmware_ls1046ardb_sdboot_secure.img, I see the same output from the hexdump|grep command you suggested.

yipingwang · ‎06-13-2022

Sorry I am not familiar with the command you are using, is it lauterbach?
When you issue
mdw 0x1570600 4
which JTAG chain position/device you are issue from?

When you set boot-ho, all the ARM A72 core are on hold and not accessible. That is why in the previous example we gave has the following command:
ccs::config_chain {<platform> dap sap2}
display ccs::get_config_chain
# Check Initial SNVS State and Value in SCRATCH Registers
ccs::display_mem <dap position> 0x1e90014 4 0 4
Because the A72 is not available, only DAP/SAP2 in the JTAG scan chain can be access to run the instruction, that is why you have to specify to issue the command with <dap position>.
e.g. For CW Tap
% disp ::ccs::get_config_chain
Chain Position 0: LS1043A
Chain Position 1: DAP
Chain Position 2: SAP2
Then my sample command of
ccs::display_mem <dap position> 0x1e90014 4 0 4
will become
ccs::display_mem 1 0x1e90014 4 0 4

Can you do the same with your JTAG tool?

Without boot_ho, your JTAG chain will see something like below and the A72 will be accessible to execute register read/write/
% display ccs::get_config_chain
Chain Position 0: LS1043A
Chain Position 1: CoreSight ATB Funnel
Chain Position 2: CoreSight ATB Funnel
Chain Position 3: CoreSight TMC
Chain Position 4: CoreSight TMC
Chain Position 5: CoreSight ATB Funnel
Chain Position 6: CoreSight STM
Chain Position 7: CoreSight TMC
Chain Position 8: CoreSight ATB Funnel
Chain Position 9: CoreSight ATB Funnel
Chain Position 10: CoreSight TMC
Chain Position 11: CoreSight TMC
Chain Position 12: CoreSight TMC
Chain Position 13: CoreSight CTI
Chain Position 14: CoreSight CTI
Chain Position 15: CoreSight CTI
Chain Position 16: Cortex-A72
Chain Position 17: CoreSight CTI
Chain Position 18: Cortex-A72 PMU
Chain Position 19: Cortex-A72 ETM
Chain Position 20: Cortex-A72
Chain Position 21: CoreSight CTI
Chain Position 22: Cortex-A72 PMU
Chain Position 23: Cortex-A72 ETM
Chain Position 24: Cortex-A72
Chain Position 25: CoreSight CTI
Chain Position 26: Cortex-A72 PMU
Chain Position 27: Cortex-A72 ETM
Chain Position 28: Cortex-A72
Chain Position 29: CoreSight CTI
Chain Position 30: Cortex-A72 PMU
Chain Position 31: Cortex-A72 ETM
Chain Position 32: DAP
Chain Position 33: SAP2

stadium_aquino · ‎06-13-2022

> Sorry I am not familiar with the command you are using, is it lauterbach?

OpenOCD. I believe the mnemonics are "memory display word" and "memory write word".

> When you issue
> mdw 0x1570600 4
> which JTAG chain position/device you are issue from?

SAP. I am using it because, as you noted, it is not possible to read/write using a held-off core. As shown in my first comment, I can read/write from registers in other areas of the device. I can also read/write the mirror registers from JTAG/SAP after booting to U-Boot. I believe my JTAG setup is working OK because of this, so I suspect that ignored writes are due to something else.

yipingwang · ‎06-16-2022

Please refer to the following update from the AE team.

Can customer confirm, when BOOT_HO is enable, they can read/write any registers except 0x1570600 and/or 0x1e80254?

as from the customer log on 6/10/2022, customer said:

I can't seem to write to the mirror registers when BOOT_HO=1.

...

When BOOT_HO=0, this same write succeeds.

My understanding is when BOOT_HO=1, "mww" does not work. That is why i suggest to make sure the "mww" is issue the instruction from SAP. How does the customer to confirm it is execute the mww from SAP?

p.s. We have no issue doing the JTAG register write with CWTap + CCS. That is why we suggest the incompatibility between their JTAG environment setting.

If customer cannot write to 0x1e80254 when BOOT_HO is enabled, can they try to do it with CWTAP + CCS?

stadium_aquino · ‎06-28-2022

> Can customer confirm, when BOOT_HO is enable, they can read/write any registers except 0x1570600 and/or 0x1e80254?

> ls1046a.sap mdw 0x10000000
0x10000000: aa0003f4 

> ls1046a.sap mww 0x10000000 0xdeadbeef
> ls1046a.sap mdw 0x10000000           
0x10000000: deadbeef 

> ls1046a.sap mdw 0x1ee0200
0x01ee0200: 00770110 

> ls1046a.sap mww 0x1ee0200 0xdeadbeef
> ls1046a.sap mdw 0x1ee0200           
0x01ee0200: deadbeef 

> ls1046a.sap mdw 0x1570600
0x01570600: 00000000 

> ls1046a.sap mww 0x1570600 0xdeadbeef
> ls1046a.sap mdw 0x1570600           
0x01570600: deadbeef 

> ls1046a.sap mdw 0x1e80254           
0x01e80254: de136529 

> ls1046a.sap mww 0x1e80254 0xdeadbeef
> ls1046a.sap mdw 0x1e80254           
0x01e80254: deadbeef

> # !!!

Well, as you can see above, I can now write to the mirror registers... Not sure what's different

> My understanding is when BOOT_HO=1, "mww" does not work.

It works for other registers, hence why I demonstrated writing/reading from 0x1570600.

> That is why i suggest to make sure the "mww" is issue the instruction from SAP. How does the customer to confirm it is execute the mww from SAP?

The JTAG target used to execute the mww command is implicitly set with the targets command. For maximum clarity, I will use the explicit version in the following example:

> ls1046a.cpu0 mdw 0x10000000
aarch64_mmu: target ls1046a.cpu0 not halted

> halt

> ls1046a.cpu0 mdw 0x10000000
aarch64_mmu: target ls1046a.cpu0 not halted

> ls1046a.sap mdw 0x10000000
0x10000000: aa0003f4

Because I get an error message if I try to use CPU0 to read/write, it is very obvious when I have selected the wrong JTAG target.

> If customer cannot write to 0x1e80254 when BOOT_HO is enabled, can they try to do it with CWTAP + CCS?

I don't have a CWTAP.

So now that writing to the mirror registers works, lets try it out

> ls1046a.sap mww 0x1e80254 0xb4a78768
> ls1046a.sap mww 0x1e80258 0x2a7fbff5
> ls1046a.sap mww 0x1e8025c 0xd6f633ac
> ls1046a.sap mww 0x1e80260 0xe4c1e27b
> ls1046a.sap mww 0x1e80264 0x61bb21f1
> ls1046a.sap mww 0x1e80268 0x132f3e17
> ls1046a.sap mww 0x1e8026c 0xec489c67
> ls1046a.sap mww 0x1e80270 0x792ecc6d
> ls1046a.sap mww 0x1ee00e4 1
> # output on console appears
> ls1046a.sap mdw 0x1ee0300 4
0x01ee0300: 00000000 00000000 00000000 00000000

Which looks like success (or failure, depending on how you look at it) to me. I think this confirms that 2048-bit keys do not work on the LS1046A.

LS1046A Secure boot ERROR_HASH_COMPARE_EM

LS1046A Secure boot ERROR_HASH_COMPARE_EM

QorIQ LS1 Devices