BBG-SWD

Originally, I submit the entry of

https://www.hackster.io/gniibe/bbg-swd-93bcea

But I had a trouble to submit the entry above as my submission to the contest.

Thus, I cut&paste things from the original project to make this new entry.

BeagleBoneGreen SWD – a practical tool for computing freedom

http://git.gniibe.org/gitweb/?p=bbg-swd.git;a=summary

Benefit

It’s all-in-one SWD programmer. You can just login to the system and invoke OpenOCD. No installation of any proprietary software on to your PC is required. The implementation is done by Free Software only.

Usefulness

Any applications for "THING"s require programming some sort of generation of signals, PWM, serial communications, whatever. And any devices (with flash) are required to be flashed.

BBG-SWD is a concrete example to control signal accurately, so, it can be a good start point to learn use of PRUSS controlling signal. Having trustworthy technology for flashing helps everyone.

The Problem to Solve

I design FST-01, the USB 32-bit "computer" with STM32F103, so that I can use it for my crypto computation securely (OpenPGP, SSH, etc.). To flash this board, I used ST-Link/V2 or its compatible. But, here is the problem. Am I sure flashing the binary reliably?

How can we reliably flash our boards securely?

Motivation

In modern crypto, we have strong enough algorithms and implementations. The problems tend to be in the platform which runs those crypto computations and environment/process which enables such a computation. That’s my viewpoint, and I develop my own solution, named Gnuk Token. For Gnuk Token, I design FST-01.

Then, I encounter the problem above. Before BBG-SWD, I have no concrete way to ask manufacturer how to flash FST-01 reliably.

I wanted to fix missing link and/or possible weakest link to achieve best practical crypto computation.

Writing process of firmware would be a missing link in freedom of user computing

Writing process of firmware for "secure device" would be possible weakest link

How to Fix the Problem

By BBG as all-in-one tool

By using PRUSS to do the Right Thing

Comparison

• ST-Link/V2 with software tool on PC

Firmware in ST-Link/V2 would be weakest link, nobody except vendor can check the correctness. Proprietary tool would be also weak against attacks.

• Bus Pirate with software tool on PC

Even if software tool could be Free Software, Operating System would be weakest link.

• Bus Pirate with BBG

This is the best practice (until BBG-SWD).

• BBG alone, directly connected to the target board, that’s BBG-SWD

This is ultimate solution.

HOWTO

(0) BBG with Debian

Kernel should be bone-kernel (not ti) to use uio_pruss module.

https://github.com/beagleboard/am335x_pru_package
must be already in your system.

(1) Clone BBG-SWD repository

Get it and build PRU-SWD binary with pasm. The instruction is in the source code (pru-swd.p).

(2) Clone OpenOCD repository
http://repo.or.cz/w/openocd.git

Get it and apply a patch in BBG-SWD. Build with configure option of –enable-bbg-swd.

(3) Connect your target board to BBG

See following for pins.

(4) Enjoy OpenOCD with BBG-SWD driver

Future Works

SRST support should be added soon.

If throughput is important, queuing system should be considered (currently, it’s simple request and response).