Two weeks ago I got a Beaglebone board from the people at Beagleboard.org to create the documentation I always create with every device I get.

Like always i’d like to announce the guide for installing Gentoo in the Beaglebone. Have a look at: http://dev.gentoo.org/~armin76/arm/beaglebone/install.xml . Feel free to send any corrections my way.

The Beaglebone is a bit different from the devices i got lately, as it lacks video out(well, there’s video out with an LCD connector but i lack an LCD screen), and its pretty simple apart from that. One of the big points of the Beaglebone is the price(89$) and the ability of creating addon boards for it, which are already famous amongst the Beagleboard people.

The specs of the Beaglebone are:
# ARMv7-A 500MHz(USB power)/720MHz(PSU power) TI AM3358/9 ARM Cortex-A8 processor
# 256MB DDR2 RAM
# SMSC LAN8710 Ethernet card
#
# 1x microSDHC slot
# 1x USB 2.0 Type-A port
# 1x mini-USB 2.0 OTG port
# 1x RJ45
#
# Reset and user-defined button

Yes, the processor runs at 500MHz when being powered using the mini-USB port, and 720MHz when using a power supply. More info about the specs in Beaglebone’s webpage.

For those curious as me, here’s the bootlog and the cpuinfo.

All the hardware provided by the Beaglebone works fine, except the USB port. But thats due to a bug in the USB driver used on the Beaglebone. The bug appears when you disconnect the first USB device you connect. Once that happens, the USB port won’t recognize any new USB device.

The workaround is to do:
echo F > /proc/driver/musb_hdrc.1

After that, the USB port will work again. This idea comes from the Angstrom people. In the guide i’ve documented an udev rule to workaround this issue, its from Angstrom as well.

I’d like to thank the people at Beagleboard.org for providing me a Beaglebone to document this. Next step is getting everything upstream

Have fun!

In this post i’ll speak about putting Gentoo on the trimslice.

Months ago the people from Trimslice.com kindly sent me a devkit for the purpose of documenting and supporting Gentoo on it. It took me a while because i’ve had a lot of stuff going on at work, and because Stephen Klimaszewski(steev) started documentating it, but since he doesn’t have time to finish it, i decided to do it myself.

Therefore i’d like to announce the guide for installing Gentoo on the Trimslice. Check it out at: http://dev.gentoo.org/~armin76/arm/trimslice/install.xml and feel free to send corrections to my way, either by mail or by putting a comment on this post.

Regarding the hardware provided by the pandaboard, here’s what i got:
-Audio(non HDMI): Works fine.
-Bluetooth: No bluetooth on the devkit.
-Wifi: No wifi on the devkit.
-SD slot: Works fine
-Ethernet: Works fine
-Video: Works fine

Let me remind you about the overlay for Tegra devices, which includes the video drivers and libraries for Tegra, based on the L4T released by Nvidia.

I’d like to thank the people at TrimSlice.com for their support and the hard work they’re doing with the open source community and dealing with Nvidia for us.

Also, probably you’ve heard about hardfloat graphics drivers for the TrimSlice or Tegra-based devices. They’re real, although Nvidia has said they’ll build them but won’t support them, it hasn’t been clear about the licensing. You can find them on the images of Meego and ArchLinux ARM for the Trimslice.

These hardfloat drivers can be integrated into an image, but the tarball can’t be published as of now. Thats why i can’t create ebuilds for them on Gentoo.

Have fun!

It’s been a long time since i’ve wrote something. I’ve got a lot of things going at work and its taking all the energy from me. However i still spend time with Gentoo on weekends.

Anyway, some days ago NVIDIA published the updated Linux For Tegra(previously known as L4T) Linux development kit. The main difference with the previous one is that it uses a 2.6.38 kernel from the Chromium OS. Another thing is that the stupid nvrm daemon isn’t needed anymore, it was needed before to get audio and cpufreq functionality, and who knows what else. Also, NVIDIA was kind enough releasing the X.org drivers for the GPU in the tegra SoC. It also released them for different ABIs, which is appreciated.

I’ve done the ebuilds for it(it was really easy) and i’ve pushed them to the overlay: http://git.overlays.gentoo.org/gitweb/?p=proj/tegra.git;a=summary
The overlay should be available on layman too.

The ebuilds provide the libraries+drivers for the X.org driver, nothing else as far as i know…

I’m writing this post just to publish some results of benchmarks i’ve done lately on the ARM devices i have. They seem pretty popular, so i guess i could publish them on my blog so other people have it easy to find them.

== memcpy ==

The most popular one is the memcpy benchmark. It was written by a gentoo user and friend Siarhei Siamashka (ssvb is his nick on irc.freenode.net). He published it on: http://sourceware.org/ml/libc-ports/2009-07/msg00000.html
I simply ran it on the devices i have.

You can get the latest results of this benchmark on the devices i’ve been able to run the benchmark on the following page: http://dev.gentoo.org/~armin76/arm/memcpy-neon_result.txt

== Gentoo build times ==

If you’ve read my blog before, you’ll know i have a page where i list the buildtimes of different basic packages(binutils, gcc, glibc and portage) on different kind of machines to compare it. The page is here: http://dev.gentoo.org/~armin76/arm/buildtimes.xml

Unfortunately those results have a problem, i only did a part of them myself, the rest were provided by other people, and as you can see they were using different kind of storage… so last year i decided i could do a new page where all the build times were using the same storage (USB stick), same package versions and same configuration…

The result is this one: http://dev.gentoo.org/~armin76/arm/nwbuildtimes.xml

Hope you find them useful.

Since gcc-4.5.0, the option for a hardfloat toolchain has been available for ARM. I’m not going to duplicate the information about hardfloat on ARM, since its really well explained here: http://wiki.debian.org/ArmHardFloatPort

Summarizing, using hardfloat over softfp and softfloat, provides a better performance. However there is a “problem”. Almost all the devices using ARMv5 processors don’t have VFP, so for the users of those devices it won’t make a difference. With ARMv7 there’s no problem, because as far as i know, there’s no ARMv7 processor which doesn’t have VFP(correct me if i’m wrong).

Anyway, focusing on the Gentoo part, back in July, Siarhei Siamashka (ssvb) bootstraped a hardfloat ARMv7 stage3. For which i’d like to thank him. I worked with Siarhei on getting the changes needed for getting a hardfloat toolchain in Gentoo if -hardfloat- is used in the CHOST, among other things.

Last month i released a hardfloat stage3, so anyone who wants to use it, is free to do so. However keep in mind that since gcc-4.5.0 is not stable(stable is 4.4.4-r2 as of this writing), you need to have this in your package.keywords file, so portage won’t downgrade gcc and diffutils:

sys-devel/gcc
sys-apps/diffutils


You can download the stage3 from here:
http://distfiles.gentoo.org/releases/arm/autobuilds/current-stage3-armv7a_hardfp/

Those stages have been built using:
-CHOST=”armv7a-hardfloat-linux-gnueabi”
-CFLAGS=”-O2 -pipe -march=armv7-a -mfpu=vfpv3-d16″

The “-mfloat-abi=hard” is implied by the hardfloat string in CHOST using the Gentoo eclasses.

Have fun and happy testing!

Update: I forgot to say that binary blobs won’t work with hardfloat if they’re not built using a hardfloat toolchain. That means that if you’re using a video driver(f.ex, pvr drivers for OMAP hw) that is built as binary, it won’t work.

This is the second post on Pandaboard and Gentoo, after the first one with the unpack and specifications. In this one i’ll speak about putting Gentoo on it.

First i’d like to announce the guide for installing Gentoo on the Pandaboard. Check it out at: http://dev.gentoo.org/~armin76/arm/pandaboard/install.xml and feel free to send corrections to my way, either by mail or by putting a comment on this post.

I’d like to thank my coworker Jordi Inglés for providing me an 8GB SDHC to use with the pandaboard.

Secondly here are my impressions about it. Installing Gentoo on it was easy as always, one of the first problems i encountered was that there was no information about what x-loader/uboot/kernel should everyone use, as the vanilla kernel.org doesn’t work yet(or thats what i’m being told).

After i found the correct/updated x-loader/uboot/kernel i was able to boot gentoo on it, using 1GB of RAM. After doing some heavy compiling, for example when building gcc, i encountered random segfaults and sigbuses. Of course, this wasn’t documented either(Ubuntu is not Linux). There’s a bug in the kernel for the pandaboard, which gives those issues when using more than 716MB of RAM, check this link.

Regarding the hardware provided by the pandaboard, here’s what i got:
-Audio(non HDMI): Works fine with an updated kernel
-Bluetooth: Needs external tools to be able to use it.
-Wifi: The pandaboard uses a TI WL1271, but the driver in the mainline kernel doesn’t support the pandaboard yet. For now you need to use an external driver and external tools(to load the firmware) which i haven’t been able to do yet.
-Video: Haven’t had time to test it, obviously needs an external driver for full acceleration.
-SD slot: Works fine
-Ethernet: Works fine

Regarding the buildtimes, i compared it with the other Cortex A9 hardware i have, which is the Nvidia Tegra2 devkit. I used an 8GB USB stick(with an ext2 filesystem) to do the “benchmarking”, using the same stage3 and portage snapshot on both boards. The results are the following
-glibc: 1h24m <- the tegra was 13 minutes faster
-gcc: 2h6m <- the tegra was 15 minutes faster
-binutils: 12m7s <- the tegra was 5 seconds slower
-portage: 1m10s <- the tegra was 8 seconds faster

Also i'd like to announce the pandaboard overlay, for all the stuff needed to use the hardware integrated in the pandaboard. Please keep in mind that for now i've only got bluetooth to work.

Have fun!

Like i did with the Nvidia Tegra2, i’m going to talk about the Pandaboard which i received two days ago.

The story begins at late september, once the brand-new Pandaboard got announced. Before it was announced how much it would cost and before you could buy it, the Pandaboard Early Adopter Program (PEAP) was available. This program allowed(the two phases are now over) developers to submit their project and be allocated a Pandaboard if the project was among the most voted ones. The first phase selected the top5 projects and the second one the top10.

I submitted my proposal for the first phase, and luckily enough my project and another one were tied with 5 votes, which was the maximum any project achieved.
My project is mainly about documenting the installation of Gentoo on the Pandaboard and provide everything needed to install it. Also to help users install it as well. After i have done everything, the board will be used to test/build packages and keep testing new kernels/applications made by OMAP developers.

Let’s go with the specs. The Pandaboard has a OMAP 4430 Dual-Core ARM Cortex-A9 processor @ ~1GHz, 1GB of DDR2-800(400MHz) RAM, audio input/output, Bluetooth(through TI WiLink 6.0 solution), 802.11b/g/n Wi-Fi(through TI WiLink 6.0 solution), 10/100Mb USB-based ethernet(SMSC LAN95xx), HDMI, DVI-D(using an HDMI port), 2 USB ports, 1 USB OTG port and 1 SD slot. You can expand the specs in their official webpage: http://pandaboard.org/content/platform

One of the things i should add regarding the specs, is that there are two revisions publicly available to the board: the EA1 and A1. The EA1 are the boards that were available through the PEAP program i talked above, the A1 are the ones that you can buy. The difference between them is that the EA1 boards use 2.0 silicon and the RAM is clocked at 200MHz(DDR2-400). The A1 boards use 2.1 silicon and are clocked at 400MHz(DDR2-800). That means that you can’t compare any benchmark i can do, since the RAM of my panda is slow compared with a panda you can buy, which after all is the real product.

Here’s the cpuinfo:


Processor : ARMv7 Processor rev 2 (v7l)
processor : 0
BogoMIPS : 2013.49

Hardware : OMAP4430 Panda Board
Revision : 0010
Serial : 0000000000000000


dmesg is here

For more information you can check the official webpage and the wiki page made available for it. Until i create the documentation for installing Gentoo, you can install either Ubuntu, Android, or a minimal Angstrom distribution following the instructions in the wiki. Obviously you can also install Gentoo by yourself

Have fun!

Keeping with the previous post, i’m announcing the following changes for ARM stage3s.

The optimization flag on the default CFLAGS/CXXFLAGS will be changed from -Os to -O2 as of this month stage3.

This is a change we’re doing so we don’t hit bugs undiscovered until we hit them like bug 331641 which only ocurred when using -Os and was reported by Gentoo users. Also that way we use the same optimization flag used on the rest of the arches and distributions.

If you still want to use -Os you’re free to do so, like whatever CFLAGS you want to use.

From this month(October) the default ARMv7 CFLAGS/CXXFLAGS used to built ARMv7 stages are going to change from:
CFLAGS="-Os -march=armv7-a -mfpu=vfp -mfloat-abi=softfp -pipe"
to
CFLAGS="-Os -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -pipe"

The vfpv3-d16 option was included in gcc-4.4, and since thats what its stable, we’ll change the CFLAGS. This doesn’t affect current installations, but users are recommended to change their CFLAGS and rebuild the system.

Of course like always you’re free to use any other CFLAGS that suit better your system. You can use vfpv3 or neon if your system has those options. Those CFLAGS i mention is just for the armv7a stages we build, which target the “worst” possible armv7 processor.

In gentoo we support 13 different architectures: alpha, amd64, arm, hppa, ia64, m68k, mips, ppc, ppc64, s390, sh, sparc and x86. Although amd64 and x86 are the most common and popular, they are only 2 architectures of the total 13 we support, so i thought i could write about the rest of the architectures and their status on Gentoo.

I’ll do it in parts because i’ll get burned out too easily!

I think its sad to see a lot of that architectures that were so popular being discontinued, but i guess thats whats the progress is about The main problem of arches getting discontinued is that the hardware is slow compared with new hardware, less users because they replace their old alternative architecture computer with an standard amd64/x86 PC. That makes that there’s less users of said architecture, which makes less interesting for linux distributions to support them, then there’s no developers…and then the architecture really dies. IMHO its sad, but thats the way it is.

Alpha

The alpha processor was phased out by Compaq in 2004, being replaced by ia64. That means that you can’t buy any new hardware that has alpha processors(as to my knowledge). Of course there is some alpha hardware that wasn’t ever used, so you can say there is ‘new’ hardware, as in unused, but there’s no alpha processor manufactured after 2004. There were both workstations and servers.

The alpha status on Gentoo is good, there is three developers on the team: Tobias Klausmann (klausman, Blackb|rd on IRC), Matt Turner (mattst88) and myself. There was a lot of distributions supporting alpha back in 2001, when alpha was well and alive. But as of today, Gentoo is one of the few distributions that support it officially(guess we’re crazy ).

AMD64

Well, i don’t think i need to comment on this one…

ARM

ARM is one of the architectures that its level of activity is the same as amd64/x86 thanks to its fast-growing use on embedded devices. You can even find notebooks with ARM processors(called smartbooks), phones and NAS(Network Attached Storage) running Linux, WinCE and Android. Everytime they are getting more powerful, at the moment you can find dual-core processors at 1GHz, and thats not going to stop.

The status of ARM on Gentoo is good. We’re five developers: maekke, xmw, dagger, vapier and me. Also there are some users on #gentoo-embedded(irc.freenode.net) which are really helpful. We provide stage3s for a handful of CHOSTS: armv4l, armv4tl, armv5tel, armv6j and armv7a. Which covers most of the devices available. One of the bad things of ARM is that every device available is almost completely different, that means we can’t have install guides of each device if we don’t have the device itself…

HPPA

HPPA is another of the dead architectures that we support at Gentoo. It was an architecture designed by HP, and was phased out in 2008. It was replaced by ia64 as well. There was both workstations and servers.

The status on Gentoo is good. There is two developers: jer and GMsoft. I can’t speak too much about it because i’m not in the team, but i know its supported and doesn’t have too many issues(at least gentoo-related).

Hope you liked the first part