The Linux Daily

Calculating /proc/cpuinfo BogoMIPS After Kernel Init

Upon starting up your Linux kernel, a bogoMIPS calculation will be made and recorded into /proc/cpuinfo. This is a value that is not dynamically updated, so if you change the clock speed of the CPU, the bogoMIPS value contained in /proc/cpuinfo will not be updated. If all you’re interested in is a simple verification that your CPU speed was changed, you could compile and run the following bogoMIPS calculation program both before and after the clock speed change.

http://www.ibiblio.org/pub/linux/system/status/bogo-1.2.tar.gz

Simply call ‘make’ to compile the program. You may need to modify the Makefile in accordance to your needs (cross compiling, gcc flags, etc). You may notice that the bogoMIPS value calculated by this program is not the same as the value calculated by the kernel. That’s okay. What matters here is that you can verify a change in CPU speed. After all, “bogo” stands for “bogus” which simply means “fake”.

Source:
http://tldp.org/HOWTO/BogoMips/bogo-faq.html

Yet Another Quick Serial Read c Program

Here’s yet another quick example of a serial capture c program that I came across while at work the other day. I just figured I would share…

int main(int argc, char * argv[]){
while(1){
FILE *fp;

fp = fopen("/proc/bus/usb/001/003", "r");

char buff[100];
while(fscanf(fp, "%s", buff) != EOF){
printf("%s\n", buff);
}
fclose(fp);
}
return 0;
}

Grab Raw Keyboard Input from Event Device Node (/dev/input/event)

The following is a quick c program that will capture raw keyboard data from the event device node such as /dev/input/event1. Simply compile and run with the specific device node as an argument. ie. ./keyboard_key_capture /dev/input/event1.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>
#include <dirent.h>
#include <linux/input.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/select.h>
#include <sys/time.h>
#include <termios.h>
#include <signal.h>

void handler (int sig)
{
  printf ("\nexiting...(%d)\n", sig);
  exit (0);
}

void perror_exit (char *error)
{
  perror (error);
  handler (9);
}

int main (int argc, char *argv[])
{
  struct input_event ev[64];
  int fd, rd, value, size = sizeof (struct input_event);
  char name[256] = "Unknown";
  char *device = NULL;

  //Setup check
  if (argv[1] == NULL){
      printf("Please specify (on the command line) the path to the dev event interface device\n");
      exit (0);
    }

  if ((getuid ()) != 0)
    printf ("You are not root! This may not work...\n");

  if (argc > 1)
    device = argv[1];

  //Open Device
  if ((fd = open (device, O_RDONLY)) == -1)
    printf ("%s is not a vaild device.\n", device);

  //Print Device Name
  ioctl (fd, EVIOCGNAME (sizeof (name)), name);
  printf ("Reading From : %s (%s)\n", device, name);

  while (1){
      if ((rd = read (fd, ev, size * 64)) < size)
          perror_exit ("read()");      

      value = ev[0].value;

      if (value != ' ' && ev[1].value == 1 && ev[1].type == 1){ // Only read the key press event
	   printf ("Code[%d]\n", (ev[1].code));
      }
  }

  return 0;
}

Here is an example output from running the above command. Notice that Code[] is printed before the key that was pressed.

# ./keyb_key_cap_x86 /dev/input/by-id/usb-Dell_Dell_USB_Keyboard-event-kbd
Reading From : /dev/input/by-id/usb-Dell_Dell_USB_Keyboard-event-kbd (Dell Dell USB Keyboard)
Code[30]
aCode[48]
bCode[46]
cCode[32]
dCode[18]
eCode[33]
fCode[34]
gCode[35]
hCode[23]
iCode[36]
jCode[37]
kCode[38]
lCode[50]
mCode[49]
nCode[24]
oCode[25]
pCode[16]
qCode[19]
rCode[31]
sCode[20]
tCode[22]
uCode[47]
vCode[17]
wCode[45]
xCode[21]
yCode[44]
zCode[2]
1Code[3]
2Code[4]
3Code[5]
4Code[6]
5Code[7]
6Code[8]
7Code[9]
8Code[10]
9Code[11]
0

This is only an example program that I picked up from work. I hope it will be of use to somebody out there so it can quickly help you get started with your project.

A Great, Simple, Quick Serial Port Test Program for Linux

For any of you out there who would like to learn about serial programming or are in need of a simple serial program for testing, I would recommend checking out the one from “Captains Universe” here:
http://www.captain.at/howto-simple-serial-port-test-example.php

It’s easy to understand, modify, and compile and I think it’s a valuable tool in any programmers or embedded Linux users arsenal.

Time Tracking and Profiling Your Program with gprof

Until today, I had only heard of the time program to track how much time a program took to execute entirely. This is useful to see if there are any optimizations that can be made to make the program run quicker, but it doesn’t help troubleshoot or debug a program very easily since it only tracks the entry and exit of the program being ran. Another utility that allows you to track time in a more detailed manner is called gprof. Here’s a quote from the CS department of Utah School of Computing (link) explaining it in more detail:

Profiling allows you to learn where your program spent its time and which functions called which other functions while it was executing. This information can show you which pieces of your program are slower than you expected, and might be candidates for rewriting to make your program execute faster. It can also tell you which functions are being called more or less often than you expected. This may help you spot bugs that had otherwise been unnoticed.

Be sure to check out the man pages and other many guides out there that explain how to use it (no need for me to reinvent the wheel).

Convert Small Array to Single Variable and Back Again

Here is a method that will allow you to essentially merge elements of an array into a single variable and then back again in c.

unsigned char mac_addr[6];
long long int x;

x = mac_addr[0] << 40;
x |= mac_addr[1] << 32;
x |= mac_addr[2] << 24;
x |= mac_addr[3] << 16;
x |= mac_addr[4] << 8;
x |= mac_addr[5];

mac_addr[0] = x >> 40;
mac_addr[1] = x >> 32;
mac_addr[2] = x >> 24;
mac_addr[3] = x >> 16;
mac_addr[4] = x >> 8;
mac_addr[5] = x;

You could probably take it a step further and throw it into a loop of sorts. If you have another solution, feel free to share it in the comments below!

Silence the rt73 Driver Message of MimeAssocReqAction()

If you utilize the rt2501usb chipset (rt73 driver) and are connect to your wireless LAN using WPA2 encryption, then you may have noticed a flurry of messages showing up in your syslog or dmesg output, filling up you logs:

[ 1321.830000] MlmeAssocReqAction(): WPA2/WPA2PSK fill the ReqVarIEs with CipherTmp!
[ 1323.980000] MlmeAssocReqAction(): WPA2/WPA2PSK fill the ReqVarIEs with CipherTmp!
[ 1328.170000] MlmeAssocReqAction(): WPA2/WPA2PSK fill the ReqVarIEs with CipherTmp!
[ 1330.480000] MlmeAssocReqAction(): WPA2/WPA2PSK fill the ReqVarIEs with CipherTmp!
[ 1332.990000] MlmeAssocReqAction(): WPA2/WPA2PSK fill the ReqVarIEs with CipherTmp!
[ 1337.060000] MlmeAssocReqAction(): WPA2/WPA2PSK fill the ReqVarIEs with CipherTmp!

It seems to me that these are simply status/debugging messages and don’t serve much of a purpose other than fillings up the logs with information that’s not all that valuable to an end-user. The connection still works, so it doesn’t seem out of line to simply comment out the offending lines in the source code. If you don’t have the source code already, then you’ll need to goto RaLink and download them. There are readme files that will help you compile from scratch. When you have the source code, simply use grep to find the messages:

grep -rn "ReqVarIEs with CipherTmp"

You should find that the lines occur in the assoc.c file at line 348 and line 402. Comment these lines out and recompile. After this, your logs will be scotch-free of all those messages.

Simple Cross Compile Example

The following is a very introductory guide to cross compiling a simple C++ program targeted towards an ARM platform. Development environments differ greatly, but for the most part, they all follow similar steps like outlined below. The very first step is to obtain a cross compile toolchain. CodeSourcery has a free, lite gcc toolchain available for download (as mentioned in a previous post). Once you download an appropriate toolchain for your target, you’ll need to extract it on your development host machine. You’ll notice a directory structure similar to opt/crosstool/gcc-4.0.1-glibc-2.3.5/arm-unknown-linux-gnu/bin/arm-unknown-linux-gnu- which is what we’ll use here.
[Read more →]

CodeSourcery.com: A Place to Get Cross Compile Toolchains for ARM

This is something that I’m still coming to grips with, but today I learned that the cross compile toolchains that Technologic Systems provides for at least some of their products come from CodeSourcery.com. A quick blurb from their website:

CodeSourcery, in partnership with ARM, Ltd., develops improvements to the GNU Toolchain for ARM processors and provides regular, validated releases of the GNU Toolchain. Sourcery G++ Lite Edition supports ARM, Thumb, and Thumb-2 compilation for all architectures in active use, including Version 7 of the ARM Architecture.

For example, today I needed a newer version of the g++ cross compiler targeted towards EABI and glibc, so I took a look around the website at http://www.codesourcery.com/sgpp/lite/arm and found the release in the downloads section here: http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite

A short term goal for myself is to figure out what goes into creating a cross compile environment. I think this would be a valuable skill in the embedded Linux market. For now, this was a shock to learn about how simple it really is to be able to simply download the toolchain and that there wasn’t any other trickery or knowledge required.

My First Makefile for Compiling GTK+ (Or Any) Apps

A Makefile provides an easy, fast way to compile an application that requires more than just a simple gcc myprogram.c -o myprogram command. For example, to compile a GTK+ app, the common, basic compile command is gcc -g -Wall myguiapp.c -o myguiapp -export-dynamic `pkg-config –cflags –libs gtk+-2.0`. It’s not terrible, but it would be a pain to have to retype that every time you need to recompile. The alternative is to create a Makefile and type make. This is my very first Makefile, and I believe it makes a great example:

NAME=myguiapp
CFLAGS=-g -Wall -o $(NAME)
GTKFLAGS=-export-dynamic `pkg-config --cflags --libs gtk+-2.0`
SRCS=main.c
CC=gcc

# top-level rule to create the program.
all: main

# compiling the source file.
main: $(SRCS)
 $(CC) $(CFLAGS) $(SRCS) $(GTKFLAGS)

# cleaning everything that can be automatically recreated with "make".
clean:
 /bin/rm -f $(NAME)

As you can see, when make is called, it will compile the source with all my options including the program name. When make clean is called, it will delete the compiled program.

One important thing to remember is that these Makefiles are very picky about spacing and tabs.  You MUST use a TAB at the beginning of commands and a TAB must not be at the beginning of blank lines. The first error causes the commands not to run. The second causes the “make” utility to complain that there is a “blank” command.

Obviously, this is an incredibly simple Makefile in comparison to a lot of them out there, but this is a good starting point. You can customize the Makefile to match your compiling needs. If you’d like to learn more, Google is your friend. I can point you in a couple of good directions with these links:
http://mrbook.org/tutorials/make/
http://www.cs.umd.edu/class/fall2002/cmsc214/Tutorial/makefile.html

Happy coding!