Gentoo Arm on Rasbpberry Pi (hard float)


30 posts   Page 1 of 2   1, 2
by pepedog » Sun Feb 19, 2012 12:24 am
I can make a dd type image easily enough using Chromatix's build (even though my normal choice is Arch) and supply torrent.

Is there an interest?

Dave
Posts: 983
Joined: Fri Oct 07, 2011 9:55 am
by amiga65 » Sun Feb 19, 2012 2:13 am
Yep :)
Posts: 70
Joined: Wed Jul 27, 2011 10:59 pm
by Chromatix » Sun Feb 19, 2012 2:48 am
If the kernel bits, the GPU libraries and the header files required to build against them are properly installed (ie. in /usr instead of /opt), that would be a useful enhancement over my version.  Gentoo also likes to put example code under /usr/share/doc.

Note that to have enough space to build new or updated packages, the image should be built for a 4GB card rather than a 2GB one.  I strongly suggest a 1K block size purely to minimise the bloat of /usr/portage, and -T small to ensure that there are sufficient inodes to go around even if the filesystem is later resized signficantly.

BTW, I suggest not using a zip or tar archive, but directly encasing the image in gzip or something stronger.  Then one can use zcat or whatever directly onto the card, instead of having to store a multi-gigabyte temporary.

The ideal would be to have an ebuild capable of installing the GPU libraries and headers, and then these would be protected by the packager against, say, the Mesa version of the same things.
The key to knowledge is not to rely on people to teach you it.
User avatar
Posts: 430
Joined: Mon Jan 02, 2012 7:00 pm
Location: Helsinki
by pepedog » Sun Feb 19, 2012 12:37 pm
I think this may be more than trivial to me. I didn't even include the extra stuff on arch. I will take a look though, going to mount deb iso now on trimslice.

Or perhaps you could fashion this way?

I agree with you on type of archive, but see the point with the zip way that win users can create the card.
Posts: 983
Joined: Fri Oct 07, 2011 9:55 am
by Chromatix » Sun Feb 19, 2012 6:13 pm
Windows users can still expand a gzip or whatever image using 7zip.  I don't consider the built-in Zip support to be a big bonus.  They still need to obtain the tool to let them put it on the card anyway.

Making an ebuild is not hugely difficult - it's essentially an enhanced Python dialect with a lot of overridable default behaviour - but it is made a lot easier if there is an official source for the goods, preferably in a tarball on a website.
The key to knowledge is not to rely on people to teach you it.
User avatar
Posts: 430
Joined: Mon Jan 02, 2012 7:00 pm
Location: Helsinki
by pepedog » Sun Feb 19, 2012 6:48 pm
I would like to see official tars of blobs, libs, and whatever to package for arch too.
Plus I have been thrown that gpu blobs only a few weeks old are not as new as Debian rootfs.
I"m going to have to attend to arch again, will write to Dom about what we want.
Posts: 983
Joined: Fri Oct 07, 2011 9:55 am
by jamesh » Sun Feb 19, 2012 10:07 pm
pepedog said:


I would like to see official tars of blobs, libs, and whatever to package for arch too.
Plus I have been thrown that gpu blobs only a few weeks old are not as new as Debian rootfs.
I"m going to have to attend to arch again, will write to Dom about what we want.


What do you mean about the age of the GPU blob?
Volunteer at the Raspberry Pi Foundation, helper at Picademy September and October 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12113
Joined: Sat Jul 30, 2011 7:41 pm
by liz » Mon Feb 20, 2012 12:23 am
pepedog said:


I would like to see official tars of blobs, libs, and whatever to package for arch too.
Plus I have been thrown that gpu blobs only a few weeks old are not as new as Debian rootfs.
I"m going to have to attend to arch again, will write to Dom about what we want.


That's because we released the Debian rootfs when we were happy with it. If we had stopped iterating the GPU firmware earlier, we would have released the rootfs earlier. I'm a bit lost as to what the problem is here.
--
Head of Comms, Raspberry Pi Foundation
User avatar
Raspberry Pi Foundation Employee & Forum Moderator
Raspberry Pi Foundation Employee & Forum Moderator
Posts: 4141
Joined: Thu Jul 28, 2011 7:22 pm
by Benedict White » Mon Feb 20, 2012 1:13 am
liz said:


pepedog said:


I would like to see official tars of blobs, libs, and whatever to package for arch too.
Plus I have been thrown that gpu blobs only a few weeks old are not as new as Debian rootfs.
I"m going to have to attend to arch again, will write to Dom about what we want.


That's because we released the Debian rootfs when we were happy with it. If we had stopped iterating the GPU firmware earlier, we would have released the rootfs earlier. I'm a bit lost as to what the problem is here.


It's not a problem as such, but as the GPU blob develops it would be good if other distros devs had some means of knowing the change, whether it was an announcements page or being included on a mailing list.
Posts: 225
Joined: Sat Dec 24, 2011 12:24 am
by jamesh » Mon Feb 20, 2012 9:56 am
In the long run blob changes on the whole won't affect the Linux side at all - they are usually just bug fixes with no affect on the API. Occasionally new features will be added, but again, they won't affect host side until the host libraries are modified to use the new features. I don't think that won't happen very often, and I think its unlikely that GPU changes will be particularly publicised - i.e. what was fixed, but could be wrong!

In the early stages, there may be some churn, but right now, just use the most recent Raspi specific GPU blob you have.
Volunteer at the Raspberry Pi Foundation, helper at Picademy September and October 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12113
Joined: Sat Jul 30, 2011 7:41 pm
by Benedict White » Mon Feb 20, 2012 10:44 pm
My understanding is that, at the moment blob differences are making massive differences (positive) that have impacted on the way kernels are built to be stable. It would be useful if there was a mailing list for distro developers.
Posts: 225
Joined: Sat Dec 24, 2011 12:24 am
by Naguissa » Tue Feb 21, 2012 1:26 pm
Just note that, for reduce compressed filesystem image you can delete whole portage files (usually on /usr/portage). With only a sync all data will be restored.
Posts: 1
Joined: Tue Feb 21, 2012 1:17 pm
by Subwire » Wed Feb 22, 2012 10:36 pm
I'm interested in lending a hand however I can, as when I get a board, I'm definitely going to want to run Gentoo on it.

Has anyone thought about creating a Gentoo overlay for RasPi? We could house ebuilds for the proprietary libraries, the official kernel sources, GPU blob, and released apps in it

My understanding is that such an overlay (along with an autobuilt stage tarball) tends to show up after an established Gentoo developer gets a board, but we could always get the ball rolling now, since I believe we can do everything save Catalyst stage building without hardware

 

Posts: 7
Joined: Wed Feb 22, 2012 4:14 pm
by pepedog » Wed Feb 22, 2012 11:06 pm
Gentoo runs (hard float too), Chromatix supplied everything except kernel, modules and blobs, I put it on a card, altered a few files in etc (mostly to do with tty and mounting mmc part 1 as /boot) and it works. Hardware GPU acceleration doesn't at this point. Somewhere on this forum is a torrent to his tar. You can get the rest from deb or arch.

I am back on archlinux compiling kernel, and arch being close to the edge has uncovered LXDE problems, xulrunner too.

Why didn't I start this topic in distributions? Can a moderator move it?
Posts: 983
Joined: Fri Oct 07, 2011 9:55 am
by liz » Wed Feb 22, 2012 11:09 pm
Moved. :)
--
Head of Comms, Raspberry Pi Foundation
User avatar
Raspberry Pi Foundation Employee & Forum Moderator
Raspberry Pi Foundation Employee & Forum Moderator
Posts: 4141
Joined: Thu Jul 28, 2011 7:22 pm
by Subwire » Wed Feb 22, 2012 11:41 pm
That image was made with a cross-compiler, right? Which libc is it using?

I tried to use crossdev to build a cross-compiler setup for the tuple Chromatix mentioned, and using the latest stable GCC and libc, and ran into build errors.  It's also possible that my host's configuration is interfering; I'll keep tinkering with it.
Posts: 7
Joined: Wed Feb 22, 2012 4:14 pm
by Michael » Fri Feb 24, 2012 11:01 pm
pepedog said:


Why didn't I start this topic in distributions? Can a moderator move it?



As per the policy, the distributions forum is for announcements of available distributions, not for project proposals and general discussions about distributions, the proper place for such topics is the Projects and collaboration sub-forum.  For the distributions sub-forum to be useful, it needs to remain un-cluttered.

As Liz has moved the topic here, I'll leave it and let her decide if it should be moved again or not.
Posts: 340
Joined: Sat Jul 30, 2011 6:05 pm
by Chromatix » Fri Feb 24, 2012 11:18 pm
Subwire said:


That image was made with a cross-compiler, right? Which libc is it using?

I tried to use crossdev to build a cross-compiler setup for the tuple Chromatix mentioned, and using the latest stable GCC and libc, and ran into build errors.  It's also possible that my host's configuration is interfering; I'll keep tinkering with it.


No, I built it natively - using a TrimSlice which has a dual Cortex-A9 inside.  I started from the official ARMv7-A hardfloat Gentoo installation materials, and recompiled it down to ARMv6 hardfloat inside itself.  The result worked first time on real R-Pi hardware - once it was properly squeezed onto an SD card, that is.

The GPU libraries and possibly the kernel are probably the only components that remain cross-compiled, and that only because I didn't build them myself.  This probably doesn't hurt them, except that there were some difficulties with matching the compiler options sufficiently well.

So it's really not necessary to start from x86 or AMD64 every time.  Considering how long I've been building natively on PowerPC hardware, that really shouldn't be a surprise to anyone any more.
The key to knowledge is not to rely on people to teach you it.
User avatar
Posts: 430
Joined: Mon Jan 02, 2012 7:00 pm
Location: Helsinki
by IDE » Sun Mar 04, 2012 6:24 pm
I'd be interested to know if there's any download links for these GPU drivers. I ordered an RP this week, Gentoo is the distribution I'd be interested to go forward with.

And hey, massive bigups to the people who has interest towards Gentoo with the RP. I've been a Gentoo user ever since 2004. I just can't wait to get myself started.
Posts: 52
Joined: Fri Jan 13, 2012 12:28 am
by Subwire » Sun Mar 04, 2012 8:39 pm
IDE said:


I'd be interested to know if there's any download links for these GPU drivers. I ordered an RP this week, Gentoo is the distribution I'd be interested to go forward with.


That's an interesting question. If you go back a bit on the blog, you'll find a post (I don't have the link offhand) with a diagram describing the various pieces that make up the RasPi's "drivers". For starters, you can already get the specially patched kernel sources and the GPU boot firmware here: https://github.com/raspberrypi/

As for the GL libraries to make the GPU go, there's a link somewhere around here to a set of the compiled libraries with hardfloat support, but it seemed like Chromatix and dom were working out the bugs, so I don't know what state they were in. You can also rip them out of the already-released Debian image.

We're interested in making ebuilds out of everything already available on that github page, plus the libraries, and making an overlay or somesuch to enable easy access. Stay tuned.
Posts: 7
Joined: Wed Feb 22, 2012 4:14 pm
by Chromatix » Sun Mar 04, 2012 9:08 pm
I think dom managed to sort out a working hardfloat library set, after pepedog tested a non-working version and I identified the problem.  I think I might even have a copy of the working version somewhere.  But AFAIK it's not on the Web anywhere obvious - maybe in a dropbox account somewhere.

If that's what you're lacking to make an ebuild, let me know and I'll see what I can dredge up.  You should probably also include a copy of the Khronos GLES1/2, EGL, OpenMAX IL and OpenVG headers for completeness, or at least depend on a package which provides them (and doesn't conflict).

There is potential for file conflicts with Mesa, which has it's own implementation of EGL, GLES1/2 and VG which can be turned on by useflags, but which operate only inside X11 and cannot use the R-Pi's GPU.  If there is not already a way of configuring those out of the way in favour of the Broadcom set, adding one would be useful.  At the same time, leaving in support for (software rendered) desktop GL via Mesa is a good thing.
The key to knowledge is not to rely on people to teach you it.
User avatar
Posts: 430
Joined: Mon Jan 02, 2012 7:00 pm
Location: Helsinki
by Subwire » Sun Mar 04, 2012 11:02 pm
Chromatix said:


I think dom managed to sort out a working hardfloat library set, after pepedog tested a non-working version and I identified the problem.  I think I might even have a copy of the working version somewhere.  But AFAIK it's not on the Web anywhere obvious - maybe in a dropbox account somewhere.

If that's what you're lacking to make an ebuild, let me know and I'll see what I can dredge up.  You should probably also include a copy of the Khronos GLES1/2, EGL, OpenMAX IL and OpenVG headers for completeness, or at least depend on a package which provides them (and doesn't conflict).

There is potential for file conflicts with Mesa, which has it's own implementation of EGL, GLES1/2 and VG which can be turned on by useflags, but which operate only inside X11 and cannot use the R-Pi's GPU.  If there is not already a way of configuring those out of the way in favour of the Broadcom set, adding one would be useful.  At the same time, leaving in support for (software rendered) desktop GL via Mesa is a good thing.


Yup, the libraries are the only missing part as far as files are concerned.  What would be extra handy is if the libraries were to end up in RasPi's github with the rest of the proprietary binaries, but I can put them someplace else (eg. in my github) for now.  Any clue what license is attached to these?

As far as Mesa goes, what we'd ideally want to do is have our libraries package conflict with mesa only when compiled with those certain USE flags for EGL, GLES, etc.  I'm reasonably sure we can do that, and am looking into it.
Posts: 7
Joined: Wed Feb 22, 2012 4:14 pm
by dom » Sun Mar 04, 2012 11:22 pm
The hard float abi libraries seemed to be fully working (I ran quake and HD video decode).
They should still be on the Dropbox link, I posted previously, but adding to GitHub is fine. I"ll try to do that tomorrow.
I"d be very interested in seeing X+Midori working in hard float gentoo. I did attempt to emerge them, but hit some build errors. No doubt there are magic USE flags to help this.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4059
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Subwire » Sun Mar 04, 2012 11:56 pm
dom said:


The hard float abi libraries seemed to be fully working (I ran quake and HD video decode).
They should still be on the Dropbox link, I posted previously, but adding to GitHub is fine. I"ll try to do that tomorrow.
I"d be very interested in seeing X+Midori working in hard float gentoo. I did attempt to emerge them, but hit some build errors. No doubt there are magic USE flags to help this.



Thanks dom! That'll help everyone package for distribution easily.

I set up the bare repo for what will be an overlay.  I'm building the structure and such now, but when there's something to see, it'll be here: https://github.com/subwire/raspberrypi-overlay
If anyone wants to contribute, let me know!
Posts: 7
Joined: Wed Feb 22, 2012 4:14 pm
by jannis » Mon Mar 05, 2012 6:13 am
Great work guys. Looking forward to get my board to try Gentoo on it :)

Since no one really replied in the thread: Would you mind having a look at:

http://www.raspberrypi.org/for.....or-openmax

Should not be too much work with Gentoo - the USE-flags are already there in the official portage tree.
Posts: 55
Joined: Tue Jan 17, 2012 3:48 pm