Skip to content
August 9, 2013 / gus3

Accessing the Raspberry Pi’s 1MHz timer, via kernel driver


As it turns out, my previous effort was, shall we say, somewhat off-base. Being a member of the “kmem” group, or running a SUID-root program, isn’t enough to access /dev/mem; the program capability CAP_SYS_RAWIO must also be present.
Read more…

July 1, 2013 / gus3

ARM VFP Vector Programming, Part 3: Source

Here are the source code and Make files for the two examples discussed in Part 2.

Read more…

June 27, 2013 / gus3

ARM VFP Vector Programming, Part 2: Examples

In Part 1, I explained the design philosophy of vector calculations using the ARM Vector Floating Point system. This article will demonstrate the actual practice of using vectors in the ARM VFP.
Read more…

June 25, 2013 / gus3

ARM VFP Vector Programming, Part 1: Introduction

The ARM VFP co-processor is most commonly used for individual floating-point computations, in the so-called “scalar mode.” In Flynn’s taxonomy, this is known as SISD, or “single instruction, single destination.” This design philosophy is the basic form for most low-level assembly most high-level compilers. In cases where different data sources are treated differently, for whatever reason, SISD is the norm.

However, when a block of identical operations are carried out on a sequence of data points, then it is possible to fetch several of the source data, and perform the operations on them all at once. This may be something as simple as adding the values of two arrays and storing the results into a third array, which may be part of a sophisticated analysis on a digital image. A close examination of the processing can show where Single Instruction, Multiple Destination (SIMD) design can boost a program’s performance.

Read more…

May 21, 2013 / gus3

Accessing the Raspberry Pi’s 1MHz timer

A fixed-rate timer is not part of the ARM specification, but most ARM-based SoC’s have such a timer. The Raspberry Pi is no exception. However, reading its timer in Linux takes a Unix hacker’s understanding.

Read more…

May 11, 2013 / gus3

When was that? Examining syslog timestamps

One convenient Linux kernel feature is an uptime stamp in each kernel log entry. This stamp is independent of the clock time, so small or large jumps in the clock have no bearing on the reported time for each entry.

Normally, the log files in /var/log/ will include a human-readable local time stamp before the log entry, but these files are readable only by the root user. Another possibility is that the logs are routed to another system for storage. This practice would also include restricting “dmesg” to the root user; the following won’t be useful in this case.

Read more…

March 18, 2013 / gus3

Tired of su-ing

One axiom of computing is to script commonly-used command sequences, akin to C’s functions, Pascal’s procedures, and Ada’s subprograms. But what if the command sequence involves “su” for elevated privileges? I found an idiom that Works For Me.

This example will pull pages from the swap space back into RAM:


case `id -u` in
    # The task is accomplished in the 0 case,
    # where we know we have root privileges.
    0) /sbin/swapoff -a
       /sbin/swapon -a
    # Everyone else gets to provide a password:
    *) exec /bin/su -c "`which $0`" - ;;

Anything requiring elevated privileges, or even simply someone else’s privileges, can be scripted this way. I have the above script in ~/bin/unswap. I have three other scripts in the same directory, called “slow”, “normal”, and “fast”, which set the CPU frequency governor to powersave, ondemand, or performance.

The one caveat is to hard-code the paths to the root-executed programs (which you already do in scripts, right?). You don’t want to execute a non-standard “swapon” that isn’t where you expect it to be.

(If someone would like to contribute an example using “sudo” instead of “su” it would be greatly appreciated.)