Image Image Image Image Image Image Image Image Image Image

This 8-Bit Life | September 27, 2016

Scroll to top

Top

13 Comments

Ubuntu Linux PandaBuilder - This 8-Bit Life

Leland Flynn

The DMS has quite a few awesome members, all of them working on amazing individual and group projects. But a little while ago we gained a new member named David Mandalla, and David just so happens to work for Canonical, better known as those awesome folks that make the Ubuntu Linux Distro!  Not only does he work for Canonical, but he works on their ARM development team. He mentioned that he had a big project he was working on and many of us, myself included were pretty stoked to see what he had going on.

It seems that Canonical had a problem to solve. They wanted to build Ubuntu and its entire software repository for ARM. The only problem was time. Sure they could cross-compile everything but that could take a seriously long time. What they needed was a native build solution, a device that they could build everything on in a reasonable amount of time and ensuring relative security to all packages. What they came up with is pretty excellent.

This what David refers to as the Panda Builder. An ARM based 4U server comprised of 20 PandaBoards controlled by another Master board that will be used to compile all 20,000+ packages for Canonical. This is  really a very slick build, it’s well laid out for optimal air flow, it’s modular design makes it easy to service and it’s not overly complex which provides very few points of failure. Now, let’s get into some spec porn shall we? Here’s a basic list of the components in the chassis.

(21) PandaBoards

(20) 300 GB SATAII USB Hard Drives

(1) 200A 5V PSU

(1) 100A 12V PSU

(24) Serial Controlled Relays – Mounted on PCBs in arrays of 8

(21) Female CAT5 Ethernet Jacks – Not mounted in picture

 

In brief the PandaBoards each have an OMAP4430 app processor, 1GB of low-power DDR2 RAM, SD/MMC slot, and HDMI 1.3 connector, 3.5” audio out, 802.11 b/g/n, Bluetooth 2.1, 1 mini USB port, 2 USB 2.0 ports, Onboard 10/100 Ethernet and JTAG headers. All for about $174. Because of how inexpensive these boards were, David was able to build this setup for relatively cheap. So if you’re like me, you probably want to know how it works. I won’t pretend to be an expert as I have a very indirect knowledge of the server but from talking to David here is the gist that I got. When a ‘customer’ requests time on the server to build and test a package a call is sent to the controller board which then queries for another board not in current use, when it finds one it trips that boards respective relay to reboot it, then issues a command to format its hard drive. Once that is complete the board is rebooted again and the controller PXE’s a pristine image of the build environment to the board in question. This is crucial as it helps ensure the security of the packages being built on the server. Once the environment is booted and ready to go, the controller board hands off the environment to the ‘customer’.  Pretty impressive no?

If you liked reading this and want to see more please check out David’s build log at dmtechtalk blog.

If you’re in the DFW area and are intersted in learning about technology and collaborating on exciting projects please check out the Dallas Makerspace!

Comments

  1. Sean Palmer

    Why is cross-compiling so much slower than native?

  2. Leland Flynn

    When I briefly interviewed David about the build, speed was the reason he gave. That being said compatibility may have been a more important reason and I might have glossed over that. Thanks for the constructive criticism though! I’m gonna e-mail David tonight and try to confirm the details.

  3. Joh Lko

    Nice technology, bad company.
    Ubuntu has become a greedy, proprietory IP stealing company.

  4. morricone

    Cross compiled code should be exactly the same as native compiled code.

  5. Nicolas Jungers

    What about the separate power supplies? Is there a need for a common ground between the 2 power lines or not?

  6. Leland Flynn

    I do believe that there is a common ground for the power supplies.

  7. teg

    Joh: Nice to see people discussing facts and not just making random comments… the internet needs a sarcasm font. What has been stolen? why have i not seen anything about this around anywhere? I have to admit I haven't gone looking, but I haven't even heard anything like this, So a suggestion when you say random stuff like that back it up with facts, or at least a link to a site where the information might be found. Without that I can only assume that you feel that you, or someone you like was wronged by the company and are our to seek revenge. I cannot say if this is at all true, but that is the way it comes accross.

  8. Innocent Bystander

    I would like to know the reason why the PandaBoard doesn't have a SATA connector for connecting the hard drive.

  9. broken

    Because it wasn't in the script?

  10. Leland Flynn

    Wow! 9 comments! The most I've ever had. LOL

  11. Rune K. Svendsen

    @Innocent Bystander me too. for some reason TI hasn't included a SATA controller in the OMAP4 processor. Freescale has (IMO) been wiser and done that in their i.MX51 and i.MX53 platform (and in their upcoming i.MX6 too). TI is including one in their OMAP5 chip though. but this is Cortex A15-based, and sampling won't start until a year from now at least.

  12. amd

    TI's OMAP devices came out of the wireless product group and are originally for cellphones (hence no SATA). As recently as a year ago it wasn't even for sure that the OMAP4 would go to general availability. Once the table craze started, they pulled in a SATA controller from somewhere. I believe the newer TI DaVinci (ARM+DSP) parts now have SATA, so maybe they used that one.

    anyways cool build. Maybe the next cluster could be a power strip full of guruplugs :-)

  13. lambo

    @amd: The {Sheeva,Guru,Dream}plugs (armv5tel) are too slow at compiling. I'd much rather sit waiting for something to compile on a pandaboard (armv7) than wait almost a day(!) for glibc to compile on a *plug. Don't get me wrong, the plugs are good for their performance/power ratio but floating point performance and compilation speed are poorer than on my old 450mhz Pentium II, it's just a good thing they don't suck the same amount of watts :)

Submit a Comment