Archive for January, 2010

armv4l/armv4tl/armv5tel/armv6j/armv7a January 2010 stages released

January 24, 2010


Hello everyone,

Just wanted to let you know that the following stages for this month have been built and released and are available on the mirrors:

  • armv4l-unknown-linux-gnu
    For the Rebel NetWinder, HP Armada 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
    For the OpenMoko FreeRunner and other devices using an ARMv4T processor. Uses the new ARM EABI and software floating point by default.
  • armv5tel-softfloat-linux-gnueabi
    For almost all ARM NAS, devices based on the Marvell Orion and Marvell Kirkwood, Marvell Sheevaplug, Marvell OpenRD, QNAP TS109/TS209/TS409/TS119/TS219/TS419, Buffalo Linkstation/Kurobox PRO, HP mv2120, HP iPAQ, Linksys NSLU” and other devices using an ARMv5TE processor. Uses the new ARM EABI and software floating point by default.
  • armv6j-unknown-linux-gnueabi
    For Nokia N800/N810, Smart Q7, OMAP2-based devices and other multimedia devices using an ARMv6 CPU and VFP. Uses the new ARM EABI and hardware floating point by default
  • armv7a-unknown-linux-gnueabi
    For OMAP3-based devices(Beagleboard, IGEPv2, Devkit8000, AlwaysInnovating Touchbook, Nokia N900), Freescale i.MX515-based devices(Efika MX, Babbage Board, Lange Board…) Marvell Dove/Armada and other devices using an ARMv7-A processor. Uses the new ARM EABI and generic(not NEON) hardware floating point by default

You can find them on your favourite mirror or clicking on the links above.

=kde-base/kdebase-meta-4.3.4 keyworded ~arm and Qualcomm MSM7201A ARMv6 processor

January 23, 2010

We now have kde-base/kdebase-meta keyworded on ~arm.

That would give you an enough KDE desktop. Its not the same as a full KDE, but since we lack manpower for keywording everything arm and then stabilize it…this is what we can give you meanwhile. We hope to have it stable soon, probably once 4.3.5 is stabilized(and released first) on the rest of the arches.

And to not make this entry so short, i’m going to write about the Qualcomm MSM7201A ARMv6 processor which you can find on the G1/HTC Dream PDA, and maybe other some devices.

The other day a Gentoo user came at #gentoo-embedded( saying that he couldn’t run the armv6j stage we published, on this G1 Dream, he reported “Illegal instruction”. That was kinda weird, since i thought that all the ARMv6 processors(or those being announced as ARMv6-compliant) had VFP. A quick search around the interweb returns that Android devs had the same issue.

So if you plan to use Gentoo on your HTC Dream or any PDA or device having said Qualcomm processor, you’ll need to use an ARMv5TE stage which has softfloat by default. I don’t plan to build softfloat ARMv6 stages unless there’s a need for it, and this just has been the only case…

I hope the smartbooks/netbooks based on the Qualcomm Snapdragon doesn’t lack VFP as well.

Google Chrome/Chromium keyworded ~arm(the definitive post)

January 19, 2010

If you’ve followed my blog lately, you’ll remember that i played with chromium on ARM. First i had some issues with javascript not working…turns out that it was an v8 issue that doesn’t seem to work on ARMv5TE and lower. Then i had it working perfectly with ARMv7 and failing to build on ARMv5TE.

I’ll write the result of all the tests a bit later on this post, first let me post some images two users have sent to me.

The first is from the user slonopotamus that runs the Gentoo on the N8x0 project, running obviously on his Nokia N800(armv6j).

Chromium running on the N800 under Gentoo (Picture by slonopotamus)

The second is from the user javaJake from the Neuvoo project, a screenshot of Chromium working on a BeagleBoard(armv7a) running Gentoo.

Chromium running on a BeagleBoard under Gentoo (Pic by javaJake)

So now let me explain what i found out with all this issues.

On an ARMv5TE system we can build the chromium browser while disabling the v8 build. However as i pointed out on the first post about Google Chrome, all pages that use javascript didn’t work. Enabling the v8 build on an ARMv5TE system makes it fail to compile, as i pointed out on the second post :)

On an ARMv6J or newer(ARMv7-A) system, it works with and without building v8. Both javaJake and slonopotamus confirmed this to me, as you can see from their screenshots. I was unable to test it on the Efika MX until i finished the stagebuilding.
There was a small problem and that was that if you enabled v8 build, it failed because it tried to use -m32 in the CFLAGS, which won’t work on ARM. But i think that’s been fixed. I wrote about it on the second post.

And that’s pretty much it…after that and finding out that chromium *WON’T* work on <ARMv6J, i keyworded it ~arm.

Google Chrome(chromium) on ARM: the return

January 7, 2010


So as i posted previously,

i got to build www-client/chromium on ARM. However all the javascript-enabled webpages didn’t work. That was because we(us and Ubuntu) we’re disabling v8 building, which as you may know, its chromium’s javascript engine. So obviously javascript wouldn’t work.

So it was easy to enable it, but there was two problems. For some reason, there’s some parts of the v8 code that forces to use the -m32 flag, which is for building 32bits binaries on 64bits systems. ARM is 32bits, so that flag doesn’t exist. To be honest i’m not sure what its doing there. Maybe i’m not getting the logic of it. If you build stuff for arm on a 64bits system, you need to use a crosscompiler. That ARM crosscompiler AFAIK doesn’t support -m32. However for compiling for x86 on a amd64 system you don’t need a crosscompiler, but you need to use -m32, am i wrong? Then i don’t see the point on using that…
Anyway, the bugs are filed upstream: here and here. Meanwhile in the 9999 ebuild i’ll apply a hackish patch.

The second problem is that the build of v8 on armv5te segfaults:

g++ -Os -march=armv5te -pipe -Os -march=armv5te -pipe -pthread -fno-exceptions -Wall -D_FILE_OFFSET_BITS=64 -O0 -g -fno
-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -DENABLE_LOGGING_AND_PROFILING -DENABLE_DEBUGGER_SUPPORT -D__ST
CHECKS -Iv8/src -MMD -MF out/Debug/ -c -o out/Debug/
rc/mksnapshot.o v8/src/
g++ -Wl,-O1 -Wl,-O1 -pthread -rdynamic -o out/Debug/mksnapshot -Wl,--start-group out/Debug/
ksnapshot.o out/Debug/ out/Debug/ -Wl,--end-gro
up -lrt
export LD_LIBRARY_PATH=/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Debug/
/www-client/chromium-9999/work/chromium-9999/out/Debug/$LD_LIBRARY_PATH; cd v8/tools/gyp; mkdir -p /var/tmp/po
rtage/www-client/chromium-9999/work/chromium-9999/out/Debug/; "/var/tmp/portage/www-client/chromium-9999/w
ork/chromium-9999/out/Debug/mksnapshot" "/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Debug/"

# Fatal error in v8/src/arm/, line 1795
# CHECK((instr & (7*B25 | P | U | B | W | 15*B16 | Off12Mask)) == (2*B25 | P | U | pc.code()*B16)) failed

/bin/sh: line 1: 26922 Aborted "/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Debug/mksnapshot" "/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Debug/"
make: *** [out/Debug/] Error 134

If anyone knows what that means, i would be glad to hear :) On the other part, it builds on armv7. So that makes me think that v8 only works on ARMv7…but i’m no ARM assembler or expert or anything, so i can’t tell… Could be that the softfloat armv5tel toolchain is doing something wrong…but looks unlikely considering nothing else fails…

Here’s a pic of it working finally on armv7(the red dots as always are kindly added by my graphic card :):

So yeah, we now have a 100% working www-client/chromium on ARM natively, only on armv7 though. But i’m pretty sure nobody wanted a browser on armv5te that didn’t had javascript, so…better than nothing :)

Here’s the binary for armv7a:

ARM status @ Gentoo

January 4, 2010

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 :)

ARMv6J stages available

January 3, 2010

Hello everyone,

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

Since the Efika MX i got assigned is capable to do ARMv7 stages, its also capable of doing the previous ARM CPUs as well. The ARMv6J CPU is used on the Nokia N800, Nokia N810 and on the Smart Q7(ARMv6ZK in this case, though the ARMv6J will work).

The stages are built with the following CFLAGS/CXXFLAGS:
“-Os -march=armv6j -mfpu=vfp -mfloat-abi=softfp -pipe” and the armv6j-unknown-linux-gnueabi CHOST.

Hope you find them useful. Binary repositories will follow soon.


Get every new post delivered to your Inbox.