MAKE How-To: Get Started with the BeagleBone

Matt Richardson from MAKE provides this introduction to the BeagleBone dev board. BeagleBone is an TI AM3358 ARM Cortex-A8-based microprocessor board that ships with a 2GB microSD card with the Angstrom Linux Distribution with node.js and Cloud9 IDE. It retails for $89 from MAKE and Adafruit.

Here’s another intro to the board by Jason Kridner from TI and a participant in the community. This site contains a wealth of technical information about the board and projects.

For more details on BeagleBone basics, visit MAKE. Details on the Linux source code can be found on MAKE’s BeagleBoard code page.

Join the Conversation


  1. Hi Gaël.
    Look at the hardware specification. The most important difference is the microchip it is based on. Raspberry has Broadcom SoC chip with ARM11, video GPU and 256 MB RAM onboard. In contrast BeagleBone has ARM Cortex A8 AM3359, 256 MB of external RAM and no GPU unit (as far as I know). So the Raspberry seems to be more powerful and what is more it is cheaper. But i think that BeagleBOARD ( is something that is even more interesting.

  2. Actually Cortex A8 is dual-issue and more progressive ARM architecture (v7), comparing to ARM11 (v6). AM3359 works at 720MHz, has NEON instruction extension. I am not quite sure why, but some features of AM3359 are not supported in BBone (native 100/1000 Ethernet, 3D graphics). Actually AM3358/9 chips should have video engine. So I would not say that it’s less powerful than RaspPi.
    Final price of AM335x chips should be much lower when the mass production will start (currently it’s experimental samples), so the price can be in comparable range.

  3. The Beaglebone is a limited export item so I don’t expect it will gain wide acceptance world wide like the Arduino or the Raspberry Pi.

  4. Widely desired, and ordered, yes, but probably we should wait until the RasPi is actually shipped, before we speak of the wide acceptance rate :-)

  5. 2 Katto: Where did you get info about limited export? I could not find that info on TI’s site. They are selling samples in Europe via Compel, and it seems to me AM335x chips were intended to be widely available as OMAP3. Is Beagelboard also limited export item?

  6. Limited export? I look at the distributors list, and see USA, China, Taiwan, India, Europe… I thought Beagleboard already gained wide popularity, but it’s more expensive than Arduino, and positioned in totally different market niche.

  7. Don’t waste your time with this over-priced nonsense. Save yourself many headaches and use an IAx86 compatible Alix board from PCEngines. Or if you insist on climbing the ARM mountain over and over again – try to get yourself a Raspberry Pi (good luck with that!)

    1. Drone, I’ve looked at PCEngines and their pricing (to the US), and I don’t see a particular advantage to that product–unless you hate ARM. It’s no problem if you do, but considering the price and availability, I don’t have any particular incentive to use the Alix. x86? I have never owned an x86 dev board, even if the laptop I bang out my comments on is using it.

      Why shouldn’t I use the Beaglebone and the ARM? I can get it with a case and a power brick and the peripherals I need for my plans for a few hundred and get basic functionality within a few hours of getting the box from UPS. (There is nothing more I hate than getting something, something expensive at that, and having it sit in my pile for six months because I could not find the other widget I needed. At that rate it’s already obsolete! Let me show you my pile of dev boards waiting for something to do…)

      What gotchas have you seen with the ARM that make you dislike it, and again, why does it matter?

      1. Hi, David Moisan…

        Yes shipping from EU can be a problem in terms of cost/risk. So I agree with you there.

        However, the major benefit of sticking to x86 based processors is that your Linux/xBSD OS will load/compile directly and most importantly, millions (if not more) programs you compile from source will likely work too – across almost any embedded x86-based board.

        With the ARM processors, there is an abstraction in that the development environment is not x86 compatible. So if you want to compile something from x86 source, you’re gong to suffer. Also, the embedded x86 machines have a clearly defined BIOS that will likely work with little or no fighting with drivers. The ARM boards are very specific to each ARM licensed realization (chip and attached peripherals), so you must tangle with a different development environment for each board (the board manufacturer will force you to use a specific Board Support Package or BSP).

        I just deployed some test router/firewalls to a customer using Alix-like boards with a mix of very old but very powerful and still supported network load test (etc.) applications. The build was fast and relatively easy – the glue is whatever version of Perl source I want to add in at whatever level of complexity. Doing that on an ARM based board would be a nightmare and not be easily transportable from board to board. That’s not the case with an x86 based board.

        Over time, we may see a standardized ARM base platform that doesn’t require different BSP’s for each board. But that sort of defeats many of the advantages for using ARM processors by high-volume manufacturers. Also, I will certainly admit, the RISC like architecture of ARM cores are very attractive compared with the legacy IAx86 instruction set – apples and oranges and ARM wins-out. But for everyday fast to market using standard Linux/xBSD (NetBSD is doing well these days with some ARM cores, but then you have the BSP issue for each specific board) – stick with x86 compatible.

        Regards, David

  8. Demon, all good points if I were to make this in some quantity, then second or third-sourcing would loom very large as you suggest. This board of mine is a one-off to satisfy a problem I need to solve as soon as possible. I’m in IT and don’t expect to make a commercial product out of this–it’s an NTPd server for my home network. For my needs, it doesn’t seem like sourcing and compatibility would loom as large.

    Good thoughts, though. Thanks.

  9. @ David Moisan,

    If what you want to make is an “NTPd” server as you said [Network Time Protocol daemon (ntpd)], then I recommend you definitely stay away from an ARM board. ntpd is honed closely to work properly with IAx86 Linux/xBSD at the kernel level. FreeBSD includes kernel timing options for certain boards. Stick with “real” NTP, not OpenNTP if you are serious about this.

    If you’re not interested in sub-millisecond timing, then just re-purpose a SOHO router that has some form of ntpd running in terms of a package (these SOHO routers are NOT IAx86, so YMMV). If you use an Alix or Soekris IAx86 embedded board (or a fanless Atom board), then you’re in good shape. If you want stratum-1 (ntp terms not telecom/ITU definition), then make sure your IAx86 embedded board has at least one serial RS-232 port to discipline the timing with both the PPS and NMEA serial sentence data stream via a GPS receiver (I think NMEA V0183 is current at post-time) using the likes of the NTP PPS drivers.

    If you have an always-up Windows machine (LAN server perhaps), then you can run NTP on it. I think there is a pre-compiled yet freely available Windows compatible version of NTP from Meinberg in Germany (Google it). There may be others.

    Now this discussion is getting rather complex. NTP client/servers and time-keeping are a science and art in-and-of-themselves. Look here:

  10. I hesitate to add to this thread, but I am familiar with time-nuts, and the comp.protocols.ntp group. Unfortunately, I’ve found that a lot of time-nuts are somewhat too focused on absolute accuracy to the exclusion of other factors like cost and practicality. (I also did not like the time I posted on time-nuts on some mundane topic and was made to feel rather small.)

    At my workplace we use a Windows machine running Meinberg’s NTP port and a Garmin hockey puck (18 LVC) with a PPS output. That is not acceptable to most time-nuts–they expect to run NTPd and everything else in their shop on BSD. (And they expect Greenbelt or Fort Collins to give them a Stratum 0 feed as well.)

    Yet, it is more than accurate enough to our needs (we are a community cable TV station), and it was very inexpensive to set up.

    I have to ask and perhaps answer the question: How bad will it be, really? How much worse? Worse than a Windows NTPd port? A quick or not so quick reading of the sources you mention, make me think it isn’t that cut and dried.

    You obviously are tied to your x86 solutions. That’s fine. I wouldn’t begrudge it.

    But I look at the BSD server taking up space under my workbench serving time and of course I’m going to wonder if I should do it any differently. I suspect you’re partially right and there are wrinkles and quirks. But I also think I will probably get something that’s good enough to use. There are many ways for me to get PPS discipline on my NTPd.

    It’ll probably be good enough.



Leave a comment

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.