Since my many articles about ARM systems, the industry has come a long way. The first few systems were pretty simple and required lots of hands on work to get them up and running. This latest batch however has been driven by the RaspberryPi and has very low cost with plenty of simplicity. It has been many months since the RPi has passed the one million sold point, and the rest of the industry has not been setting idle. This has spurred all kinds of new systems and pricing, but it seems the only real new competitor in my book is the "Black" version of the "BeagleBone" by TI and CircuitCo LLC.
I wrote several articles about the BB (BeagleBone) and I like the system. I have problems with the board size and layout of I/O ports - packaging is near impossible - but then these boards were never intended as production boards. However the same is true of the RPi and it has sold over a million boards. Clearly, packaging of these boards is not a concern, it is mainly driven by cost and feature set, with very low costs being the main point. For me there is some problems with the RPi use of propritory code in the linux kernel. As far as I know the BB and BBB still are 100% open in both design and coding. That is a strong incentive to use the BBB over the RPi.
OK - I know everyone wants my review of both boards and to help that out I logged on to all three systems and collected some output of system data. So here is the collection of RPi, BB, and BBB data. My summary of the data is that the RPi is very underpowered and greatly limited as to both I/O and features. The cost difference in the new Black to the RPi is little, but you get more serial I/O, more I/O pins, more horsepower, and just a better overall set of user options. In both cases it is now possible to have many versions of linux up and running in a matter of minutes. With the addition of HDMI interface to the Black, it too can now be a standalone system. I added a monitor, an USB mouse, and keyboard ( see picture links below) and my system came up without having to burn a single memory stick. The new Black is clearly trying to be as user friendly as possible.
When playing with the earlier BleagleBone or BB, I tried many times to load Debian to no avail.
The best linux version for me was the Arch releases. However this time when I did the
"omap-image-builder" git repository by doing (try this site for more options - http://eewiki.net/display/linuxonarm/BeagleBone)
git clone https://github.com/RobertCNelson/omap-image-builder
and ran the "./build_image.sh", I got a version of debian that actually worked. I tried building
a BB version and it still fails with the init.d parrallel setup problem ( fix by dong:
"sudo touch /etc/init.d/.legacy-bootordering" to cause CONCURRENCY="none" to be the default
operation ). The Black version of the "debian-7.1-console-armhf" - that I burned to the sdcard by doing this
command: "sudo ./setup_sdcard.sh --mmc /dev/sdd --uboot bone_dtb" in the deploy directory
of the same name, worked perfectly on both BB and BBB.
This will give you a working version of Debian 7.1 without any desktop - pure command line. I took one of my copies and copied it to the hard drive I have been using, changed one line in the "uEnv.txt" of the flash image to point at "mmcroot=/dev/sda3" and commented out the old line "#mmcroot=/dev/mmcblk0p2 ro". The results is that I now run off of the hard drive attached to the USB hub that has the mouse and keyboard as well (need external power). From there I ran the "sudo apt-get update" and then "sudo apt-get install xfce4 xfce4-goodies". You don't need to do the upgrade - since the omap-image scripts downloaded the latest version of Debian 7.1 - please note it will take a few hours for the build-image script to provide you with new versions of Debian and ubuntu in the "deploy" directory. You get both "stable" and "test" versions of each.
I need to remind new readers that these are pretty much standard Debian update and install steps. You need a good internet connection and have DHCP running - else you need to follow the Debian admin guide for networking and setup your system to match your personal environment. This may take a new user some research time and reading, but it will help you to better understand how all the bits fit together. The main point and most important point is that the BB and BBB are standard linux systems - they work the same as almost any Debian desktop - you just have less actual hardware with more I/O and different options. I have problems explaining to people that the command line steps are the same. I see all to often that they expect to be dong something different since it is an ARM chip and not an x86 cpu. With Debian and linux, the processes and steps are the same.
One of the reasons for using these boards is access to the serial I/O. We have been building embedded devices using the SiLabs run of 8051 based chips. You talk to the development boards using a serial port and lately, most desktop systems do not have actual serial I/O ports. You can try using USB to serial converters, but we have found that most just don't work very well, if at all. We require true handshaking and most converters don't do that. Lately we have started using BB and now the BBB boards for the serial interface. It works pretty well both serially and as a development system. You log in remotely, do your code changes, connect to the SiLabs device and transfer the new image. You have all the normal linux tools available and life really can't get much simpler.
I wanted to test my setup and confirm the steps on the new Black, and at first had a minor issue using an old version of gforth. The problem is that gforth version 7.0 - the default version for Debian - has the serial handshake test broken. I worked through this issue with the gforth support people and we fixed the probem sometime ago. gforth version 7.9 and greater should work correctly on linux now, however the Debian maintainers are currently not including those updates. I suspect the Debian people are waiting for a version "8" and not taking any snapshot versions.
What this means is that you must build a newer version from the source tree. This is not a complex task, just that it adds a few more steps before you can get started working. Please note that you need a working vesion of gforth to build gforth. You can get by, by exporting the build tree from one hardware platform to another hardware platform. I did that previously to get gforth running on Arch as they didn't have gforth in their repository. I tried that exported tree again - it worked under Arch, but it failed to build properly under Debian 7.1 armhf. I didn't spend time trying to figure out why, I just got a new version of the source tree using git and that built fine. There are a few steps to do, like a "build-dep" for gforth, to make sure you have all the build tools the compiling will take. So here are the steps I did:
sudo apt-get update sudo apt-get upgrade sudo apt-get install gforth sudo apt-get build-dep gforth mkdir ~/gforth cd ~/gforth git clone https://github.com/earl/gforth-mirror.git cd gforth-mirror ./BUILD-FROM-SCRATCH sudo make installPretty much it. You will have on your system, both a gforth 7.0 (do - "/usr/bin/gforth -v") and a gforth 7.9 (do - "/usr/local/bin/gforth -v"). Just make sure that any tools or scripts call the correct version of gforth and that your "PATH" (do - "env") has the "/usr/local/bin", before the "/usr/bin". Now this was specific to gforth, however it is pretty much the same for any application you might want to have a more current version of. Just remember to do a "build-dep" on the app and then your build should work. In my case we went outside the Debian repository to get the latest source tree, but you can get the current source tree for any app by just doing "sudo apt-get source gforth". That will install the current cpu version of the source tree for your current hardware in the directory you called apt-get from. Doing a "man apt-get" might answer questions about what your doing. Keep in mind these steps are valid for any version or hardware platform using Debian. One note is that gforth has it's own building script, while most apps build steps are "./configure;make;sudo make install". The "README" in the top of the source tree usually explains what steps to take for building the app.
I have talked before about using NFS exported file systems to boot these embeded systems with. NFS offers the ability to have no attached file systems other than the initial flash device used to connect with the NFS server. The Black now has the onboard flash which could be programmed to contain the server location and thus no flash needed. Personally I would still use the flash and leave the onboard alone, if for nothing else than an emergency system for testing and trouble shooting. So what are the steps to doing this. First off we need to export something.
Here is what I have done for my exporting. I took the latest version of the Debian 7.1 system image from my USB harddrive and copied it to my support server in the "/export" directory - which I made as root. You must copy the files using "sudo" as they are owned by root and you want to keep that ownership. Next is to edit the "/etc/exports" file as root and add the line "export *(rw,sync,no_subtree_check,no_root_squash)", save the file and next do "sudo /etc/init.d/nfs-kernel-server restart" to have the nfs deamon use the new settings. We test the changes, by going to another system and doing "sudo mount 192.168.0.10:/export /mnt" and you see the new file system by doing "ls /mnt". Check your man pages and be sure the test system has "nfs-common" loaded if it doesn't work. The Black Debian version did not have nfs-common and a simple apt-get solved that.
The next step is setting the flash to mount the NFS filesystem and not the flash or harddrive. Keep in mind that you have a few ways to do this process. The uboot that is in flash, has commands, and if you hit the keyboard fast enough in the BB, you will be given a command line to enter bootup options. You can boot the kernel using a TFTP server, and then have it load the NFS file system. That option is great for testing and rebuilding kernels over and over again, as the kernel image is never burned into the flash - no flash swapping. I trust my kernels and thus feel that I only have to burn the flash once and I am done. For me it is the "root" filesystem that I want to load from NFS and nothing else. Simplest setup.
I might comment that it helped me in testing the settings, by using the BB with the USB cable and minicom monitoring the bootup steps. I saw several errors and adjusted my settings to correct them. One of the errors was in the nfs setting in /etc/fstab, where I had used the wrong settings for the mount point - they needed to be nfs settings. Basically what you are doing is telling the kernel where to find the filesystem, and how to setup the ethernet system. By default the BBB coding trys to boot up the USB network system instead of using "eth0". So it means you need to make a few other updates to the "uEnv.txt" to make sure it uses "eth0". If your not using regular ethernet, then some adjustments may be needed to the parameters.
So what needs to be done is tell the kernel that the root filesystem is "/dev/nfs" and
that the "nfsroot" is your IP and PATH to the filesystem on the server. You need as well to
give an IP address for the unit with several blank values and "eth0" as the device to use
with nfs. I had problems seeing that I was passing the correct values because the echo
of the line was being shorten and thus I moved my values in the passed string. Since
it should work as shown, adjusting or not is up to you - mainly make sure all the values are
passed, as it will fail otherwise. The changes are:
#mmcroot=/dev/mmcblk0p2 ro
#mmcrootfstype=ext4 rootwait fixrtc
nfsroot=/dev/nfs rw
nfsrootpath=192.168.0.10:/export
#mmcargs=setenv bootargs console=${console} ${optargs} ${kms_force_mode} root=${mmcroot} rootfstype=${mmcrootfstype} ${expansion}
mmcargs=setenv bootargs root=${nfsroot} nfsroot=${nfsrootpath} console=${console} ${optargs} ${kms_force_mode} ${expansion}
#expansion_args=setenv expansion ip=${ip_method}
expansion_args=setenv expansion ip=192.168.0.13:::::eth0
All other lines remain the same in "uEnv.txt". I changed the filesystems "/etc/fstab" line to be:192.168.0.10:/export / nfs rsize=8192,wsize=8192,timeo=14 0 1Now I am not certain you need to set the fstab table this way, but I feel it helps the system and you later when checking for problems. The initial kernel settings probably will work, as the root filesystem will normally just crash if something changes it. So keep in mind that the server file system may be ext4, but what the BBB is concerned about is that it is NFS and doesn't care what actually is on the server. NFS just serves up files and directories for you to use and change - how they are managed is the servers responsiblilty.
A quick note here is that I setup my network services and user accounts while running from the harddrive. So the image I copied over had working network services, my personal user account, and a working xfce4 desktop. You might want to edit "/etc/network/interfaces" to make sure the default network interface is "eth0" instead of the current "RNDIS" default. The main thing to keep in mind, is that you want a working filesystem to be exported - at least to do proper testing at first. You can export more than one filesystem and thus have one that works and one that is under development.
To review my steps it goes something like this:
Do git updates to the image tools or download the latest flash images of your choice. Burn those images to flash and test that they work. Make sure the images are updated enough to do NFS mounts. Copy the "ext4" filesystem to your export directory of your NFS server. Test your NFS server by mounting the exported filesystem. Edit the "uEnv.txt" on the flash's DOS partition (#1) for NFS settings. Edit the export images "/etc/fstab" for root being nfs. Boot system with edited flash and system should boot using the NFS filesystem.That is pretty much it. Pretty simple and not much work.
Over the years the level of users interaction in linux that was needed to bring a system up, has steadly got simpler and cleaner. It was never more evident this time around than in bringing up the BeagleBoneBlack. It was less than a year since I worked with the BeagleBone, and remember all too well the numerous issues and problems I encountered. This time around I had none of those issues. I spent more than two weeks on this project, although most of that time was just watching things work and not fail as before. I found one probem I had before, the failing harddrives, and figured it might be the USB hub, and it was. A new hub has solved my disappearing filesystem issue. As to the Black itself, I found it rather simple to bring up, everything worked as expected, and the set of options better than ever. I had assumed the addition of the HDMI interface would be nice, but utilmately useless - but I was wrong. Using the HDMI and USB mouse/keyboard setup is quick and clean. If you have all the right cables or a HDMI compatible monitor, you can be using the Black in about the same amount of time it took to take it out of the shipping box.
I must make one last statment and be very clear about this, I do and did everything using linux. I do not use windows unless forced to or when trying to help normal users fix windows problems. From using windows at past work sites, I know considerably more than most about how it works. From that experience and now many years of linux usage, I know that using anything other than linux to do embedded development work is a complete waste of your time. The stumbling blocks, missing tools and easy setups just are not available on windows machines. If your trying to work on these new smaller systems, the best advice I can give is only do so using linux. Life is far too short to be spending needless hours working around the windows problems, when it just works with linux.
Enjoy!