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

Reply
  • 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

Children