Implement support for programming OpenTitan using SAM3U on CW305

[alphan]

This PR implements support for programming OpenTitan over the SPI interface of SAM3U on CW305 and includes the following commits:

• [objs] Update bitstream to remove dependencies for programming
• [objs] Update aes_serial binary
• Add pycryptodome to python dependencies
• Remove trace filtering based on min value
• Remove unused constant
• Implement support for programming OpenTitan using SAM3U on CW305

It would be great if you could checkout this PR and let me know if you run into any issues. I left the current spiflash based programmer intact just in case. I can remove it if the new implementation is reliable enough.

Closes #15.

[alphan]

Just to be clear, we don't really need these but I thought they were nice to have.

[moidx]

LGTM. @alphan very cool!

[alphan]

Implemented @moidx's comments, dropped "Remove trace filtering based on min value" commit since it's already addressed by @vogelpi in #22.

[alphan]

Minor output message updates, rebased to master.

[vogelpi]

Hi @alphan,
thanks a lot for working on this.

I just tried out this PR on my setup but it does not work:

./simple_capture_traces.py -n 1000 -p 100 
Connecting and loading FPGA
Initializing PLL1
Traceback (most recent call last):
  File "./simple_capture_traces.py", line 130, in <module>
    ot = initialize_capture(cfg_file['device'], cfg_file['spiflash'])
  File "./simple_capture_traces.py", line 31, in initialize_capture
    ot = device.OpenTitan(
  File "/home/pirmin/ot/ot-sca/cw/cw305/util/device.py", line 16, in __init__
    self.target = self.initialize_target(self.scope, fw_programmer, baudrate)
  File "/home/pirmin/ot/ot-sca/cw/cw305/util/device.py", line 62, in initialize_target
    fw_programmer.run(self.fpga)
  File "/home/pirmin/ot/ot-sca/cw/cw305/util/spiflash.py", line 205, in run
    with _Bootstrap(fpga) as bootstrap:
  File "/home/pirmin/ot/ot-sca/cw/cw305/util/spiflash.py", line 139, in __init__
    self._fpga_io = fpga.gpio_mode()
  File "/home/pirmin/ot/ot-sca/src/chipwhisperer/software/chipwhisperer/common/utils/util.py", line 453, in func_wrapper
    raise IOError(f"This function requires newer firmware: ({major}.{minor}) vs ({fw_ver['major']}.{fw_ver['minor']})")
OSError: This function requires newer firmware: (0.40) vs (0.32)

Obviously, this indicates I am using the wrong firmware. However I already updated the firmware for the CW305 and it still does not work. Do I need to download a special image from somewhere? If yes, this should probably be documented as well.

[moidx]

Ran into the same issue. I am going to try to update the cw305 fw one more time.

This is the commit that @alphan posted on slack a while ago. Adding here for cross-reference:

newaetech/chipwhisperer@91a9124

[moidx]

The firmware from the commit referenced above works for me. I already got rid of my FTDI cable!

[vogelpi]

Thanks @moidx for posting the commit, it's working for me as well now!

For your information, the firmware blob is no longer on the develop branch of chipwhisperer. Until it can be obtained using the regular firmware update procedure, the following steps are needed:

1. In the ot-sca root folder, go to src/chipwhisperer and run git checkout 91a9124. This will give you Colin's commit with the patched firmware.
2. Run the firmware update:

python3
import chipwhisperer as cw
scope = cw.scope()
target = cw.target(None, cw.targets.CW305)
programmer = cw.SAMFWLoader(scope=target)
programmer.enter_bootloader(really_enter=True)

Unplug and then plug the CW305 into your computer again, then continue the update process:

python3
import chipwhisperer as cw
programmer = cw.SAMFWLoader(scope=None)
programmer.program('/dev/ttyACM0', 'hardware/victims/cw305_artixtarget/fw/sam3u/CW305_SAM3U_FW/build/CW305_SAM3UFW.bin')

Wait for the programming to finish, then unplug and plug the hardware again.
3. Do a git checkout 9819f42. This will give you the commit with the required patch to run the capture on the CW305.

I think it wouldn't hurt to put this information in the getting started guide. Just to avoid that someone spends a lot of time figuring out why things aren't working out of the box at the moment. WDYT @alphan ?

[vogelpi]

This looks very good, thanks @alphan !

I would like to see two things:

1. An update to the getting started guide to reflect those changes and explain how the firmware upgrade has to be performed at the moment (see my previous comment).
2. Arranging the commits such that all of them are self-contained, alternatively you can squash everything into one commit upon merge.

[alphan]

For your information, the firmware blob is no longer on the develop branch of chipwhisperer. Until it can be obtained using the regular firmware update procedure, the following steps are needed:

Apologies for missing your message yesterday (skipped inbox because this thread was tagged as todo). It was there when I created this PR but it looks like it was accidentally removed in this commit. There is also another small change that I requested earlier. I'll reach out to CW folks.

I think it wouldn't hurt to put this information in the getting started guide. Just to avoid that someone spends a lot of time figuring out why things aren't working out of the box at the moment.

Assuming that this will get fixed pretty soon, I think we can skip this step but it's probably a good idea to add a note with a link to this guide.

[alphan]

This looks very good, thanks @alphan !

I would like to see two things:

1. An update to the getting started guide to reflect those changes and explain how the firmware upgrade has to be performed at the moment (see my previous comment).

Definitely, I didn't include the update in this PR since I wasn't sure what the decision would be (keep or remove current spiflash method). Since we reached a consensus there I'll create a new PR that removes spiflash related code and update the getting started guide.

2. Arranging the commits such that all of them are self-contained, alternatively you can squash everything into one commit upon merge.

I tried to split code and other changes just in case we need to revert them one-by-one but I agree that the bitstream and aes_serial binary update can and should go together. I will merge those two. I hope this makes sense.