Linuxstamp II 9260

Description

The Linuxstamp is designed to be a general purpose processor module. It is designed to work as a stand alone module (micro-SD card, Ethernet and USB/Serial converter are all on the module). This allows all initial development to be done without a motherboard, but for integration into a specific project a motherboard with specific features could be designed.

Status

You can now purchase Linuxstamp II boards from thelinuxstamp.com. Some of the original Linuxstamp info is still useful.

Features

• Atmel AT91SAM9260 processor (Arm9 processor with MMU, 200Mhz operation)
• 32MB SDRAM
• 256MB NAND Flash
• 1x 10/100 Ethernet
• 1x USB host port (allows wifi adapters, flash drives and other USB devices to be used)
• 1x micro-SD card slot
• Serial debug port 5-pin header
• JTAG port

Emdebian

The current Linux distribution is Emdebian. It is located in the NAND flash and uses UBI & UBIFS. The Emdebian folks have done a stellar job on Emdebian, and the best part is if the package your after hasn't been "gripped" yet you can get the normal debian version.

The following instructions show how to build an emdebian system. The host system is debian squeeze on a x86_64, multistrap version 2.1.7. Here's the configuration file:

[General]
arch=armel
directory=/opt/multistrap/grip_squeeze
# same as --tidy-up option if set to true
cleanup=true
# same as --no-auth option if set to true
# keyring packages listed in each debootstrap will
# still be installed.
noauth=false
# whether to add the /suite to be explicit about where apt
# needs to look for packages. Default is false.
explicitsuite=false
# extract all downloaded archives (default is true)
unpack=true
# the order of sections is not important.
# the debootstrap option determines which repository
# is used to calculate the list of Priority: required packages.
debootstrap=Emdebian
aptsources=Emdebian

[Emdebian]
#packages=
packages=gcc subversion openssh-server net-tools wireless-tools wpasupplicant ifupdown inetutils-ping isc-dhcp-client udev nano
source=http://www.emdebian.org/grip
keyring=emdebian-archive-keyring
suite=squeeze
components=main dev

Save this config to a file (example is grip_squeeze_ls2.conf but any name can be used). Run this command to generate the root filesystem:

# multistrap -f grip_squeeze_ls2.conf

To use a different directory, use the -d option to multistrap.

Before we to the actual chroot lets make sure a few files are setup. Most of the following section could be put into a simple script, but I'll go through it for reference. First lets add an /etc/fstab. It should look something like this:

proc                 /proc      proc       defaults              0 0
devpts               /dev/pts   devpts     mode=0620,gid=5       0 0
sysfs                /sys       sysfs      defaults              0 0
none                 /tmp       tmpfs      defaults,size=2M      0 0

And etc/profile should be something like:

export LANGUAGE=C
export LC_ALL=C
export LANG=C

Next we'll need a working etc/resolv.conf file. You can copy this from any working linux box on the same network. Now we should have a working network.

Now we can chroot into this new root fs from a running unit. I use a rootnfs setup that the ls2 is already booted into for this step. This does of course present a chicken & egg problem of how do you get a working emdebian root fs to bootup in order to run the chroot command. The simple answer is to use an existing emdebian root fs. Another option is to massage the root fs just created. The main requirements for this are adding the device nodes (same ones we add from chroot environment) & /etc/inittab (this is created from dpkg --configure -a within the chroot environment so it would need to be created or copied in). And finally there has been some talk of using qemu from an x86_64 side for this in system configuration.

Now we can go ahead and chroot in:

# LANG=C chroot /grip_squeeze/ /bin/bash

Now we can mount some of those partitions even from chroot, so do: (the directory /dev/pts is needed before the mount)

# mkdir /dev/pts
# mount -a

Now that we're in the chroot environment we can do some more configuration. First well need some device nodes before udev comes up. This could also be done with multistrap.

# mknod /dev/ttyS0 c 4 64
# mknod /dev/console c 5 1

Now to configure all the packages. The multistrap step installed the correct packages, but because it's not running on the native environment it doesn't want to configure the packages. You'll be prompted a couple of times for information like timezone:

# dpkg --configure -a

There might have been some errors, we'll catch those in the next pass. Before booting into our new environment, a few more steps. Edit the newly created inittab. Add a line like:

T0:2345:respawn:/sbin/getty -L ttyS0 115200 vt100

And comment all the ttyX lines.

Create a host name:

# echo ls2 > /etc/hostname

Set a root password:

# passwd

Now we can boot into this new root fs. If the network was started with a command line argument like ip=, then you might need to add a default gateway like this:

# route add default gw 192.168.0.1

Now add a line like

deb http://http.us.debian.org/debian squeeze main

to /etc/apt/sources.list.d/multistrap-emdebian.list. The deb-src line can also be commented. Now an 'apt-get update' should work. Now we can set the date manually until rdate is working:

# date 032822382011

Now back to dpkg --configure. dash needs a little extra work to configure. To get dash to configure first /var/lib/dpkg/info/dash.preinst will need to run correctly, to do this some man dir/files need to be created/touched.

# mkdir /usr/share/man; mkdir /usr/share/man/man1

And next run:

# sh /var/lib/dpkg/info/dash.preinst

And now the 'dpkg --configure -a' should work, and you can even remove the man stuff now:

# rm -rf /usr/share/man 

The last think to do is make sure the keyrings are correct. I had to remove the *pgp* files in /etc/apt, and then run:

# apt-key add /usr/share/keyrings/emdebian-archive-keyring.gpg
# apt-key add /usr/share/keyrings/debian-archive-keyring.gpg

'apt-get update' is now very happy, and you can 'apt-get install' until your hearts content.

Cross Compiler

you can use crosstool-ng to generate a cross compiler. The documentation on the website is very good.

Emdebian also has pre-built cross-compilers that you can install, as well as the tools to build your own.

U-boot

First we need u-boot. If you have not yet built a cross compilier now would be a good time to do so (See the cross compilier section above). Now you can do a test for the Atmel at91sam9g20 EL board using NAND.

• $ make at91sam9g20ek_nandflash_config
• $ make CROSS_COMPILE=your_cross_compiler

This should give you a "u-boot.bin" file. We will have to write a board specific configuration file for the Linuxstamp. We should be able to base it off the the Atmel DK board. If you look at "/u-boot-1.1.6/include/configs/at91rm9200dk.h" you can see the configuration for the DK board.
Other u-boot commands:

• > printenv, prints the enviroment variables
• > saveenv, saves the enviroment variables
• > setenv bootcmd 'tftpboot 20800000 uImage; bootm 20800000' Sets the boot command to load a image over tftp and boot it
• > setenv bootargs mem=32M nfsroot=192.168.0.3:/nfs_root ip=192.168.0.51 console=ttyS0,115200n8 rootdelay=1

This sets the command line to be passed to the kernel. As you can see it sets the nfsrot, ip address and console

License

All files for this project are licensed under the GNU GPL V2

Hardware design files

Warning!!! Use this design at your own risk. Errata: a 10k pull-up resistor is needed on the CMD line to use the uSD card. Here are the design files You can view the pdf of the schematic here

Power

The power supply for the board is based on the Linear LTC3407-3. This is a very compact high frequency switching power supply. It has both a 3.3v and a 1.8v output. It does have a very tight input range 3.3v-5.5v. The Micrel PHY also needs 2.5v, but this is provided by an internal regulator. Currently a regulated 5v must be used to power the board.

Minicom & the debug port

Above shows the proper connection of the ftdi cable to the Linuxstamp II. This provides both the debug console as well as power to the board. Pin 6 (green wire) on the cable overhangs the 5-pin connector on the board.

When you plug the Linuxstamp into your host (Linux) machine a device should appear /dev/ttyUSB0 (the suffix number will increment as you add more devices). /dev/ttyUSB0 will behave as any other serial port now. Minicom is the standard program to access the serial port in Linux. The first time you run minicom you will have to be root in order to do the setup, after that you can change the permissions on /dev/ttyUSB0 so any user can run minicom. To enter configuration mode in minicom type CTRL-A o, now scroll down to Serial port setup. Use the letters to navigate. You will want the device to be /dev/ttyUSB0 and Bps/Par/Bits to read 115200 8N1. Both hardware and software flow control should be OFF. Connection to the board is important for loading Atmel's tiny program and u-boot, but once the board is working it might not be as important.

Another alternative is to use HyperTerm on Windows, which works fine with the Hardware boot loader. If you are updating the Darrel Bootloader, note that the loader only has a short delay after you initiate the "receive" (on the loader) after which it send out the "ready to receive" signal. As a result, you'll need to be rather quick to initiate the Xmodem "send" (on HyperTerm). If you are seeing time outs on HyperTerm when you try and send the loader.bin file, you are probably hitting this problem ... you need to have initiated the send before you see the "C" on the screen from the bootloader.

nfs & tftp

Nfs (network file system) and tftp (trivial file transfer protocol) are two servers you will want running on your host machine. Nfs is useful for hosting the root file system of the Linuxstamp. Tftp is useful for u-boot to retrieve the kernel from. There are many other websites on nfs and tftp, but I will try and go over a simple setup. I would suggest being behind a firewall before trying either of these setups as neither is secure. I wrote this using a Fedora 7 system. First make sure you have nfs installed.

$ yum install nfs-utils nfs-utils-lib portmap system-config-nfs

On Ubuntu (or other debian-style systems) you could use:

$ sudo apt-get install portmap nfs-kernel-server nfs-common

Now to make sure the service is enabled run (this won't work on Ubuntu):

$ serviceconf and make sure nfs and nfs lock are checked

Now edit /etc/exports you should add a line like this /path_to_nfs_root/ *(rw,no_root_squash,insecure). Now restart nfs.

$ sudo /etc/init.d/nfs restart

You can test that it is set up correctly by typing the following on the local system (i.e. right on the NFS server)

$ showmount -e localhost

You can test this from a remote system with

$ mount -t nfs server_name:/path_to_nfs_root /path_to_test_mount

Now on to tftp. Make sure it is installed.

$ yum install tftp-server

This will create a file /etc/xinetd.d/tftp. In this file you will want to change disable from yes to no. Now make a test file.

$ cd /tftpboot
$ echo hello > file

Now we can test it

$ tftp -v server_name -c get tmp

Now with u-boot we can load image files

> tftpboot 20800000 uImage

And boot them

> bootm 20800000

NAND Flash

One good solution for the NAND flash is to use the new ubi and ubifs components. These both need to be enabled in the kernel, and then they can be used from the emdebian system. You can always check what mtd devices are avaliable in /proc/mtd. First we can format the mtd device (Note: This mtd1 will remove everything including u-boot):

$ ubiformat /dev/mtd1

Now we can "attach" it. This is telling the kernel to use the ubi subsystem for that partition. The -m 1 says use /dev/mtd1.

$ ubiattach /dev/ubi_ctrl -m 1

Now we can make a volume. As it says on the linux-mtd page you can only mount a ubi volume not a mtd device or a ubi device:

$ ubimkvol /dev/ubi0 -N rootfs -s 244MiB

Now the volume can be mounted

$ mount -t ubifs ubi0_0 /mnt/tmp/

Flashing with Atmel SAM-BA

Ateml SAM-BA can be used to to flash the linuxstampII board. Some special considerations must be taken to properly communicate with the board.

1) SAM-BA must be running in a windows environment to flash over the debug port. If running on a Windows 7 machine, you must install in XP compatibility mode. This will allow you to run SAM-BA and not SAM-BA_cdc

2) There cannot be any executable code in flash. It must be erased or you can very carefully pull the CS pin (pin 9) high to temporarily disable the NAND flash upon powering up the board.

3) You must change one line in the

4) change sam9g20ek configuration file in: Program Files/ATMEL Corporation/SAM-BA v2.10/tcl_lib/at91sam9g20-ek/at91sam9g20.tcl

1. set bus width (16 or 32)

bus width = 16

5) should connect now when choosing sam9g20ek connection

6) In scripts, select "Enable Nand" and execute

7) In scripts, select "Erase All and execute

8) You can now write fresh versions of the at91bootstrap and u-boot!

Links

• [1]: Up to date kernel patch for the AT91 parts
• Cadsoft.de: Free (as in beer) tools for schematic and PCB design
• openhardware.wordpress.com: Here is my openhardware blog
• Mborad 1 for the Linuxstamp
• ECB AT91 This is another open source project similar to the Linuxstamp. They have some very good documentation.
• Budgetdedicated Graciously hosts our ftp site

Discussion

Please join the google group for the Linuxstamp discussion http://groups.google.com/group/linuxstamp

Contact

For further questions or comments please contact Paul (pthomas8589 _at_ gmail _dot_ com)

other boards that run Linux

• ARMUS Embedded Linux Board
• Balloon board
• Bifferboard