X15 as a Build Machine

Howdy,

I’ve come into a possession of an X15 and would like to help provide feedback to the community in any way possible. My area of expertise lies on the software development side, though I occasionally dabble in working with hardware, capes, device trees, etc.

My first task is to use the X15 as a hard-core build system - I bought a WandBoard a few months back to build Linux kernel images and filesystems, and was underwhelmed with its USB2.0 and 10/100 Ethernet. I also grow weary of trying to using cross-compiler tools/QEMU, its always a pain. I see the X15 as a great platform to compile kernels, large applications, build filesystems, create Debian packages, do Android development on perhaps (though I don’t do much Android development myself). Is there anything else others would like to see benchmarked, reviewed, etc? I’d love to help.

Thanks,
Joe

Running omap-image-builder on the BeagleBoard-x15 is way faster and more reliable than using QEMU on quad core x86 machine.

Regards,
John

Oh, that is without a doubt. My experience with QEMU has been disappointing as best. The final straw was trying to build images that included NodeJS modules in the base image - https://github.com/nodejs/node-v0.x-archive/issues/8616 - a number of folks reported the near impossibility of getting that to work reliably.

At any rate, I’ve run a couple of kernel compiles on the X15 and it still takes quite a bit of time, but I’m thinking I’m IO bound at the moment (can’t get the USB3 ports working with USB3 devices).

Silly question. Why would anyone use Nodejs in QEMU ? I mean QEMU can not emulate peripheral modules, so if you need to demonstrate, or experiment with a project that uses Nodejs. Why not use an x86 virtual machine ?

Nodejs is a great test-suite for qemu. :wink:

Some day, qemu will handle it...

Regards,

Nodejs is a great test-suite for qemu. :wink:

If by this you mean that this illustrates why QEMU is the “red-headed step child” of emulators. I see your point. :wink:

I have been wondering the same thing, would the BeagleBoard-X15 make a reasonable system for developing on a native ARM platform? Are there other more cost effective alternatives?

Thanks,
Adi

It depends on what you want. If you are only interested in an ARM platform, then there are alternatives that are less expensive. If you are interested in using Dual CortexA15s, Dual DSP cores, Dual CortexM4s, quad PRUs, etc then there is nothing like this monster.

Regards,
John

I have been wondering the same thing, would the BeagleBoard-X15 make a reasonable system for developing on a native ARM platform? Are there other more cost effective alternatives?

Thanks,

Adi

Anything that has an armv7 processor. Other ARM core types too, but the original Raspberry PI for instance would not work. It has an outdated ARM core, which barely anyone support, in the context of Linux distributions.

rPI 2, wanderboard, Beagleboard X15 are 3 different boards, with the rPI 2 probably being the cheapest in terms of cost. However it is limited to sdcard / usb media for storage. The wanderboard / X15 both have SATA.

Here is another alternative that has SATA and is inexpensive: https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2/open-source-hardware

You can ask Robert about the LIME2, as he has built images for these in the past.

Something to be aware of though. Most of the less expensive alternatives are going to be missing a nice feature or have limited resources. Such as no SATA, or only having 1GB RAM versus 2GB or more. Here, this is why cross compiling can be very attractive, as an x86-64 system can have 16GB or more, of which more than half can be dedicated to a tmpfs RAM disk. Which can help speed up large source compiles drastically.

Anyway, google, and you’ll probably run into many more options

Here, this is why cross compiling can be very attractive, as an x86-64 system can have 16GB or more, of which more than half can be dedicated to a tmpfs RAM disk. Which can help speed up large source compiles drastically.

Sorry I kind of jumped the gun here, and left out some information. When compiling more than just a small personal project. 1-2GB is ideal, but always the more you have, the better off you are. For me personally, I consider 4GB the sweet spot, but have used virtual machines with 10GB of RAM dedicated to them in order to compile the Linux kernel all in memory. Which for the record, without using the RAM disk would take around an hour or slightly longer to finish. When using a RAM disk to compile, it takes about 15 minutes.

I am thinking that something with more RAM and some high speed disk option, USB3 or SATA, would make sense. Compiling anything but the smallest projects on a BBB or original Raspberry Pi is painfully slow.

I don’t know. I’ve compiled Nodejs from source on the BBB and it does not take too long. A bit over an hour. My buddy here compiled Wireshark on the BBB though, and that took half a day or more. Plus we had to setup a USB hard drive as swap in order for it to succeed.

However, my thinking is this. My buddy spent several days trying to figure out how to cross compile Wireshark for armhf, and ultimately failed. By comparison, he setup a build system, on the BBB, then initially failed because of oom, then asked me what he could do. Where I suggested he setup a USB Hard drive as swap, and it worked. SO maybe 1.5-2 days total time investment.

So the thinking is, you could spend a very long time attempting to setup a cross compile system for one thing or another( and yes they’re all different ), but ultimately fail. Or you can set things up on the BBB, and let is run off in the corner for a day or two to do it’s thing, and be done.

Now, If you can find exact step instructions, or have a reasonably easy time setting a cross compile system for whatever. I say go for it. a Good guide already exists for compiling the kernel etc. And yes there are a few other decent guides for various other things too. But if all you need is a one time compile for somethign that does not exist, or needs to be recompiled for a specific feature . . . don’t waste your life away trying to figure out how to cross compile a complex project yourself . . . life is too short.

Invest in a USB3 SSD for reasonable build I/O speed. Very helpful tip I got from Robert.

USB3 SSD sounds quite reasonable. I wonder if the memory of a rPI2 would be an advantage over the BBB?

I wonder if the memory of a rPI2 would be an advantage over the BBB?

In the context of a build system, Of course it is. In the context of running every day doing something embedded . . . It really depends, but most of the time it would make very little if any difference.

In the context of a build system, Of course it is. In the context of running every day doing something embedded . . . It really depends, but most of the time it would make very little if any difference.

Definitely looking at it from a build system point of view. For every day I have found 512MB more then plenty except for the occasional need of a ramdisk where more is better, I suppose.

Definitely looking at it from a build system point of view. For every day I have found 512MB more then plenty except for the occasional need of a ramdisk where more is better, I suppose.

My experiences over the last 3 or so years with the BBB lead me to believe that if you’re smart, the amount of memory this board has does not really matter.

That is for example. I wrote an application in C that would read from the CANBUS, decode the data coming over that bus at 1Mbit/s, format it, and then send the decoded / formated data out over a websocket. All in all, this was 4 separate processes, working towards that end. 3 Of those process were used to read individual fastpacket 2000 PGN’s. One unique PGN per process, while the fourth process was a web/websocket server written in C( using libmongoose ).

All these processes were pretty busy, using up a a good bit of processor time if I let them. But the processes hardly ever used more than ~85MB ram unless I was doing some sort of “system maintenance” while these processes were running.

Anyway, my point here is that I think that for most situations, you can use up half the BBB’s RAM ( 256MB ), and still be in very good shape. But you can not be doing something silly like running a full blown desktop - At the same time.

Well, I mean you can in many cases use up haf the RAM for a tmpfs ramdisk. So in the context of running a web server, you could theoretically do that without ever touching the onboard flash media, or sdcard.

dude, i hate qemu, i have never been able to start anything on ye olde 32-bit x86, yet alone arm machine.
Yocto is still slow, although it WORKS, unlike the mess that`s called “debian/ubuntu qemu repository”
–rant over–

I’m actually looking into using an ODRIOD XU4 for a build machine. I bought one, and have had it here for a couple weeks now. I just have not had time to work with it yet.

The XU4 is an octa-core SBC with quad A15’s running at 2Ghz, and quad A7’s which I do not recall what frequency these core run at. The board also has a 6 core GPU from what I understand. 2G RAM, USB 3.0, and a GbE network interface that is not shared with the USB buses. Also it has an interchangeable emmc 5.0 plug where you can “snap on” emmc modules that are pretty fast ( ~100M/s + throughput ). At a price of around $75 for just the board. Real costs with case, 32G emmc, and for the special serial debug module( 1.8v logic ) is around ~$150 shipped.

One thing I have not figured out yet is which ABI the board runs. I’m fairly sure it’s armhf, which would make it directly compatible with compiling binaries for the beaglebone. But I’m not 100% sure this is the case yet. Kernels used for this board seem to be slightly behind those of the latest for the beaglebone. 4.x-ish.

Anyway, it’s my belief that this board could be a perfect solution for creating an ARM build system for any ARM platform running the armhf ABI. At a lower price point than the Beagleboard X15. However, it’s functionality in the embedded space is rather limited. It’s I/O capabilities is similar to that of an rpi, just a bit more of them. So in the embedded space, it really does not even come close to the capabilities of the Beagleboard X15.