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.
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
- 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.
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
SRST support should be added soon.
If throughput is important, queuing system should be considered (currently, it's simple request and response).
2016-03-26 Initial release (Version 0.01).
Hardware-wise, it's simple enough. We just connect three (up to five) lines from BBG to target board, namely SWD-CLK, SWD-DIO, and GND (additionally, 3.3V if we source power from BBG to target board, and SRST for optional reset control).
Software-wise, it was a challenge. The chip on BBG has PRUSS, the programmable real-time subsystem, which is best for such a purpose of accurate bit-banging. But, it is hard to use this subsystem.
I select "Super-Hard" for this project as the skill level for development of this project. For development, it requires knowledge of PRUSS, SWD, and OpenOCD. However, for use only (no development of the tool itslef), it will is just easy as other JTAG/SWD programmer. "Two hours to complete" means that the first experiment will consume two hours or so, to try this project (setup of hardware, git clone of the project, build an try).
I assume a user already has a BBG with Debian.
Version 0.01 2016-03-26 Niibe Yutaka Flying Stone Technology
BeagleBoneGreen SWD (BBG-SWD) is a tool to control SWD protocol by BeagleBoneGreen.
The program on PRUSS (Programmable Realtime Unit SubSytem), PRU-SWD, is complete. The BBG-SWD driver for OpenOCD is by a patch:
The BBG-SWD driver is ready for use. To see how it works in detail , please see the debug log of OpenOCD:
The reset pin control by SRST is not yet implemented, as FST-01 doesn't have the pin. It's easy to implement.
It gives (back) us the control for our computing (freedom), again.
Pins for SWD access
- SWD-DIO P8_11
- SWD-CLK P8_12
- SRST P8_15
# echo gpio >/sys/devices/platform/ocp/ocp:P8_11_pinmux/state # echo gpio >/sys/devices/platform/ocp/ocp:P8_12_pinmux/state # echo gpio_pu >/sys/devices/platform/ocp/ocp:P8_15_pinmux/state
It takes advantage of using PRUSS (Programmable Realtime Unit SubSytem) on the processor, so that the SWD communication could be reliable, accurate and fast. It assumes use of PRUSSDRV user space library with UIO user space PRUSS driver. I use "bone-kernel" for that.
The program pru-swd.p is distributed under GPLv3+. The OpenOCD patch is under GPLv2+.
The patch is:
You can configure BBG-SWD driver by the
--enable-bbg-swd option. ./configure --enable-bbg-swd
You can use it with a configuration like:
-------------------------- File: bbg-swd.cfg interface bbg-swd transport select swd
The invacatio of command is something like this:
$ openocd -f bbg-swd.cfg -f target/stm32f1x.cfg
The above is the case for FST-01.
Request: 1-byte: CMD arg... Response: value...
Last three bits are valid for CMD.
HALT 0 BLINK 1 GPIO_OUT 2 GPIO_IN 3 SIG_IDLE 4 SIG_GEN 5 READ_REG 6 WRITE_REG 7 HALT(): none BLINK(delay, counts, led-bit): none - SIG_IDLE(count): none submit idle(=LOW) for COUNT cycles, strobing SWD-CLK SIG_GEN(bit-len, data...): none submit signal pattern to SWD-DIO, strobing SWD-CLK READ_REG(cmd): parity-and-ack, value execute SWD read register transaction WRITE_REG(cmd,value): ack execute SWD write register transaction GPIO_OUT(bit, value): none control GPIO signal directly, output GPIO_IN(): value control GPIO signal directly, input