ARM status @ Gentoo

Since we started 2010, i thought i could explain what we have now on the ARM camp @ Gentoo.

(WARN: long post)

I started playing with the ARM stuff on Gentoo back in September 2008. Gentoo already supported ARM since the first days, around 2003. Until i joined the ARM team, there was only binary repositories and stages for armv4l-unknown-linux-gnu. That made us a bit outdated, as the other major ARM distro, Debian, was using the new ARM EABI, deprecating the old one.

I saw that apart from the famous NSLU2 which was a bit outdated for 2008 and the Rebel Netwinder which doesn’t support the new ARM EABI(due to its processor), Debian was supporting new devices with the Marvell Orion SoC. I thought that would be a good starting point, as it was used on NAS devices, replacements of the slow NSLU2. That SoC is used in devices from QNAP , Buffalo… Another SoC was the Intel IOP, which devices like the ones from Thecus were using. Both SoC along with the one in the NSLU2(Intel IXP4xx) were based on the ARMv5TE architecture.

I contacted Thecus regarding a hardware donation to make Gentoo work on their devices. Unfortunately Intel was EOL’ing its IXP4xx, and so was Thecus, therefore support for a device which would stop selling in weeks wasn’t very appealing.
I then looked at the Marvell Orion SoC and i decided to contact QNAP, since they also supported Debian. They agreed to provide us a QNAP TS409, which I received and started working on it as soon as I bought a SATA HDD. That made possible that we release armv5tel-softfloat-linux-gnueabi and armv4tl-softfloat-linux-gnueabi stages along with binary repositories, which could be used on all the devices i mentioned above. Along with the documentation for using Gentoo in the TS409. Later I blindly documented the installation for the TS109/TS209, since the TS409 was a bit expensive and users bought either the TS109 or TS209.

Later in March 2009, thanks to Marvell we got an also famous and NSLU2-killer Marvell Sheevaplug. I also documented the installation on the device(pretty much the next week after i received it!), meaning that it was the first distribution to support it officially.

Unfortunately, all the devices we got were only ARMv5TE, meaning that we couldn’t provide ARMv6 and ARMv7 stages nor binary packages. The latter were the important ones due to the popularity of the BeagleBoard among embedded enthusiasts.

On August 2009, the TS409 board broke. Since I got it, it always had an issue that it took a bit to get it booting(as in the processor didn’t initialize). I found a workaround, that it was simply putting weight on the processor. I’ve been told by some engineers (*NOT* from QNAP) that it was due to bad soldering, and that i couldn’t do anything to fix it since that mean resoldering all the processor. I also wasn’t able to do it, as I don’t have the knowledge nor the tools. This workaround meant that if the board got moved(I had it at home), it would hang. At the end this workaround got worse, and it stopped working. I contacted QNAP about it and to see if they would like us to support their newer devices based on the SoC used in the Marvell Sheevaplug. I’m still waiting an answer since September 2009. I didn’t even got a “No, we’re not interested”(and i’ve insisted three times).

That meant that we were unable to build the monthly autobuilt stage3, as catalyst(our stagebuilding/release tool) doesn’t work over NFS(/me kicks agaffney). And I had the Sheevaplug working through NFS-Root as i didn’t have any USB HDD. I only had a now unused SATA HDD i bought for the QNAP.

Fortunately, Marvell donated us a Marvell Discovery Innovation MV78100 board(Debian and Ubuntu had boards as well). I would like to say a big THANK YOU to them for their support, and their engineers as well. That would allow us to resume our work on stagebuilding and binary repositories. Also we could build armv4l stages, since the processor on the QNAP board i got had an errata that made it hang when using old ABI binaries, which obviously made impossible build stages for it.

As I commented in other blogpost, we we’re looking for ARMv7 hardware(and we still are, i’m not the only one on the ARM team), to allow us building of stages and binary repositories for the upcoming ARM-based netbooks/smartbooks that use the ARMv7 processor. Some people were already building their own stages, like the Neuvoo project(previously known as gentoo-pandora) and the Gentoo on the N8x0 project, building stages and binary repositories for ARMv7A and ARMv6J respectively.
However those aren’t official projects and to be honest, its not fun having users to report bugs that only happen on armv6/armv7 and you can’t reproduce them to fix them as you lack the hardware. And *NO*, qemu isn’t a solution. If the users are using real hardware, the devs should too.

Thanks to Genesi USA we now have an Efika MX through their program which is capable of building the stages and binary repositories. Also a big THANK YOU for them too!

Thanks to all the history i wrote above, we now have the following binary repositories and monthly autobuilds of stage3:

  • armv4l-unknown-linux-gnu
    The minimal CPU, this stage and binary repositories are designed to work on the Rebel NetWinder and other devices having an ARMv4 processor, which is only capable of running the old ABI. Nevertheless it should work on newer CPUs.
  • armv4tl-softfloat-linux-gnueabi
    This CPU is present on the OpenMoko FreeRunner, which by the way there are a lot of users using Gentoo on their FreeRunner. It uses the new ARM EABI and uses software floating point by default.
  • armv5tel-softfloat-linux-gnueabi
    This CPU is present on probably all the NAS devices that use an ARM CPU. It uses the new ARM EABI and uses software floating point by default.
  • armv6j-unknown-linux-gnueabi
    This CPU is used on the Nokia N800, Nokia N810 and Smart Q7, along with other multimedia devices. It uses the new ARM EABI and uses hardware floating point by default, since AFAIK all the ARMv6+ CPUs have VFP.
  • armv7a-unknown-linux-gnueabi
    This CPU is used on the OMAP-based devices(Beagleboard, IGEPv2, Devkit8000, AlwaysInnovating Touchbook, Nokia N900…), Freescale i.MX515-based devices(like the Efika MX, Babbage Board, Lange Board…), Marvell Dove/Armada, Samsung S5PC100-based devices, Qualcomm Snapdragon-based devices…

And i believe thats pretty much it. Hope you had a fun read šŸ™‚


4 Responses to “ARM status @ Gentoo”

  1. Eric Says:

    It’s really great to see so many official stage3s. Thank you so much for all of your work!

    I am thinking of getting either a Sheevaplug, IGEPv2, or Efika MX for light desktop use, mostly web and email. With all of your experience would you suggest getting the higher clocked armv5 or a newer armv7 based board?
    The lack of video on the Sheevaplug doesn’t matter as I plan to use a displaylink based usb adapter anyway.

    • armin762 Says:

      Hi Eric,

      Well, the Sheevaplug is pretty powerful, but it lacks sound and video.

      One of the main cons of the Sheevaplug is that you won’t be able to run Ubuntu on it. And afaik it comes with ubuntu preinstalled.

      That simply means that an ARMv5TE is old as of now, at least in the desktop market. Since i now have an armv7 board i’ve seen(or started to care) that some packages start to offer enhanced performance on ARMv7 processors. Even if the Sheevaplug is able to compile faster, i believe you prefer better runtime performance. Which those CPU instructions on the ARMv7 processors would help.

      Please note that the video on the Efika MX doesn’t work as of now.

      Nevertheless there are some videos on youtube of a guy who has a sheevaplug working as a desktop.

      Buying an ARMv7 board is looking to the future.

      Hope that helps šŸ™‚

  2. TuX Says:

    Try putting one of those little candles with a metal base on the CPU. Light it & wait until it gets very hot. This may re-join any faulty solder connection.

    • Christopher Friedt Says:

      @ TuX :

      That’s actually a pretty god idea. I would have suggested to desolder any components with plastic parts and then toss it in a toaster oven, but your suggestion avoids the desoldering / resoldering entirely šŸ˜‰

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: