I posted this a month ago on my blog, it doesn't hurt to repost it here so it shows my project is still alive.

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:


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.

Hi,

Its been a while since i wrote something, therefore some things happened :)

- First i bought an USB HDD enclosure for using a SATA2 500GB HDD i used on another ARM board, but that board died 6 months ago, therefore the disk was unused. With so much space, i was now able to build a lot of stuff.

- I finally released the ARMv6J stages(although those aren't optimized for the Efika MX). I also kept building the ARMv7A monthly stages(which are optimized for the Efika MX).

- I created the ARMv7A and ARMv6J binary repositories. Both stable and unstable, so Gentoo users and developers from other distributions may use our binaries.

- Jeremy Olexa did a nice job with the documentation for installing Gentoo on the Efika MX. Try it out!

- I've been running the Efika MX non-stop since I got it, with no issues. Here's a sysinfo:
Hostname: efikamx - OS: Linux 2.6.31-ER1/armv7l - Distro: Gentoo 1.12.13 - CPU: ARMv7 rev 1 (v7l) - Processes: 136 - Uptime: 72d 15h 40m - Users: 5 - Load Average: 1.37 - Memory Usage: 147.23MB/470.49MB (31.29%) - Disk Usage: 36.55GB/461.23GB (7.92%)

- I also worked on getting Chromium to work on the Efika, here's the history: http://armin762.wordpress.com/2010/01/19/google-chromechromium-keyworded-armthe-definitive-post/

So, from the list i did on the last post:
Whats left to do:
-Document it <- done by Jeremy Olexa
-armv6j stages <- done
-Play with CFLAGS <- no time, will be the next thing i'll do, i guess
-binary repositories for tinderboxing <- done

Hello everyone,

Finally we have the ARMv7 stages available, you'll find them your favourite mirror, under the releases/arm directory.

These are possible thanks to Genesi USA's Powerdeveloper.org project. I filed a request for getting an Efika MX to port Gentoo to the ARMv7 architecture, and i received the board last week. So thanks to them for helping us, like they've done in the past.

The stages are built with the following CFLAGS/CXXFLAGS:
"-Os -march=armv7-a -mfpu=vfp -mfloat-abi=softfp -pipe" and the armv7a-unknown-linux-gnueabi CHOST.
I know in the -mpfu parameter i can use neon, but the Marvell Dove ARMv7a implementation doesn't have the NEON fpu.
I've also updated my buildtimes page with the info of the Efika MX.

Whats left to do:
-Document it
-armv6 stages
-Play with CFLAGS
-binary repositories for tinderboxing

Let me know if you have any suggestion.

Hello everyone,

I got the board on Monday finally, although i wasn't at home until wednesday. I haven't done too much as of now, as I was fighting with it until late yesterday, when i started building Gentoo on it. I'll write here the issues i encountered:

-First, the U-boot included doesn't support tftpboot, which means i need to put the kernel on a storage device. Guess i rely to much on the network :) I've been told this is due that the ethernet card is USB-based, and U-Boot doesn't support that very well.

-Second, I can't have the root filesystem on NFS: The 4GB on the SSD are a bit short for me :) And even when i tried using it, I ran out of inodes. Since the ethernet card is USB-based it takes some time to initialize it, that means that the kernel is unable to configure the ethernet card as it configures it before it is initialized. It's something like USB storage devices, however with those you have the rootdelay parameter, but i haven't been able to find something like that for the ip configuration of the kernel for the NFS root. PS: for trying this i had to recompile the kernel including the NFS module as built-in, so the NFS root function could work.

-Third, USB is slow. After giving up on the two things above, i tried booting it from an 8GB USB stick, containing an armv5tel stage3. Either the USB transfer is really slow, or its due to the armv5tel stage... I gave up on this one as well.

At the end i've done the following:
-Boot the installed ubuntu
-Mount through NFS an HDD on another machine
-Extract an armv5tel stage3 on NFS and rebuild world with the following options in make.conf:

CFLAGS="-Os -march=armv7-a -mthumb -mfpu=vfp -mfloat-abi=softfp -pipe"
CXXFLAGS="${CFLAGS}"
CHOST="armv7a-unknown-linux-gnueabi"

That's what its doing now.

More stuff soon

Hi!

So finally i got approved! I hope i get the board soon and start building stuff for it and documenting it as well, as i've done with everything i've got for those purposes.

I'm really happy to get approved because that means we will be able to build armv6/armv7 stages the users have been asking for, and offer support for the Efika MX Smartbook users once it gets released. Using an armv7-optimized stage on the Efika MX will make you be able to use all the exclusive CPU instructions the armv7 subarchitecture is able to provide regarding performance.