Gumstix User Wiki - User contributions [en]

SyntroLCam for streaming video from Overos and Duoveros

2013-07-20T14:22:47Z

Sellis: Add some external links

SyntroLCam is an open-source [http://qt-project.org/ Qt] application from
[http://www.pansenti.com Pansenti] that can be used to
stream USB webcam video from a Gumstix to a network where it can be viewed
by multiple remote systems.

With SyntroLCam the multiplexing of the video feed happens in the Syntro cloud so there
is no additional load on the Gumstix to support multiple viewers.

Some [http://pansenti.wordpress.com/2013/06/08/gumstix-rpis-beagles-action/ screenshots]
of a running system with multiple Gumstix boards and multiple remote viewers.

Here are the Github repositories for
[https://github.com/Syntro/SyntroCore SyntroCore],
[https://github.com/Syntro/SyntroLCam SyntroLCam] and
[https://github.com/Syntro/SyntroView SyntroView].

The instructions for building Syntro applications on any Linux system
with Qt4 or Qt5 developer headers and libraries installed is the same:

<pre>
qmake && make [-j<n>] && [sudo] make install
</pre>

Here are some [http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=85&Itemid=97 instructions]
for building a compatible O/S for Overos or Duoveros using the [http://www.yoctoproject.org Yocto Project]
build system.

The pansenti-qte-image from this layer will run SyntroLCam on startup automatically.

The [https://github.com/Pansenti/meta-pansenti meta-pansenti] layer has bitbake recipes
for [https://github.com/Pansenti/meta-pansenti/tree/master/recipes-pansenti/syntrocore syntrocore.bb]
and [https://github.com/Pansenti/meta-pansenti/tree/master/recipes-pansenti/syntrolcam syntrolcam.bb]
if you want to include them in another O/S image.

[[Category:How to - webcams]]

Category:How to - webcams

2013-07-18T14:51:58Z

Sellis: Remove page link now that it shows up under categories

SyntroLCam for streaming video from Overos and Duoveros

2013-07-18T14:51:02Z

Sellis: New page on SyntroLCam

SyntroLCam is a [http://qt-project.org/ Qt] application that can be used to
stream USB webcam video from a Gumstix to a network where it can be viewed
by multiple remote systems.

With SyntroLCam the multiplexing of the video feed happens in the Syntro cloud so there
is no additional load on the Gumstix to support multiple viewers.

Some [http://pansenti.wordpress.com/2013/06/08/gumstix-rpis-beagles-action/ screenshots]
of a running system with multiple Gumstix boards and multiple remote viewers.

Here are the Github repositories for
[https://github.com/Syntro/SyntroCore SyntroCore],
[https://github.com/Syntro/SyntroLCam SyntroLCam] and
[https://github.com/Syntro/SyntroView SyntroView].

The instructions for building Syntro applications on any Linux system
with Qt4 or Qt5 developer headers and libraries installed is the same:

<pre>
qmake && make [-j<n>] && [sudo] make install
</pre>

Here are some [http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=85&Itemid=97 instructions]
for building a compatible O/S for Overos or Duoveros using the Yocto Project build system.

The pansenti-qte-image from this layer will run SyntroLCam on startup automatically.

The [https://github.com/Pansenti/meta-pansenti meta-pansenti] layer has bitbake recipes
for [https://github.com/Pansenti/meta-pansenti/tree/master/recipes-pansenti/syntrocore syntrocore.bb]
and [https://github.com/Pansenti/meta-pansenti/tree/master/recipes-pansenti/syntrolcam syntrolcam.bb]
if you want to include them in another O/S image.

[[Category:How to - webcams]]

Category:How to - webcams

2013-07-18T14:50:00Z

Sellis: Add link to new page

[[SyntroLCam for streaming video from Overos and Duoveros]]

Installing Ubuntu 10.04 on Gumstix Overo

2011-10-13T23:40:12Z

Sellis: build-essential without the 's'

== Ubuntu on Overo COM ==
Constructing an Ubuntu root file system for the Gumstix Overo COM is surprisingly easy with the rootstock utility. Since Ubuntu (particularly a version including a graphical desktop) likes lots of RAM, Gumstix recommends using an Overo COM with at least 512MB RAM, such as the [http://www.gumstix.com/store/catalog/product_info.php?products_id=257 Overo Tide COM]. You can install Ubuntu on an Overo with 256MB RAM and the familiarity of Ubuntu for some users may outweigh occasional sluggishness. These instructions were tested on an Ubuntu 10.04 desktop machine; they should work for any recent Debian-based flavour of Linux. These instructions also work for Ubuntu 11.04 Natty Narwhal with a few things to keep in mind.

== Make a MicroSD card ==
The rootstock utility builds a root file system inside a virtual arm machine supplied by qemu. First, install the required packages.
<code>
$ sudo apt-get install rootstock qemu
</code>
note: To create a rootFS image for Ubuntu 11.04 you need to make sure that the machine creating the image has qemu-arm-static version 14.x or better. Ubuntu 11.04 has this but 10.04 for instance does not and segfaults during rootFS image creation.

Next, use a command like the one shown below to make a root file system; check out 'man rootstock' for some extra options. Note: this will take an hour or two.
<code>
$ sudo rootstock --serial ttyS2 -d lucid -f "gumstix" --seed lxde,gdm,openssh-server,x11vnc
</code>
* the '-d' option specifies the distribution release: in this case, Ubuntu Lucid (10.04). In the case of Ubuntu Natty (11.04) use "natty".
* the '--seed' option specifies the list of packages to install: in this case, we install a lightweight desktop and a standard login manager as well as ssh & VNC servers so we can connect remotely.
* the user name ('-l') and password ('-p') options don't seem to work at the moment; see [Configuring Ubuntu] for more information.

To create a rootFS image for a headless server you can use the following:
<code>
$ sudo rootstock --serial ttyS2 -d lucid -f "gumstix" --seed build-essential,openssh-server
</code>

You should now have a spiffy root file system tarball so now we just need to create a bootable microSD with a standard bootloader and kernel.

Format a microSD card as per [http://www.gumstix.net/Documentation/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/109.html usual]; you should copy a [http://www.sakoman.com/feeds/omap3/glibc/images/overo/201009091145/ recent] MLO, u-boot, and uImage to the boot partition. Extract the generated root file system to the second partition of the microSD card.

Finally, the loadable modules in the file system should match the kernel. For users that don't want to build a kernel, you can use this [http://dl.dropbox.com/u/211887/Ubuntu/uImage-2.6.34-r88-overo.bin 2.6.34 kernel] and the associated [http://dl.dropbox.com/u/211887/Ubuntu/modules-2.6.34-r88-overo.tgz modules] tarball; this is approximately the Gumstix Overo kernel from September 9th, 2010. Extract the modules file into the second partition over top of the root file system. E.g. for a root partition mounted at /media/rootfs:
<code>
sudo tar xaf modules-2.6.34-r88-overo.tgz -C /media/rootfs
</code>

note: For Ubuntu 11.04 the compatible kernel version should be 2.6.38. However, the current version of openembedded ("bitbake virtual/kernel") at most yields a kernel version 2.6.36. The 2.6.36 was tested with the Ubuntu 11.04 rootFS image and seems to be working fine. Only some system messages about TWI2C, which should only concern you if you plan to use I2C on you Overo. Everything else seems to be working fine.

== Configuring Ubuntu ==
The ''rootstock'' utility doesn't make passwords properly. For now, it is easiest to remove the root password, boot your system to create new users and choose a new root password. To do this, open the ''/etc/shadow'' file on the second partition and delete the '*' for the root entry. E.g.
<code>
$ sudo gedit /path/to/second/partition/etc/shadow
</code>
Note: remember to put the ‘*’ back after you have created a user so someone can’t login as root and screw up your system

For Overo expansion boards with an Ethernet interface, it is nice to have Ethernet working right off the bat without having to have Network Manager installed. Open the ''/etc/network/interfaces'' file on the second partition.
<code>
$ sudo gedit /path/to/second/partition/etc/network/interfaces
</code>
Add the following code to the bottom:
<code>
auto eth0
iface eth0 inet dhcp
</code>
You can now unmount the microSD card, place it in the Gumstix and boot to it.

Login using serial console using these [http://www.gumstix.net/Documentation/view/Overo-Setup-and-Programming/Getting-started/109.html instructions] or you can plug an Ethernet card in and jump in via ssh.

Once you are logged in, you might make some other tweaks:
* login as root and then create a user for yourself and give yourself sudo
<code>
$ sudo adduser youruser
$ sudo adduser youruser sudo
</code>
* edit /etc/shadow and add the ‘*’ back in that we removed earlier. E.g.
<code>
$ nano /etc/shadow
</code>

* add some useful package repositories if they're not already present. Edit /etc/apt/sources.list and add these lines:
<code>
$ deb http://ports.ubuntu.com/ubuntu-ports lucid-updates main
$ deb http://ports.ubuntu.com/ubuntu-ports lucid-security main
</code>
* get up-to-date:
<code>
$ sudo apt-get update && sudo apt-get upgrade
</code>
Have fun!

== Related Links ==
Here are some links I found useful when putting this post together:
* https://wiki.ubuntu.com/ARM/RootfsFromScratch
* http://labs.igep.es/index.php/How_to_get_the_Ubuntu_distribution
* https://wiki.ubuntu.com/ARM/RootfsFromScratch
* http://free-electrons.com/blog/ubuntu-1004-igepv2/
* http://omapzoom.org/wiki/Ubuntu_rootfs

[[Category:How_to_-_Ubuntu]]

Category:SPI

2011-01-20T15:53:40Z

Sellis: Added some muxing notes

== Overo SPI ==

Kernel documentation for the SPI framework can be found in the Documentation directory of your linux source tree or here [http://www.kernel.org/doc/Documentation/spi/spi-summary Documentation/spi/spi-summary].

Linux SPI drivers are broken into two parts. A controller driver that handles direct communication with the hardware and a protocol driver to handle the details of the data for a particular device. The interface defined in spi.c/spi.h is the bridge between the two.

For the OMAP3's, the controller driver is omap2_mcspi.c. The OMAP3's have 4 SPI busses which the omap2_mcspi driver handles. The kernel config option to include the omap2_mcspi driver is CONFIG_SPI_OMAP24XX and is already built into standard Gumstix Overo kernels.

The OMAP3 SPI controller has the ability to act as either a SPI master or SPI slave, but the current kernel code only supports the SPI master configuration.

Gumstix brings out SPI bus 1 chip select pins 0 and 1 on most of the Overo expansion boards.

SPI pins for the OMAP3 are multi-functional and need to be multiplexed for SPI use. The SPI bus 1 MOSI, SIMO, CLK, CS0 and CS1 brought out on the Overo expansion boards are correctly setup for SPI use. This configuration is done in the bootloader U-Boot.

=== Protocol Drivers ===

A protocol driver is what you need to use the SPI system on Linux.

There are a couple of steps that need to happen.

# Slave devices must be registered for each SPI bus and chip select position used.
# A protocol driver needs to be registered with the system using the same name as the devices it will be handling so the kernel can link the two.

It doesn't matter which order these steps are performed. Most existing SPI drivers do the device registration completely outside the driver code in a board file. If you are writing your own driver, it is probably more convenient to do it in the driver code itself. When both device and driver registration are completed, the probe() function for the protocol driver will be called and SPI communications can start.

SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages in the protocol driver. The protocol driver submits the SPI messages to the controller driver's I/O queue. These messages are then processed asynchronously by the controller driver in FIFO order. As each message finishes, the controller notifies the protocol driver via a callback function.

There are some synchronous helper functions exposed by the interface to simplify the asynchronous behaviour of the Linux SPI system for protocol driver writers.

=== Spidev ===

Spidev is a standard Linux module that implements a generic SPI protocol driver while exposing a char device interface to userland.

The documentation for spidev can be found here - [http://www.mjmwired.net/kernel/Documentation/spi/spidev Documentation/spi/spidev].

The spidev driver does not register devices so a board file patch like this one [https://github.com/scottellis/spike/blob/0d633a22da47022073abd9224ec8709c5b9db932/patches/spidev-enable.patch spidev-enable.patch] is required to use spidev with the Overos. You should customize that patch for the particular device(s) you are using. Things you might want to change are the bus speed and the mode.

The spidev driver is already built into the standard Overo kernels.

Only one protocol driver at a time can manage a particular CS line on a given SPI bus.

As you can see from the above patch, the standard Overo kernels already have devices registering for SPI bus 1 CS0 (ADS7846 touchscreen controller) and SPI bus 1 CS1 (LGPHILIPS LB035Q02 display driver). You will have to disable one or both of these drivers in your kernel config if you want to use those respective CS lines.

If you are using OE, apply the board patch by copying it to the org.openembedded.dev/recipes/linux/linux-omap3-2.6.xx/ directory and then adding a line to include the patch in your kernel recipe org.openembedded.dev/recipes/linux/linux-omap3_2.6.xx.bb

There are more detailed instructions for getting spidev working on an Overo at the 'Writing a Linux SPI driver' link below.

=== Additional Links ===

[http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57:gumstix-spi-driver-part1&catid=35:gumstix&Itemid=62 Writing a Linux SPI driver] - A series of articles using Gumstix Overo in the examples

[http://elinux.org/BeagleBoard/SPI BeagleBoard/SPI] - Beagleboard SPI section on eLinux.org

[http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus Serial Peripheral Interface Bus] - Wikipedia SPI article

[http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

Category:SPI

2011-01-20T15:39:34Z

Sellis: Minor wording changes

== Overo SPI ==

Kernel documentation for the SPI framework can be found in the Documentation directory of your linux source tree or here [http://www.kernel.org/doc/Documentation/spi/spi-summary Documentation/spi/spi-summary].

Linux SPI drivers are broken into two parts. A controller driver that handles direct communication with the hardware and a protocol driver to handle the details of the data for a particular device. The interface defined in spi.c/spi.h is the bridge between the two.

For the OMAP3's, the controller driver is omap2_mcspi.c. The OMAP3's have 4 SPI busses which the omap2_mcspi driver handles. The kernel config option to include the omap2_mcspi driver is CONFIG_SPI_OMAP24XX and is already built into standard Gumstix Overo kernels.

The OMAP3 SPI controller has the ability to act as either a SPI master or SPI slave, but the current kernel code only supports the SPI master configuration.

Gumstix brings out SPI bus 1 chip select pins 0 and 1 on most of the Overo expansion boards.

=== Protocol Drivers ===

A protocol driver is what you need to use the SPI system on Linux.

There are a couple of steps that need to happen.

# Slave devices must be registered for each SPI bus and chip select position used.
# A protocol driver needs to be registered with the system using the same name as the devices it will be handling so the kernel can link the two.

It doesn't matter which order these steps are performed. Most existing SPI drivers do the device registration completely outside the driver code in a board file. If you are writing your own driver, it is probably more convenient to do it in the driver code itself. When both device and driver registration are completed, the probe() function for the protocol driver will be called and SPI communications can start.

SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages in the protocol driver. The protocol driver then submits the SPI messages to the controller driver's I/O queue. These messages are then processed asynchronously by the controller driver in FIFO order. As each message finishes, the controller notifies the protocol driver via a callback function.

There are some synchronous helper functions exposed by the interface to simplify the asynchronous behaviour of the Linux SPI system for protocol driver writers.

=== Spidev ===

Spidev is a standard Linux module that implements a generic SPI protocol driver while exposing a char device interface to userland.

The documentation for spidev can be found here - [http://www.mjmwired.net/kernel/Documentation/spi/spidev Documentation/spi/spidev].

The spidev driver does not register devices so a board file patch like this one [https://github.com/scottellis/spike/blob/0d633a22da47022073abd9224ec8709c5b9db932/patches/spidev-enable.patch spidev-enable.patch] is required to use spidev with the Overos. You should customize that patch for the particular device(s) you are using. Things you might want to change are the bus speed and the mode.

The spidev driver is already built into the standard Overo kernels.

Only one protocol driver at a time can manage a particular CS line on a given SPI bus.

As you can see from the above patch, the standard Overo kernels already have devices registering for SPI bus 1 CS0 (ADS7846 touchscreen controller) and SPI bus 1 CS1 (LGPHILIPS LB035Q02 display driver). You will have to disable one or both of these drivers in your kernel config if you want to use those respective CS lines.

If you are using OE, apply the board patch by copying it to the org.openembedded.dev/recipes/linux/linux-omap3-2.6.xx/ directory and then adding a line to include the patch in your kernel recipe org.openembedded.dev/recipes/linux/linux-omap3_2.6.xx.bb

There are more detailed instructions for getting spidev working on an Overo at the 'Writing a Linux SPI driver' link below.

You can also search the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

=== Custom Driver ===

Here is an article that can get you started writing your own custom SPI driver for Linux using Gumstix Overos as the example board - [http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57:gumstix-spi-driver-part1&catid=35:gumstix&Itemid=62 Writing a Linux SPI driver]

Category:SPI

2011-01-20T13:46:45Z

Sellis: More details

== Overo SPI ==

Kernel documentation for the SPI framework can be found in the Documentation directory of your linux source tree or here [http://www.kernel.org/doc/Documentation/spi/spi-summary Documentation/spi/spi-summary].

Linux SPI drivers are broken into two parts. A controller driver that handles direct communication with the hardware and a protocol driver to handle the details of the data for a particular device. The interface defined in spi.c/spi.h is the bridge between the two.

For the OMAP3's, the controller driver is omap2_mcspi.c. The OMAP3's have 4 SPI busses which the omap2_mcspi driver handles. The kernel config option to include the omap2_mcspi driver is CONFIG_SPI_OMAP24XX and is already built into standard Gumstix Overo kernels.

The OMAP3 SPI controller has the ability to act as either a SPI master or SPI slave, but the current kernel code only supports the SPI master configuration.

Gumstix brings out SPI bus 1 chip select pins 0 and 1 on most of the Overo expansion boards.

=== Protocol Drivers ===

A protocol driver is what you need to use the SPI system on Linux.

There are a couple of steps that need to happen.

# Slave devices must be registered for each SPI bus and chip select position used.
# A protocol driver needs to be registered with the system using the same name as the devices it will be handling so the kernel can link the two.

It doesn't matter which order these steps are performed. Most existing SPI drivers do the device registration completely outside the driver code in a board file. If you are writing your own driver, it is probably more convenient to do it in the driver code itself. When both device and driver registration are completed, the probe() function for the protocol driver will be called and SPI communications can start.

SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages in the protocol driver. The protocol driver then submits the SPI messages to the controller driver's I/O queue. These messages are then processed asynchronously by the controller driver in FIFO order. As each message finishes, the controller notifies the protocol driver via a callback function.

There are some synchronous helper functions exposed by the interface to simplify the asynchronous behaviour of the Linux SPI system for protocol driver writers.

=== Spidev ===

Spidev is a standard Linux module that implements a generic SPI protocol driver while exposing a char device interface to userland.

The documentation for spidev can be found here - [http://www.mjmwired.net/kernel/Documentation/spi/spidev Documentation/spi/spidev].

The spidev driver does not register devices so a board file patch like this one [https://github.com/scottellis/spike/blob/0d633a22da47022073abd9224ec8709c5b9db932/patches/spidev-enable.patch spidev-enable.patch] is required to use spidev with the Overos. You should customize that patch for the particular device you are using. Things you might want to change are the bus speed and the mode.

The spidev driver is built in to the standard Overo kernels.

Only one protocol driver at a time can manage a particular CS line on a given SPI bus.

As you can see from the above patch, the standard Overo kernels already have devices registering for SPI bus 1 CS0 (ADS7846 touchscreen controller) and SPI bus 1 CS1 (LGPHILIPS LB035Q02 display driver). You will have to disable one or both of these drivers in your kernel config if you want to use that respective CS line.

If you are using OE, apply the board patch by copying it to the org.openembedded.dev/recipes/linux/linux-omap3-2.6.xx/ directory and then adding a line to include the patch in your kernel recipe org.openembedded.dev/recipes/linux/linux-omap3_2.6.xx.bb

There are more detailed instructions for getting spidev working on an Overo on the 'Writing a Linux SPI driver' link below.

You can also search the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

=== Custom Driver ===

Here is an article that can get you started writing your own custom SPI driver for Linux using Gumstix Overos as the example board - [http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57:gumstix-spi-driver-part1&catid=35:gumstix&Itemid=62 Writing a Linux SPI driver]

Category:SPI

2011-01-20T13:40:06Z

Sellis: Remove old board patch link

== Overo SPI ==

Kernel documentation for the SPI framework can be found in the Documentation directory of your linux source tree or here [http://www.kernel.org/doc/Documentation/spi/spi-summary Documentation/spi/spi-summary].

Linux SPI drivers are broken into two parts. A controller driver that handles direct communication with the hardware and a protocol driver to handle the details of the data for a particular device. The interface defined in spi.c/spi.h is the bridge between the two.

For the OMAP3's, the controller driver is omap2_mcspi.c. The OMAP3's have 4 SPI busses which the omap2_mcspi driver handles. The kernel config option to include the omap2_mcspi driver is CONFIG_SPI_OMAP24XX and is already built into standard Gumstix Overo kernels.

The OMAP3 SPI controller has the ability to act as either a SPI master or SPI slave, but the current kernel code only supports the SPI master configuration.

Gumstix brings out SPI bus 1 chip select pins 0 and 1 on most of the Overo expansion boards.

=== Protocol Drivers ===

A protocol driver is what you need to use the SPI system on Linux.

There are a couple of steps that need to happen.

# Slave devices must be registered for each SPI bus and chip select position used.
# A protocol driver needs to be registered with the system using the same name as the devices it will be handling so the kernel can link the two.

It doesn't matter which order these steps are performed. Most existing SPI drivers do the device registration completely outside the driver code in a board file. If you are writing your own driver, it is probably more convenient to do it in the driver code itself. When both device and driver registration are completed, the probe() function for the protocol driver will be called and SPI communications can start.

SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages in the protocol driver. The protocol driver then submits the SPI messages to the controller driver's I/O queue. These messages are then processed asynchronously by the controller driver in FIFO order. As each message finishes, the controller notifies the protocol driver via a callback function.

There are some synchronous helper functions exposed by the interface to simplify the asynchronous behaviour of the Linux SPI system for protocol driver writers.

=== Spidev ===

Spidev is a standard Linux module that implements a generic SPI protocol driver while exposing a char device interface to userland.

The documentation for spidev can be found here - [http://www.mjmwired.net/kernel/Documentation/spi/spidev Documentation/spi/spidev].

The spidev driver does not register devices so a board file patch like this one [https://github.com/scottellis/spike/blob/0d633a22da47022073abd9224ec8709c5b9db932/patches/spidev-enable.patch spidev-enable.patch] is required to use spidev with the Overos. You should customize that patch for the particular device you are using. Things you might want to change are the bus speed and the mode.

The spidev driver is built in to the standard Overo kernels. If you are using OE, apply the board patch by copying it to the org.openembedded.dev/recipes/linux/linux-omap3-2.6.xx/ directory and then adding a line to include the patch in your kernel recipe org.openembedded.dev/recipes/linux/linux-omap3_2.6.xx.bb

Only one protocol driver at a time can manage a particular CS line on a given SPI bus.

As you can see from the above patch, the standard Overo kernels already have devices registering for SPI bus 1 CS0 (ADS7846 touchscreen controller) and SPI bus 1 CS1 (LGPHILIPS LB035Q02 display driver). You will have to disable one or both of these drivers in your kernel config if you want to use that respective CS line.

You can also search the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

=== Custom Driver ===

Here is an article that can get you started writing your own custom SPI driver for Linux using Gumstix Overos as the example board - [http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57:gumstix-spi-driver-part1&catid=35:gumstix&Itemid=62 Writing a Linux SPI driver]

Category:SPI

2011-01-20T13:29:02Z

Sellis: Better wording

== Overo SPI ==

Kernel documentation for the SPI framework can be found in the Documentation directory of your linux source tree or here [http://www.kernel.org/doc/Documentation/spi/spi-summary Documentation/spi/spi-summary].

Linux SPI drivers are broken into two parts. A controller driver that handles direct communication with the hardware and a protocol driver to handle the details of the data for a particular device. The interface defined in spi.c/spi.h is the bridge between the two.

For the OMAP3's, the controller driver is omap2_mcspi.c. The OMAP3's have 4 SPI busses which the omap2_mcspi driver handles. The kernel config option to include the omap2_mcspi driver is CONFIG_SPI_OMAP24XX and is already built into standard Gumstix Overo kernels.

The OMAP3 SPI controller has the ability to act as either a SPI master or SPI slave, but the current kernel code only supports the SPI master configuration.

Gumstix brings out SPI bus 1 chip select pins 0 and 1 on most of the Overo expansion boards.

=== Protocol Drivers ===

A protocol driver is what you need to use the SPI system on Linux.

There are a couple of steps that need to happen.

# Slave devices must be registered for each SPI bus and chip select position used.
# A protocol driver needs to be registered with the system using the same name as the devices it will be handling so the kernel can link the two.

It doesn't matter which order these steps are performed. Most existing SPI drivers do the device registration completely outside the driver code in a board file. If you are writing your own driver, it is probably more convenient to do it in the driver code itself. When both device and driver registration are completed, the probe() function for the protocol driver will be called and SPI communications can start.

SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages in the protocol driver. The protocol driver then submits the SPI messages to the controller driver's I/O queue. These messages are then processed asynchronously by the controller driver in FIFO order. As each message finishes, the controller notifies the protocol driver via a callback function.

There are some synchronous helper functions exposed by the interface to simplify the asynchronous behaviour of the Linux SPI system for protocol driver writers.

=== Spidev ===

Spidev is a standard Linux module that implements a generic SPI protocol driver while exposing a char device interface to userland via sysfs.

The documentation for spidev can be found here - [http://www.mjmwired.net/kernel/Documentation/spi/spidev Documentation/spi/spidev].

The spidev driver does not register devices so a board file patch like this one [https://github.com/scottellis/spike/blob/0d633a22da47022073abd9224ec8709c5b9db932/patches/spidev-enable.patch spidev-enable.patch] is required to use spidev with the Overos. You should customize that patch for the particular device you are using. Things you might want to change are the bus speed and the mode.

The spidev driver is built in to the standard Overo kernels. If you are using OE, apply the board patch by copying it to the org.openembedded.dev/recipes/linux/linux-omap3-2.6.xx/ directory and then adding a line to include the patch in your kernel recipe org.openembedded.dev/recipes/linux/linux-omap3_2.6.xx.bb

As you can see from the patch, the standard Overo kernels already occupy the SPI bus 1 chip select lines 0 and 1 if either the ADS7846 touchscreen controller (CS0) or the LGPHILIPS LB035Q02 display driver (CS1) are enabled. You will have to disable these drivers in your kernel config if you want to connect your device to either of these lines. Only one protocol driver at a time can manage a particular CS line on a given SPI bus.

Here's one Gumstix [http://www.nabble.com/SPI%2C-spidev%2C-et.-al-to24588398.html#a24594755 mailing list thread] posted on 7/21/09, where some users have successfully used spidev with the Overos.

You can also search the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

=== Custom Driver ===

Here is an article that can get you started writing your own custom SPI driver for Linux using Gumstix Overos as the example board - [http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57:gumstix-spi-driver-part1&catid=35:gumstix&Itemid=62 Writing a Linux SPI driver]

Category:SPI

2011-01-20T12:11:16Z

Sellis: Clean up SPI description and add link for writing a driver

== Overo SPI ==

Kernel documentation for the SPI framework can be found in the Documentation directory of your linux source tree or here [http://www.kernel.org/doc/Documentation/spi/spi-summary Documentation/spi/spi-summary].

Linux SPI drivers are broken into two parts. A controller driver that handles direct communication with the hardware and a protocol driver to handle the details of the data for a particular device. The interface defined in spi.c/spi.h is the bridge between the two.

For the OMAP3's, the controller driver is omap2_mcspi.c. The OMAP3's have 4 SPI busses which the omap2_mcspi driver handles. The kernel config option to include the omap2_mcspi driver is CONFIG_SPI_OMAP24XX and is already built into standard Gumstix Overo kernels.

The OMAP3 SPI controller has the ability to act as either a SPI master or SPI slave, but the current kernel code only supports the SPI master configuration.

Gumstix brings out SPI bus 1 chip select pins 0 and 1 on most of the Overo expansion boards.

=== Protocol Drivers ===

A protocol driver is what you need if you want to use the SPI system.

There are a couple of steps every SPI protocol driver needs to follow.

# Slave devices must be registered for each SPI bus and chip select position used.
# The SPI protocol driver needs to be registered with the system using the same name as the devices it will be handling so the kernel can link the two.

It doesn't matter which order these steps are performed. Most existing SPI drivers do the device registration completely outside the driver code in a board file. If you are writing your own driver, it is probably more convenient to do it in the driver code itself. When both device and driver registration are completed, the probe() function for the driver will be called and SPI communications can start.

SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages in the protocol driver. The protocol driver then submits the SPI messages to the controller driver's I/O queue with calls to spi_async(). These messages are processed in FIFO order asynchronously by the controller driver. As each message finishes, the controller notifies the protocol driver via 'completion' callbacks. The protocol driver can then process the raw data as necessary.

There are some simple synchronous functions exposed by the spi.h/spi.c interface to simplify the asynchronous behaviour of the Linux SPI system for protocol drivers.

=== Spidev ===

Spidev is a standard Linux module that implements a generic SPI protocol driver while exposing a char device interface to userland via sysfs.

The documentation for spidev can be found here - [http://www.mjmwired.net/kernel/Documentation/spi/spidev Documentation/spi/spidev].

The spidev driver does not register devices so a board file patch like this one [https://github.com/scottellis/spike/blob/0d633a22da47022073abd9224ec8709c5b9db932/patches/spidev-enable.patch spidev-enable.patch] is required to use spidev with the Overos. You should customize that patch for the particular device you are using. Things you might want to change are the bus speed and the mode.

The spidev driver is built in to the standard Overo kernels. If you are using OE, apply the board patch by copying it to the org.openembedded.dev/recipes/linux/linux-omap3-2.6.xx/ directory and then adding a line to include the patch in your kernel recipe org.openembedded.dev/recipes/linux/linux-omap3_2.6.xx.bb

As you can see from the patch, the standard Overo kernels already occupy the SPI bus 1 chip select lines 0 and 1 if either the ADS7846 touchscreen controller (CS0) or the LGPHILIPS LB035Q02 display driver (CS1) are enabled. You will have to disable these drivers in your kernel config if you want to connect your device to either of these lines. Only one protocol driver at a time can manage a particular CS line on a given SPI bus.

Here's one Gumstix [http://www.nabble.com/SPI%2C-spidev%2C-et.-al-to24588398.html#a24594755 mailing list thread] posted on 7/21/09, where some users have successfully used spidev with the Overos.

You can also search the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

=== Custom Driver ===

Here is an article that can get you started writing your own custom SPI driver for Linux using Gumstix Overos as the example board - [http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57:gumstix-spi-driver-part1&catid=35:gumstix&Itemid=62 Writing a Linux SPI driver]

Kernel Reconfiguration

2010-08-30T09:21:14Z

Sellis: Removed redundant cd command

[[Category:How_to_-_linux]]
[[Category:How_to_-_general]]
There are several possible work flows for modifying the kernel:
[[http://blogs.elphel.com/2009/12/openembeddedangstrom-kernel-workflow/ Using bitbake]]
[[http://bec-systems.com/site/521/best-practices-for-kernel-development-with-openembedded Using kernel tools]]

==Overo==

These instructions assume you are using the default gumstix-oe kernel which is declared here

$ cd $OVEROTOP
$ grep linux org.openembedded/conf/machine/overo.conf
PREFERRED_PROVIDER_virtual/kernel = "linux-omap3"

And the current revision as defined here

$ bitbake --show-versions | grep linux-omap3
linux-omap3 0:2.6.32-r51

So the rest of the example will assume linux-omap3-2.6.32 revision 51. This is the kernel that will be built when we use the reference 'virtual/kernel' in bitbake commands.

Substitute the kernel version and revision your system is using in the following steps.

First build the kernel normally with bitbake. If you have built an image, then it's already done.

If not run this command

$ bitbake virtual/kernel

This will create a source directory in the ${OVEROTOP}/tmp/work/overo-angstrom-linux-gnueabi directory.
In this case it will be

${OVEROTOP}/tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.32-r51

To modify the kernel configuration, run menuconfig via bitbake. Make your changes and save the configuration.

$ bitbake -c menuconfig virtual/linux

The new kernel configuration file you created can be found here.

${OVEROTOP}/tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.32-r51/git/.config

Copy that file to where the bitbake recipe for the kernel will use it.

$ cp ${OVEROTOP}/tmp/work/overo-angstrom-linux/gnueabi/linux-omap3-2.6.32-r51/git/.config \
${OVEROTOP}/org.openembedded.dev/recipes/linux/linux-omap3-2.6.32/overo/defconfig

Then rebuild the kernel.

$ bitbake -c clean virtual/kernel
$ bitbake virtual/kernel

Then rebuild the rootfs to get the modules installed correctly.

Substitute the image you are using, the example if you are using the omap3-console-image.

$ bitbake omap3-console-image

Finally, install the new kernel and rootfs the way you normally would using either a
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html microSD card]
or by copying to [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html onboard nand].

==Verdex==

To reconfigure the kernel with the current state of Gumstix's OE things, you will need ''gnome-terminal''. Run this command: '''bitbake gumstix-kernel -c menuconfig'''

NOTE: You have to have ncurses and ncurses-dev installed in order for the MENUCONFIG to actually work. 
NOTE: If a screen flashes infront of you and dissapears edit $OE_HOME/org.openembedded.snapshot/conf/bitbake.conf to the following 
<code><pre>
-GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -x ${SHELLRCCMD}'
+GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -x ${SHELLCMDS}'
</pre></code>

NOTE: If you don't have gnome-terminal installed and wish to use xterm instead, use:
<code><pre>
-GNOME_TERMCMD = 'gnome-terminal --disable-factory -t "$TERMWINDOWTITLE"'
-GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -x ${SHELLRCCMD}'
+GNOME_TERMCMD = 'xterm -title "$TERMWINDOWTITLE"'
+GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -e ${SHELLCMDS}'
</pre></code>

The kernel config information is kept in 
''$OE_HOME/com.gumstix.collection/packages/linux/gumstix-kernel-2.6.XX/gumstix-custom-YYYYY/defconfig'' 
where XX is the current default kernel version for your bitbake environment. That nugget is set in the
''$OE_HOME/com.gumstix.collection/conf/machine/include/gumstix.inc'' file, under the PREFERRED_VERSION_gumstix-kernel
and YYYYY is usually one of connex/basix/verdex. That nugget comes from 
''$OE_HOME/build/conf/auto.conf''

After running menuconfig, running "bitbake -c rebuild gumstix-kernel" will blow away the customizations just made. There is probably a better way to do this, but in order to preserve the customizations, you can copy the new config file and replace the default config. For example, to preserve a verdex board's config, do:

<code><pre>
cp \
$OE_HOME/tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.21-r1/linux-2.6.21/.config \
$OE_HOME/com.gumstix.collection/packages/linux/gumstix-kernel-2.6.21/gumstix-custom-verdex/defconfig
</pre></code>

Now that you have replaced the default config, the following commands will rebuild and repackage the new kernel and create new images for you:

<code><pre>
bitbake -c rebuild gumstix-kernel
bitbake -c rebuild task-base-gumstix
bitbake gumstix-basic-image
</pre></code>

==Other notes==
Totally lost inside of menuconfig? Press '/' to search for appropriate options.

Want to know more about the kernel? I found the 'Linux Kernel in a Nutshell' book (not to be confused with the 'Linux in a Nutshell' book) quite helpful. The book is freely available online here (http://www.kroah.com/lkn/); Chapter 4 (Configuring and Building) and Chapter 6 (Upgrading a Kernel) as well as the first bit of Chapter 7 (Customizing a Kernel) and the last bit of Chapter 8 (Kernel Configuration: Kernel Debugging) have useful notes about kernel configuration.

Your kernel is now larger than the 1MB originally specified so do_sizecheck() fails?
You'll probably want to edit the ~/verdex-oe/org.openembedded.dev/conf/machine/include and change the maximum image size to, say, 2MB, i.e. KERNEL_IMAGE_MAXSIZE = "2097153". Actually, you should really do this in the user.collections directory to keep the original source tree clean.

Kernel Reconfiguration

2010-08-30T09:18:22Z

Sellis: Use virtual/kernel in bitbake commands

[[Category:How_to_-_linux]]
[[Category:How_to_-_general]]
There are several possible work flows for modifying the kernel:
[[http://blogs.elphel.com/2009/12/openembeddedangstrom-kernel-workflow/ Using bitbake]]
[[http://bec-systems.com/site/521/best-practices-for-kernel-development-with-openembedded Using kernel tools]]

==Overo==

These instructions assume you are using the default gumstix-oe kernel which is declared here

$ cd $OVEROTOP
$ grep linux org.openembedded/conf/machine/overo.conf
PREFERRED_PROVIDER_virtual/kernel = "linux-omap3"

And the current revision as defined here

$ bitbake --show-versions | grep linux-omap3
linux-omap3 0:2.6.32-r51

So the rest of the example will assume linux-omap3-2.6.32 revision 51. This is the kernel that will be built when we use the reference 'virtual/kernel' in bitbake commands.

Substitute the kernel version and revision your system is using in the following steps.

First build the kernel normally with bitbake. If you have built an image, then it's already done.

If not run this command

$ bitbake virtual/kernel

This will create a source directory in the ${OVEROTOP}/tmp/work/overo-angstrom-linux-gnueabi directory.
In this case it will be

${OVEROTOP}/tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.32-r51

To modify the kernel configuration, run menuconfig via bitbake. Make your changes and save the configuration.

$ cd $OVEROTOP
$ bitbake -c menuconfig virtual/linux

The new kernel configuration file you created can be found here.

${OVEROTOP}/tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.32-r51/git/.config

Copy that file to where the bitbake recipe for the kernel will use it.

$ cp ${OVEROTOP}/tmp/work/overo-angstrom-linux/gnueabi/linux-omap3-2.6.32-r51/git/.config \
${OVEROTOP}/org.openembedded.dev/recipes/linux/linux-omap3-2.6.32/overo/defconfig

Then rebuild the kernel.

$ bitbake -c clean virtual/kernel
$ bitbake virtual/kernel

Then rebuild the rootfs to get the modules installed correctly.

Substitute the image you are using, the example assumes the omap3-console-image.

$ bitbake omap3-console-image

Finally, install the new kernel and rootfs the way you normally would using either a
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html microSD card]
or by copying to [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html onboard nand].

==Verdex==

To reconfigure the kernel with the current state of Gumstix's OE things, you will need ''gnome-terminal''. Run this command: '''bitbake gumstix-kernel -c menuconfig'''

NOTE: You have to have ncurses and ncurses-dev installed in order for the MENUCONFIG to actually work. 
NOTE: If a screen flashes infront of you and dissapears edit $OE_HOME/org.openembedded.snapshot/conf/bitbake.conf to the following 
<code><pre>
-GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -x ${SHELLRCCMD}'
+GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -x ${SHELLCMDS}'
</pre></code>

NOTE: If you don't have gnome-terminal installed and wish to use xterm instead, use:
<code><pre>
-GNOME_TERMCMD = 'gnome-terminal --disable-factory -t "$TERMWINDOWTITLE"'
-GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -x ${SHELLRCCMD}'
+GNOME_TERMCMD = 'xterm -title "$TERMWINDOWTITLE"'
+GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -e ${SHELLCMDS}'
</pre></code>

The kernel config information is kept in 
''$OE_HOME/com.gumstix.collection/packages/linux/gumstix-kernel-2.6.XX/gumstix-custom-YYYYY/defconfig'' 
where XX is the current default kernel version for your bitbake environment. That nugget is set in the
''$OE_HOME/com.gumstix.collection/conf/machine/include/gumstix.inc'' file, under the PREFERRED_VERSION_gumstix-kernel
and YYYYY is usually one of connex/basix/verdex. That nugget comes from 
''$OE_HOME/build/conf/auto.conf''

After running menuconfig, running "bitbake -c rebuild gumstix-kernel" will blow away the customizations just made. There is probably a better way to do this, but in order to preserve the customizations, you can copy the new config file and replace the default config. For example, to preserve a verdex board's config, do:

<code><pre>
cp \
$OE_HOME/tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.21-r1/linux-2.6.21/.config \
$OE_HOME/com.gumstix.collection/packages/linux/gumstix-kernel-2.6.21/gumstix-custom-verdex/defconfig
</pre></code>

Now that you have replaced the default config, the following commands will rebuild and repackage the new kernel and create new images for you:

<code><pre>
bitbake -c rebuild gumstix-kernel
bitbake -c rebuild task-base-gumstix
bitbake gumstix-basic-image
</pre></code>

==Other notes==
Totally lost inside of menuconfig? Press '/' to search for appropriate options.

Want to know more about the kernel? I found the 'Linux Kernel in a Nutshell' book (not to be confused with the 'Linux in a Nutshell' book) quite helpful. The book is freely available online here (http://www.kroah.com/lkn/); Chapter 4 (Configuring and Building) and Chapter 6 (Upgrading a Kernel) as well as the first bit of Chapter 7 (Customizing a Kernel) and the last bit of Chapter 8 (Kernel Configuration: Kernel Debugging) have useful notes about kernel configuration.

Your kernel is now larger than the 1MB originally specified so do_sizecheck() fails?
You'll probably want to edit the ~/verdex-oe/org.openembedded.dev/conf/machine/include and change the maximum image size to, say, 2MB, i.e. KERNEL_IMAGE_MAXSIZE = "2097153". Actually, you should really do this in the user.collections directory to keep the original source tree clean.

Category:How to - usb

2010-08-25T23:00:41Z

Sellis: A little clarity on the -s switch.

Note: if you have issues with USB not resuming properly after a suspend on Overo, please see [http://old.nabble.com/Update-on-Overo-EHCI-issues-td27617583.html#a27617583 this] forum post.
==USBNet with Overo==

The OTG USB port on the Overo expansion boards support USB networking. To enable this, the OTG port needs to be configured as a USB peripheral or gadget. The default kernels from Gumstix have the OTG port configured to act as a USB host.

The procedure for changing the configuration requires rebuilding your kernel, so you should first be comfortable with [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html setting up a build environment] and building images for your Overo.

The following steps assume you are using a recent snapshot of the gumstix-oe git tree and are going to use kernel version 2.6.31 or greater.

The gumstix recipes for these kernels have a variable that allows you to specify how the OTG usb port is configured.

Gumstix Overos use the linux-omap3 kernels by default. You can check which kernel version you'll be working with this way:

$ cd ${OVEROTOP}
$ bitbake --show-versions | grep linux-omap3
linux-omap3 0:2.6.34-r81

So the recipe file in this case would be ${OVEROTOP}/org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb.

You'll see a line in there

MUSB_MODE ?= "host"

There are three valid values for MUSB_MODE: "host", "peripheral" or "otg".

You could change the MUSB_MODE assignment directly in the recipe, but a better way to do this is to modify your local.conf file and add a MUSB_MODE variable.

The ?= assignment means "host" will be assigned to MUSB_MODE only if it does not already have a value which it will if you give it one in local.conf.

The local.conf file is found here ${OVEROTOP}/build/conf/local.conf.

Add the line

MUSB_MODE = "peripheral"

or

MUSB_MODE = "otg"

depending on your preference.

Now rebuild your kernel.

$ cd ${OVEROTOP}
$ bitbake -c clean linux-omap3
$ bitbake linux-omap3

And then rebuild your rootfs since the drivers available in /lib/modules will have changed.

$ bitbake omap3-console-image

Change omap3-console-image to whatever image you use.

Install the new kernel and rootfs the way you normally would using either a
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html microSD card]
or by copying to [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html onboard nand].

Once you have booted the new system, you still need to load the g_ether driver since it was built as a module.

You can add g_ether to /etc/modules if you always want it to load at boot.

root@overo# modbprobe g_ether
g_ether gadget: using random self ethernet address
g_ether gadget: using random host ethernet address
usb0: MAC d6:2c:8f:d9:51:32
usb0: HOST MAC f2:99:dc:4c:cb:7a
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready

root@overo:~# ifconfig -a
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

usb0 Link encap:Ethernet HWaddr D6:2C:8F:D9:51:32
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Configure the usb0 interface the way you would any other.

For example

root@overo:~# ifconfig usb0 192.168.20.2 netmask 255.255.255.0

If you then plug the usb OTG cable into a host computer ready for usb networking you'll get a console message

g_ether gadget: high speed config #1: CDC Ethernet (ECM)

The rest is all standard Linux networking.

Category:How to - Build helloworld

2010-08-14T14:08:00Z

Sellis: Fixed some whitespace

==Overview==

What follows is a description for building C programs on a workstation using the cross-build tools of [http://wiki.openembedded.net/index.php/Main_Page OpenEmbedded], but NOT USING the bitbake/recipe framework.

For an alternative method USING the bitbake/recipe framework, a series of sample recipes can be found [[HelloWorld Examples | here]].

==Setup==

Follow the instructions for [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html setting up a build environment] to get the cross-build tools correctly installed.

The tools are built under the TMPDIR directory declared in ${OVEROTOP}/build/conf/site.conf.

TMPDIR defaults to ${OVEROTOP}/tmp, but you can point it somewhere else.

==Makefile==

After you have built an image, the cross-tools will be installed on your workstation.

You can now create a standard makefile for your project pointing to this cross-build toolchain.

Here is a simple example for helloworld.

# Makefile for building with the OE cross tools
#
# OVEROTOP is normally ${HOME}/overo-oe
#
# OETMP is the same as TMPDIR as defined in ${OVEROTOP}/build/conf/site.conf
#

OETMP = ${OVEROTOP}/tmp

# There were some OE toolchain path changes recently

# OE prior to around 30July2010
# TOOLDIR = ${OETMP}/cross/armv7a/bin
# STAGEDIR = ${OETMP}/staging/armv7a-angstrom-linux-gnueabi/usr

# OE after 30July2010
TOOLDIR = ${OETMP}/sysroots/`uname -m`-linux/usr/armv7a/bin
STAGEDIR = ${OETMP}/sysroots/armv7a-angstrom-linux-gnueabi/usr

CC = ${TOOLDIR}/arm-angstrom-linux-gnueabi-gcc

CFLAGS = -Wall

LIBDIR = ${STAGEDIR}/lib

INCDIR = ${STAGEDIR}/include

TARGET = helloworld

OBJS = helloworld.o

${TARGET} : $(OBJS)
${CC} ${CFLAGS} ${OBJS} -L ${LIBDIR} -o ${TARGET}

helloworld.o: helloworld.c
${CC} ${CFLAGS} -I ${INCDIR} -c helloworld.c

clean:
rm -f ${TARGET} ${OBJS} *~

==Distribute==

After building with make, copy the resulting target executable to the overo.

Here are some alternatives.

1. If you are using [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html a microSD card], copy your executable to the rootfs before you unmount it in the final step.

2. If you have a network connection to the overo, use scp.

3. If you are doing a [http://www.gumstix.net/wiki/index.php?title=Category:How_to_-_Network_Boot network boot] then copy the executable directly to the nfs exported root filesystem the gumstix is using on the workstation.

==Only the Tools==

You don't need to build a complete image to get the cross-tools.

If you only want to cross compile a C program without third-party dependencies, then you can build just the gcc-cross recipe.

bitbake gcc-cross

You can use OE to selectively build additional cross-compiled libraries as needed. Look around in the OE recipes folder.

If you build a complete image, then most of the cross-build tools and libraries will get installed as as side-effect. That is probably the easiest way to setup your workstation the first time.

Category:How to - Build helloworld

2010-08-14T14:01:13Z

Sellis: Update for latest OE toolchain changes

==Overview==

What follows is a description for building C programs on a workstation using the cross-build tools of [http://wiki.openembedded.net/index.php/Main_Page OpenEmbedded], but NOT USING the bitbake/recipe framework.

For an alternative method USING the bitbake/recipe framework, a series of sample recipes can be found [[HelloWorld Examples | here]].

==Setup==

Follow the instructions for [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html setting up a build environment] to get the cross-build tools correctly installed.

The tools are built under the TMPDIR directory declared in ${OVEROTOP}/build/conf/site.conf.

TMPDIR defaults to ${OVEROTOP}/tmp, but you can point it somewhere else.

==Makefile==

After you have built an image, the cross-tools will be installed on your workstation.

You can now create a standard makefile for your project pointing to this cross-build toolchain.

Here is a simple example for helloworld.

# Makefile for building with the OE cross tools
#
# OVEROTOP is normally ${HOME}/overo-oe
#
# OETMP is the same as TMPDIR as defined in ${OVEROTOP}/build/conf/site.conf
#

OETMP = ${OVEROTOP}/tmp

# OE prior to around 30July2010
# TOOLDIR = ${OETMP}/cross/armv7a/bin
# STAGEDIR = ${OETMP}/staging/armv7a-angstrom-linux-gnueabi/usr

# OE after 30July2010, the multi-machine safe toolchain patches
TOOLDIR = ${OETMP}/sysroots/`uname -m`-linux/usr/armv7a/bin
STAGEDIR = ${OETMP}/sysroots/armv7a-angstrom-linux-gnueabi/usr

CC = ${TOOLDIR}/arm-angstrom-linux-gnueabi-gcc

CFLAGS = -Wall

LIBDIR = ${STAGEDIR}/lib

INCDIR = ${STAGEDIR}/include

TARGET = helloworld

OBJS = helloworld.o

${TARGET} : $(OBJS)
${CC} ${CFLAGS} ${OBJS} -L ${LIBDIR} -o ${TARGET}

helloworld.o: helloworld.c
${CC} ${CFLAGS} -I ${INCDIR} -c helloworld.c

clean:
rm -f ${TARGET} ${OBJS} *~

==Distribute==

After building with make, copy the resulting target executable to the overo.

Here are some alternatives.

1. If you are using [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html a microSD card], copy your executable to the rootfs before you unmount it in the final step.

2. If you have a network connection to the overo, use scp.

3. If you are doing a [http://www.gumstix.net/wiki/index.php?title=Category:How_to_-_Network_Boot network boot] then copy the executable directly to the nfs exported root filesystem the gumstix is using on the workstation.

==Only the Tools==

You don't need to build a complete image to get the cross-tools.

If you only want to cross compile a C program without third-party dependencies, then you can build just the gcc-cross recipe.

bitbake gcc-cross

You can use OE to selectively build additional cross-compiled libraries as needed. Look around in the OE recipes folder.

If you build a complete image, then most of the cross-build tools and libraries will get installed as as side-effect. That is probably the easiest way to setup your workstation the first time.

Category:How to - i2c

2010-08-12T20:52:12Z

Sellis: Remove the Further Information section since the link dest has no content

==Background==

I2c is a 2-wire serial 8 bit communications protocol from the old days. It is mainly used to communicate between on-board components when the design does not allow for a data and address bus. Typical components are elapsed timer chips, ee-proms, FRAM's, A/D and D/A chips. Some cpu's have the I2c hardware shift registers built in.

The 2 wires are the SCL or clock wire and the SDL or data wire. The clock high to low transition is used to signal that the data wire has a stable 1/0 data value and that the receiver should shift this into the data results register. The clock line is high when the bus is idle. A special high to low transition on the clock line followed by a high to low transition on the data line signals the start of a message sequence. the end of a message sequence is a low to high transition in the data line followed by a low to high transition in the SCL line. An important aspect of this communication standard is that each device is assigned a unique 7 bit address, (oh yea the 8th bit is the Read/write indicator to complete the byte). The device address is the first byte sent in any communication. Subsequent bytes of a message depend on the device you are talking to.

Because of patents that have since expired, other companies had to use slightly different ways to do the same thing so a very similar serial communications method called SPI uses 4 wires and another called TWI uses the same 2 wires.

== I2C with Gumstix Overo ==

There are several i2c buses available on the overo board.

The bus accessible from most of the 40 pin expansion board headers is i2c-3.

Refer to the board [http://pubs.gumstix.com/boards/ schematics] to find whether the board you are using exposes the i2c lines.

You are looking for GPIO184_SCL3 and GPIO185_SDA3.

For many of the boards, pin 23 is SCL and pin 24 is SDA.

The voltage levels are 1.8v, so a voltage level shifter is required to connect to 3.3 or 5 volt slave devices.
A good explanation can be found [http://www.nxp.com/documents/application_note/AN10441.pdf here.]

The overo main board already has pullup resistors for SCL and SDA.

The default gumstix kernels set the i2c-3 bus speed to 400 kHz.

This can be changed to 100 kHz with a kernel command line parameter in u-boot.

i2c_bus=3,100

The i2c-3 bus appears as a character device under /dev

root@overo:/dev# ls -all i2c*
crw-rw---- 1 root root 89, 1 Jan 1 2000 i2c-1
crw-rw---- 1 root root 89, 3 Jan 1 2000 i2c-3

Programmers can access devices on the bus using standard unix file i/o.

You must set the slave address with an ioctl() call prior to communicating with a slave device.

The driver takes care of shifting the slave address one bit and appending the R/W bit in the first byte of the transfer.

Here's a C example minus any error checking.

...
#include <stdint.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <linux/i2c-dev.h> /* for I2C_SLAVE */
...

int fh;
uint8_t data[4];

fh = open("/dev/i2c-3", O_RDWR);

/* tell the driver we want the device with address 0x20 on the I2C bus */
ioctl(fh, I2C_SLAVE, 0x20);

/* write two bytes */
data[0] = 0x05;
data[1] = 0x08;
write(fh, data, 2);

/* read 4 bytes */
read(fh, data, 4);

close(fh);

==Sample code==

Here is a small project showing how to write Overo I2C userland code to communicate with an I/O expander as the slave device. It includes a schematic for the voltage level conversion of the I2C lines that's required.

[http://github.com/scottellis/overo-mcp23017 overo-mcp23017]

[[Category:How_to_-_general]]

Category:How to - usb

2010-07-24T13:34:37Z

Sellis: Simplified, remove kernel version numbers

Note: if you have issues with USB not resuming properly after a suspend on Overo, please see [http://old.nabble.com/Update-on-Overo-EHCI-issues-td27617583.html#a27617583 this] forum post.
==USBNet with Overo==

The OTG USB port on the Overo expansion boards support USB networking. To enable this, the OTG port needs to be configured as a USB peripheral or gadget. The default kernels from Gumstix have the OTG port configured to act as a USB host.

The procedure for changing the configuration requires rebuilding your kernel, so you should first be comfortable with [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html setting up a build environment] and building images for your Overo.

The following steps assume you are using a recent snapshot of the gumstix-oe git tree and are going to use kernel version 2.6.31 or greater.

The gumstix recipes for these kernels has a variable that allows you to specify how the OTG usb port is configured.

You can check which kernel you'll be working with like this.

$ cd ${OVEROTOP}
$ bitbake -s | grep linux-omap3
linux-omap3 0:2.6.34-r81

So the recipe file in this case would be ${OVEROTOP}/org.openembedded.dev/recipes/linux/linux-omap3_2.6.34.bb.

You'll see a line in there

MUSB_MODE ?= "host"

There are three valid values for MUSB_MODE: "host", "peripheral" or "otg".

You could change the MUSB_MODE assignment directly in the recipe, but a better way to do this is to modify your local.conf file and add a MUSB_MODE variable.

The ?= assignment means "host" will be assigned to MUSB_MODE only if it does not already have a value which it will if you give it one in local.conf.

The local.conf file is found here ${OVEROTOP}/build/conf/local.conf.

Add the line

MUSB_MODE = "peripheral"

or

MUSB_MODE = "otg"

depending on your preference.

Now rebuild your kernel.

$ cd ${OVEROTOP}
$ bitbake -c clean linux-omap3
$ bitbake linux-omap3

And then rebuild your rootfs since the drivers available in /lib/modules will have changed.

$ bitbake omap3-console-image

Change omap3-console-image to whatever image you use.

Install the new kernel and rootfs the way you normally would using either a
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html microSD card]
or by copying to [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html onboard nand].

Once you have booted the new system, you still need to load the g_ether driver since it was built as a module.

You can add g_ether to /etc/modules if you always want it to load at boot.

root@overo# modbprobe g_ether
g_ether gadget: using random self ethernet address
g_ether gadget: using random host ethernet address
usb0: MAC d6:2c:8f:d9:51:32
usb0: HOST MAC f2:99:dc:4c:cb:7a
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready

root@overo:~# ifconfig -a
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

usb0 Link encap:Ethernet HWaddr D6:2C:8F:D9:51:32
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Configure the usb0 interface the way you would any other.

For example

root@overo:~# ifconfig usb0 192.168.20.2 netmask 255.255.255.0

If you then plug the usb OTG cable into a host computer ready for usb networking you'll get a console message

g_ether gadget: high speed config #1: CDC Ethernet (ECM)

The rest is all standard Linux networking.

Category:How to - Build helloworld

2010-07-21T12:32:42Z

Sellis: linux-libc-headers already gets built with gcc-cross. Bad example.

==Overview==

What follows is a description for building C programs on a workstation using the cross-build tools of [http://wiki.openembedded.net/index.php/Main_Page OpenEmbedded], but NOT USING the bitbake/recipe framework.

For an alternative method USING the bitbake/recipe framework, a series of sample recipes can be found [[HelloWorld Examples | here]].

==Setup==

Follow the instructions for [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html setting up a build environment] to get the cross-build tools correctly installed.

The tools are built under the TMPDIR directory declared in ${OVEROTOP}/build/conf/site.conf.

TMPDIR defaults to ${OVEROTOP}/tmp, but you can point it somewhere else.

==Makefile==

After you have built an image, the cross-tools will be installed on your workstation.

You can now create a standard makefile for your project pointing to this cross-build toolchain.

Here is a simple example for helloworld.

# Makefile for building with the OE cross tools
#
# OVEROTOP is normally ${HOME}/overo-oe
#
# OETMP is the same as TMPDIR as defined in ${OVEROTOP}/build/conf/site.conf
#

OETMP = ${OVEROTOP}/tmp

TOOLDIR = ${OETMP}/cross/armv7a/bin

STAGEDIR = ${OETMP}/staging/armv7a-angstrom-linux-gnueabi/usr

CC = ${TOOLDIR}/arm-angstrom-linux-gnueabi-gcc

CFLAGS = -Wall

LIBDIR = ${STAGEDIR}/lib

INCDIR = ${STAGEDIR}/include

TARGET = helloworld

OBJS = helloworld.o

${TARGET} : $(OBJS)
${CC} ${CFLAGS} ${OBJS} -L ${LIBDIR} -o ${TARGET}

helloworld.o: helloworld.c
${CC} ${CFLAGS} -I ${INCDIR} -c helloworld.c

clean:
rm -f ${TARGET} ${OBJS} *~

==Distribute==

After building with make, copy the resulting target executable to the overo.

Here are some alternatives.

1. If you are using [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html a microSD card], copy your executable to the rootfs before you unmount it in the final step.

2. If you have a network connection to the overo, use scp.

3. If you are doing a [http://www.gumstix.net/wiki/index.php?title=Category:How_to_-_Network_Boot network boot] then copy the executable directly to the nfs exported root filesystem the gumstix is using on the workstation.

==Only the Tools==

You don't need to build a complete image to get the cross-tools.

If you only want to cross compile a C program without third-party dependencies, then you can build just the gcc-cross recipe.

bitbake gcc-cross

You can use OE to selectively build additional cross-compiled libraries as needed. Look around in the OE recipes folder.

If you build a complete image, then most of the cross-build tools and libraries will get installed as as side-effect. That is probably the easiest way to setup your workstation the first time.

Build Environment Ubuntu 9.04

2010-06-14T14:16:11Z

Sellis: Redirect overo users

== Overo Users ==

These instructions are not for the Gumstix Overo.

Overo users should use the instructions here - [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html Overo-Setup-and-Programming/Setting-up-a-build-environment].

== Overview ==

This is based on the set-up for Ubuntu 8.10 with file modifications as described [http://www.nabble.com/Ubuntu-8.10-and-Open-Embeded-td21136352.html on this thread]. gumstix-oe version is 318.

This HOWTO has also been tested and found to work with Ubuntu 9.10.

== Setup Build Environment ==
1) Get Ubuntu linux 9.04, and install it on your computer; you can install a vmware version of Ubuntu too, but it will be slow during the building process.

Reconfigure sh to point to bash, not dash:

sudo dpkg-reconfigure dash

Answer no when asked whether you want to install dash as /bin/sh.

2) Install (build-essential, help2man, diffstat, texi2html, texinfo, libncurses5-dev, cvs, gawk, python-dev, python-pysqlite2, python-psyco, ckermit, lrzsz, subversion) by using apt-get. i.e:
sudo apt-get update
sudo apt-get install build-essential help2man diffstat texi2html texinfo libncurses5-dev cvs gawk
sudo apt-get install python-dev python-pysqlite2 python-psyco ckermit lrzsz subversion

See [[Bitbake_on_Ubuntu|Bitbake On Ubuntu]] for directions on how to setup Bitbake.

3) Download the source from svn, caching the source code
mkdir ~/gumstix
cd ~/gumstix
<nowiki>svn co https://gumstix.svn.sourceforge.net/svnroot/gumstix/trunk gumstix-oe</nowiki>
cat gumstix-oe/extras/profile >> ~/.bashrc
sudo groupadd oe
sudo usermod -a -G oe YOUR_CURRENT_USERNAME
sudo mkdir /usr/share/sources
sudo chgrp oe /usr/share/sources
sudo chmod 0775 /usr/share/sources
sudo chmod ug+s /usr/share/sources

3.5) Modify ~/gumstix/gumstix-oe/org.openembedded.snapshot/classes/base.bbclass to correct a common SIGPIPE error (fix is in OE trunk, but not yet in gumstix-oe). basically we are adding a small function called subprocess_setup() which removes the SIGPIPE handler and then modifying oe_unpack_file() to call the function instead of system():

<pre>--- a/classes/base.bbclass
+++ b/classes/base.bbclass
@@ -728,9 +728,14 @@
:
}

+def subprocess_setup():
+ import signal, subprocess
+ # Python installs a SIGPIPE handler by default. This is usually not what
+ # non-Python subprocesses expect.
+ signal.signal(signal.SIGPIPE, signal.SIG_DFL)

def oe_unpack_file(file, data, url = None):
- import bb, os
+ import bb, os, signal, subprocess
if not url:
url = "file://%s" % file
dots = file.split(".")
@@ -799,7 +804,7 @@

cmd = "PATH=\"%s\" %s" % (bb.data.getVar('PATH', data, 1), cmd)
bb.note("Unpacking %s to %s/" % (base_path_out(file, data), base_path_out(os.getcwd(), data)))
- ret = os.system(cmd)
+ ret = subprocess.call(cmd, preexec_fn=subprocess_setup, shell=True)

os.chdir(save_cwd)
</pre>

(source: kergoth on #oe on irc.freenode.net. [http://gitorious.org/gumstix-oe/mainline/commit/f73c64e7295be1e1065f898b49f50a02e812161c original commit])

4) Downgrade to gcc-4.1 and g++-4.1 and change the links:

sudo aptitude install gcc-4.1 g++-4.1
sudo ln -sf /usr/bin/gcc-4.1 /usr/bin/gcc
sudo ln -sf /usr/bin/g++-4.1 /usr/bin/g++

Check the links are correct using:

ls -l /usr/bin/gcc
ls -l /usr/bin/g++

5) Log out and log in again.

6) Build the basic image, it will fail with an error in dbus:

bitbake gumstix-basic-image

Edit <code>gumstix/gumstix-oe/tmp/work/i686-linux/dbus-native-1.0.1-r0/dbus-1.0.1/dbus/dbus-sysdeps-unix.c</code>

Add this struct,

<code><pre>
struct ucred {
unsigned int pid;
unsigned int uid;
unsigned int gid;
};
</pre></code>

after the macros.

7) Build the basic image, it will fail with an error in sumversion:

bitbake gumstix-basic-image

Edit <code>gumstix/gumstix-oe/tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.21-r1/linux-2.6.21/scripts/mod/sumversion.c</code>

Add this line,

#include <limits.h>

after all of the other includes.

8) Build the basic image again. If it fails with an error in gconf-dbus, do the following:

a. download file http://download.gnome.org/sources/GConf-dbus/2.16/GConf-dbus-2.16.0.tar.gz

b. move and rename this file to:
/usr/share/sources/trunk_developer.imendio.com_.svn.gconf-dbus_606_.tar.gz

9) Build the basic image again, this time it should work:

bitbake gumstix-basic-image

10) If everything builds ok, it could be a good idea to modify the dbus-sysdeps-unix.c and sumversion.c files in their respective packages in /usr/share/sources as otherwise everytime you do a rebuild they will be wiped. Note that dbus-sysdeps-unix.c is found in package dbus-1.0.1.tar.gz, and sumversion.c is found in package linux-2.6.21.tar.bz2.

[[Category:How_to_-_general]]
[[Category:How_to_-_Ubuntu]]

Category:How to - Build helloworld

2010-06-14T09:45:08Z

Sellis: wording

==Overview==

What follows is a description for building C programs on a workstation using the cross-build tools of [http://wiki.openembedded.net/index.php/Main_Page OpenEmbedded], but NOT USING the bitbake/recipe framework.

For an alternative method USING the bitbake/recipe framework, a series of sample recipes can be found [[HelloWorld Examples | here]].

==Setup==

Follow the instructions for [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html setting up a build environment] to get the cross-build tools correctly installed.

The tools are built under the TMPDIR directory declared in ${OVEROTOP}/build/conf/site.conf.

TMPDIR defaults to ${OVEROTOP}/tmp, but you can point it somewhere else.

==Makefile==

After you have built an image, the cross-tools will be installed on your workstation.

You can now create a standard makefile for your project pointing to this cross-build toolchain.

Here is a simple example for helloworld.

# Makefile for building with the OE cross tools
#
# OVEROTOP is normally ${HOME}/overo-oe
#
# OETMP is the same as TMPDIR as defined in ${OVEROTOP}/build/conf/site.conf
#

OETMP = ${OVEROTOP}/tmp

TOOLDIR = ${OETMP}/cross/armv7a/bin

STAGEDIR = ${OETMP}/staging/armv7a-angstrom-linux-gnueabi/usr

CC = ${TOOLDIR}/arm-angstrom-linux-gnueabi-gcc

CFLAGS = -Wall

LIBDIR = ${STAGEDIR}/lib

INCDIR = ${STAGEDIR}/include

TARGET = helloworld

OBJS = helloworld.o

${TARGET} : $(OBJS)
${CC} ${CFLAGS} ${OBJS} -L ${LIBDIR} -o ${TARGET}

helloworld.o: helloworld.c
${CC} ${CFLAGS} -I ${INCDIR} -c helloworld.c

clean:
rm -f ${TARGET} ${OBJS} *~

==Distribute==

After building with make, copy the resulting target executable to the overo.

Here are some alternatives.

1. If you are using [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html a microSD card], copy your executable to the rootfs before you unmount it in the final step.

2. If you have a network connection to the overo, use scp.

3. If you are doing a [http://www.gumstix.net/wiki/index.php?title=Category:How_to_-_Network_Boot network boot] then copy the executable directly to the nfs exported root filesystem the gumstix is using on the workstation.

==Only the Tools==

You don't need to build a complete image to get the cross-tools.

If you only want to cross compile a C program without third-party dependencies, then you can build just the gcc-cross recipe.

bitbake gcc-cross

You can use OE to selectively build additional cross-compiled libraries as needed. Look around in the OE recipes folder.

For example, if you needed the kernel headers too...

bitbake linux-libc-headers

If you build a complete image, then most of the cross-build tools and libraries will get installed as as side-effect. That is probably the easiest way to setup your workstation the first time.

Category:How to - Build helloworld

2010-06-14T09:22:10Z

Sellis: Be explicit that the Hello World recipe link is an alternative to this page.

==Overview==

What follows is a description for building C programs on a workstation using the cross-build tools of [http://wiki.openembedded.net/index.php/Main_Page OpenEmbedded], but NOT USING the bitbake/recipe framework.

For an alternative method USING the bitbake/recipe framework, a series of sample recipes can be found [[HelloWorld Examples | here]].

==Setup==

Follow the instructions for [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html setting up a build environment] to get the cross-build tools correctly installed.

The tools are built under the TMPDIR directory declared in ${OVEROTOP}/build/conf/site.conf.

TMPDIR defaults to ${OVEROTOP}/tmp, but you can point it somewhere else.

==Makefile==

After you have built an image, the cross-tools will be installed on your workstation.

You can now create a standard makefile for your project pointing to this cross-build toolchain.

Here is a simple example for helloworld.

# Makefile for building with the OE cross tools
#
# OVEROTOP is normally ${HOME}/overo-oe
#
# OETMP is the same as TMPDIR as defined in ${OVEROTOP}/build/conf/site.conf
#

OETMP = ${OVEROTOP}/tmp

TOOLDIR = ${OETMP}/cross/armv7a/bin

STAGEDIR = ${OETMP}/staging/armv7a-angstrom-linux-gnueabi/usr

CC = ${TOOLDIR}/arm-angstrom-linux-gnueabi-gcc

CFLAGS = -Wall

LIBDIR = ${STAGEDIR}/lib

INCDIR = ${STAGEDIR}/include

TARGET = helloworld

OBJS = helloworld.o

${TARGET} : $(OBJS)
${CC} ${CFLAGS} ${OBJS} -L ${LIBDIR} -o ${TARGET}

helloworld.o: helloworld.c
${CC} ${CFLAGS} -I ${INCDIR} -c helloworld.c

clean:
rm -f ${TARGET} ${OBJS} *~

==Distribute==

Copy the resulting target executable to the overo.

1. If you are using [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html a microSD card], copy your executable to the rootfs before you unmount it in the final step.

2. If you have a network connection to the overo, use scp.

3. If you are doing a [http://www.gumstix.net/wiki/index.php?title=Category:How_to_-_Network_Boot network boot] then copy the executable directly to the nfs exported root filesystem the gumstix is using on the workstation.

==Only the Tools==

You don't need to build a complete image to get the cross-tools.

If you only want to cross compile a C program without third-party dependencies, then you can build just the gcc-cross recipe.

bitbake gcc-cross

You can use OE to selectively build additional cross-compiled libraries as needed. Look around in the OE recipes folder.

For example, if you needed the kernel headers too...

bitbake linux-libc-headers

If you build a complete image, then most of the cross-build tools and libraries will get installed as as side-effect. That is probably the easiest way to setup your workstation the first time.

Category:How to - Network Boot

2010-05-03T14:25:43Z

Sellis: Ubuntu 10.04 tftpd-hpa config file format change

==Overview==

Network booting can be very convenient during the development cycle
for an embedded device. Current Gumstix Overos have a bootloader
and kernel ready for network booting if you have an expansion board
with an ethernet connector. Older Gumstix Overos can upgrade their
version of u-boot to get support for network booting. This procedure
also works for Verdex-Pro boards although all the text and links
refer to Overo.

The procedures that follow are for setting up a workstation to act
as both the tftp server and the nfs server to host the root file
system.

The procedure described does not require a dhcp server.

==Setup==

A workstation running Ubuntu 9.10 is used for the example.

The names of the packages will be different if you are using another
distribution.

There are multiple ways to configure the nfs server and the tftpd
server. This is just one method.

Here is the network configuration.

Workstation IP: 192.168.4.4

Gumstix IP: 192.168.4.50

You will also need a Gumstix Overo rootfs on the workstation.

You can either
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html build]
one yourself or download one
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Downloading-pre-built-images/111.html here.]

I'll assume an omap3-console-image custom built with OE located in the standard location.
Any image will work though.

==Packages==

Install the following Ubuntu packages on the workstation

tftp-hpa

nfs-common

nfs-kernel-server

portmap

==Create a root filesystem==

Create and populate the /exports directory with a kernel and a root filesystem

sudo mkdir -p /exports/overo
sudo tar -C /exports/overo -xvjf ${OVEROTOP}/tmp/deploy/glibc/images/overo/omap3-console-image-overo.tar.bz2

==Configure the tftp server==

Disable inetd control of tftpd which is the default for Ubuntu. Either comment the line in /etc/inetd.conf that references tftpd by adding a # to the start of the tftp line

# tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/int.tftpd -s /var/lib/tftpboot

or if you don't need inetd for any other service, which a Ubuntu desktop install typically doesn't, disable inetd completely this way

sudo mv /etc/rc2.d/S20openbsd-inetd /etc/rc2.d/K20openbsd-inetd

See the NOTES(1) section.

The tftpd-hpa configuration file format changed between Ubuntu 9.10 and 10.04.

Edit /etc/default/tftpd-hpa (for 9.10)

RUN_DAEMON="yes"
OPTIONS="-l -s /exports/overo/boot"

Edit /etc/default/tftpd-hpa (for 10.04)

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/exports/overo/boot"
TFTP_ADDRESS="192.168.4.4:69"
TFTP_OPTIONS="-s"

What we are doing is pointing the tftp daemon at the Gumstix root filesystem we created above so that it will find the uImage kernel that sits there.

$ ls -all /exports/overo/boot/*
lrwxrwxrwx 1 root root 13 2010-01-13 11:50 /exports/overo/boot/uImage -> uImage-2.6.32
-rw-r--r-- 1 root root 3147516 2010-01-10 11:12 /exports/overo/boot/uImage-2.6.32

==Configure the nfs server==

Add the following line to /etc/exports

/exports/overo 192.168.4.50(rw,no_root_squash,no_subtree_check)

This tells the nfs server what directories to export as an nfs mountpoint and what machines have access to it.
Use man exports to get the documentation for /etc/exports.

==Restart the servers==

sudo /etc/init.d/tftpd-hpa restart
sudo service portmap restart
sudo /etc/init.d/nfs-kernel-server restart

==Configure u-boot==

Establish a serial console connection with the gumstix.

Power the gumstix unit and hit a key to stop the process in uboot.

Add some environment variables to u-boot.

Overo # setenv ipaddr 192.168.4.50
Overo # setenv netmask 255.255.255.0
Overo # setenv serverip 192.168.4.4
Overo # setenv gatewayip 192.168.4.1
Overo # setenv hostname overo
Overo # setenv ip ${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:none
Overo # setenv nfsroot /exports/overo
Overo # setenv nfsargs setenv bootargs console=\${console} root=/dev/nfs rootfstype=nfs ip=\${ip} nfsroot=\${nfsroot} rootwait
Overo # setenv loadnfskernel tftp \${loadaddr} uImage

Save what you've entered in the u-boot environment so far. None of these variables are used by default, so the boot behavior is still unchanged.

Overo # saveenv

==Testing==

The next step is to test the network boot by running each step manually.
Later we will modify u-boot to run this automatically.

1. First tftp load the kernel into the overo memory

Overo # print loadaddr
loadaddr=0x82000000

Overo # tftp ${loadaddr} uImage
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 00:15:c9:28:c1:78
Using smc911x-0 device
TFTP from server 192.168.4.4; our IP address is 192.168.4.50
Filename 'uImage'.
Load address: 0x82000000
Loading: T ######################################################
######################################################
######################################################
#####################################################
done
Bytes transferred = 3147516 (3006fc hex)

If you get the following error

Overo # tftp ${loadaddr} uImage
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 00:00:00:00:00:00
*** ERROR: `ethaddr' not set

see Note 12 below.

Okay, if that worked, make sure the loadnfskernel variable we created doesn't
have a typo by running the same process again using the u-boot run command.

Overo # run loadnfskernel

You should get the same results, a kernel tftp loaded into memory.

If it did not work, use a network monitoring tool like tcpdump or wireshark to
see if you are getting any traffic.

See the Notes section for some troubleshooting tips.

2. Test the loading of the boot arguments.

Overo # print bootargs
## Error: "bootargs" not defined
Overo # print nfsargs
nfsargs=setenv bootargs console=${console} root=/dev/nfs rootfstype=nfs ip=${ip} nfsroot=${nfsroot} rootwait
Overo # run nfsargs
Overo # print bootargs
bootargs=console=ttyS2,115200n8 root=/dev/nfs rootfstype=nfs ip=192.168.4.50:192.168.4.4:192.168.4.1:255.255.255.0:overo:eth0:none nfsroot=/exports/overo rootwait

Make sure that bootargs looks correct. The format of the ip kernel command line argument is found in the kernel documentation under [http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/nfsroot.txt filesystems/nfsroot.txt]

3. Boot the kernel

With a kernel of the correct format loaded into memory, the u-boot command bootm will
transfer control of the processor to this kernel.

Overo # bootm ${loadaddr}

...normal kernel boot messages here, then...
net eth0: SMSC911x/921x identified at 0xd08c8000, IRQ: 336
IP-Config: Complete:
device=eth0, addr=192.168.4.50, mask=255.255.255.0, gw=192.168.4.1,
host=overo, domain=, nis-domain=(none),
bootserver=192.168.4.4, rootserver=192.168.4.4, rootpath=
Looking up port of RPC 100003/2 on 192.168.4.4
Looking up port of RPC 100005/1 on 192.168.4.4
VFS: Mounted root (nfs filesystem) on device 0:13.
Freeing init memory: 928K
INIT: version 2.86 booting
...
The Angstrom Distribution overo ttyS2
Angstrom 2009.X-test-20100110 overo ttyS2
overo login:

==Making it automatic==

So if everything worked and you want to boot this way every time you need to modify the
bootcmd u-boot variable.

Reboot the gumstix and hit a key to stop it in u-boot again.

Overo # print bootcmd
bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi; fi; else run nandboot; fi

You may want to save this for the future or see the Notes section for where it is defined in the build.

Make a new bootcmd using the u-boot environment variables that we created.

Overo # setenv bootcmd echo Booting nfs ...\; run loadnfskernel\; run nfsargs\; bootm \${loadaddr}

Overo # saveenv

Now reboot and the gumstix should nfsboot by default.

Overo # reset

==Notes==

1. tftp and inetd. You can use inetd to run tftp if you want. Just edit the -s option for tftp appropriately in /etc/inetd.conf

tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /exports/overo/boot

and instead of this restart command

sudo /etc/init.d/tftpd-hpa restart

use this one

sudo /etc/init.d/openbsd-inetd restart

And finally, prevent tftpd-hpa from starting by

sudo mv /etc/rc2.d/S20tftpd-hpa /etc/rc2.d/s20tftpd-hpa

2. The default u-boot environment variables for the overo are defined in the u-boot source tree under include/configs/omap3-overo.h if you wanted to customize or go back to defaults.

3. The documentation for linux kernel parameters for nfs booting can be found in the linux source tree under
[http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/nfsroot.txt Documentation/filesystems/nfsroot.txt]
and [http://www.kernel.org/doc/Documentation/kernel-parameters.txt Documentation/kernel-parameters.txt.]

4. tftp listens over udp on port 69
$ grep tftp /etc/services
tftp 69/udp

You can check if it is listening with the following command.

$ netstat -an | grep udp
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:880 0.0.0.0:*
udp 0 0 0.0.0.0:39921 0.0.0.0:*
udp 0 0 0.0.0.0:56957 0.0.0.0:*
udp 0 0 0.0.0.0:2049 0.0.0.0:*
udp 0 0 0.0.0.0:59435 0.0.0.0:*
udp 0 0 0.0.0.0:69 0.0.0.0:*

5. nfs listens on port 2049 both tcp and udp. The nfs root process uses only udp.
$ grep nfs /etc/services
nfs 2049/tcp # Network File System
nfs 2049/udp # Network File System

6. The following is a tcpdump command for watching the gumstix boot traffic. Choose the appropriate
interface for your workstation.

$ sudo tcpdump -i eth1 -l -n udp

7. A cross-over ethernet cable connected between the workstation and the gumstix works well
if you can't host services on your regular network. You may want to check before starting a
tftp server on a shared network. A dedicated switch/hub will also work to keep things isolated.

8. You can check for running firewall rules with this command

$ sudo iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

If you get output different then this (nothing running) and you are having problems booting, then
you should ensure you are not blocking any of the required traffic.

9. I removed the kernel parameters for the kernel display configuration for wiki formatting reasons.
You should add the settings you require to the bootcmd variable in the example.

10. There is a patch to u-boot in the current gumstix overo-oe tree that improves the ethernet
network speeds on the overos. You can save about 10 seconds on an nfs boot using a u-boot
built with this patch as well as get better ethernet performance after booting. When you do a
network boot without a microSD card, you are using the u-boot on the NAND flash which
was probably built without this patch.
Build a newer version of u-boot following the standard build procedures. (U-boot is built
whenever you build an image.) Then copy it to NAND using the instructions
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html here.]

11. If the gumstix seems unwilling to connect to your NFS server, ensure you've enabled NFS options in your kernel.
You'll need to include (directly, not as modules) CONFIG_NFS_FS, CONFIG_ROOT_NFS, CONFIG_NET_ETHERNET,
and, the appropriate Ethernet chip driver, in my case, CONFIG_SMC911X.

12. Older gumstix ethernet boards did not come with an EEPROM specifying a MAC address and so the ethernet controller's reset value of FF:FF:FF:FF:FF:FF was being used by U-Boot. Older versions of U-Boot didn't complain about this, but newer versions do. So if you are in the situation with an older gumstix ethernet board running a newer U-Boot, you must specify an ethaddr U-Boot environment variable manually if you want to tftp boot. Newer U-Boot still allows FF:FF:FF:FF:FF:FF when set from the environment, though that's just an oversight that might get fixed anytime.

This works for now.

setenv ethaddr FF:FF:FF:FF:FF:FF

If U-Boot starts checking more thoroughly, you may have to use another value.

This is not a problem once Linux is booted. The Linux driver will assign a random MAC if it detects FF:FF:FF:FF:FF:FF.

Again this is a problem that is going away and shouldn't affect any new gumstix owners.

Category:How to - Build helloworld

2010-04-03T16:35:05Z

Sellis: Seems this was confusing people combining lib path with libs. Just show lib path now.

==Overview==

What follows is a description for building C programs on a workstation using the cross-build tools of [http://wiki.openembedded.net/index.php/Main_Page OpenEmbedded], but not using the bitbake/recipe framework.

A series of sample recipes can be found [[HelloWorld Examples | here]].

==Setup==

Follow the instructions for [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html setting up a build environment] to get the cross-build tools correctly installed.

While you don't necessarily need to build a complete image to get the cross-tools for a C program, as a practical matter, successfully building an image is a good test that the cross-tools are correctly installed.

If you only want to cross compile a C program without third-party dependencies, then you can build just the gcc-cross recipe.

bitbake gcc-cross

And if you need the kernel headers too...

bitbake linux-libc-headers

There is no time lost building only these recipes, since both are dependencies of a full image.

The tools are built under the TMPDIR directory declared in ${OVEROTOP}/build/conf/site.conf.

TMPDIR defaults to ${OVEROTOP}/tmp, but you can point it somewhere else.

For instance, putting TMPDIR on a faster disk can speed your build.

==Makefile==

Create a makefile for your project pointing to the cross-build toolchain.

Here is a simple one for helloworld.

# Makefile for building with the OE cross tools
#
# OVEROTOP is normally ${HOME}/overo-oe
#
# OETMP is the same as TMPDIR as defined in ${OVEROTOP}/build/conf/site.conf
#

OETMP = ${OVEROTOP}/tmp

TOOLDIR = ${OETMP}/cross/armv7a/bin

STAGEDIR = ${OETMP}/staging/armv7a-angstrom-linux-gnueabi/usr

CC = ${TOOLDIR}/arm-angstrom-linux-gnueabi-gcc

CFLAGS = -Wall

LIBDIR = ${STAGEDIR}/lib

INCDIR = ${STAGEDIR}/include

TARGET = helloworld

OBJS = helloworld.o

${TARGET} : $(OBJS)
${CC} ${CFLAGS} ${OBJS} -L ${LIBDIR} -o ${TARGET}

helloworld.o: helloworld.c
${CC} ${CFLAGS} -I ${INCDIR} -c helloworld.c

clean:
rm -f ${TARGET} ${OBJS} *~

==Distribute==

Copy the resulting target executable to the overo.

1. If you are using [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html a microSD card], copy your executable to the rootfs before you unmount it in the final step.

2. If you have a network connection to the overo, use scp.

3. If you have a kermit console session, use the kermit SEND command.

4. If you are doing a [http://www.gumstix.net/wiki/index.php?title=Category:How_to_-_Network_Boot network boot] then copy the executable directly to the nfs exported root filesystem the gumstix is using on the workstation.

Category:How to - usb

2010-04-01T18:07:42Z

Sellis: Added links for how to use the new kernel and rootfs

Note: if you have issues with USB not resuming properly after a suspend on Overo, please see [http://old.nabble.com/Update-on-Overo-EHCI-issues-td27617583.html#a27617583 this] forum post.
==USBNet with Overo==

The OTG USB port on the Overo expansion boards support USB networking. To enable this, the OTG port needs to be configured as a USB peripheral or gadget. The default kernels from Gumstix have the OTG port configured to act as a USB host.

The procedure for changing the configuration requires rebuilding your kernel, so you should first be comfortable with [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html setting up a build environment] and building images for your Overo.

The following steps assume you are using a recent snapshot of the gumstix-oe git tree and are going to use kernel version 2.6.31 or 2.6.32.

The gumstix recipes for either of these kernels has a variable that allows you to specify how the OTG usb port is configured.

Kernel version 2.6.31 is used for the example. Substitute 2.6.32 if that's the kernel you are using.

To get started, look at the recipe file ${OVEROTOP}/org.openembedded.dev/recipes/linux/linux-omap3_2.6.31.bb. You'll see a line

MUSB_MODE ?= "host"

There are three valid values for MUSB_MODE: "host", "peripheral" or "otg".

You could change the MUSB_MODE assignment directly in the recipe, but a better way to do this is to modify your local.conf file and add a MUSB_MODE variable.

The ?= assignment means "host" will be assigned to MUSB_MODE only if it does not already have a value which it will if you give it one in local.conf.

The local.conf file is found here ${OVEROTOP}/build/conf/local.conf.

Add the line

MUSB_MODE = "peripheral"

or

MUSB_MODE = "otg"

depending on your preference.

Now rebuild your kernel.

cd ${OVEROTOP}
bitbake -c clean linux-omap3-2.6.31
bitbake -c rebuild linux-omap3-2.6.31

And then rebuild your rootfs since the drivers available in /lib/modules will have changed.

bitbake omap3-console-image

Change omap3-console-image to whatever image you use.

Install the new kernel and rootfs the way you normally would using either a
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html microSD card]
or by copying to [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html onboard nand].

Once you have booted the new system, you still need to load the g_ether driver since it was built as a module.

You can add g_ether to /etc/modules if you always want it to load at boot.

root@overo# modbprobe g_ether
g_ether gadget: using random self ethernet address
g_ether gadget: using random host ethernet address
usb0: MAC d6:2c:8f:d9:51:32
usb0: HOST MAC f2:99:dc:4c:cb:7a
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready

root@overo:~# ifconfig -a
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

usb0 Link encap:Ethernet HWaddr D6:2C:8F:D9:51:32
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Configure the usb0 interface the way you would any other.

For example

root@overo:~# ifconfig usb0 192.168.20.2 netmask 255.255.255.0

If you then plug the usb OTG cable into a host computer ready for usb networking you'll get a console message

g_ether gadget: high speed config #1: CDC Ethernet (ECM)

The rest is all standard Linux networking.

Category:SPI

2010-03-13T22:08:02Z

Sellis: Switched order of sections

== Overo SPI ==

Kernel documentation for the SPI framework is excellent and should be your starting point. You can find it under the Documentation directory of your linux source tree or here [http://www.kernel.org/doc/Documentation/spi/spi-summary Documentation/spi/spi-summary].

Linux SPI drivers are broken into two parts. A controller driver that handles direct communication with the hardware and a protocol driver to handle the details of the data for a particular device. The interface defined in spi.c/spi.h is the bridge between the two.

For the OMAP3's, the controller driver is omap2_mcspi.c. The OMAP3's have 4 SPI busses which the omap2_mcspi driver handles. The kernel config option to include the omap2_mcspi driver is CONFIG_SPI_OMAP24XX.

The OMAP3 SPI controller has the ability to act as either a SPI master or SPI slave, but the current kernel code only supports the SPI master configuration. There are some new checkins to the kernel code indicating that SPI slave functionality might be coming.

=== Protocol Drivers ===
A protocol driver is probably what you want to write.

There are a couple of steps you need to follow in writing a SPI protocol driver.

# You need to tell the SPI subsystem about the slave device(s) on each SPI bus that you want to use. This gets passed along to the controller driver when it's needed. You can do this during kernel init in a board file like board-overo.c or it can be done at run time in module code. A device name (modalias) is specified as a key part of this process.
# You need to register a SPI protocol driver. This driver should have the same name (modalias) as was specified above. You register a spi_device using the spi_register_driver() call. When this internal mapping connection is made by the SPI subsystem, the result is a probe() call to your protocol driver.

It doesn't matter which order you perform these steps. But after both are completed and your probe() function returns success, your driver will be ready for SPI communication. You are given a spi_device in the probe() function that you need to hang onto.

SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages in the protocol driver. The protocol driver then submits the SPI messages to the controller driver's I/O queue with calls to spi_async(). These messages are processed in FIFO order asynchronously by the controller driver. As each message finishes, the controller notifies the protocol driver via 'completion' callbacks. The protocol driver can then process the raw data as necessary.

There is also a simple synchronous interface exposed by spi.h/spi.c. Here the SPI framework puts the caller, a protocol driver, to sleep while the same asynchronous interface to the controller driver is used behind the scenes. When the controller is done, the protocol driver is woken up and can then proceed to process the data.

=== Spidev ===

Spidev is a stock linux module that implements a generic SPI protocol driver while exposing a char device interface to userland via sysfs.

The documentation can be found in the linux source tree. Here is a link [http://www.mjmwired.net/kernel/Documentation/spi/spidev Documentation/spi/spidev].

Spidev is not designed to dynamically register itself with the SPI subsystem. You will need to add code to do this in either a kernel module or more likely in the board file, board-overo.c, so registration takes place during boot.

Spidev implements its own synchronous interface to the SPI system.

Here's one Gumstix [http://www.nabble.com/SPI%2C-spidev%2C-et.-al-to24588398.html#a24594755 mailing list thread] posted on 7/21/09, where some users have successfully used spidev with the Overos.

You can also search the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

=== Another Example Driver ===

A simpler OMAP3 linux SPI driver can be found [http://www.github.com/scottellis/overo-adc-mcp3002 here].

Two inexpensive ADC's are used as the slave devices. The protocol for these devices is sufficiently simple that other devices could be easily swapped in place of them and the code modified appropriately.

This driver demonstrates how to add SPI devices to a SPI bus at runtime instead of at boot time, which can simplify development.

The driver also demonstrates how to handle asynchronous I/O with the SPI controller.

There is no attempt to do anything useful with the ADC data. The driver is just intended to be used to explore the linux SPI framework.

The driver also exposes a simple character device interface to interact with userland.

Category:SPI

2010-03-13T21:57:03Z

Sellis: Added spidev doc link

== Overo SPI ==

Kernel documentation for the SPI framework is excellent and should be your starting point. You can find it under the Documentation directory of your linux source tree or here [http://www.kernel.org/doc/Documentation/spi/spi-summary Documentation/spi/spi-summary].

Linux SPI drivers are broken into two parts. A controller driver that handles direct communication with the hardware and a protocol driver to handle the details of the data for a particular device. The interface defined in spi.c/spi.h is the bridge between the two.

For the OMAP3's, the controller driver is omap2_mcspi.c. The OMAP3's have 4 SPI busses which the omap2_mcspi driver handles. The kernel config option to include the omap2_mcspi driver is CONFIG_SPI_OMAP24XX.

The OMAP3 SPI controller has the ability to act as either a SPI master or SPI slave, but the current kernel code only supports the SPI master configuration. There are some new checkins to the kernel code indicating that SPI slave functionality might be coming.

=== Protocol Drivers ===
A protocol driver is probably what you want to write.

There are a couple of steps you need to follow in writing a SPI protocol driver.

# You need to tell the SPI subsystem about the slave device(s) on each SPI bus that you want to use. This gets passed along to the controller driver when it's needed. You can do this during kernel init in a board file like board-overo.c or it can be done at run time in module code. A device name (modalias) is specified as a key part of this process.
# You need to register a SPI protocol driver. This driver should have the same name (modalias) as was specified above. You register a spi_device using the spi_register_driver() call. When this internal mapping connection is made by the SPI subsystem, the result is a probe() call to your protocol driver.

It doesn't matter which order you perform these steps. But after both are completed and your probe() function returns success, your driver will be ready for SPI communication. You are given a spi_device in the probe() function that you need to hang onto.

SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages in the protocol driver. The protocol driver then submits the SPI messages to the controller driver's I/O queue with calls to spi_async(). These messages are processed in FIFO order asynchronously by the controller driver. As each message finishes, the controller notifies the protocol driver via 'completion' callbacks. The protocol driver can then process the raw data as necessary.

There is also a simple synchronous interface exposed by spi.h/spi.c. Here the SPI framework puts the caller, a protocol driver, to sleep while the same asynchronous interface to the controller driver is used behind the scenes. When the controller is done, the protocol driver is woken up and can then proceed to process the data.

=== Example Driver ===

A sample OMAP3 Linux SPI driver can be found [http://www.github.com/scottellis/overo-adc-mcp3002 here].

The adc.c driver demonstrates how to add SPI devices at runtime instead of at boot time in order to simplify development. It also demonstrates how to handle asynchronous I/O with the SPI controller.

There is no attempt to do anything useful with the data, a couple of ADC slaves, it's just for testing out the SPI framework.

The driver exposes a simple character device interface to interact with userland.

=== Spidev ===

Spidev is a stock linux module that implements a generic SPI protocol driver while exposing a char device interface to userland via sysfs.

The documentation can be found in the linux source tree. Here is a link [http://www.mjmwired.net/kernel/Documentation/spi/spidev Documentation/spi/spidev].

Spidev is not designed to dynamically register itself with the SPI subsystem. You will need to add code to do this in either a kernel module or more likely in the board file, board-overo.c, so registration takes place during boot.

Spidev implements its own synchronous interface to the SPI system.

Here's one Gumstix [http://www.nabble.com/SPI%2C-spidev%2C-et.-al-to24588398.html#a24594755 mailing list thread] posted on 7/21/09, where some users have successfully used spidev with the Overos.

You can also search the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

Category:SPI

2010-03-13T21:51:33Z

Sellis: spidev notes

== Overview ==

Kernel documentation for the SPI framework is excellent and should be your starting point. You can find it under the Documentation directory of your linux source tree or here [http://www.kernel.org/doc/Documentation/spi/spi-summary Documentation/spi/spi-summary].

Linux SPI drivers are broken into two parts. A controller driver that handles direct communication with the hardware and a protocol driver to handle the details of the data for a particular device. The interface defined in spi.c/spi.h is the bridge between the two.

For the OMAP3's, the controller driver is omap2_mcspi.c. The OMAP3's have 4 SPI busses which the omap2_mcspi driver handles. The kernel config option to include the omap2_mcspi driver is CONFIG_SPI_OMAP24XX.

The OMAP3 SPI controller has the ability to act as either a SPI master or SPI slave, but the current kernel code only supports the SPI master configuration. There are some new checkins to the kernel code indicating that SPI slave functionality might be coming.

=== Protocol Drivers ===
A protocol driver is probably what you want to write.

There are a couple of steps you need to follow in writing a SPI protocol driver.

# You need to tell the SPI subsystem about the slave device(s) on each SPI bus that you want to use. This gets passed along to the controller driver when it's needed. You can do this during kernel init in a board file like board-overo.c or it can be done at run time in module code. A device name (modalias) is specified as a key part of this process.
# You need to register a SPI protocol driver. This driver should have the same name (modalias) as was specified above. You register a spi_device using the spi_register_driver() call. When this internal mapping connection is made by the SPI subsystem, the result is a probe() call to your protocol driver.

It doesn't matter which order you perform these steps. But after both are completed and your probe() function returns success, your driver will be ready for SPI communication. You are given a spi_device in the probe() function that you need to hang onto.

SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages in the protocol driver. The protocol driver then submits the SPI messages to the controller driver's I/O queue with calls to spi_async(). These messages are processed in FIFO order asynchronously by the controller driver. As each message finishes, the controller notifies the protocol driver via 'completion' callbacks. The protocol driver can then process the raw data as necessary.

There is also a simple synchronous interface exposed by spi.h/spi.c. Here the SPI framework puts the caller, a protocol driver, to sleep while the same asynchronous interface to the controller driver is used behind the scenes. When the controller is done, the protocol driver is woken up and can then proceed to process the data.

=== Example Driver ===

A sample OMAP3 Linux SPI driver can be found [http://www.github.com/scottellis/overo-adc-mcp3002 here].

The adc.c driver demonstrates how to add SPI devices at runtime instead of at boot time in order to simplify development. It also demonstrates how to handle asynchronous I/O with the SPI controller.

There is no attempt to do anything useful with the data, a couple of ADC slaves, it's just for testing out the SPI framework.

The driver exposes a simple character device interface to interact with userland.

=== Spidev ===

Spidev is a stock linux module that implements a generic SPI protocol driver while exposing a char device interface to userland via sysfs.

Spidev is not designed to dynamically register itself with the SPI subsystem. You will need to add code to do this in either a kernel module or more likely in the board file, board-overo.c, so registration takes place during boot.

Spidev implements its own synchronous interface to the SPI system.

(This is just from reading the code. I have never tried to use spidev. Maybe someone who has can elaborate.)

Here's one Gumstix [http://www.nabble.com/SPI%2C-spidev%2C-et.-al-to24588398.html#a24594755 mailing list thread] posted on 7/21/09, where some users have successfully used spidev with the Overos.

You can also search the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

Category:SPI

2010-03-13T15:50:59Z

Sellis: Added some documentation

== Overview ==

Kernel documentation for the SPI framework is excellent and should be your starting point. You can find it under the Documentation directory of your linux source tree or here [http://www.kernel.org/doc/Documentation/spi/spi-summary Documentation/spi/spi-summary].

Linux SPI drivers are broken into two parts. A controller driver that handles direct communication with the hardware and a protocol driver to handle the details of the data for a particular device. The interface defined in spi.c/spi.h is the bridge between the two.

For the OMAP3's, the controller driver is omap2_mcspi.c. The OMAP3's have 4 SPI busses which the omap2_mcspi driver handles. The kernel config option to include the omap2_mcspi driver is CONFIG_SPI_OMAP24XX.

The OMAP3 SPI controller has the ability to act as either a SPI master or SPI slave, but the current kernel code only supports the SPI master configuration. There are some new checkins to the kernel code indicating that SPI slave functionality might be coming.

=== Protocol Drivers ===
A protocol driver is probably what you want to write.

There are a couple of steps you need to follow in writing a SPI protocol driver.

# You need to tell the SPI subsystem about the slave device(s) on each SPI bus that you want to use. This gets passed along to the controller driver when it's needed. You can do this during kernel init in a board file like board-overo.c or it can be done at run time in module code. A device name (modalias) is specified as a key part of this process.
# You need to register a SPI protocol driver. This driver should have the same name (modalias) as was specified above. You register a spi_device using the spi_register_driver() call. When this internal mapping connection is made by the SPI subsystem, the result is a probe() call to your protocol driver.

It doesn't matter which order you perform these steps. But after both are completed and your probe() function returns success, your driver will be ready for SPI communication. You are given a spi_device in the probe() function that you need to hang onto.

SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages by you in your driver. You then submit your messages to the controller driver's I/O queue with calls to spi_async(). These messages are processed in FIFO order asynchronously by the controller and your driver is notified via completion callbacks as each message finishes. You can then process the raw data in your driver.

There is also a simple synchronous interface exposed by spi.h/spi.c that just halts your driver while the same asynchronous interface to the controller driver is used behind the scenes.

=== Example Driver ===

A sample OMAP3 Linux SPI driver can be found [http://www.github.com/scottellis/overo-adc-mcp3002 here].

The adc.c driver demonstrates how to add SPI devices at runtime instead of at boot time in order to simplify development. It also demonstrates how to handle asynchronous I/O with the SPI controller.

There is no attempt to do anything useful with the data, a couple of ADC slaves, it's just for testing out the SPI framework.

The driver exposes a simple character device interface to interact with userland.

== Using Spidev ==

Check the [http://www.nabble.com/forum/Search.jtp?query=spidev&sort=date&local=y&forum=22543 Gumstix mailing list archives for spidev]

In particular, [http://www.nabble.com/SPI%2C-spidev%2C-et.-al-to24588398.html#a24594755 this article on spidev] posted on 7/21/09.

Category:How to - Network Boot

2010-02-19T16:00:34Z

Sellis: Added ethaddr error note

==Overview==

Network booting can be very convenient during the development cycle
for an embedded device. Current Gumstix Overos have a bootloader
and kernel ready for network booting if you have an expansion board
with an ethernet connector. Older Gumstix Overos can upgrade their
version of u-boot to get support for network booting. This procedure
also works for Verdex-Pro boards although all the text and links
refer to Overo.

The procedures that follow are for setting up a workstation to act
as both the tftp server and the nfs server to host the root file
system.

The procedure described does not require a dhcp server.

==Setup==

A workstation running Ubuntu 9.10 is used for the example.

The names of the packages will be different if you are using another
distribution.

There are multiple ways to configure the nfs server and the tftpd
server. This is just one method.

Here is the network configuration.

Workstation IP: 192.168.4.4

Gumstix IP: 192.168.4.50

You will also need a Gumstix Overo rootfs on the workstation.

You can either
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html build]
one yourself or download one
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Downloading-pre-built-images/111.html here.]

I'll assume an omap3-console-image custom built with OE located in the standard location.
Any image will work though.

==Packages==

Install the following Ubuntu packages on the workstation

tftp-hpa

nfs-common

nfs-kernel-server

portmap

==Create a root filesystem==

Create and populate the /exports directory with a kernel and a root filesystem

sudo mkdir -p /exports/overo
sudo tar -C /exports/overo -xvjf ${OVEROTOP}/tmp/deploy/glibc/images/overo/omap3-console-image-overo.tar.bz2

==Configure the tftp server==

Disable inetd control of tftpd which is the default for Ubuntu. Either comment the line in /etc/inetd.conf that references tftpd by adding a # to the start of the tftp line

# tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/int.tftpd -s /var/lib/tftpboot

or if you don't need inetd for any other service, which a Ubuntu desktop install typically doesn't, disable inetd completely this way

sudo mv /etc/rc2.d/S20openbsd-inetd /etc/rc2.d/s20openbsd-inetd

See the NOTES(1) section.

Edit /etc/default/tftpd-hpa

RUN_DAEMON="yes"
OPTIONS="-l -s /exports/overo/boot"

What we are doing is pointing the tftp daemon at the Gumstix root filesystem we created above so that it will find the uImage kernel that sits there.

$ ls -all /exports/overo/boot/*
lrwxrwxrwx 1 root root 13 2010-01-13 11:50 /exports/overo/boot/uImage -> uImage-2.6.32
-rw-r--r-- 1 root root 3147516 2010-01-10 11:12 /exports/overo/boot/uImage-2.6.32

==Configure the nfs server==

Add the following line to /etc/exports

/exports/overo 192.168.4.50(rw,no_root_squash,no_subtree_check)

This tells the nfs server what directories to export as an nfs mountpoint and what machines have access to it.
Use man exports to get the documentation for /etc/exports.

==Restart the servers==

sudo /etc/init.d/tftpd-hpa restart
sudo service portmap restart
sudo /etc/init.d/nfs-kernel-server restart

==Configure u-boot==

Establish a serial console connection with the gumstix.

Power the gumstix unit and hit a key to stop the process in uboot.

Add some environment variables to u-boot.

Overo # setenv ipaddr 192.168.4.50
Overo # setenv netmask 255.255.255.0
Overo # setenv serverip 192.168.4.4
Overo # setenv gatewayip 192.168.4.1
Overo # setenv hostname overo
Overo # setenv ip ${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:none
Overo # setenv nfsroot /exports/overo
Overo # setenv nfsargs setenv bootargs console=\${console} root=/dev/nfs rootfstype=nfs ip=\${ip} nfsroot=\${nfsroot} rootwait
Overo # setenv loadnfskernel tftp \${loadaddr} uImage

Save what you've entered in the u-boot environment so far. None of these variables are used by default, so the boot behavior is still unchanged.

Overo # saveenv

==Testing==

The next step is to test the network boot by running each step manually.
Later we will modify u-boot to run this automatically.

1. First tftp load the kernel into the overo memory

Overo # print loadaddr
loadaddr=0x82000000

Overo # tftp ${loadaddr} uImage
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 00:15:c9:28:c1:78
Using smc911x-0 device
TFTP from server 192.168.4.4; our IP address is 192.168.4.50
Filename 'uImage'.
Load address: 0x82000000
Loading: T ######################################################
######################################################
######################################################
#####################################################
done
Bytes transferred = 3147516 (3006fc hex)

If you get the following error

Overo # tftp ${loadaddr} uImage
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 00:00:00:00:00:00
*** ERROR: `ethaddr' not set

see Note 12 below.

Okay, if that worked, make sure the loadnfskernel variable we created doesn't
have a typo by running the same process again using the u-boot run command.

Overo # run loadnfskernel

You should get the same results, a kernel tftp loaded into memory.

If it did not work, use a network monitoring tool like tcpdump or wireshark to
see if you are getting any traffic.

See the Notes section for some troubleshooting tips.

2. Test the loading of the boot arguments.

Overo # print bootargs
## Error: "bootargs" not defined
Overo # print nfsargs
nfsargs=setenv bootargs console=${console} root=/dev/nfs rootfstype=nfs ip=${ip} nfsroot=${nfsroot} rootwait
Overo # run nfsargs
Overo # print bootargs
bootargs=console=ttyS2,115200n8 root=/dev/nfs rootfstype=nfs ip=192.168.4.50:192.168.4.4:192.168.4.1:255.255.255.0:overo:eth0:none nfsroot=/exports/overo rootwait

Make sure that bootargs looks correct. The format of the ip kernel command line argument is found in the kernel documentation under [http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/nfsroot.txt filesystems/nfsroot.txt]

3. Boot the kernel

With a kernel of the correct format loaded into memory, the u-boot command bootm will
transfer control of the processor to this kernel.

Overo # bootm ${loadaddr}

...normal kernel boot messages here, then...
net eth0: SMSC911x/921x identified at 0xd08c8000, IRQ: 336
IP-Config: Complete:
device=eth0, addr=192.168.4.50, mask=255.255.255.0, gw=192.168.4.1,
host=overo, domain=, nis-domain=(none),
bootserver=192.168.4.4, rootserver=192.168.4.4, rootpath=
Looking up port of RPC 100003/2 on 192.168.4.4
Looking up port of RPC 100005/1 on 192.168.4.4
VFS: Mounted root (nfs filesystem) on device 0:13.
Freeing init memory: 928K
INIT: version 2.86 booting
...
The Angstrom Distribution overo ttyS2
Angstrom 2009.X-test-20100110 overo ttyS2
overo login:

==Making it automatic==

So if everything worked and you want to boot this way every time you need to modify the
bootcmd u-boot variable.

Reboot the gumstix and hit a key to stop it in u-boot again.

Overo # print bootcmd
bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi; fi; else run nandboot; fi

You may want to save this for the future or see the Notes section for where it is defined in the build.

Make a new bootcmd using the u-boot environment variables that we created.

Overo # setenv bootcmd echo Booting nfs ...\; run loadnfskernel\; run nfsargs\; bootm \${loadaddr}

Overo # saveenv

Now reboot and the gumstix should nfsboot by default.

Overo # reset

==Notes==

1. tftp and inetd. You can use inetd to run tftp if you want. Just edit the -s option for tftp appropriately in /etc/inetd.conf

tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /exports/overo/boot

and instead of this restart command

sudo /etc/init.d/tftpd-hpa restart

use this one

sudo /etc/init.d/openbsd-inetd restart

And finally, prevent tftpd-hpa from starting by

sudo mv /etc/rc2.d/S20tftpd-hpa /etc/rc2.d/s20tftpd-hpa

2. The default u-boot environment variables for the overo are defined in the u-boot source tree under include/configs/omap3-overo.h if you wanted to customize or go back to defaults.

3. The documentation for linux kernel parameters for nfs booting can be found in the linux source tree under
[http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/nfsroot.txt Documentation/filesystems/nfsroot.txt]
and [http://www.kernel.org/doc/Documentation/kernel-parameters.txt Documentation/kernel-parameters.txt.]

4. tftp listens over udp on port 69
$ grep tftp /etc/services
tftp 69/udp

You can check if it is listening with the following command.

$ netstat -an | grep udp
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:880 0.0.0.0:*
udp 0 0 0.0.0.0:39921 0.0.0.0:*
udp 0 0 0.0.0.0:56957 0.0.0.0:*
udp 0 0 0.0.0.0:2049 0.0.0.0:*
udp 0 0 0.0.0.0:59435 0.0.0.0:*
udp 0 0 0.0.0.0:69 0.0.0.0:*

5. nfs listens on port 2049 both tcp and udp. The nfs root process uses only udp.
$ grep nfs /etc/services
nfs 2049/tcp # Network File System
nfs 2049/udp # Network File System

6. The following is a tcpdump command for watching the gumstix boot traffic. Choose the appropriate
interface for your workstation.

$ sudo tcpdump -i eth1 -l -n udp

7. A cross-over ethernet cable connected between the workstation and the gumstix works well
if you can't host services on your regular network. You may want to check before starting a
tftp server on a shared network. A dedicated switch/hub will also work to keep things isolated.

8. You can check for running firewall rules with this command

$ sudo iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

If you get output different then this (nothing running) and you are having problems booting, then
you should ensure you are not blocking any of the required traffic.

9. I removed the kernel parameters for the kernel display configuration for wiki formatting reasons.
You should add the settings you require to the bootcmd variable in the example.

10. There is a patch to u-boot in the current gumstix overo-oe tree that improves the ethernet
network speeds on the overos. You can save about 10 seconds on an nfs boot using a u-boot
built with this patch as well as get better ethernet performance after booting. When you do a
network boot without a microSD card, you are using the u-boot on the NAND flash which
was probably built without this patch.
Build a newer version of u-boot following the standard build procedures. (U-boot is built
whenever you build an image.) Then copy it to NAND using the instructions
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html here.]

11. If the gumstix seems unwilling to connect to your NFS server, ensure you've enabled NFS options in your kernel.
You'll need to include (directly, not as modules) CONFIG_NFS_FS, CONFIG_ROOT_NFS, CONFIG_NET_ETHERNET,
and, the appropriate Ethernet chip driver, in my case, CONFIG_SMC911X.

12. Older gumstix ethernet boards did not come with an EEPROM specifying a MAC address and so the ethernet controller's reset value of FF:FF:FF:FF:FF:FF was being used by U-Boot. Older versions of U-Boot didn't complain about this, but newer versions do. So if you are in the situation with an older gumstix ethernet board running a newer U-Boot, you must specify an ethaddr U-Boot environment variable manually if you want to tftp boot. Newer U-Boot still allows FF:FF:FF:FF:FF:FF when set from the environment, though that's just an oversight that might get fixed anytime.

This works for now.

setenv ethaddr FF:FF:FF:FF:FF:FF

If U-Boot starts checking more thoroughly, you may have to use another value.

This is not a problem once Linux is booted. The Linux driver will assign a random MAC if it detects FF:FF:FF:FF:FF:FF.

Again this is a problem that is going away and shouldn't affect any new gumstix owners.

GPIO

2010-02-16T15:13:46Z

Sellis: remux as gpio not limited to 5 spi pins

== Overo GPIO ==

The Overo kernels support the sysfs gpio implementation for accessing GPIO from userspace.

This allows you to control GPIO from the command line this way

root@overo# echo 146 > /sys/class/gpio/export
root@overo:/sys/class/gpio# cat gpio146/direction
in
root@overo# echo out > /sys/class/gpio/gpio146/direction
root@overo:/sys/class/gpio# cat gpio146/direction
out
root@overo# cat /sys/class/gpio/gpio146/value
0
root@overo# echo 1 > /sys/class/gpio/gpio146/value
root@overo# cat /sys/class/gpio/gpio146/value
1

If you have an expansion card with a 40 pin header, then this will be controlling pin 27. You can use pin 1 for a ground. (If you don't have a meter, a p/n 276-0330 1.8V Red LED from Radio Shack works for testing.)

Schematics and pin-outs for the Gumstix expansion boards can be found [http://pubs.gumstix.com/boards/ here.]

=== How It Works ===

See the kernel docs [http://www.kernel.org/doc/Documentation/gpio.txt gpio.txt] for an overview of gpio and the userspace sysfs interface. The "Sysfs Interface for Userspace (OPTIONAL)" section near the end discusses the userspace implementation.

See the [http://www-s.ti.com/sc/techlit/spruf98 OMAP35X Technical Reference Manual] Section 7.6.3 PADCONFS Register Description and Table 7.5 Core Control Module PadConf Register Field in Section 7.4.4.3 Pad Multiplexing Register Fields for identifying the possible MUX configuration for each GPIO.

Then see the U-Boot source code, board/overo/overo.h for how the pins on the Overo are actually being muxed. See include/asm-arm/arch-omap3/mux.h in the U-Boot tree for the definitions used in overo.h. The pins in mux mode M4 are already configured for GPIO.

=== Making Modifications ===

Currently all the GPIO multiplexing for the Overo's is being done by the bootloader U-Boot, so the conventional way to modify the pin muxing is to edit overo.h and rebuild U-Boot.

You can also change the mux configuration from within Linux. One simple approach is to do it from userspace accessing /dev/mem. A program devmem2 is part of the omap3-console-image and will work. See the remuxing example below.

If you are writing your own kernel module, you can also read/write the PADCONF registers the way you normally would after an ioremap.

Third, there is a Linux build config option CONFIG_OMAP_MUX, not normally enabled in the Overo configs, that will give you some additional utility functions to simplify mux changes within kernel or module code (see arch/arm/plat-omap/mux.c).

Finally, it looks like the Linux OMAP34xx pin muxing code is getting a complete overhaul. See this [http://www.mail-archive.com/linux-omap@vger.kernel.org/msg18474.html thread] on the Linux OMAP mailing list. Judging from some posts on the Gumstix lists, it sounds like this will be available in 2.6.33.

=== Overo Kernel Usage ===

Just because pins are configured as GPIO in u-boot, doesn't necessarily mean you can use them. If you look at /sys/class/gpio on a default Overo, you'll get something like this.

root@overo:~# ls /sys/class/gpio
export gpio164 gpio65 gpiochip160 gpiochip64
gpio15 gpio168 gpiochip0 gpiochip192 gpiochip96
gpio16 gpio176 gpiochip128 gpiochip32 unexport

The reason you see some GPIO already exported is because the linux code in arch/arm/mach-omap2/board-overo.c is explicitly exporting these pins for another use. Whether they are being used depends on the hardware you have attached. The kernel also uses pins configured as GPIO that it doesn't export. These depend on the board configuration and the kernel drivers being used.

To be more explicit, look inside board-overo.c, you'll see these definitions

#define OVERO_GPIO_BT_XGATE 15
#define OVERO_GPIO_W2W_NRESET 16
#define OVERO_GPIO_PENDOWN 114
#define OVERO_GPIO_BT_NRESET 164
#define OVERO_GPIO_USBH_CPEN 168
#define OVERO_GPIO_USBH_NRESET 183
...
#define OVERO_SMSC911X_GPIO 176
#define OVERO_SMSC911X2_GPIO 65
...
#define OVERO_GPIO_LCD_EN 144
#define OVERO_GPIO_LCD_BL 145

Follow their usage inside the file and you will be able to explain the /sys/class/gpio output you see above.

=== Input or Output ===

Pins configured as GPIO are sometimes also specified as being strictly input or output.

This can happen when they are mux'd or when they are explicitly exported by the kernel.

In either of those cases you won't be able to change the I/O direction from userspace.

=== Electrical Specifications ===

Voltage is 1.8v

Current specifications <TODO ???>

=== Usable Pins ===

Here's a few GPIO you can use immediately from userspace without any u-boot or kernel changes.

==== 40 Pin Expansion Header ====

Pin 4 - gpio114 
It's the pendown signal on the touchscreen controller but it's available if you aren't using a touchscreen. 
Configured as input only when exported by the kernel in board-overo.h. Can't change the direction from userspace without modifying kernel. 
Pulled-low, reads 0 with no input, reads 1 with an input applied 

Pin 19 - gpio170 
The HDQ/1-Wire output. Not used unless you explicitly enable the 1-wire module. 
User exportable 
Output only - configured this way in the u-boot muxing 

Pin 27 - gpio146 
Pin 29 - gpio147 
User exportable 
Direction can be changed 
Floating state 

Pin 28 - gpio145 
Pin 30 - gpio144 
Used with LCD, but available if not using an LCD 
Configured as output only when exported by the kernel in board-overo.h. Can't change direction from userspace without modifying kernel. 
Set to ON by kernel during init (not all configs, see board-overo.c). This could be a problem for real use, but okay for testing. 

==== Palo43 Board ====

LED D2 - gpio21 
LED D3 - gpio22 
Userspace exportable, set the direction as out 
echo 0 > gpioxx/value to turn on, echo 1 > gpioxx/value to turn off 

Switch - gpio14 
Switch - gpio23 
Userspace exportable, leave direction as in 
With the switch open (not pushed) will register a value of 1 
Push the switch and the value will be 0 

=== Example: Changing the multiplexing for a pin ===

If you aren't using the first SPI bus, then there are 5 pins on the 40-pin expansion header that you could repurpose for GPIO.

Pin 3 - gpio171(spi1_clk) 
Pin 5 - gpio172 (spi1_mosi) 
Pin 6 - gpio174 (spi1_cs0) 
Pin 7 - gpio173 (spi1_miso) 
Pin 8 - gpio175 (spi1_cs1) 

The first step is to find the appropriate PADCONF register address for each gpio from Table 7.5 of the TRM. Pay attention to whether it is the low or high order 16 bits for each gpio. You should come up with these values.

gpio171 : 0x4800 21C8 
gpio172 : 0x4800 21CA 
gpio173 : 0x4800 21CC 
gpio174 : 0x4800 21CE 
gpio175 : 0x4800 21D0 

Using devmem2, here is how you could read the current PADCONF value for what could be gpio171

root@overo# devmem2 0x480021c8 h
...
Value at address 0x480021C8 (0x400201c8): 0x100

Which corresponds to a mux value of (IEN | PTD | DIS | M0) using the U-Boot mux.h definitions. Mux mode 0 for this pin is the spi1_clk configuration found by looking in Table 7.5 of the TRM.

To reconfigure pin 3 to be gpio171, as input or output with inputs pulled low, write 0x010C to the controlling PADCONF register. This would correspond to (IEN | PTD | EN | M4). The bit fields are defined in the TRM Section 7.6.3.

root@overo# devmem2 0x480021c8 h 0x10c

Now you can export and configure gpio171 from userspace like the example with gpio146 at the beginning.

If you want this multiplexing to be permanent, then you would modify the U-Boot file board/overo/overo.h and rebuild U-Boot. If you are using OE, then you'll want to generate a patch file to be used in the u-boot-omap3 recipe.

There are additional pins on the header that can be reconfigured this way.

=== GPIO Software for the Overo ===

Dave Hylands has written several software packages to facilitate GPIO programming on the Overos.

[http://www.gumstix.net/wiki/index.php?title=GPIO_Event_Driver GPIO Event Driver] allows multiple GPIO lines to be monitored from user-space.

[http://www.gumstix.net/wiki/index.php?title=User_GPIO_Driver User GPIO Driver] is a reflection of the kernel's gpiolib API into user space.

=== More Links ===

Here is another article [http://elinux.org/BeagleBoardPinMux BeagleBoardPinMux] talking about OMAP3 pin muxing.

== Verdex GPIO ==
{| border="1" cellpadding="5" cellspacing="0" style="width:100px"
| style="background:yellow;" | GPIO( n )
|}

* Logic level (3.3V) signals
* 3-4mA max

all GPIO's information and examples should go here

todo

According to the PXA270 datasheet:
http://pubs.gumstix.com/documents/PXA%20Documentation/PXA270/PXA270%20Electrical,%20Mechanical,%20and%20Thermal%20Specification%20%5b280002-005%5d.pdf
most of the pins are limited to 3mA, and a few can go upto 4 mA (see page 5-9)

 
 

=== Accessing GPIO's from userland ===

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:
<pre>
# cat /proc/gpio/GPIO12
12 GPIO in set
</pre>

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:
<pre>
# echo "AF1 out" > /proc/gpio/GPIO12
</pre>

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:
<pre>
# echo "GPIO out set" > /proc/gpio/GPIO12
# echo "GPIO out clear" > /proc/gpio/GPIO12
</pre>
The alternative functions are described in the PXA255 Developer's Manual (link should be found in the Featured links-box) section 4.1.2.

=== Alternative method to access GPIO's from userland ===

The [[User GPIO Driver]] provides a reflection of the kernel's gpiolib library into userspace.

=== gpio-event driver ===

The [[GPIO Event Driver]] allows gpio changes to be captured from user-space.

 
 
 
-----------------------------

Related pages on the old wiki:

http://docwiki.gumstix.org/index.php/Tips_and_tricks#Access_GPIOs_from_user-space

http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs

http://docwiki.gumstix.org/index.php/Kernel_programming

.
[[Category:Literature]]
[[Category:GPIO]]

GPIO

2010-02-15T14:09:35Z

Sellis: Added remux example

== Overo GPIO ==

The Overo kernels support the sysfs gpio implementation for accessing GPIO from userspace.

This allows you to control GPIO from the command line this way

root@overo# echo 146 > /sys/class/gpio/export
root@overo:/sys/class/gpio# cat gpio146/direction
in
root@overo# echo out > /sys/class/gpio/gpio146/direction
root@overo:/sys/class/gpio# cat gpio146/direction
out
root@overo# cat /sys/class/gpio/gpio146/value
0
root@overo# echo 1 > /sys/class/gpio/gpio146/value
root@overo# cat /sys/class/gpio/gpio146/value
1

If you have an expansion card with a 40 pin header, then this will be controlling pin 27. You can use pin 1 for a ground. (If you don't have a meter, a p/n 276-0330 1.8V Red LED from Radio Shack works for testing.)

Schematics and pin-outs for the Gumstix expansion boards can be found [http://pubs.gumstix.com/boards/ here.]

=== How It Works ===

See the kernel docs [http://www.kernel.org/doc/Documentation/gpio.txt gpio.txt] for an overview of gpio and the userspace sysfs interface. The "Sysfs Interface for Userspace (OPTIONAL)" section near the end discusses the userspace implementation.

See the [http://www-s.ti.com/sc/techlit/spruf98 OMAP35X Technical Reference Manual] Section 7.6.3 PADCONFS Register Description and Table 7.5 Core Control Module PadConf Register Field in Section 7.4.4.3 Pad Multiplexing Register Fields for identifying the possible MUX configuration for each GPIO.

Then see the U-Boot source code, board/overo/overo.h for how the pins on the Overo are actually being muxed. See include/asm-arm/arch-omap3/mux.h in the U-Boot tree for the definitions used in overo.h. The pins in mux mode M4 are already configured for GPIO.

=== Making Modifications ===

Currently all the GPIO multiplexing for the Overo's is being done by the bootloader U-Boot, so the conventional way to modify the pin muxing is to edit overo.h and rebuild U-Boot.

You can also change the mux configuration from within Linux. One simple approach is to do it from userspace accessing /dev/mem. A program devmem2 is part of the omap3-console-image and will work. See the remuxing example below.

If you are writing your own kernel module, you can also read/write the PADCONF registers the way you normally would after an ioremap.

Third, there is a Linux build config option CONFIG_OMAP_MUX, not normally enabled in the Overo configs, that will give you some additional utility functions to simplify mux changes within kernel or module code (see arch/arm/plat-omap/mux.c).

Finally, it looks like the Linux OMAP34xx pin muxing code is getting a complete overhaul. See this [http://www.mail-archive.com/linux-omap@vger.kernel.org/msg18474.html thread] on the Linux OMAP mailing list. Judging from some posts on the Gumstix lists, it sounds like this will be available in 2.6.33.

=== Overo Kernel Usage ===

Just because pins are configured as GPIO in u-boot, doesn't necessarily mean you can use them. If you look at /sys/class/gpio on a default Overo, you'll get something like this.

root@overo:~# ls /sys/class/gpio
export gpio164 gpio65 gpiochip160 gpiochip64
gpio15 gpio168 gpiochip0 gpiochip192 gpiochip96
gpio16 gpio176 gpiochip128 gpiochip32 unexport

The reason you see some GPIO already exported is because the linux code in arch/arm/mach-omap2/board-overo.c is explicitly exporting these pins for another use. Whether they are being used depends on the hardware you have attached. The kernel also uses pins configured as GPIO that it doesn't export. These depend on the board configuration and the kernel drivers being used.

To be more explicit, look inside board-overo.c, you'll see these definitions

#define OVERO_GPIO_BT_XGATE 15
#define OVERO_GPIO_W2W_NRESET 16
#define OVERO_GPIO_PENDOWN 114
#define OVERO_GPIO_BT_NRESET 164
#define OVERO_GPIO_USBH_CPEN 168
#define OVERO_GPIO_USBH_NRESET 183
...
#define OVERO_SMSC911X_GPIO 176
#define OVERO_SMSC911X2_GPIO 65
...
#define OVERO_GPIO_LCD_EN 144
#define OVERO_GPIO_LCD_BL 145

Follow their usage inside the file and you will be able to explain the /sys/class/gpio output you see above.

=== Input or Output ===

Pins configured as GPIO are sometimes also specified as being strictly input or output.

This can happen when they are mux'd or when they are explicitly exported by the kernel.

In either of those cases you won't be able to change the I/O direction from userspace.

=== Electrical Specifications ===

Voltage is 1.8v

Current specifications <TODO ???>

=== Usable Pins ===

Here's a few GPIO you can use immediately from userspace without any u-boot or kernel changes.

==== 40 Pin Expansion Header ====

Pin 4 - gpio114 
It's the pendown signal on the touchscreen controller but it's available if you aren't using a touchscreen. 
Configured as input only when exported by the kernel in board-overo.h. Can't change the direction from userspace without modifying kernel. 
Pulled-low, reads 0 with no input, reads 1 with an input applied 

Pin 19 - gpio170 
The HDQ/1-Wire output. Not used unless you explicitly enable the 1-wire module. 
User exportable 
Output only - configured this way in the u-boot muxing 

Pin 27 - gpio146 
Pin 29 - gpio147 
User exportable 
Direction can be changed 
Floating state 

Pin 28 - gpio145 
Pin 30 - gpio144 
Used with LCD, but available if not using an LCD 
Configured as output only when exported by the kernel in board-overo.h. Can't change direction from userspace without modifying kernel. 
Set to ON by kernel during init (not all configs, see board-overo.c). This could be a problem for real use, but okay for testing. 

==== Palo43 Board ====

LED D2 - gpio21 
LED D3 - gpio22 
Userspace exportable, set the direction as out 
echo 0 > gpioxx/value to turn on, echo 1 > gpioxx/value to turn off 

Switch - gpio14 
Switch - gpio23 
Userspace exportable, leave direction as in 
With the switch open (not pushed) will register a value of 1 
Push the switch and the value will be 0 

=== Example: Changing the multiplexing for a pin ===

If you aren't using the first SPI bus, then there are 5 pins on the 40-pin expansion header that you could repurpose for GPIO.

Pin 3 - gpio171(spi1_clk) 
Pin 5 - gpio172 (spi1_mosi) 
Pin 6 - gpio174 (spi1_cs0) 
Pin 7 - gpio173 (spi1_miso) 
Pin 8 - gpio175 (spi1_cs1) 

The first step is to find the appropriate PADCONF register address for each gpio from Table 7.5 of the TRM. Pay attention to whether it is the low or high order 16 bits for each gpio. You should come up with these values.

gpio171 : 0x4800 21C8 
gpio172 : 0x4800 21CA 
gpio173 : 0x4800 21CC 
gpio174 : 0x4800 21CE 
gpio175 : 0x4800 21D0 

Using devmem2, here is how you could read the current PADCONF value for what could be gpio171

root@overo# devmem2 0x480021c8 h
...
Value at address 0x480021C8 (0x400201c8): 0x100

Which corresponds to a mux value of (IEN | PTD | DIS | M0) using the U-Boot mux.h definitions. Mux mode 0 for this pin is the spi1_clk configuration found by looking in Table 7.5 of the TRM.

To reconfigure pin 3 to be gpio171, as input or output with inputs pulled low, write 0x010C to the controlling PADCONF register. This would correspond to (IEN | PTD | EN | M4). The bit fields are defined in the TRM Section 7.6.3.

root@overo# devmem2 0x480021c8 h 0x10c

Now you can export and configure gpio171 from userspace like the example with gpio146 at the beginning.

If you want this multiplexing to be permanent, then you would modify the U-Boot file board/overo/overo.h and rebuild U-Boot. If you are using OE, then you'll want to generate a patch file to be used in the u-boot-omap3 recipe.

=== GPIO Software for the Overo ===

Dave Hylands has written several software packages to facilitate GPIO programming on the Overos.

[http://www.gumstix.net/wiki/index.php?title=GPIO_Event_Driver GPIO Event Driver] allows multiple GPIO lines to be monitored from user-space.

[http://www.gumstix.net/wiki/index.php?title=User_GPIO_Driver User GPIO Driver] is a reflection of the kernel's gpiolib API into user space.

=== More Links ===

Here is another article [http://elinux.org/BeagleBoardPinMux BeagleBoardPinMux] talking about OMAP3 pin muxing.

== Verdex GPIO ==
{| border="1" cellpadding="5" cellspacing="0" style="width:100px"
| style="background:yellow;" | GPIO( n )
|}

* Logic level (3.3V) signals
* 3-4mA max

all GPIO's information and examples should go here

todo

According to the PXA270 datasheet:
http://pubs.gumstix.com/documents/PXA%20Documentation/PXA270/PXA270%20Electrical,%20Mechanical,%20and%20Thermal%20Specification%20%5b280002-005%5d.pdf
most of the pins are limited to 3mA, and a few can go upto 4 mA (see page 5-9)

 
 

=== Accessing GPIO's from userland ===

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:
<pre>
# cat /proc/gpio/GPIO12
12 GPIO in set
</pre>

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:
<pre>
# echo "AF1 out" > /proc/gpio/GPIO12
</pre>

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:
<pre>
# echo "GPIO out set" > /proc/gpio/GPIO12
# echo "GPIO out clear" > /proc/gpio/GPIO12
</pre>
The alternative functions are described in the PXA255 Developer's Manual (link should be found in the Featured links-box) section 4.1.2.

=== Alternative method to access GPIO's from userland ===

The [[User GPIO Driver]] provides a reflection of the kernel's gpiolib library into userspace.

=== gpio-event driver ===

The [[GPIO Event Driver]] allows gpio changes to be captured from user-space.

 
 
 
-----------------------------

Related pages on the old wiki:

http://docwiki.gumstix.org/index.php/Tips_and_tricks#Access_GPIOs_from_user-space

http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs

http://docwiki.gumstix.org/index.php/Kernel_programming

.
[[Category:Literature]]
[[Category:GPIO]]

GPIO

2010-02-12T14:15:14Z

Sellis: Better OMAP3 TRM link

== Overo GPIO ==

The Overo kernels support the sysfs gpio implementation for accessing GPIO from userspace.

This allows you to control GPIO from the command line this way

root@overo# echo 146 > /sys/class/gpio/export
root@overo:/sys/class/gpio# cat gpio146/direction
in
root@overo# echo out > /sys/class/gpio/gpio146/direction
root@overo:/sys/class/gpio# cat gpio146/direction
out
root@overo# cat /sys/class/gpio/gpio146/value
0
root@overo# echo 1 > /sys/class/gpio/gpio146/value
root@overo# cat /sys/class/gpio/gpio146/value
1

If you have an expansion card with a 40 pin header, then this will be controlling pin 27. You can use pin 1 for a ground. (If you don't have a meter, a p/n 276-0330 1.8V Red LED from Radio Shack works for testing.)

Schematics and pin-outs for the Gumstix expansion boards can be found [http://pubs.gumstix.com/boards/ here.]

=== How It Works ===

See the kernel docs [http://www.kernel.org/doc/Documentation/gpio.txt gpio.txt] for an overview of gpio and the userspace sysfs interface. The "Sysfs Interface for Userspace (OPTIONAL)" section near the end discusses the userspace implementation.

See the [http://www-s.ti.com/sc/techlit/spruf98 OMAP35X Technical Reference Manual] Section 7.6.3 PADCONFS Register Description and Table 7.5 Core Control Module PadConf Register Field in Section 7.4.4.3 Pad Multiplexing Register Fields for identifying the possible MUX configuration for each GPIO.

Then see the U-Boot source code, board/overo/overo.h for how the pins on the Overo are actually being muxed. See include/asm-arm/arch-omap3/mux.h in the U-Boot tree for the definitions used in overo.h. The pins in mux mode M4 are already configured for GPIO.

=== Making Modifications ===

Currently all the GPIO multiplexing for the Overo's is being done by the bootloader U-Boot, so the conventional way to modify the pin muxing is to edit overo.h and rebuild U-Boot.

You can also change the mux configuration from within Linux. One simple approach is to do it from userspace accessing /dev/mem. A program devmem2 is part of the omap3-console-image and will work. TODO: show an example

If you are writing your own kernel module, you can also read/write the PADCONF registers the way you normally would after an ioremap.

Third, there is a Linux build config option CONFIG_OMAP_MUX, not normally enabled in the Overo configs, that will give you some additional utility functions to simplify mux changes within kernel or module code (see arch/arm/plat-omap/mux.c).

Finally, it looks like the Linux OMAP34xx pin muxing code is getting a complete overhaul. See this [http://www.mail-archive.com/linux-omap@vger.kernel.org/msg18474.html thread] on the Linux OMAP mailing list. Judging from some posts on the Gumstix lists, it sounds like this will be available in 2.6.33.

=== Overo Kernel Usage ===

Just because pins are configured as GPIO in u-boot, doesn't necessarily mean you can use them. If you look at /sys/class/gpio on a default Overo, you'll get something like this.

root@overo:~# ls /sys/class/gpio
export gpio164 gpio65 gpiochip160 gpiochip64
gpio15 gpio168 gpiochip0 gpiochip192 gpiochip96
gpio16 gpio176 gpiochip128 gpiochip32 unexport

The reason you see some GPIO already exported is because the linux code in arch/arm/mach-omap2/board-overo.c is explicitly exporting these pins for another use. Whether they are being used depends on the hardware you have attached. The kernel also uses pins configured as GPIO that it doesn't export. These depend on the board configuration and the kernel drivers being used.

To be more explicit, look inside board-overo.c, you'll see these definitions

#define OVERO_GPIO_BT_XGATE 15
#define OVERO_GPIO_W2W_NRESET 16
#define OVERO_GPIO_PENDOWN 114
#define OVERO_GPIO_BT_NRESET 164
#define OVERO_GPIO_USBH_CPEN 168
#define OVERO_GPIO_USBH_NRESET 183
...
#define OVERO_SMSC911X_GPIO 176
#define OVERO_SMSC911X2_GPIO 65
...
#define OVERO_GPIO_LCD_EN 144
#define OVERO_GPIO_LCD_BL 145

Follow their usage inside the file and you will be able to explain the /sys/class/gpio output you see above.

=== Input or Output ===

Pins configured as GPIO are sometimes also specified as being strictly input or output.

This can happen when they are mux'd or when they are explicitly exported by the kernel.

In either of those cases you won't be able to change the I/O direction from userspace.

=== Electrical Specifications ===

Voltage is 1.8v

Current specifications <TODO ???>

=== Usable Pins ===

Here's a few GPIO you can use immediately from userspace without any u-boot or kernel changes.

==== 40 Pin Expansion Header ====

Pin 4 - gpio114 
It's the pendown signal on the touchscreen controller but it's available if you aren't using a touchscreen. 
Configured as input only when exported by the kernel in board-overo.h. Can't change the direction from userspace without modifying kernel. 
Pulled-low, reads 0 with no input, reads 1 with an input applied 

Pin 19 - gpio170 
The HDQ/1-Wire output. Not used unless you explicitly enable the 1-wire module. 
User exportable 
Output only - configured this way in the u-boot muxing 

Pin 27 - gpio146 
Pin 29 - gpio147 
User exportable 
Direction can be changed 
Floating state 

Pin 28 - gpio145 
Pin 30 - gpio144 
Used with LCD, but available if not using an LCD 
Configured as output only when exported by the kernel in board-overo.h. Can't change direction from userspace without modifying kernel. 
Set to ON by kernel during init (not all configs, see board-overo.c). This could be a problem for real use, but okay for testing. 

==== Palo43 Board ====

LED D2 - gpio21 
LED D3 - gpio22 
Userspace exportable, set the direction as out 
echo 0 > gpioxx/value to turn on, echo 1 > gpioxx/value to turn off 

Switch - gpio14 
Switch - gpio23 
Userspace exportable, leave direction as in 
With the switch open (not pushed) will register a value of 1 
Push the switch and the value will be 0 

=== GPIO Software for the Overo ===

Dave Hylands has written several software packages to facilitate GPIO programming on the Overos.

[http://www.gumstix.net/wiki/index.php?title=GPIO_Event_Driver GPIO Event Driver] allows multiple GPIO lines to be monitored from user-space.

[http://www.gumstix.net/wiki/index.php?title=User_GPIO_Driver User GPIO Driver] is a reflection of the kernel's gpiolib API into user space.

=== More Links ===

Here is another article [http://elinux.org/BeagleBoardPinMux BeagleBoardPinMux] talking about OMAP3 pin muxing.

== Verdex GPIO ==
{| border="1" cellpadding="5" cellspacing="0" style="width:100px"
| style="background:yellow;" | GPIO( n )
|}

* Logic level (3.3V) signals
* 3-4mA max

all GPIO's information and examples should go here

todo

According to the PXA270 datasheet:
http://pubs.gumstix.com/documents/PXA%20Documentation/PXA270/PXA270%20Electrical,%20Mechanical,%20and%20Thermal%20Specification%20%5b280002-005%5d.pdf
most of the pins are limited to 3mA, and a few can go upto 4 mA (see page 5-9)

 
 

=== Accessing GPIO's from userland ===

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:
<pre>
# cat /proc/gpio/GPIO12
12 GPIO in set
</pre>

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:
<pre>
# echo "AF1 out" > /proc/gpio/GPIO12
</pre>

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:
<pre>
# echo "GPIO out set" > /proc/gpio/GPIO12
# echo "GPIO out clear" > /proc/gpio/GPIO12
</pre>
The alternative functions are described in the PXA255 Developer's Manual (link should be found in the Featured links-box) section 4.1.2.

=== Alternative method to access GPIO's from userland ===

The [[User GPIO Driver]] provides a reflection of the kernel's gpiolib library into userspace.

=== gpio-event driver ===

The [[GPIO Event Driver]] allows gpio changes to be captured from user-space.

 
 
 
-----------------------------

Related pages on the old wiki:

http://docwiki.gumstix.org/index.php/Tips_and_tricks#Access_GPIOs_from_user-space

http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs

http://docwiki.gumstix.org/index.php/Kernel_programming

.
[[Category:Literature]]
[[Category:GPIO]]

GPIO

2010-02-12T14:00:42Z

Sellis: Added Overo stuff

== Overo GPIO ==

The Overo kernels support the sysfs gpio implementation for accessing GPIO from userspace.

This allows you to control GPIO from the command line this way

root@overo# echo 146 > /sys/class/gpio/export
root@overo:/sys/class/gpio# cat gpio146/direction
in
root@overo# echo out > /sys/class/gpio/gpio146/direction
root@overo:/sys/class/gpio# cat gpio146/direction
out
root@overo# cat /sys/class/gpio/gpio146/value
0
root@overo# echo 1 > /sys/class/gpio/gpio146/value
root@overo# cat /sys/class/gpio/gpio146/value
1

If you have an expansion card with a 40 pin header, then this will be controlling pin 27. You can use pin 1 for a ground. (If you don't have a meter, a p/n 276-0330 1.8V Red LED from Radio Shack works for testing.)

Schematics and pin-outs for the Gumstix expansion boards can be found [http://pubs.gumstix.com/boards/ here.]

=== How It Works ===

See the kernel docs [http://www.kernel.org/doc/Documentation/gpio.txt gpio.txt] for an overview of gpio and the userspace sysfs interface. The "Sysfs Interface for Userspace (OPTIONAL)" section near the end discusses the userspace implementation.

See the [http://wiki.davincidsp.com/index.php/OMAP35x_Technical_Reference_Manual_%28TRM%29 OMAP35X Technical Reference Manual] Section 7.6.3 PADCONFS Register Description and Table 7.5 Core Control Module PadConf Register Field in Section 7.4.4.3 Pad Multiplexing Register Fields for identifying the possible MUX configuration for each GPIO.

Then see the U-Boot source code, board/overo/overo.h for how the pins on the Overo are actually being muxed. See include/asm-arm/arch-omap3/mux.h in the U-Boot tree for the definitions used in overo.h. The pins in mux mode M4 are already configured for GPIO.

=== Making Modifications ===

Currently all the GPIO multiplexing for the Overo's is being done by the bootloader U-Boot, so the conventional way to modify the pin muxing is to edit overo.h and rebuild U-Boot.

You can also change the mux configuration from within Linux. One simple approach is to do it from userspace accessing /dev/mem. A program devmem2 is part of the omap3-console-image and will work. TODO: show an example

If you are writing your own kernel module, you can also read/write the PADCONF registers the way you normally would after an ioremap.

Third, there is a Linux build config option CONFIG_OMAP_MUX, not normally enabled in the Overo configs, that will give you some additional utility functions to simplify mux changes within kernel or module code (see arch/arm/plat-omap/mux.c).

Finally, it looks like the Linux OMAP34xx pin muxing code is getting a complete overhaul. See this [http://www.mail-archive.com/linux-omap@vger.kernel.org/msg18474.html thread] on the Linux OMAP mailing list. Judging from some posts on the Gumstix lists, it sounds like this will be available in 2.6.33.

=== Overo Kernel Usage ===

Just because pins are configured as GPIO in u-boot, doesn't necessarily mean you can use them. If you look at /sys/class/gpio on a default Overo, you'll get something like this.

root@overo:~# ls /sys/class/gpio
export gpio164 gpio65 gpiochip160 gpiochip64
gpio15 gpio168 gpiochip0 gpiochip192 gpiochip96
gpio16 gpio176 gpiochip128 gpiochip32 unexport

The reason you see some GPIO already exported is because the linux code in arch/arm/mach-omap2/board-overo.c is explicitly exporting these pins for another use. Whether they are being used depends on the hardware you have attached. The kernel also uses pins configured as GPIO that it doesn't export. These depend on the board configuration and the kernel drivers being used.

To be more explicit, look inside board-overo.c, you'll see these definitions

#define OVERO_GPIO_BT_XGATE 15
#define OVERO_GPIO_W2W_NRESET 16
#define OVERO_GPIO_PENDOWN 114
#define OVERO_GPIO_BT_NRESET 164
#define OVERO_GPIO_USBH_CPEN 168
#define OVERO_GPIO_USBH_NRESET 183
...
#define OVERO_SMSC911X_GPIO 176
#define OVERO_SMSC911X2_GPIO 65
...
#define OVERO_GPIO_LCD_EN 144
#define OVERO_GPIO_LCD_BL 145

Follow their usage inside the file and you will be able to explain the /sys/class/gpio output you see above.

=== Input or Output ===

Pins configured as GPIO are sometimes also specified as being strictly input or output.

This can happen when they are mux'd or when they are explicitly exported by the kernel.

In either of those cases you won't be able to change the I/O direction from userspace.

=== Electrical Specifications ===

Voltage is 1.8v

Current specifications <TODO ???>

=== Usable Pins ===

Here's a few GPIO you can use immediately from userspace without any u-boot or kernel changes.

==== 40 Pin Expansion Header ====

Pin 4 - gpio114 
It's the pendown signal on the touchscreen controller but it's available if you aren't using a touchscreen. 
Configured as input only when exported by the kernel in board-overo.h. Can't change the direction from userspace without modifying kernel. 
Pulled-low, reads 0 with no input, reads 1 with an input applied 

Pin 19 - gpio170 
The HDQ/1-Wire output. Not used unless you explicitly enable the 1-wire module. 
User exportable 
Output only - configured this way in the u-boot muxing 

Pin 27 - gpio146 
Pin 29 - gpio147 
User exportable 
Direction can be changed 
Floating state 

Pin 28 - gpio145 
Pin 30 - gpio144 
Used with LCD, but available if not using an LCD 
Configured as output only when exported by the kernel in board-overo.h. Can't change direction from userspace without modifying kernel. 
Set to ON by kernel during init (not all configs, see board-overo.c). This could be a problem for real use, but okay for testing. 

==== Palo43 Board ====

LED D2 - gpio21 
LED D3 - gpio22 
Userspace exportable, set the direction as out 
echo 0 > gpioxx/value to turn on, echo 1 > gpioxx/value to turn off 

Switch - gpio14 
Switch - gpio23 
Userspace exportable, leave direction as in 
With the switch open (not pushed) will register a value of 1 
Push the switch and the value will be 0 

=== GPIO Software for the Overo ===

Dave Hylands has written several software packages to facilitate GPIO programming on the Overos.

[http://www.gumstix.net/wiki/index.php?title=GPIO_Event_Driver GPIO Event Driver] allows multiple GPIO lines to be monitored from user-space.

[http://www.gumstix.net/wiki/index.php?title=User_GPIO_Driver User GPIO Driver] is a reflection of the kernel's gpiolib API into user space.

=== More Links ===

Here is another article [http://elinux.org/BeagleBoardPinMux BeagleBoardPinMux] talking about OMAP3 pin muxing.

== Verdex GPIO ==
{| border="1" cellpadding="5" cellspacing="0" style="width:100px"
| style="background:yellow;" | GPIO( n )
|}

* Logic level (3.3V) signals
* 3-4mA max

all GPIO's information and examples should go here

todo

According to the PXA270 datasheet:
http://pubs.gumstix.com/documents/PXA%20Documentation/PXA270/PXA270%20Electrical,%20Mechanical,%20and%20Thermal%20Specification%20%5b280002-005%5d.pdf
most of the pins are limited to 3mA, and a few can go upto 4 mA (see page 5-9)

 
 

=== Accessing GPIO's from userland ===

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:
<pre>
# cat /proc/gpio/GPIO12
12 GPIO in set
</pre>

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:
<pre>
# echo "AF1 out" > /proc/gpio/GPIO12
</pre>

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:
<pre>
# echo "GPIO out set" > /proc/gpio/GPIO12
# echo "GPIO out clear" > /proc/gpio/GPIO12
</pre>
The alternative functions are described in the PXA255 Developer's Manual (link should be found in the Featured links-box) section 4.1.2.

=== Alternative method to access GPIO's from userland ===

The [[User GPIO Driver]] provides a reflection of the kernel's gpiolib library into userspace.

=== gpio-event driver ===

The [[GPIO Event Driver]] allows gpio changes to be captured from user-space.

 
 
 
-----------------------------

Related pages on the old wiki:

http://docwiki.gumstix.org/index.php/Tips_and_tricks#Access_GPIOs_from_user-space

http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs

http://docwiki.gumstix.org/index.php/Kernel_programming

.
[[Category:Literature]]
[[Category:GPIO]]

Category:How to - Network Boot

2010-02-11T13:39:26Z

Sellis: Added links to kernel docs, cleanup

==Overview==

Network booting can be very convenient during the development cycle
for an embedded device. Current Gumstix Overos have a bootloader
and kernel ready for network booting if you have an expansion board
with an ethernet connector. Older Gumstix Overos can upgrade their
version of u-boot to get support for network booting. This procedure
also works for Verdex-Pro boards although all the text and links
refer to Overo.

The procedures that follow are for setting up a workstation to act
as both the tftp server and the nfs server to host the root file
system.

The procedure described does not require a dhcp server.

==Setup==

A workstation running Ubuntu 9.10 is used for the example.

The names of the packages will be different if you are using another
distribution.

There are multiple ways to configure the nfs server and the tftpd
server. This is just one method.

Here is the network configuration.

Workstation IP: 192.168.4.4

Gumstix IP: 192.168.4.50

You will also need a Gumstix Overo rootfs on the workstation.

You can either
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html build]
one yourself or download one
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Downloading-pre-built-images/111.html here.]

I'll assume an omap3-console-image custom built with OE located in the standard location.
Any image will work though.

==Packages==

Install the following Ubuntu packages on the workstation

tftp-hpa

nfs-common

nfs-kernel-server

portmap

==Create a root filesystem==

Create and populate the /exports directory with a kernel and a root filesystem

sudo mkdir -p /exports/overo
sudo tar -C /exports/overo -xvjf ${OVEROTOP}/tmp/deploy/glibc/images/overo/omap3-console-image-overo.tar.bz2

==Configure the tftp server==

Disable inetd control of tftpd which is the default for Ubuntu. Either comment the line in /etc/inetd.conf that references tftpd by adding a # to the start of the tftp line

# tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/int.tftpd -s /var/lib/tftpboot

or if you don't need inetd for any other service, which a Ubuntu desktop install typically doesn't, disable inetd completely this way

sudo mv /etc/rc2.d/S20openbsd-inetd /etc/rc2.d/s20openbsd-inetd

See the NOTES(1) section.

Edit /etc/default/tftpd-hpa

RUN_DAEMON="yes"
OPTIONS="-l -s /exports/overo/boot"

What we are doing is pointing the tftp daemon at the Gumstix root filesystem we created above so that it will find the uImage kernel that sits there.

$ ls -all /exports/overo/boot/*
lrwxrwxrwx 1 root root 13 2010-01-13 11:50 /exports/overo/boot/uImage -> uImage-2.6.32
-rw-r--r-- 1 root root 3147516 2010-01-10 11:12 /exports/overo/boot/uImage-2.6.32

==Configure the nfs server==

Add the following line to /etc/exports

/exports/overo 192.168.4.50(rw,no_root_squash,no_subtree_check)

This tells the nfs server what directories to export as an nfs mountpoint and what machines have access to it.
Use man exports to get the documentation for /etc/exports.

==Restart the servers==

sudo /etc/init.d/tftpd-hpa restart
sudo service portmap restart
sudo /etc/init.d/nfs-kernel-server restart

==Configure u-boot==

Establish a serial console connection with the gumstix.

Power the gumstix unit and hit a key to stop the process in uboot.

Add some environment variables to u-boot.

Overo # setenv ipaddr 192.168.4.50
Overo # setenv netmask 255.255.255.0
Overo # setenv serverip 192.168.4.4
Overo # setenv gatewayip 192.168.4.1
Overo # setenv hostname overo
Overo # setenv ip ${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:none
Overo # setenv nfsroot /exports/overo
Overo # setenv nfsargs setenv bootargs console=\${console} root=/dev/nfs rootfstype=nfs ip=\${ip} nfsroot=\${nfsroot} rootwait
Overo # setenv loadnfskernel tftp \${loadaddr} uImage

Save what you've entered in the u-boot environment so far. None of these variables are used by default, so the boot behavior is still unchanged.

Overo # saveenv

==Testing==

The next step is to test the network boot by running each step manually.
Later we will modify u-boot to run this automatically.

1. First tftp load the kernel into the overo memory

Overo # print loadaddr
loadaddr=0x82000000

Overo # tftp ${loadaddr} uImage
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 00:15:c9:28:c1:78
Using smc911x-0 device
TFTP from server 192.168.4.4; our IP address is 192.168.4.50
Filename 'uImage'.
Load address: 0x82000000
Loading: T ######################################################
######################################################
######################################################
#####################################################
done
Bytes transferred = 3147516 (3006fc hex)

Okay, if that worked, make sure the loadnfskernel variable we created doesn't
have a typo by running the same process again using the u-boot run command.

Overo # run loadnfskernel

You should get the same results, a kernel tftp loaded into memory.

If it did not work, use a network monitoring tool like tcpdump or wireshark to
see if you are getting any traffic.

See the Notes section for some troubleshooting tips.

2. Test the loading of the boot arguments.

Overo # print bootargs
## Error: "bootargs" not defined
Overo # print nfsargs
nfsargs=setenv bootargs console=${console} root=/dev/nfs rootfstype=nfs ip=${ip} nfsroot=${nfsroot} rootwait
Overo # run nfsargs
Overo # print bootargs
bootargs=console=ttyS2,115200n8 root=/dev/nfs rootfstype=nfs ip=192.168.4.50:192.168.4.4:192.168.4.1:255.255.255.0:overo:eth0:none nfsroot=/exports/overo rootwait

Make sure that bootargs looks correct. The format of the ip kernel command line argument is found in the kernel documentation under [http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/nfsroot.txt filesystems/nfsroot.txt]

3. Boot the kernel

With a kernel of the correct format loaded into memory, the u-boot command bootm will
transfer control of the processor to this kernel.

Overo # bootm ${loadaddr}

...normal kernel boot messages here, then...
net eth0: SMSC911x/921x identified at 0xd08c8000, IRQ: 336
IP-Config: Complete:
device=eth0, addr=192.168.4.50, mask=255.255.255.0, gw=192.168.4.1,
host=overo, domain=, nis-domain=(none),
bootserver=192.168.4.4, rootserver=192.168.4.4, rootpath=
Looking up port of RPC 100003/2 on 192.168.4.4
Looking up port of RPC 100005/1 on 192.168.4.4
VFS: Mounted root (nfs filesystem) on device 0:13.
Freeing init memory: 928K
INIT: version 2.86 booting
...
The Angstrom Distribution overo ttyS2
Angstrom 2009.X-test-20100110 overo ttyS2
overo login:

==Making it automatic==

So if everything worked and you want to boot this way every time you need to modify the
bootcmd u-boot variable.

Reboot the gumstix and hit a key to stop it in u-boot again.

Overo # print bootcmd
bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi; fi; else run nandboot; fi

You may want to save this for the future or see the Notes section for where it is defined in the build.

Make a new bootcmd using the u-boot environment variables that we created.

Overo # setenv bootcmd echo Booting nfs ...\; run loadnfskernel\; run nfsargs\; bootm \${loadaddr}

Overo # saveenv

Now reboot and the gumstix should nfsboot by default.

Overo # reset

==Notes==

1. tftp and inetd. You can use inetd to run tftp if you want. Just edit the -s option for tftp appropriately in /etc/inetd.conf

tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /exports/overo/boot

and instead of this restart command

sudo /etc/init.d/tftpd-hpa restart

use this one

sudo /etc/init.d/openbsd-inetd restart

And finally, prevent tftpd-hpa from starting by

sudo mv /etc/rc2.d/S20tftpd-hpa /etc/rc2.d/s20tftpd-hpa

2. The default u-boot environment variables for the overo are defined in the u-boot source tree under include/configs/omap3-overo.h if you wanted to customize or go back to defaults.

3. The documentation for linux kernel parameters for nfs booting can be found in the linux source tree under
[http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/nfsroot.txt Documentation/filesystems/nfsroot.txt]
and [http://www.kernel.org/doc/Documentation/kernel-parameters.txt Documentation/kernel-parameters.txt.]

4. tftp listens over udp on port 69
$ grep tftp /etc/services
tftp 69/udp

You can check if it is listening with the following command.

$ netstat -an | grep udp
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:880 0.0.0.0:*
udp 0 0 0.0.0.0:39921 0.0.0.0:*
udp 0 0 0.0.0.0:56957 0.0.0.0:*
udp 0 0 0.0.0.0:2049 0.0.0.0:*
udp 0 0 0.0.0.0:59435 0.0.0.0:*
udp 0 0 0.0.0.0:69 0.0.0.0:*

5. nfs listens on port 2049 both tcp and udp. The nfs root process uses only udp.
$ grep nfs /etc/services
nfs 2049/tcp # Network File System
nfs 2049/udp # Network File System

6. The following is a tcpdump command for watching the gumstix boot traffic. Choose the appropriate
interface for your workstation.

$ sudo tcpdump -i eth1 -l -n udp

7. A cross-over ethernet cable connected between the workstation and the gumstix works well
if you can't host services on your regular network. You may want to check before starting a
tftp server on a shared network. A dedicated switch/hub will also work to keep things isolated.

8. You can check for running firewall rules with this command

$ sudo iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

If you get output different then this (nothing running) and you are having problems booting, then
you should ensure you are not blocking any of the required traffic.

9. I removed the kernel parameters for the kernel display configuration for wiki formatting reasons.
You should add the settings you require to the bootcmd variable in the example.

10. There is a patch to u-boot in the current gumstix overo-oe tree that improves the ethernet
network speeds on the overos. You can save about 10 seconds on an nfs boot using a u-boot
built with this patch as well as get better ethernet performance after booting. When you do a
network boot without a microSD card, you are using the u-boot on the NAND flash which
was probably built without this patch.
Build a newer version of u-boot following the standard build procedures. (U-boot is built
whenever you build an image.) Then copy it to NAND using the instructions
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html here.]

11. If the gumstix seems unwilling to connect to your NFS server, ensure you've enabled NFS options in your kernel.
You'll need to include (directly, not as modules) CONFIG_NFS_FS, CONFIG_ROOT_NFS, CONFIG_NET_ETHERNET,
and, the appropriate Ethernet chip driver, in my case, CONFIG_SMC911X.

Category:How to - Network Boot

2010-02-07T16:37:36Z

Sellis: Note to disable inetd

==Overview==

Network booting can be very convenient during the development cycle
for an embedded device. Current Gumstix Overos have a bootloader
and kernel ready for network booting if you have an expansion board
with an ethernet connector. Older Gumstix Overos can upgrade their
version of u-boot to get support for network booting. This procedure
also works for Verdex-Pro boards although all the text and links
refer to Overo.

The procedures that follow are for setting up a workstation to act
as both the tftp server and the nfs server to host the root file
system.

The procedure described does not require a dhcp server.

==Setup==

The following procedure assumes a Linux workstation to host all
the services. The workstation for the example is running Ubuntu 9.10.

There are multiple ways to configure the nfs server and the tftpd
server. This example tries to keep it simple.

The names of the packages may be different if you are using another
Linux distribution.

The example will use the following network configuration.

Workstation IP: 192.168.4.4

Gumstix IP: 192.168.4.50

You will also need a Gumstix Overo kernel and rootfs on the workstation.

You can either
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html build]
one yourself or download one
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Downloading-pre-built-images/111.html here.]

I'll assume an omap3-console-image custom built with OE located in the standard location.
Any image will work though.

==Packages==

Install the following Ubuntu packages on the workstation

tftp-hpa

nfs-common

nfs-kernel-server

portmap

==Create a root filesystem==

Create and populate the /exports directory with a kernel and a root filesystem

sudo mkdir -p /exports/overo
sudo tar -C /exports/overo -xvjf ${OVEROTOP}/tmp/deploy/glibc/images/overo/omap3-console-image-overo.tar.bz2

==Configure the tftp server==

Disable inetd control of tftpd which is the default for Ubuntu. Either comment the line in /etc/inetd.conf that references tftpd by adding a # to the start of the tftp line

# tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/int.tftpd -s /var/lib/tftpboot

or if you don't need inetd for any other service, which a Ubuntu desktop install typically doesn't, disable inetd completely this way

sudo mv /etc/rc2.d/S20openbsd-inetd /etc/rc2.d/s20openbsd-inetd

See the NOTES section.

Edit /etc/default/tftpd-hpa

RUN_DAEMON="yes"
OPTIONS="-l -s /exports/overo/boot"

What we are doing here is pointing the tftp daemon at the Gumstix root
filesystem we created above. The uImage kernel image sits here.

$ ls -all /exports/overo/boot/*
lrwxrwxrwx 1 root root 13 2010-01-13 11:50 /exports/overo/boot/uImage -> uImage-2.6.32
-rw-r--r-- 1 root root 3147516 2010-01-10 11:12 /exports/overo/boot/uImage-2.6.32

==Configure the nfs server==

Add the following line to /etc/exports

/exports/overo 192.168.4.50(rw,no_root_squash,no_subtree_check)

This tells the nfs server what directories to export as an nfs mountpoint and what machines have access to it.
Use man exports to get the documentation for /etc/exports.

==Restart the servers==

sudo /etc/init.d/tftpd-hpa restart
sudo service portmap restart
sudo /etc/init.d/nfs-kernel-server restart

==Configure u-boot==

Establish a serial console connection with the gumstix.

Power the gumstix unit and hit a key to stop the process in uboot.

Add some environment variables to u-boot.

Overo # setenv ipaddr 192.168.4.50
Overo # setenv netmask 255.255.255.0
Overo # setenv serverip 192.168.4.4
Overo # setenv gatewayip 192.168.4.1
Overo # setenv hostname overo

Overo # setenv ip ${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:none
Overo # setenv nfsroot /exports/overo
Overo # setenv nfsargs setenv bootargs console=\${console} root=/dev/nfs rootfstype=nfs ip=\${ip} nfsroot=\${nfsroot} rootwait
Overo # setenv loadnfskernel tftp \${loadaddr} uImage

Save what you've entered in the u-boot environment so far. None of these variables
are used by the default boot process so there will be no booting behavior changes
yet.

Overo # saveenv

==Testing==

The next step is to test the network boot by running each step manually.
Later we will modify u-boot to run this automatically.

1. First tftp load the kernel into the overo memory

Overo # print loadaddr
loadaddr=0x82000000

Overo # tftp ${loadaddr} uImage
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 00:15:c9:28:c1:78
Using smc911x-0 device
TFTP from server 192.168.4.4; our IP address is 192.168.4.50
Filename 'uImage'.
Load address: 0x82000000
Loading: T ######################################################
######################################################
######################################################
#####################################################
done
Bytes transferred = 3147516 (3006fc hex)

Okay, if that worked, make sure the loadnfskernel variable we created doesn't
have a typo by running the same process again using the u-boot run command.

Overo # run loadnfskernel

You should get the same results, a kernel tftp loaded into memory.

If it did not work, use a network monitoring tool like tcpdump or wireshark to
see if you are getting any traffic.

See the Notes section for some troubleshooting tips.

2. Test the loading of the boot arguments.

Overo # print bootargs
## Error: "bootargs" not defined
Overo # print nfsargs
nfsargs=setenv bootargs console=${console} root=/dev/nfs rootfstype=nfs ip=${ip} nfsroot=${nfsroot} rootwait
Overo # run nfsargs
Overo # print bootargs
bootargs=console=ttyS2,115200n8 root=/dev/nfs rootfstype=nfs ip=192.168.4.50:192.168.4.4:192.168.4.1:255.255.255.0:overo:eth0:none nfsroot=/exports/overo rootwait

Make sure that bootargs looks correct.

3. Boot the kernel

With a kernel of the correct format loaded into memory, the u-boot command bootm will
transfer control of the processor to this kernel.

Overo # bootm ${loadaddr}

...normal kernel boot messages here, then...
net eth0: SMSC911x/921x identified at 0xd08c8000, IRQ: 336
IP-Config: Complete:
device=eth0, addr=192.168.4.50, mask=255.255.255.0, gw=192.168.4.1,
host=overo, domain=, nis-domain=(none),
bootserver=192.168.4.4, rootserver=192.168.4.4, rootpath=
Looking up port of RPC 100003/2 on 192.168.4.4
Looking up port of RPC 100005/1 on 192.168.4.4
VFS: Mounted root (nfs filesystem) on device 0:13.
Freeing init memory: 928K
INIT: version 2.86 booting
...
The Angstrom Distribution overo ttyS2
Angstrom 2009.X-test-20100110 overo ttyS2
overo login:

==Making it automatic==

So if everything worked and you want to boot this way every time you need to modify the
bootcmd u-boot variable.

Reboot the gumstix and hit a key to stop it in u-boot again.

Overo # print bootcmd
bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi; fi; else run nandboot; fi

You may want to save this for the future or see the Notes section for where it is defined in the build.

Make a new bootcmd using the u-boot environment variables that we created.

Overo # setenv bootcmd echo Booting nfs ...\; run loadnfskernel\; run nfsargs\; bootm \${loadaddr}

Overo # saveenv

Now reboot and the gumstix should nfsboot by default.

Overo # reset

==Notes==

1. tftp and inetd. You can use inetd to run tftp if you want. Just edit the -s option for tftp appropriately in /etc/inetd.conf

tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /exports/overo/boot

and instead of this restart command

sudo /etc/init.d/tftpd-hpa restart

use this one

sudo /etc/init.d/openbsd-inetd restart

And finally, prevent tftpd-hpa from starting by

sudo mv /etc/rc2.d/S20tftpd-hpa /etc/rc2.d/s20tftpd-hpa

though that's not really necessary since inetd beats him to the socket.

TIMTOWTDI

2. The default u-boot environment variables are defined in the u-boot source tree under include/configs/omap3-overo.h

3. The documentation for linux kernel parameters for nfs booting can be found in the linux source tree under
Documentation/filesystems/nfsroot.txt and Documentation/kernel-parameters.txt.

4. tftp listens over udp on port 69
$ grep tftp /etc/services
tftp 69/udp

You can check if it is listening with the following command.

$ netstat -an | grep udp
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:880 0.0.0.0:*
udp 0 0 0.0.0.0:39921 0.0.0.0:*
udp 0 0 0.0.0.0:56957 0.0.0.0:*
udp 0 0 0.0.0.0:2049 0.0.0.0:*
udp 0 0 0.0.0.0:59435 0.0.0.0:*
udp 0 0 0.0.0.0:69 0.0.0.0:*

5. nfs listens on port 2049 both tcp and udp. The nfs root process uses only udp.
$ grep nfs /etc/services
nfs 2049/tcp # Network File System
nfs 2049/udp # Network File System

6. The following is a tcpdump command for watching the gumstix boot traffic. Choose the appropriate
interface for your workstation.

$ sudo tcpdump -i eth1 -l -n udp

7. A cross-over ethernet cable connected between the workstation and the gumstix works well
if you can't host services on your regular network. You may want to check before starting a
tftp server on a shared network. A dedicated switch/hub will also work to keep things isolated.

8. You can check for running firewall rules with this command

$ sudo iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

If you get output different then this (nothing running) and you are having problems booting, then
you should ensure you are not blocking any of the required traffic.

9. I removed the kernel parameters for the kernel display configuration for wiki formatting reasons.
You should add the settings you require to the bootcmd variable in the example.

10. There is a patch to u-boot in the current gumstix overo-oe tree that improves the ethernet
network speeds on the overos. You can save about 10 seconds on an nfs boot using a u-boot
built with this patch as well as get better ethernet performance after booting. When you do a
network boot without a microSD card, you are using the u-boot on the NAND flash which
was probably built without this patch.
Build a newer version of u-boot following the standard build procedures. (U-boot is built
whenever you build an image.) Then copy it to NAND using the instructions
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html here.]

11. If the gumstix seems unwilling to connect to your NFS server, ensure you've enabled NFS options in your kernel.
You'll need to include (directly, not as modules) CONFIG_NFS_FS, CONFIG_ROOT_NFS, CONFIG_NET_ETHERNET,
and, the appropriate Ethernet chip driver, in my case, CONFIG_SMC911X.

Category:How to - i2c

2010-02-04T13:07:42Z

Sellis: Not supposed to include linux/i2c.h in userspace progs, I2C_SLAVE is also in linux/i2c-dev.h

==Background==

I2c is a 2-wire serial 8 bit communications protocol from the old days. It is mainly used to communicate between on-board components when the design does not allow for a data and address bus. Typical components are elapsed timer chips, ee-proms, FRAM's, A/D and D/A chips. Some cpu's have the I2c hardware shift registers built in.

The 2 wires are the SCL or clock wire and the SDL or data wire. The clock high to low transition is used to signal that the data wire has a stable 1/0 data value and that the receiver should shift this into the data results register. The clock line is high when the bus is idle. A special high to low transition on the clock line followed by a high to low transition on the data line signals the start of a message sequence. the end of a message sequence is a low to high transition in the data line followed by a low to high transition in the SCL line. An important aspect of this communication standard is that each device is assigned a unique 7 bit address, (oh yea the 8th bit is the Read/write indicator to complete the byte). The device address is the first byte sent in any communication. Subsequent bytes of a message depend on the device you are talking to.

Because of patents that have since expired, other companies had to use slightly different ways to do the same thing so a very similar serial communications method called SPI uses 4 wires and another called TWI uses the same 2 wires.

== I2C with Gumstix Overo ==

There are several i2c buses available on the overo board.

The bus accessible from most of the 40 pin expansion board headers is i2c-3.

Refer to the board [http://pubs.gumstix.com/boards/ schematics] to find whether the board you are using exposes the i2c lines.

You are looking for GPIO184_SCL3 and GPIO185_SDA3.

For many of the boards, pin 23 is SCL and pin 24 is SDA.

The voltage levels are 1.8v, so a voltage level shifter is required to connect to 3.3 or 5 volt slave devices.
A good explanation can be found [http://www.nxp.com/documents/application_note/AN10441.pdf here.]

The overo main board already has pullup resistors for SCL and SDA.

The default gumstix kernels set the i2c-3 bus speed to 400 kHz.

This can be changed to 100 kHz with a kernel command line parameter in u-boot.

i2c_bus=3,100

The i2c-3 bus appears as a character device under /dev

root@overo:/dev# ls -all i2c*
crw-rw---- 1 root root 89, 1 Jan 1 2000 i2c-1
crw-rw---- 1 root root 89, 3 Jan 1 2000 i2c-3

Programmers can access devices on the bus using standard unix file i/o.

You must set the slave address with an ioctl() call prior to communicating with a slave device.

The driver takes care of shifting the slave address one bit and appending the R/W bit in the first byte of the transfer.

Here's a C example minus any error checking.

...
#include <stdint.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <linux/i2c-dev.h> /* for I2C_SLAVE */
...

int fh;
uint8_t data[4];

fh = open("/dev/i2c-3", O_RDWR);

/* tell the driver we want the device at address 0x20 */
ioctl(fh, I2C_SLAVE, 0x20);

/* write two bytes */
data[0] = 0x05;
data[1] = 0x08;
write(fh, data, 2);

/* read 4 bytes */
read(fh, data, 4);

close(fh);

==Further information==

Another source of I2C information can be found [http://www.gumstix.net/wiki/index.php?title=I%C2%B2C here].

==Sample code==

Here is a small project showing how to write Overo I2C userland code to communicate with an I/O expander as the slave device. It includes a schematic for the voltage level conversion of the I2C lines that's required.

[http://github.com/scottellis/overo-mcp23017 overo-mcp23017]

[[Category:How_to_-_general]]

Category:How to - Network Boot

2010-02-02T16:26:04Z

Sellis: Missing restart arg

==Overview==

Network booting can be very convenient during the development cycle
for an embedded device. Current Gumstix Overos have a bootloader
and kernel ready for network booting if you have an expansion board
with an ethernet connector. Older Gumstix Overos can upgrade their
version of u-boot to get support for network booting. This procedure
also works for Verdex-Pro boards although all the text and links
refer to Overo.

The procedures that follow are for setting up a workstation to act
as both the tftp server and the nfs server to host the root file
system.

The procedure described does not require a dhcp server.

==Setup==

The following procedure assumes a Linux workstation to host all
the services. The workstation for the example is running Ubuntu 9.10.

There are multiple ways to configure the nfs server and the tftpd
server. This example tries to keep it simple.

The names of the packages may be different if you are using another
Linux distribution.

The example will use the following network configuration.

Workstation IP: 192.168.4.4

Gumstix IP: 192.168.4.50

You will also need a Gumstix Overo kernel and rootfs on the workstation.

You can either
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html build]
one yourself or download one
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Downloading-pre-built-images/111.html here.]

I'll assume an omap3-console-image custom built with OE located in the standard location.
Any image will work though.

==Packages==

Install the following Ubuntu packages on the workstation

tftp-hpa

nfs-common

nfs-kernel-server

portmap

==Create a root filesystem==

Create and populate the /exports directory with a kernel and a root filesystem

sudo mkdir -p /exports/overo
sudo tar -C /exports/overo -xvjf ${OVEROTOP}/tmp/deploy/glibc/images/overo/omap3-console-image-overo.tar.bz2

==Configure the tftp server==

Edit /etc/default/tftpd-hpa

RUN_DAEMON="yes"
OPTIONS="-l -s /exports/overo/boot"

What we are doing here is pointing the tftp daemon at the Gumstix root
filesystem we created above. The uImage kernel image sits here.

$ ls -all /exports/overo/boot/*
lrwxrwxrwx 1 root root 13 2010-01-13 11:50 /exports/overo/boot/uImage -> uImage-2.6.32
-rw-r--r-- 1 root root 3147516 2010-01-10 11:12 /exports/overo/boot/uImage-2.6.32

==Configure the nfs server==

Add the following line to /etc/exports

/exports/overo 192.168.4.50(rw,no_root_squash,no_subtree_check)

This tells the nfs server what directories to export as an nfs mountpoint and what machines have access to it.
Use man exports to get the documentation for /etc/exports.

==Restart the servers==

sudo /etc/init.d/tftpd-hpa restart
sudo service portmap restart
sudo /etc/init.d/nfs-kernel-server restart

==Configure u-boot==

Establish a serial console connection with the gumstix.

Power the gumstix unit and hit a key to stop the process in uboot.

Add some environment variables to u-boot.

Overo # setenv ipaddr 192.168.4.50
Overo # setenv netmask 255.255.255.0
Overo # setenv serverip 192.168.4.4
Overo # setenv gatewayip 192.168.4.1
Overo # setenv hostname overo

Overo # setenv ip ${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:none
Overo # setenv nfsroot /exports/overo
Overo # setenv nfsargs setenv bootargs console=\${console} root=/dev/nfs rootfstype=nfs ip=\${ip} nfsroot=\${nfsroot} rootwait
Overo # setenv loadnfskernel tftp \${loadaddr} uImage

Save what you've entered in the u-boot environment so far. None of these variables
are used by the default boot process so there will be no booting behavior changes
yet.

Overo # saveenv

==Testing==

The next step is to test the network boot by running each step manually.
Later we will modify u-boot to run this automatically.

1. First tftp load the kernel into the overo memory

Overo # print loadaddr
loadaddr=0x82000000

Overo # tftp ${loadaddr} uImage
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 00:15:c9:28:c1:78
Using smc911x-0 device
TFTP from server 192.168.4.4; our IP address is 192.168.4.50
Filename 'uImage'.
Load address: 0x82000000
Loading: T ######################################################
######################################################
######################################################
#####################################################
done
Bytes transferred = 3147516 (3006fc hex)

Okay, if that worked, make sure the loadnfskernel variable we created doesn't
have a typo by running the same process again using the u-boot run command.

Overo # run loadnfskernel

You should get the same results, a kernel tftp loaded into memory.

If it did not work, use a network monitoring tool like tcpdump or wireshark to
see if you are getting any traffic.

See the Notes section for some troubleshooting tips.

2. Test the loading of the boot arguments.

Overo # print bootargs
## Error: "bootargs" not defined
Overo # print nfsargs
nfsargs=setenv bootargs console=${console} root=/dev/nfs rootfstype=nfs ip=${ip} nfsroot=${nfsroot} rootwait
Overo # run nfsargs
Overo # print bootargs
bootargs=console=ttyS2,115200n8 root=/dev/nfs rootfstype=nfs ip=192.168.4.50:192.168.4.4:192.168.4.1:255.255.255.0:overo:eth0:none nfsroot=/exports/overo rootwait

Make sure that bootargs looks correct.

3. Boot the kernel

With a kernel of the correct format loaded into memory, the u-boot command bootm will
transfer control of the processor to this kernel.

Overo # bootm ${loadaddr}

...normal kernel boot messages here, then...
net eth0: SMSC911x/921x identified at 0xd08c8000, IRQ: 336
IP-Config: Complete:
device=eth0, addr=192.168.4.50, mask=255.255.255.0, gw=192.168.4.1,
host=overo, domain=, nis-domain=(none),
bootserver=192.168.4.4, rootserver=192.168.4.4, rootpath=
Looking up port of RPC 100003/2 on 192.168.4.4
Looking up port of RPC 100005/1 on 192.168.4.4
VFS: Mounted root (nfs filesystem) on device 0:13.
Freeing init memory: 928K
INIT: version 2.86 booting
...
The Angstrom Distribution overo ttyS2
Angstrom 2009.X-test-20100110 overo ttyS2
overo login:

==Making it automatic==

So if everything worked and you want to boot this way every time you need to modify the
bootcmd u-boot variable.

Reboot the gumstix and hit a key to stop it in u-boot again.

Overo # print bootcmd
bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi; fi; else run nandboot; fi

You may want to save this for the future or see the Notes section for where it is defined in the build.

Make a new bootcmd using the u-boot environment variables that we created.

Overo # setenv bootcmd echo Booting nfs ...\; run loadnfskernel\; run nfsargs\; bootm \${loadaddr}

Overo # saveenv

Now reboot and the gumstix should nfsboot by default.

Overo # reset

==Notes==

1. The default u-boot environment variables are defined in the u-boot source tree under include/configs/omap3-overo.h

2. The documentation for linux kernel parameters for nfs booting can be found in the linux source tree under
Documentation/filesystems/nfsroot.txt and Documentation/kernel-parameters.txt.

3. tftp listens over udp on port 69
$ grep tftp /etc/services
tftp 69/udp

You can check if it is listening with the following command.

$ netstat -an | grep udp
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:880 0.0.0.0:*
udp 0 0 0.0.0.0:39921 0.0.0.0:*
udp 0 0 0.0.0.0:56957 0.0.0.0:*
udp 0 0 0.0.0.0:2049 0.0.0.0:*
udp 0 0 0.0.0.0:59435 0.0.0.0:*
udp 0 0 0.0.0.0:69 0.0.0.0:*

4. nfs listens on port 2049 both tcp and udp. The nfs root process uses only udp.
$ grep nfs /etc/services
nfs 2049/tcp # Network File System
nfs 2049/udp # Network File System

5. The following is a tcpdump command for watching the gumstix boot traffic. Choose the appropriate
interface for your workstation.

$ sudo tcpdump -i eth1 -l -n udp

6. A cross-over ethernet cable connected between the workstation and the gumstix works well
if you can't host services on your regular network. You may want to check before starting a
tftp server on a shared network. A dedicated switch/hub will also work to keep things isolated.

7. You can check for running firewall rules with this command

$ sudo iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

If you get output different then this (nothing running) and you are having problems booting, then
you should ensure you are not blocking any of the required traffic.

8. I removed the kernel parameters for the kernel display configuration for wiki formatting reasons.
You should add the settings you require to the bootcmd variable in the example.

9. There is a patch to u-boot in the current gumstix overo-oe tree that improves the ethernet
network speeds on the overos. You can save about 10 seconds on an nfs boot using a u-boot
built with this patch as well as get better ethernet performance after booting. When you do a
network boot without a microSD card, you are using the u-boot on the NAND flash which
was probably built without this patch.
Build a newer version of u-boot following the standard build procedures. (U-boot is built
whenever you build an image.) Then copy it to NAND using the instructions
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html here.]

10. If the gumstix seems unwilling to connect to your NFS server, ensure you've enabled NFS options in your kernel.
You'll need to include (directly, not as modules) CONFIG_NFS_FS, CONFIG_ROOT_NFS, CONFIG_NET_ETHERNET,
and, the appropriate Ethernet chip driver, in my case, CONFIG_SMC911X.

Category:How to - usb

2010-01-30T13:21:33Z

Sellis: better method, use local.conf instead of editting recipe directly

==USBNet with Overo==

The OTG USB port on the Overo expansion boards support USB networking. To enable this, the OTG port needs to be configured as a USB peripheral or gadget. The default kernels from Gumstix have the OTG port configured to act as a USB host.

The procedure for changing the configuration requires rebuilding your kernel, so you should first be comfortable with [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html setting up a build environment] and building images for your Overo.

The following steps assume you are using a recent snapshot of the gumstix-oe git tree and are going to use kernel version 2.6.31 or 2.6.32.

The gumstix recipes for either of these kernels has a variable that allows you to specify how the OTG usb port is configured.

Kernel version 2.6.31 is used for the example. Substitute 2.6.32 if that's the kernel you are using.

To get started, look at the recipe file ${OVEROTOP}/org.openembedded.dev/recipes/linux/linux-omap3_2.6.31.bb. You'll see a line

MUSB_MODE ?= "host"

There are three valid values for MUSB_MODE: "host", "peripheral" or "otg".

You could change the MUSB_MODE assignment directly in the recipe, but a better way to do this is to modify your local.conf file and add a MUSB_MODE variable.

The ?= assignment means "host" will be assigned to MUSB_MODE only if it does not already have a value which it will if you give it one in local.conf.

The local.conf file is found here ${OVEROTOP}/build/conf/local.conf.

Add the line

MUSB_MODE = "peripheral"

or

MUSB_MODE = "otg"

depending on your preference.

Now rebuild your kernel.

cd ${OVEROTOP}
bitbake -c clean linux-omap3-2.6.31
bitbake -c rebuild linux-omap3-2.6.31

And then rebuild your rootfs since the drivers available in /lib/modules will have changed.

bitbake omap3-console-image

Change omap3-console-image to whatever image you use.

Once you have booted the new system, you still need to load the g_ether driver since it was built as a module.

You can add g_ether to /etc/modules if you always want it to load at boot.

root@overo# modbprobe g_ether
g_ether gadget: using random self ethernet address
g_ether gadget: using random host ethernet address
usb0: MAC d6:2c:8f:d9:51:32
usb0: HOST MAC f2:99:dc:4c:cb:7a
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready

root@overo:~# ifconfig -a
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

usb0 Link encap:Ethernet HWaddr D6:2C:8F:D9:51:32
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Configure the usb0 interface the way you would any other.

For example

root@overo:~# ifconfig usb0 192.168.20.2 netmask 255.255.255.0

If you then plug the usb OTG cable into a host computer ready for usb networking you'll get a console message

g_ether gadget: high speed config #1: CDC Ethernet (ECM)

The rest is all standard Linux networking.

Category:How to - i2c

2010-01-28T21:19:48Z

Sellis: Point to a simpler example, maybe more useful

==Background==

I2c is a 2-wire serial 8 bit communications protocol from the old days. It is mainly used to communicate between on-board components when the design does not allow for a data and address bus. Typical components are elapsed timer chips, ee-proms, FRAM's, A/D and D/A chips. Some cpu's have the I2c hardware shift registers built in.

The 2 wires are the SCL or clock wire and the SDL or data wire. The clock high to low transition is used to signal that the data wire has a stable 1/0 data value and that the receiver should shift this into the data results register. The clock line is high when the bus is idle. A special high to low transition on the clock line followed by a high to low transition on the data line signals the start of a message sequence. the end of a message sequence is a low to high transition in the data line followed by a low to high transition in the SCL line. An important aspect of this communication standard is that each device is assigned a unique 7 bit address, (oh yea the 8th bit is the Read/write indicator to complete the byte). The device address is the first byte sent in any communication. Subsequent bytes of a message depend on the device you are talking to.

Because of patents that have since expired, other companies had to use slightly different ways to do the same thing so a very similar serial communications method called SPI uses 4 wires and another called TWI uses the same 2 wires.

== I2C with Gumstix Overo ==

There are several i2c buses available on the overo board.

The bus accessible from most of the 40 pin expansion board headers is i2c-3.

Refer to the board [http://pubs.gumstix.com/boards/ schematics] to find whether the board you are using exposes the i2c lines.

You are looking for GPIO184_SCL3 and GPIO185_SDA3.

For many of the boards, pin 23 is SCL and pin 24 is SDA.

The voltage levels are 1.8v, so a voltage level shifter is required to connect to 3.3 or 5 volt slave devices.
A good explanation can be found [http://www.nxp.com/documents/application_note/AN10441.pdf here.]

The overo main board already has pullup resistors for SCL and SDA.

The default gumstix kernels set the i2c-3 bus speed to 400 kHz.

This can be changed to 100 kHz with a kernel command line parameter in u-boot.

i2c_bus=3,100

The i2c-3 bus appears as a character device under /dev

root@overo:/dev# ls -all i2c*
crw-rw---- 1 root root 89, 1 Jan 1 2000 i2c-1
crw-rw---- 1 root root 89, 3 Jan 1 2000 i2c-3

Programmers can access devices on the bus using standard unix file i/o.

You must set the slave address with an ioctl() call prior to communicating with a slave device.

The driver takes care of shifting the slave address one bit and appending the R/W bit in the first byte of the transfer.

Here's a C example minus any error checking.

...
#include <stdint.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <linux/i2c.h> /* for I2C_SLAVE */
...

int fh;
uint8_t data[4];

fh = open("/dev/i2c-3", O_RDWR);

/* tell the driver we want the device at address 0x20 */
ioctl(fh, I2C_SLAVE, 0x20);

/* write two bytes */
data[0] = 0x05;
data[1] = 0x08;
write(fh, data, 2);

/* read 4 bytes */
read(fh, data, 4);

close(fh);

==Further information==

Another source of I2C information can be found [http://www.gumstix.net/wiki/index.php?title=I%C2%B2C here].

==Sample code==

Here is a small project showing how to write Overo I2C userland code to communicate with an I/O expander as the slave device. It includes a schematic for the voltage level conversion of the I2C lines that's required.

[http://github.com/scottellis/overo-mcp23017 overo-mcp23017]

[[Category:How_to_-_general]]

Category:How to - usb

2010-01-20T21:46:24Z

Sellis: Formatting

==USBNet with Overo==

The OTG USB port on the Overo expansion boards support USB networking. To enable this, the OTG port needs to be configured as a USB peripheral or gadget. The default kernels from Gumstix have the OTG port configured to act as a USB host.

The procedure for changing the configuration requires rebuilding your kernel, so you should first be comfortable with [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html setting up a build environment] and building images for your Overo.

The following steps assume you are using a recent snapshot of the gumstix-oe git tree and are going to use kernel version 2.6.31 or 2.6.32.

The gumstix-oe linux-omap3_2.6.xx recipes for either of these kernels has a variable that allows you to specify how you want the OTG usb port configured.

Kernel version 2.6.31 is used for the example. Substitute 2.6.32 if that's the kernel you are using.

To get started, first edit the recipe file ${OVEROTOP}/org.openembedded.dev/recipes/linux/linux-omap3_2.6.31.bb

Change the line

MUSB_MODE ?= "host"

to

MUSB_MODE ?= "peripheral"

or "otg".

Next rebuild your kernel.

cd ${OVEROTOP}
bitbake -c clean linux-omap3-2.6.31
bitbake -c rebuild linux-omap3-2.6.31

And then rebuild your rootfs.

bitbake omap3-console-image

Change omap3-console-image to whatever image you use.

Once you have booted the new system, you still need to load the g_ether driver since it was built as a module.

You can add g_ether to /etc/modules if you always want it to load at boot.

root@overo# modbprobe g_ether
g_ether gadget: using random self ethernet address
g_ether gadget: using random host ethernet address
usb0: MAC d6:2c:8f:d9:51:32
usb0: HOST MAC f2:99:dc:4c:cb:7a
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready

root@overo:~# ifconfig -a
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

usb0 Link encap:Ethernet HWaddr D6:2C:8F:D9:51:32
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Configure the usb0 interface the way you would any other.

For example

root@overo:~# ifconfig usb0 192.168.20.2 netmask 255.255.255.0

If you then plug the usb OTG cable into a host computer ready for usb networking you'll get a console message

g_ether gadget: high speed config #1: CDC Ethernet (ECM)

The rest is all standard Linux networking.

Category:How to - Network Boot

2010-01-19T11:27:28Z

Sellis: Clarify when nand u-boot is used

==Overview==

Network booting can be very convenient during the development cycle
for an embedded device. Current Gumstix Overos have a bootloader
and kernel ready for network booting if you have an expansion board
with an ethernet connector. Older Gumstix Overos can upgrade their
version of u-boot to get support for network booting.

The procedures that follow are for setting up a workstation to act
as both the tftp server and the nfs server to host the root file
system.

The procedure described does not require a dhcp server.

==Setup==

The following procedure assumes a Linux workstation to host all
the services. The workstation for the example is running Ubuntu 9.10.

There are multiple ways to configure the nfs server and the tftpd
server. This example tries to keep it simple.

The names of the packages may be different if you are using another
Linux distribution.

The example will use the following network configuration.

Workstation IP: 192.168.4.4

Gumstix IP: 192.168.4.50

You will also need a Gumstix Overo kernel and rootfs on the workstation.

You can either
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html build]
one yourself or download one
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Downloading-pre-built-images/111.html here.]

I'll assume an omap3-console-image custom built with OE located in the standard location.
Any image will work though.

==Packages==

Install the following Ubuntu packages on the workstation

tftp-hpa

nfs-common

nfs-kernel-server

portmap

==Create a root filesystem==

Create and populate the /exports directory with a kernel and a root filesystem

sudo mkdir -p /exports/overo
sudo tar -C /exports/overo -xvjf ${OVEROTOP}/tmp/deploy/glibc/images/overo/omap3-console-image-overo.tar.bz2

==Configure the tftp server==

Edit /etc/default/tftpd-hpa

RUN_DAEMON="yes"
OPTIONS="-l -s /exports/overo/boot"

What we are doing here is pointing the tftp daemon at the Gumstix root
filesystem we created above. The uImage kernel image sits here.

$ ls -all /exports/overo/boot/*
lrwxrwxrwx 1 root root 13 2010-01-13 11:50 /exports/overo/boot/uImage -> uImage-2.6.32
-rw-r--r-- 1 root root 3147516 2010-01-10 11:12 /exports/overo/boot/uImage-2.6.32

==Configure the nfs server==

Add the following line to /etc/exports

/exports/overo 192.168.4.50(rw,no_root_squash,no_subtree_check)

This tells the nfs server what directories to export as an nfs mountpoint and what machines have access to it.
Use man exports to get the documentation for /etc/exports.

==Restart the servers==

sudo /etc/init.d/tftpd-hpa restart
sudo service portmap restart
sudo /etc/init.d/nfs-kernel-server

==Configure u-boot==

Establish a serial console connection with the gumstix.

Power the gumstix unit and hit a key to stop the process in uboot.

Add some environment variables to u-boot.

Overo # setenv ipaddr 192.168.4.50
Overo # setenv netmask 255.255.255.0
Overo # setenv serverip 192.168.4.4
Overo # setenv gatewayip 192.168.4.1
Overo # setenv hostname overo

Overo # setenv ip ${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:none
Overo # setenv nfsroot /exports/overo
Overo # setenv nfsargs setenv bootargs console=\${console} root=/dev/nfs rootfstype=nfs ip=\${ip} nfsroot=\${nfsroot} rootwait
Overo # setenv loadnfskernel tftp \${loadaddr} uImage

Save what you've entered in the u-boot environment so far. None of these variables
are used by the default boot process so there will be no booting behavior changes
yet.

Overo # saveenv

==Testing==

The next step is to test the network boot by running each step manually.
Later we will modify u-boot to run this automatically.

1. First tftp load the kernel into the overo memory

Overo # print loadaddr
loadaddr=0x82000000

Overo # tftp ${loadaddr} uImage
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 00:15:c9:28:c1:78
Using smc911x-0 device
TFTP from server 192.168.4.4; our IP address is 192.168.4.50
Filename 'uImage'.
Load address: 0x82000000
Loading: T ######################################################
######################################################
######################################################
#####################################################
done
Bytes transferred = 3147516 (3006fc hex)

Okay, if that worked, make sure the loadnfskernel variable we created doesn't
have a typo by running the same process again using the u-boot run command.

Overo # run loadnfskernel

You should get the same results, a kernel tftp loaded into memory.

If it did not work, use a network monitoring tool like tcpdump or wireshark to
see if you are getting any traffic.

See the Notes section for some troubleshooting tips.

2. Test the loading of the boot arguments.

Overo # print bootargs
## Error: "bootargs" not defined
Overo # print nfsargs
nfsargs=setenv bootargs console=${console} root=/dev/nfs rootfstype=nfs ip=${ip} nfsroot=${nfsroot} rootwait
Overo # run nfsargs
Overo # print bootargs
bootargs=console=ttyS2,115200n8 root=/dev/nfs rootfstype=nfs ip=192.168.4.50:192.168.4.4:192.168.4.1:255.255.255.0:overo:eth0:none nfsroot=/exports/overo rootwait

Make sure that bootargs looks correct.

3. Boot the kernel

With a kernel of the correct format loaded into memory, the u-boot command bootm will
transfer control of the processor to this kernel.

Overo # bootm ${loadaddr}

...normal kernel boot messages here, then...
net eth0: SMSC911x/921x identified at 0xd08c8000, IRQ: 336
IP-Config: Complete:
device=eth0, addr=192.168.4.50, mask=255.255.255.0, gw=192.168.4.1,
host=overo, domain=, nis-domain=(none),
bootserver=192.168.4.4, rootserver=192.168.4.4, rootpath=
Looking up port of RPC 100003/2 on 192.168.4.4
Looking up port of RPC 100005/1 on 192.168.4.4
VFS: Mounted root (nfs filesystem) on device 0:13.
Freeing init memory: 928K
INIT: version 2.86 booting
...
The Angstrom Distribution overo ttyS2
Angstrom 2009.X-test-20100110 overo ttyS2
overo login:

==Making it automatic==

So if everything worked and you want to boot this way every time you need to modify the
bootcmd u-boot variable.

Reboot the gumstix and hit a key to stop it in u-boot again.

Overo # print bootcmd
bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi; fi; else run nandboot; fi

You may want to save this for the future or see the Notes section for where it is defined in the build.

Make a new bootcmd using the u-boot environment variables that we created.

Overo # setenv bootcmd echo Booting nfs ...\; run loadnfskernel\; run nfsargs\; bootm \${loadaddr}

Overo # saveenv

Now reboot and the gumstix should nfsboot by default.

Overo # reset

==Notes==

1. The default u-boot environment variables are defined in the u-boot source tree under include/configs/omap3-overo.h

2. The documentation for linux kernel parameters for nfs booting can be found in the linux source tree under
Documentation/filesystems/nfsroot.txt and Documentation/kernel-parameters.txt.

3. tftp listens over udp on port 69
$ grep tftp /etc/services
tftp 69/udp

You can check if it is listening with the following command.

$ netstat -an | grep udp
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:880 0.0.0.0:*
udp 0 0 0.0.0.0:39921 0.0.0.0:*
udp 0 0 0.0.0.0:56957 0.0.0.0:*
udp 0 0 0.0.0.0:2049 0.0.0.0:*
udp 0 0 0.0.0.0:59435 0.0.0.0:*
udp 0 0 0.0.0.0:69 0.0.0.0:*

4. nfs listens on port 2049 both tcp and udp. The nfs root process uses only udp.
$ grep nfs /etc/services
nfs 2049/tcp # Network File System
nfs 2049/udp # Network File System

5. The following is a tcpdump command for watching the gumstix boot traffic. Choose the appropriate
interface for your workstation.

$ sudo tcpdump -i eth1 -l -n udp

6. A cross-over ethernet cable connected between the workstation and the gumstix works well
if you can't host services on your regular network. You may want to check before starting a
tftp server on a shared network. A dedicated switch/hub will also work to keep things isolated.

7. You can check for running firewall rules with this command

$ sudo iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

If you get output different then this (nothing running) and you are having problems booting, then
you should ensure you are not blocking any of the required traffic.

8. I removed the kernel parameters for the kernel display configuration for wiki formatting reasons.
You should add the settings you require to the bootcmd variable in the example.

9. There is a patch to u-boot in the current gumstix overo-oe tree that improves the ethernet
network speeds on the overos. You can save about 10 seconds on an nfs boot using a u-boot
built with this patch as well as get better ethernet performance after booting. When you do a
network boot without a microSD card, you are using the u-boot on the NAND flash which
was probably built without this patch.
Build a newer version of u-boot following the standard build procedures. (U-boot is built
whenever you build an image.) Then copy it to NAND using the instructions
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html here.]

Kernel Reconfiguration

2010-01-19T11:04:45Z

Sellis: Formatting of commands

[[Category:How_to_-_linux]]
[[Category:How_to_-_general]]
==Verdex==

To reconfigure the kernel with the current state of Gumstix's OE things, you will need ''gnome-terminal''. Run this command: '''bitbake gumstix-kernel -c menuconfig'''

NOTE: You have to have ncurses and ncurses-dev installed in order for the MENUCONFIG to actually work. 
NOTE: If a screen flashes infront of you and dissapears edit $OE_HOME/org.openembedded.snapshot/conf/bitbake.conf to the following 
<code><pre>
-GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -x ${SHELLRCCMD}'
+GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -x ${SHELLCMDS}'
</pre></code>

NOTE: If you don't have gnome-terminal installed and wish to use xterm instead, use:
<code><pre>
-GNOME_TERMCMD = 'gnome-terminal --disable-factory -t "$TERMWINDOWTITLE"'
-GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -x ${SHELLRCCMD}'
+GNOME_TERMCMD = 'xterm -title "$TERMWINDOWTITLE"'
+GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -e ${SHELLCMDS}'
</pre></code>

The kernel config information is kept in 
''$OE_HOME/com.gumstix.collection/packages/linux/gumstix-kernel-2.6.XX/gumstix-custom-YYYYY/defconfig'' 
where XX is the current default kernel version for your bitbake environment. That nugget is set in the
''$OE_HOME/com.gumstix.collection/conf/machine/include/gumstix.inc'' file, under the PREFERRED_VERSION_gumstix-kernel
and YYYYY is usually one of connex/basix/verdex. That nugget comes from 
''$OE_HOME/build/conf/auto.conf''

After running menuconfig, running "bitbake -c rebuild gumstix-kernel" will blow away the customizations just made. There is probably a better way to do this, but in order to preserve the customizations, you can copy the new config file and replace the default config. For example, to preserve a verdex board's config, do:

<code><pre>
cp \
$OE_HOME/tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.21-r1/linux-2.6.21/.config \
$OE_HOME/com.gumstix.collection/packages/linux/gumstix-kernel-2.6.21/gumstix-custom-verdex/defconfig
</pre></code>

Now that you have replaced the default config, the following commands will rebuild and repackage the new kernel and create new images for you:

<code><pre>
bitbake -c rebuild gumstix-kernel
bitbake -c rebuild task-base-gumstix
bitbake gumstix-basic-image
</pre></code>

==Overo==

These instructions assume you are using the default gumstix-oe kernel as defined here

$ cd $OVEROTOP
$ grep linux org.openembedded/conf/machine/overo.conf
PREFERRED_PROVIDER_virtual/kernel = "linux-omap3"

And the current revision as defined here

$ bitbake --show-versions | grep linux-omap3
linux-omap3 0:2.6.32-r51

So the rest of the example will assume linux-omap3-2.6.32 revision 51.

Substitute the kernel version and revision your system is using in the following steps.

First build the kernel normally with bitbake. If you have built an image, then it's already done.

If not run this command

$ bitbake linux-omap3-2.6.32

This will create a source directory in the ${OVEROTOP}/tmp/work/overo-angstrom-linux-gnueabi directory.
In this case it will be

${OVEROTOP}/tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.32-r51

To modify the kernel configuration, run menuconfig via bitbake. Make your changes and save the configuration.

$ cd $OVEROTOP
$ bitbake -c menuconfig linux-omap3-2.6.32

The new kernel configuration file you created can be found here.

${OVEROTOP}/tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.32-r51/git/.config

Copy that file to where the bitbake recipe for the kernel will use it.

$ cp ${OVEROTOP}/tmp/work/overo-angstrom-linux/gnueabi/linux-omap3-2.6.32-r51/git/.config \
${OVEROTOP}/org.openembedded.dev/recipes/linux/linux-omap3-2.6.32/overo/defconfig

Then rebuild the kernel.

$ bitbake -c clean linux-omap3-2.6.32
$ bitbake -c rebuild linux-omap3-2.6.32

Then rebuild the rootfs to get the modules installed correctly.

Substitute the image you are using, the example assumes the omap3-console-image.

$ bitbake omap3-console-image

Finally, install the new kernel and rootfs the way you normally would using either a
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html microSD card]
or by copying to [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html onboard nand].

Kernel Reconfiguration

2010-01-18T11:35:19Z

Sellis: Added overo instructions.

[[Category:How_to_-_linux]]
[[Category:How_to_-_general]]
==Verdex==

To reconfigure the kernel with the current state of Gumstix's OE things, you will need ''gnome-terminal''. Run this command: '''bitbake gumstix-kernel -c menuconfig'''

NOTE: You have to have ncurses and ncurses-dev installed in order for the MENUCONFIG to actually work. 
NOTE: If a screen flashes infront of you and dissapears edit $OE_HOME/org.openembedded.snapshot/conf/bitbake.conf to the following 
<code><pre>
-GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -x ${SHELLRCCMD}'
+GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -x ${SHELLCMDS}'
</pre></code>

NOTE: If you don't have gnome-terminal installed and wish to use xterm instead, use:
<code><pre>
-GNOME_TERMCMD = 'gnome-terminal --disable-factory -t "$TERMWINDOWTITLE"'
-GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -x ${SHELLRCCMD}'
+GNOME_TERMCMD = 'xterm -title "$TERMWINDOWTITLE"'
+GNOME_TERMCMDRUN = '${GNOME_TERMCMD} -e ${SHELLCMDS}'
</pre></code>

The kernel config information is kept in 
''$OE_HOME/com.gumstix.collection/packages/linux/gumstix-kernel-2.6.XX/gumstix-custom-YYYYY/defconfig'' 
where XX is the current default kernel version for your bitbake environment. That nugget is set in the
''$OE_HOME/com.gumstix.collection/conf/machine/include/gumstix.inc'' file, under the PREFERRED_VERSION_gumstix-kernel
and YYYYY is usually one of connex/basix/verdex. That nugget comes from 
''$OE_HOME/build/conf/auto.conf''

After running menuconfig, running "bitbake -c rebuild gumstix-kernel" will blow away the customizations just made. There is probably a better way to do this, but in order to preserve the customizations, you can copy the new config file and replace the default config. For example, to preserve a verdex board's config, do:

<code><pre>
cp \
$OE_HOME/tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.21-r1/linux-2.6.21/.config \
$OE_HOME/com.gumstix.collection/packages/linux/gumstix-kernel-2.6.21/gumstix-custom-verdex/defconfig
</pre></code>

Now that you have replaced the default config, the following commands will rebuild and repackage the new kernel and create new images for you:

<code><pre>
bitbake -c rebuild gumstix-kernel
bitbake -c rebuild task-base-gumstix
bitbake gumstix-basic-image
</pre></code>

==Overo==

These instructions assume you are using the default gumstix-oe kernel as defined here

$ cd $OVEROTOP
$ grep linux org.openembedded/conf/machine/overo.conf
PREFERRED_PROVIDER_virtual/kernel = "linux-omap3"

And the current revision as defined here

$ bitbake --show-versions | grep linux-omap3
linux-omap3 0:2.6.32-r51

So the rest of the example will assume linux-omap3-2.6.32 revision 51.

Substitute the kernel version and revision your system is using in the following steps.

First build the kernel normally with bitbake. If you have built an image, then it's already done.

If not run this command

$ bitbake linux-omap3-2.6.32

This will create a source directory in the ${OVEROTOP}/tmp/work/overo-angstrom-linux-gnueabi directory.
In this case it will be

${OVEROTOP}/tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.32-r51

To modify the kernel configuration, run menuconfig via bitbake. Make your changes and save the configuration.

cd $OVEROTOP
bitbake -c menuconfig linux-omap3-2.6.32

The new kernel configuration file you created can be found here.

${OVEROTOP}/tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.32-r51/git/.config

Copy that file to where the bitbake recipe for the kernel will use it.

cp ${OVEROTOP}/tmp/work/overo-angstrom-linux/gnueabi/linux-omap3-2.6.32-r51/git/.config \
${OVEROTOP}/org.openembedded.dev/recipes/linux/linux-omap3-2.6.32/overo/defconfig

Then rebuild the kernel.

bitbake -c clean linux-omap3-2.6.32
bitbake -c rebuild linux-omap3-2.6.32

Then rebuild the rootfs to get the modules installed correctly.

Substitute the image you are using, the example assumes the omap3-console-image.

bitbake omap3-console-image

Finally, install the new kernel and rootfs the way you normally would using either a
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html microSD card]
or by copying to [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html onboard nand].

Category:How to - i2c

2010-01-15T14:02:31Z

Sellis: Added a link to a level shifter explanation.

==Background==

I2c is a 2-wire serial 8 bit communications protocol from the old days. It is mainly used to communicate between on-board components when the design does not allow for a data and address bus. Typical components are elapsed timer chips, ee-proms, FRAM's, A/D and D/A chips. Some cpu's have the I2c hardware shift registers built in.

The 2 wires are the SCL or clock wire and the SDL or data wire. The clock high to low transition is used to signal that the data wire has a stable 1/0 data value and that the receiver should shift this into the data results register. The clock line is high when the bus is idle. A special high to low transition on the clock line followed by a high to low transition on the data line signals the start of a message sequence. the end of a message sequence is a low to high transition in the data line followed by a low to high transition in the SCL line. An important aspect of this communication standard is that each device is assigned a unique 7 bit address, (oh yea the 8th bit is the Read/write indicator to complete the byte). The device address is the first byte sent in any communication. Subsequent bytes of a message depend on the device you are talking to.

Because of patents that have since expired, other companies had to use slightly different ways to do the same thing so a very similar serial communications method called SPI uses 4 wires and another called TWI uses the same 2 wires.

== I2C with Gumstix Overo ==

There are several i2c buses available on the overo board.

The bus accessible from most of the 40 pin expansion board headers is i2c-3.

Refer to the board [http://pubs.gumstix.com/boards/ schematics] to find whether the board you are using exposes the i2c lines.

You are looking for GPIO184_SCL3 and GPIO185_SDA3.

For many of the boards, pin 23 is SCL and pin 24 is SDA.

The voltage levels are 1.8v, so a voltage level shifter is required to connect to 3.3 or 5 volt slave devices.
A good explanation can be found [http://www.nxp.com/documents/application_note/AN10441.pdf here.]

The overo main board already has pullup resistors for SCL and SDA.

The default gumstix kernels set the i2c-3 bus speed to 400 kHz.

This can be changed to 100 kHz with a kernel command line parameter in u-boot.

i2c_bus=3,100

The i2c-3 bus appears as a character device under /dev

root@overo:/dev# ls -all i2c*
crw-rw---- 1 root root 89, 1 Jan 1 2000 i2c-1
crw-rw---- 1 root root 89, 3 Jan 1 2000 i2c-3

Programmers can access devices on the bus using standard unix file i/o.

You must set the slave address with an ioctl() call prior to communicating with a slave device.

The driver takes care of shifting the slave address one bit and appending the R/W bit in the first byte of the transfer.

Here's a C example minus any error checking.

...
#include <stdint.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <linux/i2c.h> /* for I2C_SLAVE */
...

int fh;
uint8_t data[4];

fh = open("/dev/i2c-3", O_RDWR);

/* tell the driver we want the device at address 0x20 */
ioctl(fh, I2C_SLAVE, 0x20);

/* write two bytes */
data[0] = 0x05;
data[1] = 0x08;
write(fh, data, 2);

/* read 4 bytes */
read(fh, data, 4);

close(fh);

==Further information==

Another source of I2C information can be found [http://www.gumstix.net/wiki/index.php?title=I%C2%B2C here].

==Sample code==

Here is a simple project showing how to use an overo to control some "smart" leds. It includes a schematic for the voltage level conversion of the I2C lines that's required.

[http://github.com/scottellis/overo-blinkm Controlling BlinkM leds over I2C using a Gumstix Overo]

[[Category:How_to_-_general]]

Category:How to - Build helloworld

2010-01-14T18:39:21Z

Sellis: Added a network boot link

==Overview==

What follows is a description for building C programs on a workstation using the cross-build tools of [http://wiki.openembedded.net/index.php/Main_Page OpenEmbedded], but not using the bitbake/recipe framework.

==Setup==

Follow the instructions for [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html setting up a build environment] to get the cross-build tools correctly installed.

While you don't necessarily need to build a complete image to get the cross-tools for a C program, as a practical matter, successfully building an image is a good test that the cross-tools are correctly installed.

If you only want to cross compile a C program without third-party dependencies, then you can build just the gcc-cross recipe.

bitbake gcc-cross

And if you need the kernel headers too...

bitbake linux-libc-headers

There is no time lost building only these recipes, since both are dependencies of a full image.

The tools are built under the TMPDIR directory declared in ${OVEROTOP}/build/conf/site.conf.

TMPDIR defaults to ${OVEROTOP}/tmp, but you can point it somewhere else.

For instance, putting TMPDIR on a faster disk can speed your build.

==Makefile==

Create a makefile for your project pointing to the cross-build toolchain.

Here is a simple one for helloworld.

# Makefile for building with the OE cross tools
#
# OVEROTOP is normally ${HOME}/overo-oe
#
# OETMP is the same as TMPDIR as defined in ${OVEROTOP}/build/conf/site.conf
#

OETMP = ${OVEROTOP}/tmp

TOOLDIR = ${OETMP}/cross/armv7a/bin

STAGEDIR = ${OETMP}/staging/armv7a-angstrom-linux-gnueabi/usr

CC = ${TOOLDIR}/arm-angstrom-linux-gnueabi-gcc

CFLAGS = -Wall

LIBDIR = ${STAGEDIR}/lib

INCDIR = ${STAGEDIR}/include

LIBS = -L ${LIBDIR}

TARGET = helloworld

OBJS = helloworld.o

${TARGET} : $(OBJS)
${CC} ${CFLAGS} ${OBJS} ${LIBS} -o ${TARGET}

helloworld.o: helloworld.c
${CC} ${CFLAGS} -I ${INCDIR} -c helloworld.c

clean:
rm -f ${TARGET} ${OBJS} *~

==Distribute==

Copy the resulting target executable to the overo.

1. If you are using [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html a microSD card], copy your executable to the rootfs before you unmount it in the final step.

2. If you have a network connection to the overo, use scp.

3. If you have a kermit console session, use the kermit SEND command.

4. If you are doing a [http://www.gumstix.net/wiki/index.php?title=Category:How_to_-_Network_Boot network boot] then copy the executable directly to the nfs exported root filesystem the gumstix is using on the workstation.

Category:How to - usb

2010-01-14T18:31:19Z

Sellis: Added 2.6.32 reference

==USBNet with Overo==

The OTG USB port on the Overo expansion boards support USB networking. To enable this, the OTG port needs to be configured as a USB peripheral or gadget. The default kernels from Gumstix have the OTG port configured to act as a USB host.

The procedure for changing the configuration requires rebuilding your kernel, so you should first be comfortable with [http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html setting up a build environment] and building images for your Overo.

The following steps assume you are using a recent snapshot of the gumstix-oe git tree and are going to use kernel version 2.6.31 or 2.6.32.

The gumstix-oe linux-omap3_2.6.xx recipes for either of these kernels has a variable that allows you to specify how you want the OTG usb port configured.

Kernel version 2.6.31 is used for the example. Substitute 2.6.32 if that's the kernel you are using.

To get started, first edit the recipe file ${OVEROTOP}/org.openembedded.dev/recipes/linux/linux-omap3_2.6.31.bb

Change the line

MUSB_MODE ?= "host"

to

MUSB_MODE ?= "peripheral"

or "otg".

Next rebuild your kernel.

cd ${OVEROTOP}
bitbake -c clean linux-omap3-2.6.31
bitbake -c rebuild linux-omap3-2.6.31

And then rebuild your rootfs.

bitbake omap3-console-image

Change omap3-console-image to whatever image you use.

Once you have booted the new system, you still need to load the g_ether driver since it was built as a module.

You can add g_ether to /etc/modules if you always want it to load at boot.

root@overo# modbprobe g_ether
g_ether gadget: using random self ethernet address
g_ether gadget: using random host ethernet address
usb0: MAC d6:2c:8f:d9:51:32
usb0: HOST MAC f2:99:dc:4c:cb:7a
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready

root@overo:~# ifconfig -a
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

usb0 Link encap:Ethernet HWaddr D6:2C:8F:D9:51:32
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Configure the usb0 interface the way you would any other.

For example

root@overo:~# ifconfig usb0 192.168.20.2 netmask 255.255.255.0

If you then plug the usb OTG cable into a host computer ready for usb networking you'll get a console message

g_ether gadget: high speed config #1: CDC Ethernet (ECM)

The rest is all standard Linux networking.

Category:How to - i2c

2010-01-14T18:19:11Z

Sellis: Added reference to the schematics page

==Background==

I2c is a 2-wire serial 8 bit communications protocol from the old days. It is mainly used to communicate between on-board components when the design does not allow for a data and address bus. Typical components are elapsed timer chips, ee-proms, FRAM's, A/D and D/A chips. Some cpu's have the I2c hardware shift registers built in.

The 2 wires are the SCL or clock wire and the SDL or data wire. The clock high to low transition is used to signal that the data wire has a stable 1/0 data value and that the receiver should shift this into the data results register. The clock line is high when the bus is idle. A special high to low transition on the clock line followed by a high to low transition on the data line signals the start of a message sequence. the end of a message sequence is a low to high transition in the data line followed by a low to high transition in the SCL line. An important aspect of this communication standard is that each device is assigned a unique 7 bit address, (oh yea the 8th bit is the Read/write indicator to complete the byte). The device address is the first byte sent in any communication. Subsequent bytes of a message depend on the device you are talking to.

Because of patents that have since expired, other companies had to use slightly different ways to do the same thing so a very similar serial communications method called SPI uses 4 wires and another called TWI uses the same 2 wires.

== I2C with Gumstix Overo ==

There are several i2c buses available on the overo board.

The bus accessible from most of the 40 pin expansion board headers is i2c-3.

Refer to the board [http://pubs.gumstix.com/boards/ schematics] to find whether the board you are using exposes the i2c lines.

You are looking for GPIO184_SCL3 and GPIO185_SDA3.

For many of the boards, pin 23 is SCL and pin 24 is SDA.

The voltage levels are 1.8v, so a voltage level shifter is required to connect to 3.3 or 5 volt slave devices.

The overo main board already has pullup resistors for SCL and SDA.

The default gumstix kernels set the i2c-3 bus speed to 400 kHz.

This can be changed to 100 kHz with a kernel command line parameter in u-boot.

i2c_bus=3,100

The i2c-3 bus appears as a character device under /dev

root@overo:/dev# ls -all i2c*
crw-rw---- 1 root root 89, 1 Jan 1 2000 i2c-1
crw-rw---- 1 root root 89, 3 Jan 1 2000 i2c-3

Programmers can access devices on the bus using standard unix file i/o.

You must set the slave address with an ioctl() call prior to communicating with a slave device.

The driver takes care of shifting the slave address one bit and appending the R/W bit in the first byte of the transfer.

Here's a C example minus any error checking.

...
#include <stdint.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <linux/i2c.h> /* for I2C_SLAVE */
...

int fh;
uint8_t data[4];

fh = open("/dev/i2c-3", O_RDWR);

/* tell the driver we want the device at address 0x20 */
ioctl(fh, I2C_SLAVE, 0x20);

/* write two bytes */
data[0] = 0x05;
data[1] = 0x08;
write(fh, data, 2);

/* read 4 bytes */
read(fh, data, 4);

close(fh);

==Further information==

Another source of I2C information can be found [http://www.gumstix.net/wiki/index.php?title=I%C2%B2C here].

==Sample code==

[http://github.com/scottellis/overo-blinkm Controlling BlinkM leds over I2C using a Gumstix Overo]

[[Category:How_to_-_general]]

Category:How to - Network Boot

2010-01-14T14:38:01Z

Sellis: Formatting, reason for missing display kernel parameters

==Overview==

Network booting can be very convenient during the development cycle
for an embedded device. Current Gumstix Overos have a bootloader
and kernel ready for network booting if you have an expansion board
with an ethernet connector. Older Gumstix Overos can upgrade their
version of u-boot to get support for network booting.

The procedures that follow are for setting up a workstation to act
as both the tftp server and the nfs server to host the root file
system.

The procedure described does not require a dhcp server.

==Setup==

The following procedure assumes a Linux workstation to host all
the services. The workstation for the example is running Ubuntu 9.10.

There are multiple ways to configure the nfs server and the tftpd
server. This example tries to keep it simple.

The names of the packages may be different if you are using another
Linux distribution.

The example will use the following network configuration.

Workstation IP: 192.168.4.4

Gumstix IP: 192.168.4.50

You will also need a Gumstix Overo kernel and rootfs on the workstation.

You can either
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html build]
one yourself or download one
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Downloading-pre-built-images/111.html here.]

I'll assume an omap3-console-image custom built with OE located in the standard location.
Any image will work though.

==Packages==

Install the following Ubuntu packages on the workstation

tftp-hpa

nfs-common

nfs-kernel-server

portmap

==Create a root filesystem==

Create and populate the /exports directory with a kernel and a root filesystem

sudo mkdir -p /exports/overo
sudo tar -C /exports/overo -xvjf ${OVEROTOP}/tmp/deploy/glibc/images/overo/omap3-console-image-overo.tar.bz2

==Configure the tftp server==

Edit /etc/default/tftpd-hpa

RUN_DAEMON="yes"
OPTIONS="-l -s /exports/overo/boot"

What we are doing here is pointing the tftp daemon at the Gumstix root
filesystem we created above. The uImage kernel image sits here.

$ ls -all /exports/overo/boot/*
lrwxrwxrwx 1 root root 13 2010-01-13 11:50 /exports/overo/boot/uImage -> uImage-2.6.32
-rw-r--r-- 1 root root 3147516 2010-01-10 11:12 /exports/overo/boot/uImage-2.6.32

==Configure the nfs server==

Add the following line to /etc/exports

/exports/overo 192.168.4.50(rw,no_root_squash,no_subtree_check)

This tells the nfs server what directories to export as an nfs mountpoint and what machines have access to it.
Use man exports to get the documentation for /etc/exports.

==Restart the servers==

sudo /etc/init.d/tftpd-hpa restart
sudo service portmap restart
sudo /etc/init.d/nfs-kernel-server

==Configure u-boot==

Establish a serial console connection with the gumstix.

Power the gumstix unit and hit a key to stop the process in uboot.

Add some environment variables to u-boot.

Overo # setenv ipaddr 192.168.4.50
Overo # setenv netmask 255.255.255.0
Overo # setenv serverip 192.168.4.4
Overo # setenv gatewayip 192.168.4.1
Overo # setenv hostname overo

Overo # setenv ip ${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:none
Overo # setenv nfsroot /exports/overo
Overo # setenv nfsargs setenv bootargs console=\${console} root=/dev/nfs rootfstype=nfs ip=\${ip} nfsroot=\${nfsroot} rootwait
Overo # setenv loadnfskernel tftp \${loadaddr} uImage

Save what you've entered in the u-boot environment so far. None of these variables
are used by the default boot process so there will be no booting behavior changes
yet.

Overo # saveenv

==Testing==

The next step is to test the network boot by running each step manually.
Later we will modify u-boot to run this automatically.

1. First tftp load the kernel into the overo memory

Overo # print loadaddr
loadaddr=0x82000000

Overo # tftp ${loadaddr} uImage
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 00:15:c9:28:c1:78
Using smc911x-0 device
TFTP from server 192.168.4.4; our IP address is 192.168.4.50
Filename 'uImage'.
Load address: 0x82000000
Loading: T ######################################################
######################################################
######################################################
#####################################################
done
Bytes transferred = 3147516 (3006fc hex)

Okay, if that worked, make sure the loadnfskernel variable we created doesn't
have a typo by running the same process again using the u-boot run command.

Overo # run loadnfskernel

You should get the same results, a kernel tftp loaded into memory.

If it did not work, use a network monitoring tool like tcpdump or wireshark to
see if you are getting any traffic.

See the Notes section for some troubleshooting tips.

2. Test the loading of the boot arguments.

Overo # print bootargs
## Error: "bootargs" not defined
Overo # print nfsargs
nfsargs=setenv bootargs console=${console} root=/dev/nfs rootfstype=nfs ip=${ip} nfsroot=${nfsroot} rootwait
Overo # run nfsargs
Overo # print bootargs
bootargs=console=ttyS2,115200n8 root=/dev/nfs rootfstype=nfs ip=192.168.4.50:192.168.4.4:192.168.4.1:255.255.255.0:overo:eth0:none nfsroot=/exports/overo rootwait

Make sure that bootargs looks correct.

3. Boot the kernel

With a kernel of the correct format loaded into memory, the u-boot command bootm will
transfer control of the processor to this kernel.

Overo # bootm ${loadaddr}

...normal kernel boot messages here, then...
net eth0: SMSC911x/921x identified at 0xd08c8000, IRQ: 336
IP-Config: Complete:
device=eth0, addr=192.168.4.50, mask=255.255.255.0, gw=192.168.4.1,
host=overo, domain=, nis-domain=(none),
bootserver=192.168.4.4, rootserver=192.168.4.4, rootpath=
Looking up port of RPC 100003/2 on 192.168.4.4
Looking up port of RPC 100005/1 on 192.168.4.4
VFS: Mounted root (nfs filesystem) on device 0:13.
Freeing init memory: 928K
INIT: version 2.86 booting
...
The Angstrom Distribution overo ttyS2
Angstrom 2009.X-test-20100110 overo ttyS2
overo login:

==Making it automatic==

So if everything worked and you want to boot this way every time you need to modify the
bootcmd u-boot variable.

Reboot the gumstix and hit a key to stop it in u-boot again.

Overo # print bootcmd
bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi; fi; else run nandboot; fi

You may want to save this for the future or see the Notes section for where it is defined in the build.

Make a new bootcmd using the u-boot environment variables that we created.

Overo # setenv bootcmd echo Booting nfs ...\; run loadnfskernel\; run nfsargs\; bootm \${loadaddr}

Overo # saveenv

Now reboot and the gumstix should nfsboot by default.

Overo # reset

==Notes==

1. The default u-boot environment variables are defined in the u-boot source tree under include/configs/omap3-overo.h

2. The documentation for linux kernel parameters for nfs booting can be found in the linux source tree under
Documentation/filesystems/nfsroot.txt and Documentation/kernel-parameters.txt.

3. tftp listens over udp on port 69
$ grep tftp /etc/services
tftp 69/udp

You can check if it is listening with the following command.

$ netstat -an | grep udp
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:880 0.0.0.0:*
udp 0 0 0.0.0.0:39921 0.0.0.0:*
udp 0 0 0.0.0.0:56957 0.0.0.0:*
udp 0 0 0.0.0.0:2049 0.0.0.0:*
udp 0 0 0.0.0.0:59435 0.0.0.0:*
udp 0 0 0.0.0.0:69 0.0.0.0:*

4. nfs listens on port 2049 both tcp and udp. The nfs root process uses only udp.
$ grep nfs /etc/services
nfs 2049/tcp # Network File System
nfs 2049/udp # Network File System

5. The following is a tcpdump command for watching the gumstix boot traffic. Choose the appropriate
interface for your workstation.

$ sudo tcpdump -i eth1 -l -n udp

6. A cross-over ethernet cable connected between the workstation and the gumstix works well
if you can't host services on your regular network. You may want to check before starting a
tftp server on a shared network. A dedicated switch/hub will also work to keep things isolated.

7. You can check for running firewall rules with this command

$ sudo iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

If you get output different then this (nothing running) and you are having problems booting, then
you should ensure you are not blocking any of the required traffic.

8. I removed the kernel parameters for the kernel display configuration for wiki formatting reasons.
You should add the settings you require to the bootcmd variable in the example.

9. There is a patch to u-boot in the current gumstix overo-oe tree that improves the ethernet
network speeds on the overos. You can save about 10 seconds on an nfs boot using a u-boot
built with this patch as well as get better ethernet performance after booting. (The patch is
a tuning of the timing registers of the GPMC connected to the ethernet controller. This
configuration is done by u-boot when the board is brought up and not modified by Linux kernel
after booting.) When you do a network boot, you are using the u-boot on the NAND flash which
was probably built without this patch.
Build a newer version of u-boot following the standard build procedures. (U-boot is built
whenever you build an image.) Then copy it to NAND using the instructions
[http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Writing-images-to-onboard-nand/111.html here.]

Main Page

2010-01-14T14:29:43Z

Sellis: Added a new Network Boot page

<big>''Welcome to the gumstix users wiki''</big>

This site is provided so that users of the gumstix OpenEmbedded build system can share their knowledge, showcase their gumstix based projects, and pass on links to other sources of information and materials. This information is entirely user generated and supported. Please contribute your know-how to help your fellow developers.

'''Customer additions and edits are encouraged, but please read the help page before you make any major edits.'''
''Note: you will need to create a new user account if you would like to contribute or edit content on this site.''

Go to the [http://www.gumstix.net Gumstix Developer's website] for official Gumstix supported documentation on OpenEmbedded and other information of interest to developers:
{|
| valign="top" |
{|cellpadding="2" cellspacing="5" style="vertical-align:top;background-color:#f5fffa;border:1px solid #bcc"
! style="margin:0;background:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:How-tos |User how to's]]
! style="margin:0;background:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:projects|User projects]]
! style="margin:0;background:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:User_pics_videos|User Pics & Videos]]
! style="margin:0;background:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:resources|Resources]]
! style="margin:0;background:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;" | [[:Category:faqs|Questions and Answers]]

|-
| valign="top" |
* [[:Category:how to - general|General]]
* [[:Category:how to - Android|Android]]
* [[:Category:how to - audio|Audio]]
* [[:Category:how to - batteries|Batteries]]
* [[:Category:how to - bluetooth|Bluetooth]]
* [[:Category:how to - fedora|Fedora]]
* [[:Category:Connect_hardware|Connect Hardware]]
* [[:Category:how to - displays|Displays]]
* [[:Category:how to - DSP|DSP]]
* [[:Category:how to - git|Git]]
* [[:Category:how to - gui|GUI]]
* [[:Category:how to - Build helloworld|HelloWorld]]
* [[:Category:how to - i2c|I2C]]
* [[:Category:how to - JAVA|JAVA]]
* [[:Category:how to - LCD|LCD]]
* [[:Category:how to - linux|Linux]]
* [[:Category:how to - Network_Boot|Network Boot]]
* [[:Category:How_to_-_qemu|Qemu]]
* [[:Category:How_to_-_Qt|Qt]]
* [[:Category:how to - robotics|Robotics]]
* [[:Category:how to - security|Security]]
* [[:Category:SPI|SPI]]
* [[:Category:SUSE|SUSE]]
* [[:Category:how to - Ubuntu|Ubuntu]]
* [[:Category:how to - usb|USB]]
* [[:Category:how to - webcams|Webcams]]
* [[:Category:how to - wifi|Wifi]]
| valign="top" |
* [[:Category:projects - audio|Audio]]
* [[:Category:projects - competitions|Competitions]]
* [[:Category:projects - displays|Displays]]
* [[:Category:Projects_-Research_and_Education|Research & Education]]
* [[:Category:projects - monitoring and control|Monitoring and Control]]
* [[:Category:projects - robotics|Robotics & UAV's]]
| valign="top" |
* [http://johnwoconnor.blogspot.com/2009/03/linux-on-gumstick-tour-of-gumstix-overo.html Short & Sweet - A User's Tour of Overo Earth]
* [http://www.flickr.com/search/?q=gumstix&s=rec Gumstix in Flickr]
* [http://www.youtube.com/results?search_query=gumstix&search_sort=video_date_uploaded Gumstix on Youtube]
* [http://www.cs.umd.edu/alandaluz/nchen/ebook/dualdisp-chi.mov Dual Display device at UMD]
* [http://ca.youtube.com/watch?v=3ZFmjOHnWds&eurl=http://paginas.fe.up.pt/~jca/fast/en/media.php First World Robotic Sailing Championships in May 2008]
| valign="top" |
* [[Windows CE solution|Solutions for Windows CE]]
* [[Qt solution|Solutions for Qt]]
* [[Manufacturer's specifications|Specifications for Processors & Components]]
* [[Software information]]
* [[Supported hardware]]
| valign="top" |
* [https://lists.sourceforge.net/lists/listinfo/gumstix-users Sign-up - Community mailing list]
* [http://www.nabble.com/Gumstix-f22543.html Archives - Community mailing list]
* [http://www.gumstix.net/wiki/index.php?title=Other_FAQs Other FAQs]
|}

For information and support for the legacy gumstix buildroot build system:
[http://docwiki.gumstix.org/Main_Page docwiki.gumstix.org]