Secure JTAG

Hi Rob,

Is it possible to program just a secure key for the JTAG or does enabling secure jtag also mandate that a secure boot stream is required ?
>> Secure booting is considered as whole.

Please note, from 0x202BFFFF to 0x28240000 is reserved memory space. Since you are trying to read data from the RESERVED Memory location, it is not accessible.

Also, please refer "Figure 5. ADSP-SC58x/ADSP-2158x Memory Map" in the below linked datasheet of ADSP-SC58x/ADSP-2158x.
www.analog.com/.../ADSP-SC582_583_584_587_589_ADSP-21583_584_587.pdf

Is there any documentation about how to use cldp to program the OTP ?
>> Please refer in below CCES help:
CrossCore® Embedded Studio 2.11.0 > Integrated Development Environment > Working with Bootable and Non-bootable Files > Device Programmer > Device Programmer Command Line > Device Programmer Command-Line Switches

Please note that once the part is locked, it can only be accessed via JTAG with the emulation key.

Regards
Divya.P

Hi Divya,

Thanks for your response.

The datasheet only mentioned OTP once..

One Time Programmable Memory (OTP) The processors feature 7 kB of one time programmable (OTP) memory which is memory-map accessible. This memory contains space for programmable unique keys and supports secure boot and secure operation. 

But doesn't mention it in the memory map, hence my question.

Any ideas why the EE note example code doesn't seem to work on an SC589 ? That's my main concern at the moment as I'm unable to proceed in my evaluation of security options. 

Thanks

Rob

Hi Divya, 

I'm using the Program_OTP project from here 

http://www.analog.com/media/en/technical-documentation/application-notes/EE-366.zip

Here are the steps I followed..

1) imported the keygen & Program_OTP projects into cces (2.8.3)

2) Delete all the pre-build artefacts in the keygen project & build project to create new keys

3) Fix out of date python scripts to work with Python 3

 bin2inc.py : 

     Bytes.append(ord(b))  >> Bytes.append(b)
     if args.mode is 'c': >> if args.mode == 'c':

genRandKey.py

 print "File %s exists, will not overwrite" % f >> print ("File %s exists, will not overwrite" , f)

Makefile
   PYTHON: - change to path to Pythong 3.10

4) Build keygen project to generate a new set of keys

5) There are no example projects for the SC589, so I created a new cces project Program_OTP_Sharc (for Cores 0 & 1)
    - remove addins from Core0 & 1 projects except heap add in for core 0 

    - delete Program_OTP_Sharc_Core1.h & .c auto generated files

    - add new linked file to the Core 1 project (PROJECT_LOC/../Program_OTP/src/Program_OTP.c)

    - add include path to C++ preprocessor settings ("${workspace_loc:/keygen}")

    - enable call to setupBlp() in main() and comment out all references to lock_part() 

          - one in setupBlp()

          - one in main()

    - Set custom linker script for Core0 project to run from L2

          C:\Analog Devices\CrossCore Embedded Studio 2.9.3\ARM\arm-none-eabi\arm-none-eabi\lib\ldscripts\adsp-sc589-l2.ld

  - Add while(1); to end of arm main()

  - configure heap to 4KB. Configure all stacks to 1KB so that project fits in L2

6) Setup launch config for Core 0 & 1 projects (using standard EzKit preloads)

7) Set custom board to No Boot mode

8) Launch debug project, continue the ARM core and start stepping through code in sharc core 1

    - Step into SetupBlp

         - Step into program_authentication_key()

                run to line in the disas windows to step over adi_rom_otp_pgm - note that R0=1 (success)

                run to line to step over validate_pgm - note R0 = 0 (fail) 

                continue and observe output...

Programming auth key:
Qx: a2 6a ff 68 f8 d0 ab c0 03 03 f9 98 60 b1 7d 02 89 be b1 a3 9a 26 a0 d4 18 de 9c 08
Qy: 5e 2d ba 86 50 56 89 3b 2b c8 25 71 f1 1b 04 4b 05 d5 41 3d 84 bf 09 c9 0e 1e b7 df

failed to program authentication key
Reading auth key:
Qx: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Qy: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I've tried this on several boards. I know the boards haven't been locked, because I accidentally locked one (forgot to comment out lock_part() and the behaviour is different for a locked part - the adi_rom_opt_pgm call fails if the part has been locked.

To confirm, I haven't got as far as generating a secure boot image yet, I was just trying to verify the process of securing a processor. 

Kind Regards

Rob

Hi Rob,

We have OTP program example for ADSP-SC589 from EE366v02 notes. Also, we suspect you may face error when trying to import the ADSP-SC589 Program_OTP in CCES.

Please note that, Typically a project will use a number of relative paths in its configuration that may become invalid once the project has been moved. These are files that do not exist within the directory structure of the project, and are instead linked into the project from relative paths

In order to recover the "file not found error", use the linked resources path, please follow the below steps.

1. Open project properties > Resources > Linked Resources
2. Select the "Linked Resources" tab which is next to Path Variables.
3. Select the to be changed to relative location under 'Resource name' and click 'Edit'.
4. Select the source file/folder to be link and click OK.

Please find the attached screenshot for reference.OTP.zip

Could you please try to use the default key available in Keygen project without creating new keys and let us know whether you are able to read the authentication key properly.  And confirm whether the issue occurs only in generating new key's. Please share us the screenshot of the console.

If still facing issue in example project, can you please share us your modified project along with keys you have used.

Regards,
Divya.P

Hi Divya,

I didn't have that issue with the missing linked file because I re-generated the projects from scratch for the SC589 (the example project was for a blackfin and I couldn't change the target family type). 

You state "We have OTP program example for ADSP-SC589 from EE366v02 notes."

but I don't see an example for the 589 in EE366v02.zip ? 

I still get a programming / verification error ..

Programming auth key:
Qx: a2 6a ff 68 f8 d0 ab c0 03 03 f9 98 60 b1 7d 02 89 be b1 a3 9a 26 a0 d4 18 de 9c 08
Qy: 5e 2d ba 86 50 56 89 3b 2b c8 25 71 f1 1b 04 4b 05 d5 41 3d 84 bf 09 c9 0e 1e b7 df

failed to program authentication key
Reading auth key:
Qx: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Qy: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I then tried replacing all the bin, xml and h files in the keygen folder with the original ones provided in the zip and I get the same result.

Programming auth key:
Qx: 0e 6d 81 c4 ed ba 49 85 2a 9f 0f 3f 74 06 be aa 90 6b 78 52 02 5e b2 64 9d ef c0 c7
Qy: 81 11 33 ca 87 ed 11 33 29 b8 76 10 29 10 f0 3f ce a7 32 23 57 0b ba a1 ba 2b c0 03

failed to program authentication key
Reading auth key:
Qx: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Qy: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Perhaps I'm missing some setup ? Do I need any of this stuff from adi_initComponents() ? 

#ifdef __ADI_USE_UTILITY_ROM /* check if Utility ROM support is enabled */

#ifndef NO_UTILITY_ROM_LIBDRV
/* Drivers initialization for the parts that have a Utility ROM. */
if (result == 0) {
static uint8_t bfrom_memory[ADI_BF70X_RAM_SIZE_FOR_ROM_CODE];

result = adi_init_drv_Rom(bfrom_memory, (uint32_t) ADI_BF70X_RAM_SIZE_FOR_ROM_CODE);
}

#endif /* NO_UTILITY_ROM_LIBDRV */

#endif /* __ADI_USE_UTILITY_ROM */

Arm & Core1 Projects attached...

SecureJTAG.zip

Hi Rob,

Please find the attached OTP program example with the source file "Program_OTP.c" project.
0207.OTP.zip
We also recommend upgrading to the latest CCES version 2.11.1. You can use the below link to download latest version of  CCES 2.11.1:
download.analog.com/.../ADI_CrossCoreEmbeddedStudio-Rel2.11.1.exe

Could you please try to run the attached project in latest cces version 2.11.1 and let us know how to get on.

Regards
Divya.P

Hi Rob,

Please find the attached OTP program example with the source file "Program_OTP.c" project.
0207.OTP.zip
We also recommend upgrading to the latest CCES version 2.11.1. You can use the below link to download latest version of  CCES 2.11.1:
download.analog.com/.../ADI_CrossCoreEmbeddedStudio-Rel2.11.1.exe

Could you please try to run the attached project in latest cces version 2.11.1 and let us know how to get on.

Regards
Divya.P

Hi Divja,

I wasn't able to successfully load the example you provided, it never hits main() of the ARM executable. Should I be using this with the following preload ? 

C:\Analog Devices\CrossCore Embedded Studio 2.11.1\SHARC\ldr\ezkitSC589_preload_core0_v01

I've also tried using our custom preload app which I know initialises DDR correctly on our boards but get the same result....

Error in launch sequence
[TpsdkServer] Failed to load file: D:\SecureJTAG\0207_OTP\OTP\examples\Program_OTP\Project\SC589\Program_OTP_Core0\Debug\Program_OTP_Core0 [Error: Failed to connect to target., Code=0x80047344]

And also 
Loading application: "D:\Sharc\zpu_preload_Core0\Release\zpu_preload_Core0"
Load complete.
Loading application: "D:\SecureJTAG\0207_OTP\OTP\examples\Program_OTP\Project\SC589\Program_OTP_Core0\Debug\Program_OTP_Core0"
Error loading section ".text" to target.

and yet, using the same custom preload is fine when trying to load other applications into the ARM core (also built into DDR)

After looking at the output map file from the Program_OTP_Core0 ARM project, I realised it was trying to deploy to non-existent DDR memory (0xC.....) so switched to linking the Program_OTP_Core0 project with the LD file for our board and now the load completes but the A5 core is stuck at "Running : User Request" and if I try & halt it, I get 

Failed to remove automatic breakpoint. Error writing opcode at address: 0x8200d4b0.
Failed to remove automatic breakpoint. Error writing opcode at address: 0x8200a8dc.
Failed to remove automatic breakpoint. Error writing opcode at address: 0x82008536.
Failed to remove automatic breakpoint. Error writing opcode at address: 0x8200901e.

and the ICE-1000 takes a good 30 seconds or so to disconnect & go green after stopping cces.

The ARM memory is quite constricted in our map file so not sure if it's trying to allocate a large heap or something ?

/* #### ARM L3 Memory ################################################## */

/* ARM CORE 0 L3, DMC0 */
MEM_L3 : ORIGIN = 0x82000000, LENGTH = 12M
MEM_L3_UNCACHED : ORIGIN = 0x82C00000, LENGTH = 4M

I tried adding the Heap and Stack add in and limited all the heap & stacks to 4KB but it still does the same.

ok, I got a bit further by adding in our version of apt-sc589.c which makes the above DDR regions useable ...

Loading application: "D:\Neural\SecureJTAG\0207_OTP\OTP\examples\Program_OTP\Project\SC589\Program_OTP_Core0\Debug\Program_OTP_Core0"
Load complete.
Programming auth key:
Qx: 0e 6d 81 c4 ed ba 49 85 2a 9f 0f 3f 74 06 be aa 90 6b 78 52 02 5e b2 64 9d ef c0 c7
Qy: 81 11 33 ca 87 ed 11 33 29 b8 76 10 29 10 f0 3f ce a7 32 23 57 0b ba a1 ba 2b c0 03

A non-recoverable error or exception has occurred.
Description: Data Fault Exception - caused by attempting to access invalid data memory.
General Type: RunTimeError
Specific Type: ExceptAbrtData
Error Message: If this is a synchronous fault, address 0x240002c0 held in Data Fault Address Register (DFAR) is the problem address.
Error PC: 0x00003bc0

That seems to occur somewhere in the call to adi_rom_otp_pgm

OK, I got a bit further still by adding the region definition for the OTP to the apt file which I guess answers my question about where it gets memory mapped..

{ 0x24000000u, 0x24001FFFu, ADI_MMU_RW_DEVICE           }, /* 8KB OTP space */

I found that in C:\Analog Devices\CrossCore Embedded Studio 2.11.1\ARM\arm-none-eabi\arm-none-eabi\lib\src\cortex-a5\crt\apt-sc589.c

Now it no longer generates an exception, but gets me back to the original issue

Programming auth key:
Qx: 0e 6d 81 c4 ed ba 49 85 2a 9f 0f 3f 74 06 be aa 90 6b 78 52 02 5e b2 64 9d ef c0 c7
Qy: 81 11 33 ca 87 ed 11 33 29 b8 76 10 29 10 f0 3f ce a7 32 23 57 0b ba a1 ba 2b c0 03

failed to program authentication key. If you can email me, I can provide the project I'm using now.

Hi Rob,

Could you please confirm whether you are still receiving the 0 values in Reading auth key or  getting random values.
Also, Could you please share us the project to "processor.support@analog.com" email address.

Regards,
Divya.P

I let the app continue (in order to print out the auth key) and noticed that it was already programmed, but not with the same key.  I assume this must have happened when I was initially using a different key. 

I then added additional key printouts to main() and found that the emulation key was also already programmed but the encryption key was not as I'd never run setupBlx(). I then tried commenting out program_authentication_key and lock_part in setupBlx in order to test programming the encryption key and my output went from.. 

Programming JTAG key: d4 00 bd 01 75 00 49 00 d5 01 8b 01 bc 01 cb 00

failed to program the emulation key

Reading  auth key:

       Qx: fd 97 ff bf be 45 f6 7a fd 60 f4 c1 ef f9 db 55 7f f6 ef ef ff e1 6d ff 6b 7e 67 20

       Qy: 20 61 75 74 68 20 6b 65 79 3a 0a 00 09 51 78 3a 20 00 00 00 25 30 32 78 20 00 00 00

Reading  emu key:

       : 3f ff 56 fe ee ff b6 ff 3f ff 7e ff ef ff bd ff

Reading  encryption key:

       : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

to (after enabling the encryption key programming) 

failed to program encryption key

Reading  auth key:

       Qx: 03 68 00 00 49 ba 08 85 02 9b 0b 3e 11 06 2c aa 80 09 10 10 00 0e 92 00 94 a1 67 20

       Qy: 20 61 75 74 68 20 6b 65 79 3a 0a 00 09 51 78 3a 20 00 00 00 25 30 32 78 20 00 00 00

Reading  emu key:

       : c0 04 a9 05 19 00 49 00 c2 00 81 04 30 00 62 00

Reading  encryption key:

       : e5 01 9c 01 41 01 1c 01 50 01 2d 00 99 00 bb 00

So, that suggests to me that although the call to adi_rom_otp_pgm failed, hence the "Failed to program... " message, it DID appear to actually write the encryption key - would you agree ? If so, I'll modify the code to ignore the return value and continue then try on a fresh board.

I'm not sure why the auth & emu keys changed though, I was consistently reading the fd 97 ff bf key before programming the encryption key. 

I've started fresh with a new board and have 

 - generated a new unique set of keys

 - adapted LedBlink for our board & verified it runs ok when launched through CCES

 - programmed BLw loader image to SPI2 flash

I'm trying to verify the operation now using the SecureBoot_OpenPart example project as described in the EE note. I'm using the same adsp-sc589_L2.ld file for both blink & openPart projects. When I launch the app in cces, with or without a preload, I can see that the ConfigureForSecureBoot function gets called twice, but after configuring the SPI for memory mapped operation and I let the app run (and hopefully start seeing an LED blinking), nothing happens.

If I halt the ARM core, I can see it's stuck somewhere in the bootloader at PC=0x11e4 with regs

CPSR 6000013F
LR 000011DB
PC 000011E4
R0 00000100
R1 3108B064
R2 78F4646D
R3 310CD000
R4 00000100
R5 200AADF8
R6 200B0825
R7 0000002A
R8 200B0825
R9 14A4000C
R10 200A3000
R11 00000000
R12 53FAB83D
SP 200AACD8

Any ideas what could be going wrong ? 

I got a bit further : I found that the ld file I was using had an error due to overlapping region definitions.

I added, to the linker commands..

-Tadsp-sc589.ld

-Tadsp-sc58x-common-l2.ld

I enabled the heap & stack add-in and limited the heap size to 4KB in order to get the image to fit in L2. 

I can now successfully boot the secure BLp and BLx images created by the LedBlink project (with the appropriate configureBXX function enabled in ConfigureForSecureBoot ) but not the BLw image - which ends up in a similar error condition : 

CPSR 6000013F
LR 000011DB
PC 000011E4
R0 00000100
R1 3108B064
R2 78F4646D
R3 310CD000
R4 00000100
R5 20087FF8
R6 20088F25
R7 0000002A
R8 20088F25
R9 AD4E2053
R10 20080200
R11 00000000
R12 0CBD8ADE
SP 20087ED8

There was a similar report in this thread which was resolved, but it's not clear how ?

 RE: Secure Booting - Using Secure Boot_Open Part Directory 

Mem window showing address of pBootConfig after a failed BLw boot...

Compared with examining that block of memory after a good BLx boot..

Looks like the header has been parsed but it didn't go any further, presumably it failed to decrypt the wrapped key ??

Hi Rob,

We understand that this issue is already handled through private support. To avoid duplication of efforts, you can continue the discussions through private support and final resolution here if appropriate.

Regards,
Divya.P

Hi Divya, yes thanks : tools support were able to provide a fix for the BLw images which I'll post here for anyone else having trouble.. 

Use aesKey parameter instead of using aesWrapKey under configureBlw() in SecureBoot_OpenPart.c 
from 

"uint8_t * aesWrap  = (uint8_t *)&pBootConfig->aesWrapKey;" 
to
"uint8_t * aes  = (uint8_t *)&pBootConfig->aesKey;" 

whole function for reference 

void configureBlw(ADI_ROM_BOOT_CONFIG* pBootConfig) {

uint8_t * pKey = (uint8_t *)&pBootConfig->publicKey;
uint8_t * aes = (uint8_t *)&pBootConfig->aesKey;
uint8_t i;

for(i=0; i<56; i++) {
pKey[i] = secure_boot_public_key[i];
}

for(i=0; i<16; i++) {
aes[i] = wrapper_key[i];
}
}