The Computer Corner Take II (#7) by Bill Kibler

To see more Computer Corner articles look here: CCII page or check out the Home Page .

Working with the Atmel NGW100

The Basic product

The Atmel NGW100 is a "Reference Design" board that features Atmel's AP7000 cpu for about $90. It is a 32 bit cpu with MMU or memory managment unit that is needed to run linux. It is more than just a cpu, as it is actually a DSP with lots of support devices. The NGW100 comes with two ethernet ports, a serial port, one USB devce port or client interface. It runs from a single 9 to 12 volt supply and can use SD/MMC devices. It has RAM and FLASH of serveral types. It normally ships with a running linux based network gateway system. When running - it hosts a web page that has information and cgi based LED trigger. All the source code used is freely available and can be rebuilt using the buildroot tool set. There are several support web pages and numerous extra programs to compliment the linux system.

The biggest problem for new users is the documentation and finding answers to some of the simplest questions. The documentation is spread over numerous web sites and associated tools directories, as well as included in the web pages on the NGW100. Some of the simplest topics are simply not covered anywhere and an example is factory boot settings - they are not documented at all.

What I hope to do here is give you a good start through the maze of information and to get you going quickly without too many failures. Once I learned and figured out the undocumented information, the system came up easily and was rebuilt several times using various options. There are still un-knowns about all sorts of things, yet I can add programs and use it without major difficulty, and so will you.

First boot

When I powered my system up for the first time, it went looking for a TFTP server at IP 172.24.41.2. I used the serial port as console interface and got gibberish - I use linux's minicom as terminal emulator. For minicom, use "minicom -o" to start it, that way it will not send modem setup codes when it starts. After starting minicom - following the displayed help message to get to the com port setup screen (ALT-A-P) and select the 115kb8N1 settings (4). Reboot the NGW100 by pushing the reset button just back from the USB port. You should now be able to see what is happening. If no ethernet is attached, it should be trying to find a DHCP server on both ethernet ports alternately. Put your ethernet cable into the WAN socket. The gateway expects to have a DHCP server on the WAN port (ether0) while assigning fixed IP addresses to the LAN port (ether1).

I was very cautious and did not use the WAN port at first, since my utilmate use is not as a gateway. As I learned that was a bad choice, as several features will not work correctly without the WAN connection to an outside network and DHCP host. The date/time is set using NTP which needs access to the larger internet after getting the gateway IP from the DHCP server. Needless to say I spent several hours tracking down NTP failures before understanding all the relationships. In /etc is the network directory with "interfaces" configuration file in it. This file controls the two ethernet ports setup options and if you look, port0 is DHCP, while port1 is static setting - without an option for gateway values. So by default it gets the gateway IP address to use only from the DHCP server. Do not change these for now.

Now my unit failed to boot since it could not find the TFTP server to get a new linux kernel from. I suspect my unit was used or returned, as I think the factory would have had it setup to boot from internal flash. It took some looking, but I did find support on the boot commands to see what was their settings, but never what the actual factory settings are. After you push the reset button, hit the space bar within one second and you will get the Uboot prompt. To see the saved settings enter "printenv" and you should get a display of options. Typing "help" should also give you a list of possible commands. Trying "v" will give you the version of Uboot, mine was 1.1.4, and based on some web information needed updating.

It took some searching, but avrfreaks "NGW/Newbie/boot from flash" had the answer for what to do. After looking at SD booting commmands as well as NFS/TFTP, it seems there are several env settings that control how it boots. I don't know why all this isn't in one place, but then the documentation seems to be based on people asking questions with no one unifying all the answers at some point. It seems the items in "bootcmd" tell the boot loader which file to load - i.e. the kernel file name - normally uImage, and then which processes to use after finding the file. The "bootargs" is the test string to append to the linux kernel as it starts up. If you have ever played with non-standard linux boot issues you will reconize the "bootargs" as normal linux passing of settings. However the "bootcmds" is special to Uboot and in the case of TFTP, uses other env settings as well.

I noticed the newbie doc was updated, as the first "bootcmd" seemed wrong and didn't work. I suspect later versions of the Uboot source do not contain default values and thus you need to be specific about the kernel file name and location. The first example has no file name to load, while the second example correctly includes the file name. The "fsload" command loads a "file" at some fixed address and then you do a "bootm" or boot system from memory action. You edit the setting in one of two ways "askenv xx" or "set xx". The "askenv" command will prompt for input, while the "set" command expects to have the input wrapped by a single quote. Here is the good example from the newbie doc:

Uboot> askenv bootcmd
Please enter 'bootcmd':fsload boot/uImage;bootm
Uboot> set bootargs 'console=ttyS0 root=/dev/mtdblock1 rootfstype=jffs2'
Uboot> saveenv
Uboot> boot
Keep in mind that if this doesn't work, use help, and do some "fsls mtdblock1" to see what is on the file system. "mtd" is the on board flash device, block means partiton, and "1" means first partition. "block3" is suppose to be /usr data.

While on the topic of booting - here is how to boot from a SD rom card, while how to load the OS on a card will come later - as there are several gotchas to keep in mind for SD cards.

Uboot> askenv bootcmd
Please enter 'bootcmd':mmcinit; ext2load mmc 0:1 0x10400000 /boot/uImage;bootm
Uboot> set bootargs 'console=ttyS0 root=/dev/mmcblk0p1 rootwait'
Uboot> saveenv
Uboot> boot
So we have mmcinit command to initialize or read the card type and data structure, so it knows how to get the data. The ext2load, means the file system is an ext2 file structure, and load the given file named uImage at address 0x1040000. Lastly is the bootcmd to 'boot' the program from 'memory'. The bootargs is different only as it relates to the device naming and partiton information used by Linux for MMC/SD cards - /dev/mmcblk0p1 - means use mmc block device 0 and partiton 1 or first partition. Please note - that if you just want to test a boot process, skip the "saveenv" and a hard reset will restore the env values to what was saved last.

Lastly is a review of TFTP/NFS setup and command settings. Let me say here quickly that you will need both an NFS and TFTP server, and as I did, both can be on the same system. The advantage of using this setup has to be the speed and simplicity of compiling or editing the file system on the NFS server. Make your changes, maybe do a recompile, or add/copy changes to the file system and push reset on the NGW100 to see if it works. As I will cover next, programming a SDrom is several steps that have you removing the card from NGW100 and inserting it into the programmer, programming it, then removing and replacing it in the NGW100 where you reboot it. A simple shell script can be written to automate the NFS over-writting of old code when a new set of files is created. You can even edit files in the NFS file structure and simply reboot to see the changes - simple and faster.

On my openSUSE system where I do my development work, I used yast2 to turn on NFS and TFTP services. I pointed the TFTP diretory at the boot directory while the NFS directory was pointed at the root of the file system. Suppose you build in your home directory under avr32 or "/home/me/avr32" and have created a directory under it for the NFS mount point as "/home/me/avr32/nfs". The NFS services directory then would be "/home/me/avr32/nfs", while the TFTP services directory might be "/home/me/avr32/nfs/boot". It is important to note that the bootcmd file name is shortened to "uImage" as the TFTP looks in boot and not the root like NFS. The Uboot commands are thus:

uboot: set serverip 10.0.0.1
uboot: set tftpserver 10.0.0.1
Uboot> askenv bootcmd
Please enter 'bootcmd':bootfile uImage;bootm
Uboot> set bootargs 'console=ttyS0 root=/dev/nfs nfsroot=10.0.0.1:/home/me/avr32/nfs ip=dhcp'
Uboot> saveenv
Uboot> boot
If you have your DHCP server setup to provide TFTP ip settings, then your bootcmd line should be:
Please enter 'bootcmd':bootfile uImage;dhcp:bootm
and part of the bootcmd process will be to do a DHCP setup and fetch the tftp ip address at that point - while ignoring the "set tftpserver" command. Gets confusing but can be mastered with a few attempts. Keep in mind that once the kernel is loaded and linux starts, dhcp starts all over again. These settings and issues only relate to the Uboot process.

SD/MMC usage

I started out planning on using an SD card for everything, but over time have reconsidered that idea. First off you need to keep in mind that writes are limited and although the number of wirtes are large for a typical device, writing something like a log every few seconds is not a good idea. I consider SD/MMC devices great for logging long term data on a limited basis - such as once daily for data collected more than once an hour. It really comes down to a normal backup policy - how much data can you stand to loose as to how often you save it. For that SD/MMC devices are great devices.

Clearly, NFS mounted file system is the way to go during development, and when done, putting that structure into the on board flash for long term use. SD/MMC devices are used here as well for doing updates while in the field or for special updates to say the Uboot code. You might even want to add special programs through the SD/MMC device without updating the whole linux system. Having support for these devices greatly enhances your options and thus makes it a must have.

Now that I have covered all the good, what about the bad. The Uboot code at present only supports small SD devices. Uboot can not even read devices greater than 2GB, as those larger sizes use a "HC" or "high capacity" format. To boot from a 1GB or 2GB device, you must partition it with a smaller "boot" partition to even use it. I used 32 or 64mb partiton to contain the uImage, and the rest of the device contained the root file system. Now remember this is only a limitation of the Uboot program, the regular linux kernel has full support for all sizes of SD/MMC devices. I tested this by copying the filesystem to a new and unused 4GB device which was VFAT formatted.

Now I figured all that out the hard way - by trail and error. I started with a 2GB device, got lots of errors, went to 1GB, more errors, and luckily had a 64MB devices that worked. So next was formatting a 2GB device to see if just a smaller partiton would work on it. Eventually I discovered that it did work fine, but not without a few problems to overcome first. I have several systems in house and my normal work station is a Toshiba laptop that is usually powered by solar charged batteries. I used it to partiton a 2GB SD device and it corrupted the partition table. However an external programmer on the normal development station has worked fine every time - the Toshiba programmer is internal and both systems run SuSE 11.1.

It appears that there is all sorts of data in the partition table area besides partition data. Doing a DD on the device will dump the data to a file where it can be viewed. I believe there are serial numbers, company names, device type information, and more saved on the device. If this data gets removed or corrupted you will not be able to read the device anywhere. What I did to save my device was to do a DD read of a new/good device from the same vendor into a file. Then take the damaged device and re-write the device using the ok/new file structure. I found out about this from a web site and I believe there are several sites with all sorts of information on SD/MMC for the curious.

At this point you should have a partitioned SD device that has 32 or 64MB boot partition and the rest is for the file system. Now earlier versions of Uboot do not support the VFAT file system that normally comes on SD/MMC devices. So after partioning the devices you must format it with ext2. Use the normal format utility that comes with your linux system, I used "mkfs.ext2" on both partitons. If you downloaded a new version of the core, just untar as explained in the support docs to the larger partiton, then copy the boot directory contents to the boot partiton.

Latest updates and such

It is now mid-October and a recent check on software updates indicates that work on Atmel AVR32 buildroot and uboot have been continuing as expected. In reviewing my notes from several montha ago, I see that I updated uboot to version 1.3 using instructions from the web site. The notes say "it worked" which I take to mean the instructions when followed did in fact work. I think I used the SD device process but at this point I must admit my notes were way too few on the topic. I pesonally am moving away from the NGW100 due to lack of Host USB port. However Buildroot is still the ideal means of producing a linux system for these small products and as such I will try and cover using buildroot as planned.

I had stopped wmorking on this article for two reasons - first I did cover all the most important items I felt were not available somewhere else, and secondly was the lack of USB Host port. I have decided that for me the USB Host is number one item a small system must have. Without the USB Host port your options are very limited and all the items I wish to talk to are USB Device ports and thus you must have a Host port for talking to them. There is one other concern I have that input from others might help resolve - that being - what items make a good or fully implemented system for remote data collecting and working. The concept is logging into the host remotely and making changes to the program as needs arrise - but making what changes in which language - perl, TLC, GForth, or Gcc? Got any ideas as to which tools you think must be on the remote system? I like perl. but think TLC is better and Gcc is just too big and bulky to be recompiling every little change. What is your take? Send me an Email.

Some links

Atmel home page - the place to get chip information.
Atmel buildroot support pages - where to download the latest code.
Atmel AVR32 Document pages - great how-to's and tutorials.
AVR32 developer support pages - the support page for AVR32 linux in general.
Buildroot home pages - buildroot with links to packages used.


Kibler Electronics, PO Box 535, Lincoln, CA 95648-0535, USA.
Email: bill@kiblerelectronics.com
Copyright © 2011, Kibler Electronics