SBC CPU Throughput

just as another datapoint...  I've been slowly digging myself out of the 'broken distro of your choosing' (angstrom/debian/whatever) with the aid of LFS to get a clean starting point to compile my own set of packages with the aim of a common armv7l-gnueabihf userspace that makes use of the common facilites in cortex-A8 onwards (or neon and vfpv3) that will eventually work across Sabre-Lite, BBB, iMX53-QSB & Cubieboard2

I've just reached the stage of building my bc package.... on the SL I'm now getting 9.606 s....  gcc-4.8.2/glibc-2.18/kernel 3.12. I've probably been more ruthless than angstrom about stripping pointless for embedded stuff like nls, i18n etc, I'm booted from SATA rather than uSD and at this stage don't have much other than init & sshd running

Once I get enough pieces packaged to bring this up on a BBB, I'll report results for that too. As I have 3.12 running on the BBB now, it should hopefully give a slightly more interesting comparison since all of the software will be the same

One last thing, for anyone running not-so-recent angstrom on their BBB, at some point in the near future when you update angstrom the dynamic linker is going to change from ld-linux.so.3 to ld-linux-armhf.so.3 in line with http://lists.linaro.org/pipermail/cross-distro/2012-April/000261.html and you'll need to recompile anything you've built yourself at that point. You might get away with a symlink for some stuff, but the experience here is that it doesn't always work.

just as another datapoint...  I've been slowly digging myself out of the 'broken distro of your choosing' (angstrom/debian/whatever) with the aid of LFS to get a clean starting point to compile my own set of packages with the aim of a common armv7l-gnueabihf userspace that makes use of the common facilites in cortex-A8 onwards (or neon and vfpv3) that will eventually work across Sabre-Lite, BBB, iMX53-QSB & Cubieboard2

I've just reached the stage of building my bc package.... on the SL I'm now getting 9.606 s....  gcc-4.8.2/glibc-2.18/kernel 3.12. I've probably been more ruthless than angstrom about stripping pointless for embedded stuff like nls, i18n etc, I'm booted from SATA rather than uSD and at this stage don't have much other than init & sshd running

Once I get enough pieces packaged to bring this up on a BBB, I'll report results for that too. As I have 3.12 running on the BBB now, it should hopefully give a slightly more interesting comparison since all of the software will be the same

One last thing, for anyone running not-so-recent angstrom on their BBB, at some point in the near future when you update angstrom the dynamic linker is going to change from ld-linux.so.3 to ld-linux-armhf.so.3 in line with http://lists.linaro.org/pipermail/cross-distro/2012-April/000261.html and you'll need to recompile anything you've built yourself at that point. You might get away with a symlink for some stuff, but the experience here is that it doesn't always work.

selsinork wrote:

 

just as another datapoint...  I've been slowly digging myself out of the 'broken distro of your choosing' (angstrom/debian/whatever) with the aid of LFS to get a clean starting point to compile my own set of packages

Excellent!  It's been my intention to tread that path for a very long time for embedded, because any software that doesn't directly support the embedded application is actually a liability and a waste of resources.  Superfluous and poorly known code also increases the attack surface of a device, an issue of growing importance in recent times.  I'll be very interested in your progress and quite keen to follow on BBB.

I've just reached the stage of building my bc package.... on the SL I'm now getting 9.606 s....  gcc-4.8.2/glibc-2.18/kernel 3.12. I've probably been more ruthless than angstrom about stripping pointless for embedded stuff like nls, i18n etc, I'm booted from SATA rather than uSD and at this stage don't have much other than init & sshd running.

I've added your datapoint to the table.  I bet it boots fast with so little running.

Morgaine.

booting still has it's problems... after u-boot loads the kernel and devicetree you get a 'Starting kernel..' message and there's then an annoying 2-3 second delay before you get anything.  It's at exactly this point that everything stops when you've messed up something between uboot, kernel and device tree and it's not going to boot at all, so one of those hold your breath moments.. other than that, yes booting is nicely quick.

LFS is an interesting educational experience   It has it's challenges though, partially that it's rooted in x86(_64), understandable as that's where it's history lies, and partially in that the version for Arm, CLFS, is both a cross-compiled version and that it wants to use musl-libc instead of (e)glibc (as well as older kernel and gcc which I wanted to avoid)

After some odd experiences with the cross-compiled angstrom on both BBB & Minnowboard, I started out with two pre-requisites:

1. No cross compiling, ever.
2. A 'full fat' build of glibc.

So I'm using the latest development version of the main LFS-for-x86 but tweaking it for Arm as necessary.  I have to say, I like their approach in general although it's quite obvious there are some historic artifacts as well as some odd jumping through hoops while trying to satisfy some perceived need to follow FHS.

Interestingly some of the fixes for a couple of problems came from http://www.intestinate.com/pilfs/ where someone has done a version for the RPi. He even provides some scripts that might take a lot of the pain out of doing it. I think you'd mostly only need to change armv6l to armv7l in a few places and probably add the specific options to get gcc & binutils to use neon/vfpv3.  Of course, using the scripts means you miss out on some of the experience of doing it yourself