Bryan Hinton

Sunday, September 2, 2018

96Boards - JTAG and serial UART configuration for ARM powered, single-board computers

The 96boards CE specification calls for an optional JTAG connection. The specification also indicates that the optional JTAG connection shall use a 10 pin through hole, .05" (1.27mm) pitch JTAG connector. The part is readily available on most electronics sites. Breaking out the pins with long wires and shrink wrapping them is ideal for making sure that each connection is labeled and separate when connecting to a JTAG debugger. While a JTAG connection is not required for flashing or loading the bootloaders onto the board, the JTAG connection can come in handy for more advanced chip-level debugging. The serial UART connection is sufficient for loading release or debug versions of bl0, bl1, bl2, bl31, bl32, the kernel, and userspace stack. Last but not least, ARM-powered SBC boards from 96boards, with 12V power supply levels will definitely require one or more fans to keep the board cool. As seen in the below photos, two 5V fans were powered from an external power supply. Any work on microcontroller boards should be performed on a grounded surface, with grounded wrist straps.

In the below photos, a 96Boards SBC is mounted on an IP65, ABS plastic junction box for durability. The pogo pins were extended and mounted with screws underneath the junction box. The electrical conduit holes on the side of the junction box are ideal for holding small, project fans. The remaining electrical conduit holes provide a clean place to nestle the remaining wires from the board - micro USB, USB-C, and 12V power. Non industrial tested boards, such as the boards offered from 96Boards are very sensitive. They are not designed to handle the wear and tear that an industrial tested board is able to handle. Furthermore, they are very sensitive to static electricity.

Thursday, June 7, 2018

HiKey 960 Linux Bridged Firewall

The Kirin 960 SoC and on-board USB 3.0 make the HiKey 960 SBC an ideal platform for running a Linux Bridged firewall. The number of single-board computers with an SoC as powerful as the HiSilicon Kirin 960 are limited.

When compared with the Raspberry Pi series of single board computers (SBC), the HiKey 960 SBC is significantly more powerful. The Kirin 960 also stands above the ARM powered SoCs which reside in most commercial routers.

USB 3.0 makes the HiKey 960 board an especially attractive option for bridging or routing, filtering network traffic, or connecting to an external gateway via IPSec. Both network traffic filtering and IPSec tunneling can be computationally expensive operations. However; the multicore Kirin 960 is well suited for these types of tasks.

In order to be able to run an IPSec client tunnel and a Linux Bridged firewall connected over 1G ethernet links, certain kernel configuration modifications are needed. Furthermore, the Android Linux kernel for the HiKey 960 board does not boot on a standard Linux root filesystem because it is designed to boot an Android customized rootfs.

The latest googlesource Linux kernel (hikey-linaro-4.9) for Android (designed to boot Android on the HiKey 960 board) has been customized to remove the Android specific components so that the kernel boots on a standard Linux root filesystem, with the proper drivers enabled for network connectivity via attached 1000Mb/s USB 3.0 to ethernet adapters. The standard UART interface on the board should be used for serial connectivity and shell access. WiFi and Bluetooth have been removed from the kernel configuration. The kernel should be booted off of a microSDHC UHS-I card. The 96boards instructions should be followed for configuring the HiKey 960 board, setting the jumpers on the board, building and flashing the l-loader, firmware package, partition tables, UEFI loader, ARM Trusted Firmware, and optional Op-TEE. Links for the normal Linux kernel configuration, multi-interface bridge configuration, and single interface IPSec configuration are below. Additional kernel config modifications may be needed for certain types of applications.

HiKey 960 Linux kernel build instructions
Linux kernel source and custom kernel configuration
Multi-interface bridge configuration
Single interface IPSec configuration

Thursday, February 1, 2018

a Hardware Design for XOR gates using sequential logic in VHDL

VHDL is a powerful, hardware description language. The learning curve is steep and advanced hardware designs take many years of experience. As an advanced C and C++ programmer with embedded hardware experience, I decided to take on the task of learning VHDL. An FPGA board is typically needed if you intend to load your design onto a re-programmable piece of hardware. There are many choices, from simple to complex, and from cheap to very expensive.

A few years ago, a friend recommended that I purchase an FGPA board without a hybrid ARM core to start with, as working with an FPGA board is already complicated. Having worked with numerous ARM processors, I decided to instead purchase an FPGA board with a multicore ARM processor. Hybrid boards such as these integrate the FPGA fabric with an ARM processor, typically multicore, over a high speed bus. For such a configuration, the ARM processor is termed the hard processor system or HPS. Writing to the FPGA from the ARM processor is typically performed via C from an embedded Linux build (yocto or buildroot) running on the ARM core.


ModelSim Wave Output for the xor design

The following is a simple hardware design that I wrote and simulated in ModelSim. Given the frequency of XOR gates in cryptography, I decided to build a simple design using XOR gates. The sequential design is comprised of several XOR gates, XNOR'd together with a 50Mhz input clock. VHDL components are utilized and a testbench is defined for testing the design. The testbench for the design was loaded into ModelSim and the below image is the wave form simulation of the input signals, clock, and output signal.

The source code is available on github at the following link.
xorchain hardware design in VHDL

ModelSim Full Window view with wave form output of xor simulation. ModelSim-Intel FPGA Starter Edition © Intel

Sunday, February 12, 2017

Setting up a D-Star Access Point on Raspbian with PIXEL - Part II

This is part II of a two Part series. In part I, DStarRepeater and IRCDDBGateway were compiled and DstarRepeater was configured on Raspbian Jessie with PIXEL. In Part II, IRCDDBGateway will be configured,and an Icom ID-51a+ will connect to the D-Star network through the D-Star hotspot.

Elizabeth Tower at the North end of the Palace of Westminster in London

Requirements

Directions

Configure ircddbgateway

Execute ircddbgatewayconfig on the target (Raspberry Pi) as follows.

pi@hbox:~ $ sudo ircddbgatewayconfig &

Replace KF5SVQ with your call sign.

Make sure that you select Save from the File Menu in order to save your changed to the configuration file. Also make sure that you select Exit from the File menu after you select Save.

Start ircddbgateway and dstarrepeater

pi@hbox:~ $ sudo ircddbgateway &
pi@hbox:~ $ sudo dstarrepeater &

Configure the Radio

Link to the UK D-Star Megarepeater

D-Pad -> Repeater List -> Simplex -> 145.67 DV
Press PTT
D-Pad -> Local CQ
Hold Down PTT and Talk

Setting up a D-Star Access Point on Raspbian with PIXEL - Part I

This is part I of a two Part series. In part I, DStarRepeater and IRCDDBGateway will be compiled and DStarRepeater will be configured on Raspbian Jessie with PIXEL. In Part II, IRCDDBGateway will be configured and an Icom ID-51a+ will connect to the D-Star network through the D-Star hotspot.

Purpose

Create a hotspot or access point for a handheld radio in order to connect to the D-Star network.

Requirements

Definitions

Host - Your Desktop computer (Linux)
Target - Raspberry Pi 3 running Raspbian Jessie with PIXEL (Linux)

Directions

Write the Raspbian image to the uSD on the host. Execute the following commands on the host.

dev@fedora:~ $ sudo umount /dev/sdb*
dev@fedora:~ $ sudo dd if=2017-01-11-raspbian-jessie.img of=/dev/sdb bs=1M

Boot the Pi with the uSD card. Execute the following commands on the Pi.

pi@hbox:~ $ apt-get install libwxgtk3.0-dev libusb-1.0-0-dev
pi@hbox:~ $ mkdir ~/src
pi@hbox:~ $ cd ~/src
pi@hbox:~ $ git clone https://github.com/dl5di/OpenDV.git -b master
pi@hbox:~ $ cd OpenDV/ircDDBGateway
pi@hbox:~ $ ./configure
pi@hbox:~ $ make
pi@hbox:~ $ sudo make install
pi@hbox:~ $ cd ..
pi@hbox:~ $ cd DStarRepeater
pi@hbox:~ $ ./configure
pi@hbox:~ $ make
pi@hbox:~ $ sudo make install

pi@hbox:~ $ sudo mkdir -p /usr/local/etc/opendv

pi@hbox:~ $ sudo mkdir -p /usr/local/var/log/opendv

Configure DStarRepeater

Execute dstarrepeaterconfig on the target as follows.

Replace KF5SVQ with your call sign.