Efika MX on the way

Thanks to Luca Barbato (known as lu_zero in Gentooland), I’ll be able to put my hands for some days on this nice ARM board made by Genesi, the Efika MX.

As it happened with the BeagleBone, the idea is to work out the kernel, bootloader integration and create weekly automatic builds of Gentoo and Sabayon images (those you can just cat to the MMC card). It is more or less what happens with Gentoo stage3 autobuilds, but here we have kernel binaries and u-boot, so that the image can boot straight away.

So far, qemu-user (statically compiled) + OpenSUSE patches, besides minor bugs, are working quite well. Depending on the availability of these boards on the market and project financial capabilities, we’ll be able to couple qemu-user with native hardware on the build server making them work side by side without the need of a shared binhost repo (sshfs + chroot magic, I’ll talk about it in future).

One more step for these chroots will be attaching matter to it, as we already do for i686 and x86_64 ones. This way the compilation of new ebuilds (and 70% of chroot work) will be completely automated.


About lxnay

the creator of Sabayon Linux, Entropy Package Manager {Eit, Equo, Rigo}, Molecule release media buildsystem, Matter Portage buildbot/tinderbox and only God knows what else...

5 responses to “Efika MX on the way

  1. bruce

    Cool. I have the efika smartbook and was trying to set up a qemu-arm chroot over the weekend, but my compile were hanging somehow in the sort process that never finished. I’d given up on it for now, but I’ve just found your qemu-user-static ebuild on github, so I’ll try again with that & see if I have more success. Would love to hear more about how your chroot is set up.

    • Bruce, just update coreutils 😉
      Feel free to add that info to our wiki, I forgot about it.

      Also, you may be interested in our patched version of qemu-user-static on the “sabayon” overlay.
      It contains patches from OpenSUSE that make qemu-user on arm kinda work.

      • bruce

        Thanks. I’ve installed qemu-user-static from the overlay.. It failed to link for the sparc32 target, so I hacked the ebuild to only build the arm user target. Would it be practical to use QEMU_USER_TARGETS in the ebuild?

        I tried updating coreutils the other day, but that even failed, so that’s about where I gave up. It built ok tonight with the patched qemu-arm.

        Also I found your Hitchhikers Guide to the BeagleBone… its got the section “Compiling through qemu-user” twice, and they’re slightly different. I’ve followed the first version tonight, and its working so far, but does adding the “-cpu cortex-a8” with qemu-wrapper help at all?

      • Please post the complete build.log somewhere. qemu-user-static is just a quick way to get statically linked qemu-user to use inside chroots…

        I fixed the wiki entries and removed the second version, which is actually what qemu-user-static is carrying already.

      • bruce

        qemu-user-static worked this time. I think I might have run out of memory earlier when I wasn’t at the pc. It went bezerk again this time around when it was compiling sparc32-plus-linux-user/disass.o, using up 75% of swap.

        The error I had earlier was a wierd linker error, something like:
        qemu-sparc32plus “Error: can’t resolve `.text’

        Thanks for you help.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

hello, twitter

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 583 other followers


%d bloggers like this: