I've been working on this as much as my spare time permits, and at the moment it is in a workable state, although the ebuilds need to be cleaned up a bit - a proper efikamx-headers tarball would be a nice step, as well as a few other misc odds and ends (you can read the git log if interested)

I've got ebuilds for imx-lib, efikamx-headers, and libz160-bin - all 3 of those are required to build xf86-video-imx

Currently, it works - that is the good news.

The bad news is, this isn't 3D ;)

I'm currently working on xf86-video-imx-0.1.0-r1 - do NOT enable this unless you actually intend to install xorg-server, libdrm, and mesa from scm (they are in the overlay as well) 0.1.0 should suit anyone fine on arm or ~arm although the driver itself is only marked ~arm.

Please look at the git log before posting patches and follow the style set out.

http://github.com/steev/efikamx

Quick nitpick, dunno if it's relevant: x11-base/xorg-drivers doesn't have xf86-video-imx in it?

I also think you should version xf86-video-imx either by the BSP release code (09.12.01 in your case right now) or by the BSP revision (which would turn out to be something like 1.7 in your case right now) so it matches the Freescale releases..

How did you get imx-libs to build completely? It shouldn't! Some of the imx-libs are for iMX35 only and rely on some weird stuff that isn't in the kernel headers as built for the iMX51 kernel (basically, I think librng should fail and this is normal).

Have you considered bundling up the Ralink wireless code and the config.mk on PowerDeveloper so it'll build for the current kernel pending actual, real, working (non-dividing-by-zero) Ralink drivers in-kernel?

We can work on a 3D ebuild, you just gotta give me a hint since it'll all be binary, and it will rely on a specific kernel configuration (i.e. no module versioning or the damn thing will have to be updated every time the kernel changes - the module and the interfaces it uses are totally unchanging however, and it just needs to BE there for the userspace to work.)

I gotta do a proper source ebuild first though, and one for libz160 for internal use would probably be a good idea too. That should be a lovely chore.. you going to be around this weekend? I can't give you the source but we can run through what's going wrong in what place.

Where's the very best Gentoo rootfs I can install and get started on this?

_________________
Matt Sealey

No - xorg-drivers doesn't list it - I didn't consider modifying that yet. I was more focused on getting xf86-video-imx building properly.

The versioning of the file is what "make dist" gave me in the xserver-xorg-blahblahblah-09.12.01 directory.

Building imx-libs:

From the ebuild:
src_compile() {
emake INCLUDE="-I/usr/src/linux/include \
-I/usr/src/linux/drivers/mxc/security/rng/include \
-I/usr/src/linux/drivers/mxc/security/sahara2/include" \
PLATFORM="IMX51" all || die "emake failed"
}

*VERY* ugly to do that. It is definitely not proper to look into /usr/src/linux but for our current build scenario, I took the liberty of doing so. A more proper way of handling this would be to put the headers from those includes into the proper places in the system (ala efikamx-headers ebuild)

No thoughts one way or the other on the Ralink driver - shouldn't be too hard though, just a matter of sitting down and doing it.

As for the 3d ebuild, that one will just be a matter of putting the file in the correct place. It would be similar to the Ralink driver, in that you would "build" it and install it against the current (/usr/src/linux) kernel, and then install the file into /lib/modules/kernelver/$(whatever)
There is an eclass set up for dealing with the kernel config and you can go one of two ways, you can either tell it to bomb out and tell them to fix their config (for example, if they don't have module force loading enabled) - or throw out an ewarn if they do have force loading enabled and module versioning enabled that they will need to force load it.

The best Gentoo rootfs to install is the autobuilds - http://mirrors.tds.net/gentoo/releases/ ... nt-stage3/ (obviously choosing the armv7a-unknown-linux-gnueabi link there and grabbing the stage3ball)

http://dev.gentoo.org/~darkside/arm/efi ... nstall.xml has excellent instructions instructions for this. Then just follow your post about "upgrading" a kernel for extracting it.

Something that I would highly suggest:
If using a 4gb or smaller drive, use a usb thumbdrive or usb hard drive, or mount over the network, /usr/portage and /var/tmp/portage (2 seperate partitions, var/tmp/portage being ~4gb in size (assuming you will ever build openoffice.org) - /usr/portage needs to be around 3gb (mine is currently 1.2g but 572mb of that is distfiles/ (the source tarballs that have been downloaded) - there are also ways around that with some /etc/portage/bashrc magic which can delete the distfile after successful install.