thanks to Genesi USA Inc i'm going to take part in this wonderful ARM Power Developer project with a CRUX/ARM .
Since, here, a lot of you are already Efika MX developers/users from a good amount of time i'd like to know the actual state of the art and receive some hints...

linux kernel:
i just downloaded a vanilla linux-2.6.29-rc5 and i saw i.MX515 and Efika MX (both models) are quite good supported and from a quick review i only noticed pata and video drivers as vital missed parts.
Is there an overlay to get patches to use with an official linux kernel?

toolchain:
it seems the best choose is gcc-4.6.x and (e)glibc-2.13.x .
Is there some good technical reasons to choose eglibc? I say something like Neon optimized code or some "option group" that could build lighter 'n faster binaries.
E.g. LIBM_BIG if there is no reason to rely on precise floating-point math... anyway what's about CORTEX-A8 (fp double precision) and NEON abilities??

And again... as the best option seems to be -mfloat-abi=hard and -mabi=aapcs but what happens if in the next future there will be released an "arm generic" closed binary (i can think to skype or adobe flash player)? Shell we be unable to use them?

And again... is arm-unknown-linux-gnueabi the universal ABI name for the armhf build too ?

And again... -mfpu=neon -funsafe-math-optimizations is it enough stable to build a distro?

bzip2,xz,openssl,fftw and others:
is there some i.MX5 optimizations?

OpenJDk/IcedTea and OOo/LibreOffice:
are they capable to successfully finish a "native" build?

xorg:
what's about libdrm,mesa3d,xf86-video-imx ?


thanks,
--nico

_________________
acrux _at_ linuxmail _dot_ org

Please try and use the Linaro compiler. There is no point leaping to gcc 4.6 right now or you're going to live in the land of being completely unstable half the time.

The recommended C compiler flags are basically, if you are concerned about running on other systems:
Patching for Thumb might be a lot of work for some packages (although it's being done in Ubuntu and Debian right now) so you may want to get rid of the -mthumb for a quick port.

You can drop "-d16" if you do not care if it fails to run on any Marvell, Tegra etc. (because they do not support NEON, either.. :)

For quick Efika MX-and-Beagleboard-only-don't-care-about-any-weirder-ARM-implementations your best bet is
This will, as I said, work on any "true" Cortex-A8 or Cortex-A9, and Qualcomm Snapdragon, but you will cut out Tegra etc. or any ARMv7 variant that only executes Thumb2 code (in reality though building for armv7-a implies that they will not work, though).

I forget the argument for hardfloat. -mfloat-abi=hardfp I think? That's going to cause some build problems with a lot of core packages too.

The unsafe-math-optimizations is really dangerous to use. Only very specific software should have this enabled where precision and availability of rounding modes is not a primary concern. For glibc this will completely break floating point math in very subtle ways..

Anyway I'll leave my comments for now, I have asked someone with far, far more experience to basically correct me and answer your questions :)

_________________
Matt Sealey

This is indeed the right choice right now -or at least it's the choice made for Debian armhf. We used for a almost a year gcc-4.4 (with Linaro branch), then switched for a very short period to gcc-4.5, but now that Debian (and Ubuntu) is switching altogether to gcc-4.6, we will follow that switch as well. This means that we won't be using the Linaro branch, but rather the FSF 4.6 tree by default -which includes the hardfloat changes. Regarding eglibc, yes, it's definitely worth switching to it, ignore plain glibc, at least you'll have much better chance to push your patches in, and not have to worry about dealing with Drepper at all. Right now it fails on armhf here, but it's something we'll fix asap.
Once we'll have a respectable userbase for ARM hardfloat distros, skype, flash and other closed-source binaries, will definitely follow suit. You can be certain this will happen, as Ubuntu have announced a migration is taking place as we speak, Meego is already hardloat, Fedora also, Gentoo -and of course let's not forget Debian :)
The "official" triplet for hardfloat -ie the one that has been decided by both dpkg and upstream gcc maintainers is arm-linux-gnueabihf.
I don't think so, and I wouldn't advise it. For one thing, both NEON fpu math and -funsafe-math-optimizations, are known to break IEEE754 floating point accuracy. It's possible that some packages will break if the accuracy is not the one expected, I'm pretty sure some testsuites will break. OTOH, on some selected libraries it would make sense.
Debian armhf uses -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb, by default.
For iMX515, that can either mean a) NEON optimizations, or b) security optimizations using the SAHARA unit. For both meanings though the answer is no :(
Though we are planing to do a /dev/crypto implementation for the SAHARA unit, which will at least be used by openssl. It won't be much faster, but it will at least offload the cpu from crypto stuff.
OpenJDK needs to be bootstrapped first, for that to happen, it needs a working java compiler to exist, in our case it needs gcj/gij. This one builds, but it fails to run any java code (it's a known issue with libffi, libffi has been fixed to cater for hardfloat now, but there was a change in the API and we need to fix gcj/gij as well to work with the new API).
all those should work/build for hardfloat, *but* there would be no 3D support yet, at least not until one particular static library available from Freescale/AMD is built and released using a hardfloat ABI.

ok, thanks for your replies.

Thus as i can understand...

The right triplet is arm*-*-linux-gnueabihf and my choice of arm-unknown-linux-gnueabihf is good too.
It seems i'll be able to use gcc-4.6.x, (e)glibc-2.13.x and binutils-2.21.51 but nobody still tested PPL and graphite loops.

Neon SIMD use is restricted to multimedia only to avoid to break IEEE stuff altought fftw is able to benefit if included a cycle counter.
But is there a way to understand (a kind of wrapper to put somewhere) to understand if a SoC has a builtin Neon unit ? On ppc we use to grep the well known /proc/cpuinfo.

There isn't yet a free accelerated video drivers.

But what about linux kernel patches? Where are they committed untill they go on official linux git?

cheers,
--nico

_________________
acrux _at_ linuxmail _dot_ org

If NEON is present, it shows up in /proc/cpuinfo

Trimslice (no NEON):

trimslice ~ # cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 1992.29

processor : 1
BogoMIPS : 1998.84

Features : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x1
CPU part : 0xc09
CPU revision : 0

Hardware : trimslice
Revision : 0000
Serial : 0000000000000000


EfikaMX (NEON support):

efikamx:~$ cat /proc/cpuinfo
Processor : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 799.53
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc08
CPU revision : 5

Hardware : Genesi Efika MX (Smarttop)
Revision : 51030
Serial : 0000000000000000

_________________
Steev Klimaszewski, Genesi USA Inc.
Senior Software Engineer

Just don't grep /proc/cpuinfo inside code..

Your libc needs to present something like HWCAP_ARM_NEON and that is how you determine if you are in the right place or not. This is the exact same way you'd look for AltiVec.

http://freevec.org/function/altivec_run ... tion_linux

You can see what's there with:
Don't count on it ever happening either.
This is our 2.6.31 branch: http://gitorious.org/efikamx/linux-kernel

When we bump to 2.6.35 we'll go to http://github.com/genesi/linux-kernel (github is more stable)

When we bump to 2.6.38 it'll stay at that URL. That's planned for about August.

We don't do a great deal of mainline work here because it means losing about half an SoC worth of functionality. When mainline catches up - and this is Freescale's responsibility, not so much ours - we will actively maintain a git repository against it.

I don't think you will notice for now though, feel free to bug Steve personally (on IRC or something) about mainline.

_________________
Matt Sealey

ok, thanks again for your kind replies. Now i've a good knowledge for my project.

I've just today received my EfikaMX machines and I've another question... i received a debug board for each smarttop but where can i find a debug board (with flat cable connector) for the Netbook ?

_________________
acrux _at_ linuxmail _dot_ org

Hi acrux, the truth is, we are out of stock. We did not forecast the demand properly and we did not build enough. Unfortunately, it did not make sense to produce another batch of smartbook debug boards for the amount of inventory that remains (taking the cost and minimum number of units required for production). While the same software we ship today is continuously and progressively developed we will transition from the imx51 to the imx53 smartbook in the months ahead.

We are certainly pleased to have the Crux team join us from the old Efika and PowerPC to the new Efika MX and ARM. Benvenuti!

R&B :)

_________________
http://bbrv.blogspot.com

Sorry to go off topic, please tell me to make a new thread if you think that's better, but I'm very interested in this comment. Could you elaborate on it?

Why do you think this might never happen?
Patent issues? Cross-licensing issues in the code?

Are you referring to the current, proprietary 3D drivers not becoming open source (that *does* sound unrealistic), or are you saying that it's improbable that a GPU-company will ever release the documentation required to develop a new, working open-source 3D driver?

I think likely the second. PowerVR are extremely unlikely to ever release documentation for anything. Even with docs, it'd take a long time, look at radeon drivers.

Freescale's mx5x is not using Imagination IP, but your general statement still stands.

Reading the comment again, I can see Matt didn't say that *no* company was ever going to release documentation on their GPU. For some reason I just took his comment to mean that. Considering that is what he said I'd agree - I don't think any of the big players are going to release documentation on their chips.
It seems to me that it takes a smaller company that doesn't have as much to hide as the larger ones.

Also, AMD/ATI's progress on their open drivers aren't exactly encouraging to other GPU companies. I mean, the drivers work, fairly well (I use them), but are missing some features and a lot of speed compared to the proprietary ones.
I'm not sure how much easier it would be to develop and OpenGL ES driver though. If it's any simpler.

The Big Players would include Imagination Technologies (PowerVR), ARM Holdings (Mali) and Qualcomm (Adreno), right? Are there more?
And are there any "small players"?

thanks anyway! As it's a really important stuff i'll try to build a cable by myself if i'll found a compatible flatcable. Therefore are debug boards for the upcoming imx53 smartbook different?

Two EfikaMX Smarttops are going to Spain to support the former CRUX/ARM team:
http://crux-arm.nu/Main/Donors
and EfikaMX will be soon an officially supported platform by CRUX ARM 2.7-test1 (gnueabi and softfloat).
There already is a lot of work on hardfloat & thumbee switch over.



Looking on the boards... i see that deepswitches are now disabled i.e. when i tried to move it to boot directly from SDHC the smartop simply doesn't switch on. Is it right?

_________________
acrux _at_ linuxmail _dot_ org

your imx53 and imx6 boards use Mali 200/400 dont they ?

so are you going to sling a board and support network to libv http://phoronix.com/forums/showthread.p ... post248694 to help him make their reversed engineered Open Mali Gpu driver better, aka the Lima-Open-Source-GPU-Driver

"Lima: An open source graphics driver for ARM Mali GPUs

Lima is an open source graphics driver which supports Mali-200 and Mali-400 GPUs.

The aim of this driver is to finally bring all the advantages of open source software to ARM SoC graphics drivers.

Currently, the sole availability of binary drivers is increasing development and maintenance overhead, while also reducing portability, compatibility and limiting choice.

Anyone who has dealt with GPU support on ARM, be it for a linux with a GNU stack, or for an android, knows the pain of dealing with these binaries. Lima is going to solve this for you, but some time is needed still to get there."

http://www.phoronix.com/scan.php?page=a ... erse&num=1
"This open-source stack is coming by reverse-engineering ARM's official Mali GPU driver, which they thought was an impossible feat.

The reverse-engineering has been sponsored by Codethink for the past several months by Luc Verhaegen, the often controversial X.Org developer (for his radical ambitions) and former SuSE developer.

Verhaegen is the one responsible for the VIA "Unichrome" X.Org driver stack, was one of the SUSE developers responsible for much of the efforts on the RadeonHD driver, a Flashrom contributor, then a Nokia contractor, and for the past few months has been doing Mali reverse-engineering as his latest project at Codethink."


perhaps Genesi can even help them get that Lima into linaro proper as an official supported FLOSS beta Gfx driver to try and get it usable in the shortest time frame in return for some good PR

Hi.
No, the i.mx53 has an AMD GPU and the i.mx6 uses one from Vivante.


Johan.

_________________
Johan Dams, Genesi USA Inc.
Director, Software Engineering

Yep, I have a blog... PurpleAlienPlanet