Tips and tricks
From GumstixDocsWiki
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Customers working with:
1/ The Gumstix Overo series or
2/ OpenEmbedded on the Verdex Pro series
should follow the instructions at gumstix.net and the related user wiki.
The instructions are for customers using buildroot, only.
Note: Each Verdex Pro motherboard available at www.gumstix.com are pre-flashed with Linux and the OpenEmbedded build environment.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
For customers using buildroot:
Ethernet on netwifi-microSD-vx board
Follow the information on this page to get ethernet started on netwif-microSD, if needed.
Change Timer/Scheduler Frequency
By default, the Linux timer interrupt uses a frequency of 100Hz, or 10ms. This unit is called a jiffy, and controls how quickly Linux can switch between multiple running processes, as well as the precision of system time calls like sleep. If your application needs greater precision -- for example, to ensure low-latency I/O from several processes -- you can increase this frequency to 1000Hz (1ms).
A change to the Linux kernel configuration is required:
- In your Buildroot, edit build_arm_nofpu/linux-*/include/asm-arm/param.h. Change the HZ value from 100 to 1000. This will give you 1ms jiffies, and nanosleep will get you about 2ms resolution.
If you need very precise timing, you may wish to move your code into the kernel; code running in "system context" within the kernel has much finer control over the system. Keep in mind, however, that code running in system context may crash the entire system if it contains bugs, and that your code must be written in C.
Upgrading the kernel over USB
If you upgrade to a new kernel, you just need to replace the /boot/uImage file on the gumstix, and any modules in /lib/modules/...
You can do this by just over-writing the existing files in the filesystem on the gumstix. These files will be found after building in build_arm/root/boot/uImage and build_arm/root/lib/modules/... in the buildroot.
Sample Kernel Module Makefile straight from the mailing list:
GUMSTIX_ROOT=/gumstix/trunk
GUMSTIX_LINUX_DIR=linux-2.6.10gum
obj-m := module.o
default:
make -C ${GUMSTIX_ROOT}/build_arm/${GUMSTIX_LINUX_DIR}
CROSS_COMPILE=${GUMSTIX_ROOT}/build_arm/staging_dir/bin/arm-linux-uclibc-
ARCH=arm SUBDIRS=`pwd`modules
clean:
rm -rf *.o *.ko
Free ttyS0
By default the gumstix' ttyS0 is used for the u-boot status-messages, and the linux system-console. Setting an ENV var in u-boot named "silent" will make the u-boot phase quiet. Setting the "bootargs" value such as "console=null ....." will make Linux quiet too. Example: After the following commands in u-boot
GUM> pri bootdelay=2 baudrate=115200 serial#=05000700BD3F4693 bootargs=console=ttyS0,115200n8 root=1f02 rootfstype=jffs2 reboot=cold,hard bootcmd=fsload a2000000 boot/uImage;bootm a2000000 stdin=serial stdout=serial stderr=serial Environment size: 221/4092 bytes GUM> setenv bootargs console=null root=1f02 rootfstype=jffs2 reboot=cold,hard GUM> setenv silent true GUM> saveenv
the whole booting-process is reduced to the following lines:
Uncompressing Linux.......................................... done, booting the kernel. Welcome to the Gumstix Linux Distribution! gumstix login:
Note, that u-boot will still wait several seconds (in our case 2 == bootdelay) for any keypress. The "Uncompressing Linux ..."-line is hardcoded into the kernel and needs a patch (see the attachements section for one). Drop it into your gumstix-buildroot/sources/kernel-patches directory, and rebuild the kernel. To undo the uboot-changes reset bootargs to its initial value, and remove the silent-var ("setenv silent" without value). The resting login (from "Welcome.." up to "login:") can easily be removed by commenting (a "#" at the beginning of the line) the following line in /etc/inittab:
::respawn:/sbin/getty -L ttyS0 115200 vt100
I2C device node
By default images from buildroot 773 and earlier don't have any i2c-node in the /dev directory. The following command will create one:
mknod /dev/i2c-0 c 89 0
Access PXA Registers
"The PXA250 cpu has many function units, controlled via memory mapped registers (there is nothing like the ports of the x86 architecture). With pxaregs you can display, decode and set any PXA 250 periphery register. The subversion tree can build pxaregs (version 1.14 from here).
Just add TARGETS =pxaregs to your top-level buildroot Makefile and away you go.
Access GPIOs from user-space
If proc-gpio is a module, add it to /etc/modules or do a modprobe proc-gpio.
A number of files exist under /proc/gpio, one for each GPIO on the PXA processor.
If you cat one of these files, you get, eg:
# cat /proc/gpio/GPIO12 12 GPIO in set
That tells you — GPIO number, function (either GPIO, AF 1, AF 2, or AF 3), in|out, set|clear.
You can change any of those values, by writing to the file, eg:
# echo "AF1 out" > /proc/gpio/GPIO12
This sets GPIO12 to AF1, out mode. (In the case of GPIO12, the PXA defines this function as putting out the 32kHz clock signal.) this is currently case-sensitive
If you have the GPIO set to an output, and GPIO mode, you can set or clear the signal:
# echo "GPIO out set" > /proc/gpio/GPIO12 # echo "GPIO out clear" > /proc/gpio/GPIO12
The alternative functions are described in the PXA255 Developer's Manual (link should be found in the Featured links-box) section 4.1.2.
UARTs
Using ttyS2: directly from the mailinglist (craig): 1. Set GPIOs up correctly — needed to program them through /proc/gpio before, but now I've altered u-boot with r374 to set the GPIOs up correctly at boot. 2. Need to stty -F /dev/ttyS2 -ixon speed 115200
The second piece tells the kernel to ignore flow control, since the STUART doesn't do flow control, and won't transmit unless flow control is turned off on the port. The speed will obviously depend on what you're connecting to it.
The concerned gpios are: GPIO46/47 with "AF2 in" for GPIO46 and "AF1 out" for GPIO47. (If your ttyS2 doesn't work, verify these are set correctly).
ttyS3 without flow-control: By default ttyS3 uses the flow-control lines of the uart-connection. Even disabling flow-control (stty -F /dev/ttyS3 -ixon) doesn't change this. Attached to this page is a (untested) 201-gumstix-ttyS3-no-flow-control.patch that disables flow-control for ttyS3 completely. Just drop it into your gumstix-buildroot/sources/kernel-patches directory, and rebuild the kernel.
Adding and Removing Items from BusyBox
Busybox is a wonderful compilation of Unix utilities specifically geared for use in embedded development environments like the Gumstix. Many users may not realize there are a number of functions configurable within Busybox (as opposed to the buildroot itself). Here is a synopsis of the steps:
cd build_arm*/busybox* make ARCH=arm CROSS_COMPILE=`pwd`/../staging_dir/bin/arm-linux- menuconfig
At this point a self-explanatory menu will appear — add or remove items as desired and save To backup the updated configuration for later use do the following: cp .config ../../sources/busybox.config
The previous step is optional, but will mean you can later rebuild the buildroot with same settings more easily. Now:
make ARCH=arm CROSS_COMPILE=`pwd`/../staging_dir/bin/arm-linux- cd ../.. make
Credit:Craig Hughes for process details.
Making vi get the proper windows size for the serial console
If you run vi from the serial console, it defaults to using an 80x24 window size, regardless of the actual size of the terminal session. If you're running vi from an ssh session, then the size will come out correct. If you're using a terminal that supports ANSI escape codes then it's possible for a program to query the window size. So, I created a little tool called winsize which calls the same function that vi calls to determine the window size. Paul Fox sent me his copy of resize.c which is a stripped down version of the X windows utility of the same name.
| File | Description |
|---|---|
| winsize.c | Utility to display the current window size |
| winsize | Precompiled version of winsize.c |
| resize.c | Utility to query the window size from the terminal |
| resize | Precompiled version of resize.c |
| Makefile | Makefile to build them all |
To use: add the following lines to ~/.profile which says:
if [ "${TERM}" = "vt100" ]
then
resize
fi
The resize is only needed on the serial console. An alternative check might be to do:
if [ "$(tty)" = "/dev/ttyS0" ]
then
resize
fi
Getting colorized directory listings
The ls that's configured with the default buildroot is capable of outputting colorized display on an ANSI compatible terminal. To use this, use the command:
ls --color=auto
You can automate this by adding the following to your ~/.profile
alias ls='ls --color=auto'
The --color=auto mode causes the color to show up when outputting to a tty, but to be turned off when piping the output of ls to a program. Try the following options:
ls --color=auto ls --color=auto | more ls --color=always ls --color=always | more ls --color=never ls --color=never | more
Unfortunately, the colors aren't configurable. I've discovered that the colors look best on a black or dark gray background.
Mounting JFFS2 images on your host computer
The normal procedure would be to use what's know as a loop mount. However, this only works for filesystems which can be mounted on a block device, and jffs2 isn't one of those. However, there is a device called mtdram which uses RAM to emulate a flash device well enough that a JFFS2 system can be mounted on it.
The procedure (requires root accees to the linux host machine) is as follows:
modprobe mtdcore modprobe jffs2 modprobe mtdram modprobe mtdchar modprobe mtdblock dd if=image.jffs2 of=/dev/mtd0 mount -t jffs2 /dev/mtdblock0 mnt
You can now look at mnt and be seeing a copy of the jffs2 image. Note that changes to the image are happening in the RAM copy, not on your original image.
MTD also comes with a tool called jffs2dump which can be used to examine jffs2 images as well.
