Secure boot using AES module not working

If you have a simple question and just want an answer.
simonf
Member++
Posts: 16
Joined: Wed Nov 23, 2016 10:18 pm

Post by simonf »

Hi Colin,

Got it, thanks for the explanation!

Just as a quick side note, with the changed XN file for C22 (increased delay) our reboot code doesn't work anymore - no idea why, but also not too important as long as we can use our old XN with the new tools release.

Code: Select all

void reboot_device(void)
{
    unsigned int pllVal;
    unsigned int localTileId = get_local_tile_id();
    unsigned int tileId;
    unsigned int tileArrayLength;

    #ifdef DEBUG
    printstrln("Reboot...");
    #endif

    asm volatile ("ldc %0, tile.globound":"=r"(tileArrayLength));

    /* Check if reboot is called on tile 0 (tile connected to flash), otherwise throw error! */
    //assert(get_local_tile_id() == get_tile_id(tile[0]) && msg("Function can only be called on tile[0] (tile connected to SPI flash)!"));

    /* Reset all remote tiles in reverse order to ensure links to second chip
     * on dual chip boards isn't killed before second chip is rebooted
     */
    for(int i = tileArrayLength - 1; i >= 0; i--)
    {
        // Cannot cast tileref to unsigned
        tileId = get_tile_id(tile[i]);

        // Do not reboot local tile yet
        if (localTileId != tileId)
        {
            read_sswitch_reg(tileId, 6, pllVal);
            pllVal &= PLL_MASK;
            write_sswitch_reg_no_ack(tileId, 6, pllVal);
        }
    }

    // Finally reboot this tile
    read_sswitch_reg(localTileId, 6, pllVal);
    pllVal &= PLL_MASK;
    write_sswitch_reg_no_ack(localTileId, 6, pllVal);
}
Best,
Simon


simonf
Member++
Posts: 16
Joined: Wed Nov 23, 2016 10:18 pm

Post by simonf »

Hi Colin,

Great news, with the RC of the new tools both boards boot with no required changes to the XN! Thank you!

I still need to erase in order to flash new binaries, but I guess this is expected behavior, right?

Code: Select all

xrun: First stage multi-node boot failed, please check XN file and Xmos link connectivity

Thanks!
Simon
colin
Experienced Member
Posts: 74
Joined: Mon Dec 16, 2013 12:14 pm

Post by colin »

Hi Simon

Great news, glad to hear it is all sorted. Yes it is expected behaviour to erase the flash before re-programming it, this is due to a conflict for channel resources when booting from the OTP.

There are a couple of additional unrelated fixes that have been added to the 14.2.4 candidate that are currently being tested, we hope to publish the official release very soon.

Best Wishes,
Colin
simonf
Member++
Posts: 16
Joined: Wed Nov 23, 2016 10:18 pm

Post by simonf »

Hi Colin,

Looks like we are not completely done. When locking the device with --disable-jtag I get the same error message:

Code: Select all

This action will write to OTP. Once written the data cannot be modified.
Do you wish to continue (y/n)? y
Locking device...
xrun: First stage multi-node boot failed, please check XN file and Xmos link connectivity

xburn: error: unexpected error locking device
Unfortunately, I can't erase before locking... ;-)

Thanks,
Simon
colin
Experienced Member
Posts: 74
Joined: Mon Dec 16, 2013 12:14 pm

Post by colin »

Hi Simon,

This is a known limitation with the XS1. It should only affect your development parts where you leave the jtag enabled to test and verify AES boot is working.

In a production environment, you would normally program your flash part first, then burn your OTP disabling JTAG and locking the OTP in the first go. In some cases the flash part is programmed by an external programmer before it is fitted to the board.

Best Wishes
Colin
simonf
Member++
Posts: 16
Joined: Wed Nov 23, 2016 10:18 pm

Post by simonf »

Hi Colin,

Thanks for clarifying.

Best,
Simon