Categories: Electronics and Programming, Expert, General Purpose, SeeedStudio BeagleBone Green
Originally, I submit the entry of
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
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.
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?
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
- 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.
(0) BBG with Debian
Kernel should be bone-kernel (not ti) to use uio_pruss module.
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
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
SRST support should be added soon.
If throughput is important, queuing system should be considered (currently, it’s simple request and response).
Comments are not currently available for this post.