Configuring CAN interface during boot

This is an easy way to configure a CAN bus interface during boot. Just create a new config file:

$ sudo nano /etc/network/interfaces.d/can0

...and add the following:

allow-hotplug can0
iface can0 can static
    bitrate 125000

Supported bitrates are 125000, 250000, 500000, 1000000 for standard CAN (non-FD).

Creating local mirror for Buildroot package sources

When you need to frequently and quickly rebuild Buildroot for a variety of reasons, there's a neat feature in Buildroot that allows you to use a local source mirror, so you can avoid wasting bandwidth and unnecessary waiting for downloads.

Here's a list of the BR variables, which configure the mirroring behavior:

BR2_PRIMARY_SITE
BR2_PRIMARY_SITE_ONLY
BR2_BACKUP_SITE
BR2_KERNEL_MIRROR
BR2_GNU_MIRROR
BR2_LUAROCKS_MIRROR
BR2_CPAN_MIRROR

The variables usage should be pretty obvious, but as always don't hesitate to take a look at the Config.in, where the variables are documented (or use menuconfig and go to "Build options", "Mirrors and Download locations").

Basically you have 2 ways to change these variables - either edit them in Config.in file, or assign them in your boards's configuration file (configs/boardname_defconfig). The difference is that boardname_defconfig affects only your board, and Config.in affects all boards' builds.

Here's a very simple example of making a local mirror for all sources, just add this to your boardname_defconfig:

# Use local source mirror
BR2_PRIMARY_SITE="http://www.myserver.org/mirrors/buildroot"

Of course the best place to put your server is inside your LAN, which will guarantee sub-second downloads during the build process.

A closer look at GStreamer pipelines

One common issue people have with GStreamer is to understand what is the actual dynamic pipeline built via gst-launch command-line tool. There's a neat mechanism to extract the information from the pipeline, including the full media graph and all plugins/pads parameters. Here's how.

GStreamer can dump media graphs in Graphviz .dot format, in a location pointed by GST_DEBUG_DUMP_DOT_DIR env-var:

$ export GST_DEBUG_DUMP_DOT_DIR=/tmp

Now run gst-launch in the console, it will automatically create .dot files in /tmp, one per state transition:

$ gst-launch playbin2 uri=file:///test.mp4
^C

Now we we can convert the .dot files to to PNG images:

$ cd /tmp
$ for i in *.dot; do dot -Tpng -O $i; done

There's a ton of useful info in the media graphs, make sure to check them out!

All credits go to GStreamer team's online docs: http://docs.gstreamer.com/display/GstSDK/Basic+tutorial+11%3A+Debugging+tools

Building Yocto 1.8 "Fido" for i.MX6

Quick guide how to download and build Yocto 1.8 "Fido" for i.MX6 (same as my previous post about "dizzy"):

mkdir ~/bin
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo

PATH=$PATH:~/bin
mkdir yocto-fido-sabresd && cd yocto-fido-sabresd
repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b fido && repo sync
source ./setup-environment build
bitbake core-image-minimal

The default target machine is "imx6qsabresd", but you can change it in your conf/local.conf file.

Poor man's paddle (CW key)

I was impressed by PA0CMU's web site, and decided to do myself a homebrew CW key. My preferences were to have single lever key (called "paddle"). Why exactly I wanted such type of morse key - don't know, it just looked more convenient to me.

My requirements for the project materials were:
- to use only cheap and easily accessible materials;
- to be manufactured easily without needing special instruments and machines.

In addition, I wanted to extend PA0CMU's idea by:
- prevent flexing the copper-clad board pieces by adding triangle pieces in the corners;
- using contacts from a off-the-shelf automotive relay, instead of screw and copper surface contact (it will oxidize sooner or later, as it's not protected);
- mounting a wooden handle, which is much pleasant for touching/using than the copper clad board.

So, here are my materials:
- double-sided copper clad (PCB). I just had that handy, and took advantage of soldering both sides for better mechanical strength.
- 2x low-cost automotive relays (Sun Hold SG4-1220A), used for their contacts (but probably any automotive power/high-current relay will do the job);
- 2x icecream sticks (for the key handle);
- cable + 3.5mm connector cut from old damaged headphones.

Here's a photo of my good old Icom IC-706 MKII and my hand-made key:

I have to admit that I haven't used mechanical drawing diagram at all - I was just looking at PA0CMU's key and choosing materials/sizes which looked reasonable, and in the end I wanted to build this more key just for an hour or two. After I made the key I just rushed to connect it to my transceiver so I can try it and didn't bothered to properly fix the cable... but I'll have to do it anyway.

Here are more detailed pictures of the key:

Note that the screws are used to adjust the distance of side motion and to center the lever. The actual electrical contact is done by the relay pieces.

The original purpose of this hole was to make the material more flexible in this point. It turned out that it became too flexible, so it's up to you to decide how you like the lever stiffness.

PS: This is an English translation of my original article written in Aug.2011.

FTP must die!

Just stumbled upon this article, mentioned in the "News" section on kernel.org.
Needless to say that I agree with the author. So let's help FTP die with honor, long live the SCP!

Securing the SSH server

This is my checklist of TODO things to make my SSH daemons more "Internet-ready":

1. Copy my public key to the remote host:

ssh-copy-id remote_host

2. Login on the remote host

ssh remote_host

3. Edit the /etc/ssh/sshd_config file and change the following configuration options:

ChallengeResponseAuthentication no
LoginGraceTime 30
MaxStartups 2:30:10
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
UsePAM no

4. Restart the SSH daemon, but don't disconnect the SSH session:

sudo service ssh restart

5. Open another shell and verify that pubkey authentication now works:

ssh -v remote_host

6. Observe that:
- Now I logged without typing my password
- The SSH client printed the following message:

debug: Authentication succeeded (publickey)

That's it.

Mainline Buildroot for RIoTboard

Now that we have a Buildroot support for our lovely RIoTboards, lets try it. Here's short guide how to compile and run it (copy/paste from the readme.txt):

1. Compiling buildroot
----------------------

make riotboard_defconfig
make

2. Installing buildroot
-----------------------

Prepare an SD-card and plug it into your card reader. Write the bootloader to
your SD-card:

sudo dd if=output/images/u-boot.imx of=/dev/sdX bs=1k seek=1

Create 1 partition on the SD-card using your favourite tool. The partition
should be big enough to hold your rootfs, for example 128MiB. Here's how an
example of such partition layout:

   Device Boot      Start         End      Blocks   Id  System
/dev/sdX1            2048      264191      131072   83  Linux

Format the SD-card partition with your favourite filesystem:

sudo mkfs.ext2 /dev/sdX1

Deploy your rootfs to the SD-card:

sudo mkdir /mnt/sdcard/
sudo mount /dev/sdX1 /mnt/sdcard/
sudo tar xf rootfs.tar -C /mnt/sdcard/
sudo umount /dev/sdX1

3. Running buildroot
--------------------

Position the board so you can read the label "RIoTboard" on the right side of
SW1 DIP switches. Configure the SW1 swiches like this:

10100101 (1 means ON position, 0 means OFF position)

Now plug your prepared SD-card in slot J6. Connect a serial console (115200, 8,
N, 1) to header J18. Connect a 5V/1A power supply to the board and enjoy your
new toy.

Note: Buildroot automatically recognizes and takes advantage of multicore machines, so don't use "-j" flags for make.

Building Yocto 1.7 "Dizzy" for i.MX6

Quick guide how to download and build Yocto 1.7 "Dizzy" for i.MX6 (almost the same as my previous post about "daisy"):

mkdir ~/bin
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo

PATH=$PATH:~/bin
mkdir fsl-community-bsp && cd fsl-community-bsp
repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b dizzy && repo sync
source ./setup-environment build
bitbake core-image-minimal

As usual, the default target machine is "imx6qsabresd", but you can change it in your conf/local.conf file.

Linux audio support for RIoTboard

RIoTboard support was introduced with mainline Linux v3.17. Since when I got this board, I was interested in using the on-board audio codec (SGTL5000), but initially didn't managed to have the audio working properly. Later I managed to get it working, and this is a short report to remind and others what works so far:

Kernel        Status
====================
Linux 3.17.0  OK
Linux 3.17.1  OK
Linux 3.17.2  OK
Linux 3.17.3  OK
Linux 3.17.4  OK
Linux 3.17.5  OK
Linux 3.17.6  OK
Linux 3.17.7  OK
Linux 3.17.8  OK
Linux 3.18.0  OK
Linux 3.18.1  OK
Linux 3.18.2  OK
Linux 3.18.3  OK
Linux 3.18.4  OK

All the kernels have been compiled natively on the RIoTboard itself (running Debian Wheezy on external USB drive). Each build takes about 70m, so please be patient.

PS: Just found out that the RIoTboard audio subsystem is somewhat screwed-up:
1. HP_VGND is connected to analog ground, while the datasheets explicitly says that it shouldn't be connected anywhere else other than the headphones jack. This effectively shorts out the virtual ground amplifier and leads to #2.
2. Headphones are connected via 2x 47uF ceramic capacitors. Electrolytic capacitor 100-220uF would be much better, and no capacitor would be best in terms of audio quality (but this needs proper connection to HP_VGND).
3. Line-in inputs are... well, not connected. That's really bad, as it rules out a number of use cases where we need stereo line-in and/or better quality ADC, so we're left with Lo-Fi mono microphone input (say goodbay to the low-cost SDR). I feel crushed...