This article intends to provide information to help you master buildroot toolset and perhaps prepare a new system image for an embedded product such as the Atmel NGW100. There are many products that use the buildroot toolset, the latest I found was the new Hitachi NAS SimpleNET server that is reviewed in CCII#11. These two items use ARM cpus with MMUs, but buildroot can be used for any type of cpu that is supported by linux and gcc toolset. The tools are intended to be run on a Linux system under make and gcc - the normal compiling tools of Linux.
There are plenty of on line support pages for those trying to learn buildroot and I do not want to just re-do those here. What I ran into when working with the Atmel AVR32 version of buildroot are a number of problems related to lack of specific facts and details. I hope to cover what my personal digging and playing around produced so that you will not re-do my mistakes and waste all that time when there are simple steps to follow. Clearly buildroot is a complex set of tools provided by many people who are devoting their lifes to making it work well. I trully appreciate what they have done, and presently think it is the only way to make small linux systems. Having been in this industry for far too many years, I know only too well how little time programmers get to fix documents. I hope to add a little help to buildroot documentation if I can.
At this point I want to talk about what you get by downloading the Atmel buildroot tar file. You get them from the links provided at the bottom of this article. Un-tarring the latest buildroot into your home directory will create the "buildroot-avr32-v2.3.0" directory. In there you will find that it is the same basic structure of generic buildroot without the "i586" - if you were to load it from the buildroot home. Atmel has added their own items while removing the non-related products and platforms. I did find other versions of the buildroot tree that did contain almost all supported devices, but the latest for a given product will normally only be available from the vendor.
There are a few things to point out about buildroot. It has default settings that when starting a build will be used even over your changes if not done right. It allows for fetching new tools or programs and tracking them for you - until you do a clean and want to start over ( you can defeat this - by simply copying the files into a safe location and replacing them after the clean - files as in source code tars). In Atmels case they have defined several system configurations which I have yet to find a definition of what those configurations are intended to do for you. You can create you own configuration to an extent but changes in the default directories are needed to create a new default definition. Master these few concepts and you should be able to do anything you want.
I remember having trouble getting Atmels copy of the DVD from their site. There are two versions, one that is suppose to be a full DVD and one that only has the main items for those wanting to do buildroot. The DVD contains an IDE, docs, buildroot, and a little bit of everything. The smaller version only has what you need to get going. The full DVD is 1.12Gigs of data, while the shorter is 900 megs - not a big difference, but at first I was only able to get the smaller, the larger failed as soon as it got to 1gig of download. There does not appear to be any BitTorrents for these files, which would have solved my problems getting them.
Do you need the DVD stuff - for sure. Unless your on an Arm system, all your gcc tools will be for an x86 cpu. The DVD has the gcc versions and scripts to load the toolset that can compile the Arm code in buildroot. There is also a linux version of their IDE for those who like windows based compiling. I have always done command line compiling and thus have not realy tried their IDE. I will leave testing it to your own experience. The main item is their HTML "Build Support Package" that will haelp you get started. Please read it and get what you can from it - it does help, but some items are circular loops that in the end provide no real information - you will need to look elsewhere in some cases as I did.
One feature that is important if your serious about using their buildroot, is the "co" drectory. In there you will find an svn version of the buildroot tree and as such should allow you to do "svn update" and get the latest updates. I checked out the ".svn/entries" file and it contained the source location of the orginal svn tree ( http://buildroot.googlecode.com/svn/branches/john-avr32-buildroot ). I know this is the original source, as I went their on my own and did a svn checkout. I just checked my copy and did an svn update that returned "at version 776" as the current version, which looks like nothing has happened since 2009.03.20. Let me make it clear, that if your doing serious work, using svn is a "must do" and the only way to go. Learning the svn toolset is simple and can save your project from disaster over time.
To move on to doing builds after loading the cross compilers and setting up your buildroot directory is simple - invoke make. I did that in the svn version and it failed. I did it in the V.2.3.0 version and got better results, but not perfect. I read some more docs and found I need more than just "make". The proper steps are:
# make atnqw100_defconfig # make source # makeYou must setup the build structure and you do that by invoking a make with one of the pre-defined default config setups. When I did the above - I got good builds on both V2.3.0 and svn version. I found these default build packages in the V.2.3.0 tree:
/buildroot-avr32-v2.3.0/target/device/Atmel> find . | grep atngw100 | grep defconfig ./atngw100/atngw100_defconfig ./atngw100-expanded/atngw100-expanded_defconfig ./atngw100-base/atngw100-base_defconfig ./atngw100-evklcd10x/evklcd101_defconfig ./atngw100-evklcd10x/evklcd100_defconfigI believe the options are "antgw100" for the normal gateway code as it should be shipped with it. The "-evklcd" are for the board with the LCD test module, while I never found a definition for "-base" or "-expanded". I can see that "-base" is a stripped down version with practically nothing added. The "-expanded" is more files, but I never figured out what their objective was, it is not stated anywhere I looked. When I tried to build "expanded" it failed, while "base" compiled without errors. I did eventually fingure out how to add my own defconfig, but it takes more than just adding it to the directory shown above.
One of the nice features of buildroot is the source tree. You setup your source tree by doing the "make source". The source tree is a structure of source modules which get compiled and the binaries then become the items arranged in the target directory that eventually becomes the running linux on your "target" system. Making source will check to see if the source code is present for all items you need, and if not, it will downlooad them from the internet. It does stash them in a "packages" directory and as such will check first to see if it is already there - the source that is, and depending on what your doing - a first pass - then will compile a new version. If the current version is built and ready to go, the make simply skips it and checks the next in line. Thus you could add a new component and do make source at which point it will go out and get the source code and do a compile on only the new item.
The last "make" basically assembles all needed modules or components and arranges them into a target tree structure, copies that structure, and tars it up for deployment on the target files system. At this point your ready to test your code. If your tftp/nfs defaults point to the just created tree, and your atngw100 test board boots from the tftp/nfs server, a simple reboot of the board will invoke the new code you just compiled. My tftp/nfs drectory structure is separate from the build tree and thus I do a "cp" or copy from buildroot to the tftp/nfs location. That keeps me from using code I may know is not good or was just testing for a later build.
I must comment at this time, that I feel using tftp/nfs is the only way to go. I learned this by doing several builds that pointed out little errors in "/etc" files. When using the SD devices, correcting the error if it booted, was a simple edit on the SD file, but often it failed to boot. Using the tftp/nfs however, it simply meant I could edit the needed file and do a re-boot for the new value to take effect. I found many little errors and problems that way before figuring out where in buildroot the changes needed to be done.
There were a few things I wanted to do, some were simple changes in a few "/etc" configuration files, while others had to do with creating my own version of linux. I tried several builds after a few changes only to discover that those changes went back to the default settings. It turns out that a few items are set every time you do a make, most come from defaults in almost hidden locations, while others come from clearly default locations. Your task then is knowing what tasks require which locations to be changed. This is really the reason for writing this article - I made lots of mistakes figuring it all out.
Let us start with a simple change - make both ethernet ports come up the same way. From previous debuging a working system I know that the ethernet setup is done from values contained in a file called "interfaces". I searched then for the file in the V2.3.0 tree:
buildroot-avr32-v2.3.0> find . | grep atngw100 | grep interfaces ./target/device/Atmel/atngw100/target_skeleton/etc/network/interfaces ./target/device/Atmel/atngw100-expanded/target_skeleton/etc/network/interfaces ./target/device/Atmel/atngw100-base/target_skeleton/etc/network/interfaces ./target/device/Atmel/atngw100-evklcd10x/target_skeleton/etc/network/interfacescat-ing the file gets you this:
buildroot-avr32-v2.3.0> cat ./target/device/Atmel/atngw100/target_skeleton/etc/network/interfaces
# Configure Loopback
auto lo
iface lo inet loopback
# Configure Ethernet 0
auto eth0
iface eth0 inet dhcp
# Configure Ethernet 1
auto eth1
iface eth1 inet static
address 10.0.0.1
netmask 255.255.255.0
network 10.0.0.0
broadcast 10.0.0.255
You can see from the above, all I would need to do is copy one set of values over another to
make both ports act the same. We can also see that this is in the "target_skelton" section
for each type of build. If we remove the "atngw100" from our filter, we see about 14 hits,
for other devices and some generic skeltons as well. Buildroot has some generic options as well
as plenty of pre-defined hardware based settings in the whole tree. This is the advantage of
using buildroot, not only do we have several pre-done options, but each option is separate
from other options and can be built or changed without effecting other builds. Thus you could
have several projects in one buildroot tree on different hardware platforms and several
variations of those, all without one effecting the other. That feature sold me on the toolset.
Making changes in the "skeleton" tree will persist through cleaning and other re-starts, if they are not over-written later in the process. So start with changes in "skeleton" and if those get over-written, you will need to look elsewhere. Quick comment - the "base" is a good place to start building your own set of tools by using menuconfig to setup your options. I did that several times and was able to make numerous changes and additions without issues. I wanted however, to make a new option called "dev", to become for me a "development" version with all the tools you need to do target based development work. Right now your basically doing "cross-compiling" from one platform to another - but I want to remotely login and make changes on a system running anywhere in real time. Yes you could still do tftp/nfs cross build and changes even on a remote system, but that is loaded with problems related to making sure the network is always available. I want my changes to last and work even when the network is down - thus changes to items in flash.
So here starts the tricky stuff for those who want to go one step further. Clearly from what I have already covered, you will need to make a "device/Atmel/atngw100-dev" tree of files, and you can do that simply by copying everything from one of the other options. Trying to use the new structure however will fail, as none of the "Config.in" files have it in them. The "Config.in" basically are used to create the config files that then are used to do the actual build. Menuconfig uses the config.in as inputs to what it does - thus they must have any new configurations listed in them. There are only two that have atngw100 values - they are:
grep -i atngw100 ./target/device/Atmel/Config.in
default "atngw100" if BR2_TARGET_AVR32_ATNGW100
default "atngw100-base" if BR2_TARGET_AVR32_ATNGW100_BASE
default "atngw100-evklcd10x" if BR2_TARGET_AVR32_ATNGW100_EVKLCD100
default "atngw100-evklcd10x" if BR2_TARGET_AVR32_ATNGW100_EVKLCD101
default "atngw100-expanded" if BR2_TARGET_AVR32_ATNGW100_EXPANDED
grep -i atngw100 ./target/device/Atmel/AVR32_Config.in
config BR2_TARGET_AVR32_ATNGW100
config BR2_TARGET_AVR32_ATNGW100_BASE
config BR2_TARGET_AVR32_ATNGW100_EVKLCD100
config BR2_TARGET_AVR32_ATNGW100_EVKLCD101
config BR2_TARGET_AVR32_ATNGW100_EXPANDED
Thus to get a new project started, these two files need to be edited with your new project
name. After editing, try menuconfig again and you should see your new project option.
Enable it and start working through all the choices your now presented with. I found this part
actually the biggest problem, as some selections will fail building, other will have errors,
and yet you might still get a working system. My dev project ended up with errors (gcc) during build,
yet booted fine and gcc returns a correct version number. Beyond that I have not tried actually
compiling on the target yet - that is for a later time.
I know there is plenty of help on buildroot on the web. What I tried to do here was point out a few issues I ran into doing the atngw100 builds. I wanted a different "dev" tree of my own choosing and concepts. I was able to do a new project tree after some digging around and testing of changes. What I did was somewhat out of the normal method, you normally would just take the base project and add more to it, but I wanted to take the normal atngw100 project and remove and add more items, while still having a true atngw100 project to fall back on to. It all worked, I learned a number of things, and am ready to move on.
I have three projects still pending yet, work on a Olimex LPC-E2468, which does not use buildroot, doing buildroot for the Hitachi NAS SimpleNET for booting off of tftp/nfs, and lastly something for all my projects - namely defining what tools and files make up my "dev" linux system. I still feel I have yet to clearly define just what tools are must have and which are to be ignored. Any help you have in that area will greatly be appreciated. I hope this project has helped and please let me know if it has. Thanks, Bill.
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.