Post Go back to editing

Secure boot through SPI2 slave

Category: Hardware
Product Number: ADSP-BF704

Hello,

I am trying to test secure boot through SPI2 slave. I am using the (modifief) code frome the SecureBoot_Open example project.

If I use an empty hook function I can bootload unsigned ldr files.

 uint32_t spimBootCommand = 0x212; //(Spi, use SPI2, slave mode)
 adi_rom_Boot(0,BITM_ROM_BFLAG_HOOK,0,&ConfigureForSecureBoot,spimBootCommand);

For secure boot I use the hook function:

int32_t ConfigureForSecureBoot (ADI_ROM_BOOT_CONFIG * pBootConfig, ROM_HOOK_CALL_CAUSE cause)
{
  if (cause == ROM_HOOK_CALL_INIT_COMPLETE)
  {
    //return 0; //test: normal boot
    /* executed after kernel has completed boot peripheral initialization */
    /* 1. Set the boot type to secure */
    pBootConfig->bootType = ADI_ROM_SECURE_BOOT;
    /* 2. Set they key type to custom ( this disables reading the key from OTP ) */
    pBootConfig->keyType = ADI_ROM_CUSTOM_SECURITY;
    // 3. load the key to be used, this is the key that would normally be read from OTP
    //configureBlx (pBootConfig);
    configureBlp (pBootConfig);
  }
  else
  {
    /* executed after the initial boot kernel configuration is completed */
   //nothing to do
  }
  return 0;
}

The keys are set accordingly.

In secure boot setup, after writing 1024 bytes to the SPI from host, the SPI does not accept any more data and the when checking the bf704 with the debugger it seems to have entered the ROM error handler:

040026ba:   NOP;
040026bc:   R0=0x59(X);
040026c0:   [0x20004008]=R0;
040026c8:   R0=-0x2152bc00;
040026d0:   [0x20040428]=R0;
040026d8:   IDLE;
040026da:   JUMP.S -0x2;   <- PC points here

So what's possibly going wrong? Are there any errorcodes stored somewhere?

I have tried BLp and BLx files (and matching hook function settings) but makes no difference. 

Parents
  • The address stored in ADI_ROM_BOOT_CONFIG.errorReturn is 0x04002ed4

  • Hi Julian,

    Could you please confirm whether you have sent extra dummy bytes from the host, as it always sends data in multiples of 1024 bytes. This requirement is due to the sizing of internal buffers used for DMA.

    Also, please confirm whether SPI_RDY is properly connected between the MCU and the target board.

    Please share your modified SecureBoot_Open example along with the steps you followed to test the secure SPI slave boot?

    Regards,
    Nandini C

  • The host sends a 0x3 as required to set the SPI mode (single data line SPI) followed by the (signed) loader file. SPI_RDY signal is monitored and obayed.
    I would expect the sign tool to provide a loader file of correct length and padding for downloading?! Or do I have to modify/partition/pad the file in some way before sending?

    The booting process does not get to the end of the loading process but enteres the error handler after 1272 byte have been sent out (i.e. the RDY line blocks the host permanently).
    Attached are the project and the BLp file sent to the BF704.

    SecureBoot_OpenPart.zipldr-file.zip

  • Hi Julian,

    Please note that sending 1024-byte blocks is mandatory due to DMA buffer alignment requirements in the boot ROM. If the LDR file size is not a multiple of 1024 bytes, the last block must be padded with zeros. The sign tool does not provide zero padding for the loader, so please add it manually and check whether the issue persists.

    Please confirm whether the pull-up resistor is connected on the SPIx_RDY as mentioned in the HRM (Page 1896/2223). Also, please let us know the silicon revision of your processor.

    Regards,
    Nandini C

  • Hi Nandini,

    the pullup in SPI_RDY is present and the handshake works as intended.

    Regarding the LDR file it is not clear how and where padding has to done:

    Does the secure boot header need to be in a separate 1024 byte block i.e. with padding between the secure header and the start of the code blocks? Must the normal blocks not be greater than 1024 byte i.e. the -MaxBlockSize switch has to be used and if yes, what is the max bock size value to be used as the header also takes space.

    Simply padding the LDR file at the end does not help as the boot process already failes after 1272 bytes.

    I already tried:
    - adding zeros after the secure header to form a 1024 byte block
    - use -MaxBlockSize 1024 and -MaxBlockSize 1008

    All to no avail.

    Could you please provide a valid ldr file example for secure SPI slave boot or an example project or settings to generate a valid secure SPI slave boot stream/file file, e.g. of the LedBlink project?

    Is the BF70x boot rom source code available? This could help debugging the boot process.

  • Hi Julian,
    Unfortunately, we don’t have a Secure Open-Part example for secure SPI slave booting. We are working on this and will get back to you as soon as possible.
    Regards,
    Nandini C
  • Hi Julian,
    Apologies for the delay.
    Please find the attached secured LDR and secure open part example for ADSP-SC584. Please use this as a reference and modify for ADSP-BF707.
    Please ensure that the LDR is generated in binary format and does not include any INIT code. Also, please pad an extra 1024 dummy bytes at the end of the secure bootstream to ensure that the host is able to send all the bytes of an application to the Slave boot processor.
    Regards,
    Nandini C
  • Hi Nandini,
    I looked into the example. The only difference I found compared to my code is the SPU programming. I adapted that for BF7xx in main():
     *pREG_SPU0_SECUREP22 = 0x3; //SPI2
     *pREG_SPU0_SECUREP43 = 0x3; //SPI2 DMA8
     *pREG_SPU0_SECUREP44 = 0x3; //SPI2 DMA9

    However, it makes no difference.

    I also tried to load the sc584_led_BLP_1024.dat (altough it will not run on a BF70x) but that also failes at the same position in the bootstream. I compared this file to my files and all files looks all right (headers, length settings, etc)
    The BF704 always only loads between 1200 and 1300 bytes and then stalls the SPI (permanently blocks the host by SPI_RDY).

    regards,

    Julian

  • Hi Julian,

    We are checking on this and will get back to you as soon as possible.

    Regards,
    Nandini C

  • Hi Julian,

    We are checking with our internal team and will get back to you as soon as possible.

    Regards,
    Nandini C

Reply Children