Frequently Asked Questions - Stamp9G20

The boot sequence changed some time ago. J3 is used to bypass the NAND preventing the ROM code to load at91bootstrap from that media.
Since the BCH update in March 2013 (see, we do not consider the NAND to be the proper location for at91bootstrap. That is why we switched to the DataFlash which is equipped on all Stamp9G20 and NanosG20 boards since 2013. The DataFlash however uses a different chip select that has to be bypassed to prevent autoboot.
Please see to figure out which jumper is used when the DataFlash is used. In case of doubt where at91bootstrap is stored on your board, it is perfectly okay to close both jumpers during boot.

This can have two reasons, which both prevent the boot from DataFlash:

  1. If you just plugged in the Stamp and booted the system for the first time, this is most probably caused by some undefined value in the Reset Controller Mode register. To prevent this from happening remove the battery, switch on the system and than place the battery into the socket.
  2. The system already booted with a battery but you switched it off shortly after powering it. If you have done this while the last message of U-Boot was "WARNING: Caches not enabled", use the following update to fix the problem:

We will try to produce products as long as possible. This means, that there will be hardware revisions and changes of the used components if necessary. Of course, the most important factor for every product is the processor itself. Please find information about how long a certain processor is planned to be produced in the PDF attached below. In case of a processor hits its EOL, we try to offer a similar product with migration support for existing customers.

SAM9 lifetime commit Mar12.pdf322.43 KB

Error code -117 means there were bit flips in the read memory region, but the ECC algorithm could correct them. So the image is read correctly. A NAND page (typically 512 bytes) will become unreadable, if more bits flip than the ECC algorithm can handle, so depending on the situation it may make sense to rewrite the corresponding block. The standard images handle 1 bit error per NAND page, but a firmware handling 4 bit errors (or with small adjustments even more) is also available:

The boot stops displaying ROMBOOT or halts in U-Boot.
The kernel crashes randomly.

If your board runs a bootstrap prior version 3.4 (bootstrap 3.4 prints version information, older versions do not), the problem should be solved by updating.

The new images can be found here:

Update procedure:
1) launch SAM-BA and choose board according to:
2) run NANDFLASH "Enable NAND flash" script
3) run from SAM-BA console: NANDFLASH::EraseBlocks 0 0x1ffff
4) run "Send Bootfile" script with the appropriate image for your board

For even newer Stamps also consider the following download:

Since a while, running "opkg update" results in the following error messages:

Collected errors:
 * Failed to download 
error detail: HTTP response code said error
 * Failed to download 
error detail: HTTP response code said error
 * Failed to download 
error detail: HTTP response code said error
 * Failed to download 
error detail: HTTP response code said error
 * Failed to download 
error detail: HTTP response code said error
 * Failed to download 
error detail: HTTP response code said error
 * Failed to download 
error detail: HTTP response code said error

The problem here is that the default rootfs of the Stamp9G20 and PortuxG20 was the Ångström Distribution 2008 for a long time but this version is discontinued so all packages have been removed from the servers. Since Apr 19, 2012, both products will be delivered with version 2011.03.

Possible Solutions:

  • The best solution is to use the updated rootfs image provided in the download section which uses Ångström 2011.03. If you do not want to start from scratch, the other two options are also possible but are risky or inconvenient.
  • Replace the 2008 with 2011.03 in all config files in /etc/opkg and upgrade to this newer version (opkg update and opkg upgrade). Be aware that this is unsafe and can result in a completely unusable system as opkg is not prepared for such major updates.
  • Cherry pick packages from and install the manually (you have to resolve dependencies yourself). Either use wget to download and then install with opkg or give the direct URL to opkg. Using wget has the advantage, that you do not have to redownload a file if opkg notices missing dependencies. This option is much safer than the previous because you have complete control over what is installed and in which order.

After creating a new SD card from the original images the system won't boot.
Following problems are common:

  • You get a kernel panic with "no init found" message.
  • Using apt-get upgrade or similar gives you error messages like this "fopen: permission denied".

Most probably you have messed up permissions of your rootfs during copying. Please follow this Howto:

The toolchain comes with the package manager opkg. You can install the same packages as on the target device with it. To do so, follow these steps:

  1. Become root using su or sudo on your development computer
  2. Edit the file /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/etc/opkg.conf. It should look like that:
    arch all 1
    arch any 6
    arch noarch 11
    arch arm 16
    arch armv4 21
    arch armv4t 26
    arch armv5te 31
    src/gz base
    src/gz debug
    src/gz gstreamer
    src/gz no-arch
    src/gz perl
    src/gz python

    All other lines can be removed or commented.

  3. Execute the command source /usr/local/angstrom/arm/environment-setup
  4. You can now use the command opkg-target as on the target. So you first need to run opkg-target update and after that you can install the needed packages, most probably the -dev versions to get the header files.
  5. From now on, every time you want to install a new package, repeat steps 1, 3 and 4.

To compile bootstrap yourself the following steps have to be done:
1) You need an arm-gcc standalone compiler. The delivered arm-linux-gcc won't work for that task. Good ones are obtainable at
2) Extract the archive from your CD or from our download section ( on your development PC. Change to that directory.
3) Edit the Makefile in the directory at91bootstrap to point the variable CROSS_COMPILE to your installed stand-alone cross-compiler, e.g.:


4) Now issue make in the at91bootstrap directory with the following options:

	make CHIP=at91sam9g20   BOARD=at91sam9g20-ek   ORIGIN=nandflash   DESTINATION=sdram   BIN_SIZE=0x30000   FROM_ADDR=0x20000   DEST_ADDR=0x23F00000   OP_BOOTSTRAP=on STR_DESCR=\\\"appli\\\" TRACE_LEVEL=1

5) Now you find your binary in at91bootstrap/bin directory:


. Bootstrap has to be flashed via SAM-BA. It cannot be flashed with u-boot or linux. To do that see this how-to:

Example error messages:
ifup: can't open '/var/run/ifstate': No such file or directory
shutdown: warning: cannot open /var/run/

Some files in /var are located in RAM and must be recreated on every boot. Additionally /tmp is a symlink to /var/tmp. The files in /etc/default/volatile/ describe, which files, directories or symlinks have to be created. To speed up the boot, a file called /etc/volatile.cache is created. In the event of an unclean shutdown, this file might get corrupted and the creation of these files might not work. To resolve this issue simply delete /etc/volatile.cache.

This happens because NAND flash can have bad blocks. Every program not able to handle bad blocks can trigger messages like that. This is not a real problem with the flash, just with the application.

While booting the offending application is udev. It scans each block device for partitions including the MTD partitions. If the MTD partition has a bad block in the scanning region, the read will fail and this message is printed. To work around it, you can skip the scan for mtd devices by editing the file /etc/udev/rules.d/60-persistent-storage.rules. Replace the line

KERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-*|md*", GOTO="persistent_storage_end"


KERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-*|md*|mtd*", GOTO="persistent_storage_end"

and the messages should go away.

When mounting an NFS share, the mount command hangs for some time. What is wrong?

Busybox is not capable of mounting NFS shares with locking enabled. Use the option -o nolock for NFS mounts.

How can I read/write registers and physical memory regions under Linux?

This tar archive contains a simple tool providing reading and writing at physical addresses under Linux. Source code as well as binaries for OABI and EABI are included.