BBG-SWD

Make our BBG into SWD programmer by its powerful PRUSS (Programmable Reaitime Unit SubSystem), in order to control our bits.

Categories: Expert

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

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.

HOW TO

  • (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).

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).

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

BeagleBoneGreen SWD (BBG-SWD) is a tool to control SWD protocol by BeagleBoneGreen.

Note for Initial Release

The program on PRUSS (Programmable Realtime Unit SubSytem), PRU-SWD, is complete. The BBG-SWD driver for OpenOCD is by a patch:

	0001-initial-patch-for-BBG-SWD.patch

The BBG-SWD driver is ready for use. To see how it works in detail , please see the debug log of OpenOCD:

	flash-write-with-bbg-swd-20160326.log

Future Works

The reset pin control by SRST is not yet implemented, as FST-01 doesn’t have the pin. It’s easy to implement.

The purpose

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

Pinmux Configuration

   # 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

The methodology

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.

Software License

The program pru-swd.p is distributed under GPLv3+. The OpenOCD patch is under GPLv2+.

Patch for OpenOCD

The patch is: 

	0001-initial-patch-for-BBG-SWD.patch

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-Response

FORMAT:

 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

Enjoy!

Comments are not currently available for this post.