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

Secure boot using AES module not working

Postby simonf » Wed Nov 23, 2016 10:26 pm

Hi guys,

I'm currently trying to follow your application note "Safeguard IP and device authenticity (X6225B)". Unfortunately, I'm not able to get our board to boot after writing the AES-Module and keys to OTP.

The keyfile is generated with the command:
xburn --genkey keyfile.

I wrote the keys to OTP using:
xburn --id 0 --lock <keyfile> --target-file <target> --enable-jtag --disable-master-lock

The image, which is simply blinking an LED and was tested before encrypting the device is flashed with:
xflash --id 0 <xe-file> --key <keyfile>

Somehow the device doesn't seem to boot after the AES module is burned, neither with the encrypted nor with an unencrypted image. What are we doing wrong here?

Tools version used: 14.2.1
Device used: L16


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

Postby colin » Thu Nov 24, 2016 10:06 am

Hi SimonF,

You don't appear to have done anything wrong in terms of the commands used. Presumably xburn indicated that the device was programmed successfully? The first step is to verify this.

1) You can use xburn to dump out what is going to be written to the OTP. Use the same command you used to burn the otp but add the option --dump-xc <file.xc>. i.e. xburn --id 0 --lock <keyfile> --target-file <target> --enable-jtag --disable-master-lock --dump-xc <file.xc>

2) You can then use xburn to read back the contents of the OTP you have already burned i.e. xburn --read <otp.txt> --target <target>.

3) Now you can compare the memory structures found in file.xc with the contents of the OTP in otp.txt. Hopefully the contents of otp.txt is complete and accurate. Note that if xburn used differential mode then each word in otp.txt will be doubled up (excluding the bootloader that changes the L16 from single ended to differential modes). Also note if xburn used software repair then you will find some additional rows at the end of the OTP structures in otp.txt. What you don't want to find is missing rows or rows that are very different to what you expect.

If everything checks out then we can try and work out why it won't boot.

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

Postby simonf » Thu Nov 24, 2016 2:01 pm

Hi Colin,

PFA the two dumps. To me, everything looks good - even though it's kind of hard to compare the two.

Best,
Simon
You do not have the required permissions to view the files attached to this post.
colin
Experienced Member
Posts: 74
Joined: Mon Dec 16, 2013 12:14 pm

Postby colin » Thu Nov 24, 2016 5:50 pm

Hi Simon,

Yes, the OTP dump does look as though it is correct. Can you please do an xrun --dump-state so we can try and work out where in the boot process things are failing.

Many Thanks
Colin.
simonf
Member++
Posts: 16
Joined: Wed Nov 23, 2016 10:18 pm

Postby simonf » Fri Nov 25, 2016 12:13 pm

Hi Colin,

I attached the dump.

Thanks,
Simon
You do not have the required permissions to view the files attached to this post.
colin
Experienced Member
Posts: 74
Joined: Mon Dec 16, 2013 12:14 pm

Postby colin » Fri Nov 25, 2016 4:14 pm

Hi Simon,

Node 0 does appear to be well on it's way through the boot process, having booted from OTP and loaded the second stage bootloader from SPI. The little block of disassembly suggests node 0 is attempting to write to the SSwitch in the network setup code that would have been extracted from the boot image selected by the second stage bootloader. I'm not sure why it is stuck here! Have you got a copy of xlreg still? If you could use that to get a view of the current network status then I can use that to try and determine why it is stuck here. It might be useful to also post your XN file.

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

Postby simonf » Fri Nov 25, 2016 4:23 pm

Hi Colin,

XLREG output + XE + XN file attached.

Best,
Simon
You do not have the required permissions to view the files attached to this post.
colin
Experienced Member
Posts: 74
Joined: Mon Dec 16, 2013 12:14 pm

Postby colin » Fri Nov 25, 2016 4:48 pm

Thanks Simon,

Have you tried slowing the link speeds down for the 4 internal links? If not i'd suggest slowing these down to say Delays="4clk" to see if this gets your device to boot. At the minute xlreg looks good other than there does not appear to be any credits to send or receive across these internal links.

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

Postby simonf » Fri Nov 25, 2016 4:55 pm

Hi Colin,

I changed to this:

Code: Select all

    <Links>
        <Link Encoding="5wire" Delays="4clk">
            <LinkEndpoint NodeId="0" Link="XLG" />
            <LinkEndpoint NodeId="1" Link="XLF" />
        </Link>
        <Link Encoding="5wire" Delays="4clk">
            <LinkEndpoint NodeId="0" Link="XLH" />
            <LinkEndpoint NodeId="1" Link="XLE" />
        </Link>
        <Link Encoding="5wire" Delays="4clk">
            <LinkEndpoint NodeId="0" Link="XLE" />
            <LinkEndpoint NodeId="1" Link="XLH" />
        </Link>
        <Link Encoding="5wire" Delays="4clk">
            <LinkEndpoint NodeId="0" Link="XLF" />
            <LinkEndpoint NodeId="1" Link="XLG" />
        </Link>
        <Link Encoding="2wire" Delays="4,4" Flags="XSCOPE">
            <LinkEndpoint NodeId="0" Link="X0LA" />
            <LinkEndpoint NodeId="2" Chanend="1" />
        </Link>
    </Links>

Result when trying to just run the program with xtimecomposer:
xrun: First stage multi-node boot failed, please check XN file and Xmos link connectivity
colin
Experienced Member
Posts: 74
Joined: Mon Dec 16, 2013 12:14 pm

Postby colin » Fri Nov 25, 2016 5:13 pm

You will need to erase the contents of flash first using the xflash --erase-all command before you can xrun.

Colin

Who is online

Users browsing this forum: No registered users and 5 guests