People,
I have been playing with various OSs on:
http://wiki.openmoko.org/wiki/FreeRunner_Overview
and it is very nice but does not have a kernel and rootfs image available for F9. I have in mind some medical monitoring apps for this gadget but I would like to use Fedora for development. It has been a long time since I had to worry about building kernels but from:
http://fedoraproject.org/wiki/Architectures/ARM
it seems like it should be possible for this hardware? It appears we need an armv4 version? Has anyone done any work on armv4? Anyone interested in this idea?
Thanks,
Phil.
Hiya Phil,
Phil wrote:
Has anyone done any work on armv4? Anyone interested in this idea?
There is a comment on the Fedora wiki which suggests this wouldn't be that difficult:
"Although we do not provide such binaries, the sources also lend themselves for building for pre-ARMv5TE hardware. The same is true for big-endian CPUs." [1]
But where would we start?
Great idea though. The supplied software stack is awful - Fedora on there would be fantastic.
-Phil
On Wed, Oct 01, 2008 at 03:38:29PM +0100, Philip Heron wrote:
Has anyone done any work on armv4? Anyone interested in this idea?
I'm certainly interested in the idea. There's still quite a bit more ARMv4 hardware out there than I thought (although I myself haven't seen any for quite some time now).
There is a comment on the Fedora wiki which suggests this wouldn't be that difficult:
"Although we do not provide such binaries, the sources also lend themselves for building for pre-ARMv5TE hardware. The same is true for big-endian CPUs." [1]
But where would we start?
The simple approach would be to just take all SRPMS in the f8/f9 distro, and do "rpmbuild --target armv4l foobar.src.rpm" for each of them.
Unfortunately, that won't work 100%.
What sometimes happens is that if package foobar was built against some version of libdependency, and libdependency was later upgraded a new version that breaks the foobar build, then that won't be caught until a new version of foobar is uploaded (or a security update needs to be issued, etc).
(In Debian land, this is called a FTBFS (Fails To Build From Source) bug, which tend to get a lot of attention. When I bootstrapped Debian for ARM EABI, I didn't really run into a lot of packages that had such issues, but e.g. in Fedora 8 there were quite a number of them -- actually, probably the most work involved in bootstrapping Fedora/ARM was dealing with packages that wouldn't rebuild anymore even on x86.)
(Some googling does turn up this page: http://fedoraproject.org/wiki/FTBFS -- so maybe it'll be easier for Fedora 9/10.)
The idea here is that if you are a secondary Fedora architecture, you should build packages in the same order and with the same dependencies and dependency versions as they were built with on x86. Dennis Gilmore wrote some tools that can do exactly this -- which should really be set up for ARM as well.
Actually, I think Dennis has set up a koji instance for ARM, so if you want to try to use this to rebuild f8 for armv4l, that would probably be a good test of the system. And it should dramatically reduce the amount of work you'll need to do to get an ARMv4 Fedora up and running.
People,
Lennert Buytenhek wrote:
On Wed, Oct 01, 2008 at 03:38:29PM +0100, Philip Heron wrote:
Has anyone done any work on armv4? Anyone interested in this idea?
I'm certainly interested in the idea. There's still quite a bit more ARMv4 hardware out there than I thought (although I myself haven't seen any for quite some time now).
Both versions of the Openmoko product sold out pretty quickly and they haven't even started selling to ordinary consumers yet!
There is a comment on the Fedora wiki which suggests this wouldn't be that difficult:
"Although we do not provide such binaries, the sources also lend themselves for building for pre-ARMv5TE hardware. The same is true for big-endian CPUs." [1]
But where would we start?
The simple approach would be to just take all SRPMS in the f8/f9 distro, and do "rpmbuild --target armv4l foobar.src.rpm" for each of them.
I was thinking of just doing a "minimalist" development to start with - ie a basic, with networking, without X, system with as few packages as possible. Then, once that is going to add other packages on demand . .
Unfortunately, that won't work 100%.
What sometimes happens is that if package foobar was built against some version of libdependency, and libdependency was later upgraded a new version that breaks the foobar build, then that won't be caught until a new version of foobar is uploaded (or a security update needs to be issued, etc).
(In Debian land, this is called a FTBFS (Fails To Build From Source) bug, which tend to get a lot of attention. When I bootstrapped Debian for ARM EABI, I didn't really run into a lot of packages that had such issues, but e.g. in Fedora 8 there were quite a number of them -- actually, probably the most work involved in bootstrapping Fedora/ARM was dealing with packages that wouldn't rebuild anymore even on x86.)
(Some googling does turn up this page: http://fedoraproject.org/wiki/FTBFS -- so maybe it'll be easier for Fedora 9/10.)
Maybe we should only be worrying about Fedora 10? - by the time we get all the packages going, 10 should have already been released . .
The idea here is that if you are a secondary Fedora architecture, you should build packages in the same order and with the same dependencies and dependency versions as they were built with on x86. Dennis Gilmore wrote some tools that can do exactly this -- which should really be set up for ARM as well.
Sounds like a good idea in principle but I don't need most of the packages and I really just want to see if the idea is viable . .
Actually, I think Dennis has set up a koji instance for ARM, so if you want to try to use this to rebuild f8 for armv4l, that would probably be a good test of the system. And it should dramatically reduce the amount of work you'll need to do to get an ARMv4 Fedora up and running.
I am happy to have a go if I can get help from this list and I have the OM Freerunner waiting to have something tested on it!
Regards,
Phil.
On Mon, Oct 06, 2008 at 09:21:54AM +0100, Philip Heron wrote:
But where would we start?
The simple approach would be to just take all SRPMS in the f8/f9 distro, and do "rpmbuild --target armv4l foobar.src.rpm" for each of them.
Is there much if any difference between armv4l and armv4tl?
I had always assumed that armv4t code would be interworking-safe while armv4 code wouldn't be -- but I don't actually know for sure off the top of my head.
Guys,
Lennert Buytenhek wrote:
On Mon, Oct 06, 2008 at 09:21:54AM +0100, Philip Heron wrote:
But where would we start?
The simple approach would be to just take all SRPMS in the f8/f9 distro, and do "rpmbuild --target armv4l foobar.src.rpm" for each of them.
Is there much if any difference between armv4l and armv4tl?
I had always assumed that armv4t code would be interworking-safe while armv4 code wouldn't be -- but I don't actually know for sure off the top of my head.
I am happy to have a go at whichever you think is best but I was trying to keep build times & disk space as low as possible until I know if the project is viable or not. It would be good to build a "minimal", non-X version first (eg a Live CD without X, OpenOffice etc) - I suppose I could look at the RPMS on a F8 Live CD to see which SRPMS to get?
Thanks,
Phil.
Guys,
Phil wrote:
Guys,
Lennert Buytenhek wrote:
On Mon, Oct 06, 2008 at 09:21:54AM +0100, Philip Heron wrote:
But where would we start?
The simple approach would be to just take all SRPMS in the f8/f9 distro, and do "rpmbuild --target armv4l foobar.src.rpm" for each of them.
Is there much if any difference between armv4l and armv4tl?
I had always assumed that armv4t code would be interworking-safe while armv4 code wouldn't be -- but I don't actually know for sure off the top of my head.
I am happy to have a go at whichever you think is best but I was trying to keep build times & disk space as low as possible until I know if the project is viable or not. It would be good to build a "minimal", non-X version first (eg a Live CD without X, OpenOffice etc) - I suppose I could look at the RPMS on a F8 Live CD to see which SRPMS to get?
I just checked the the current version:
Linux om-gta02 2.6.24mw-g78199ea0 #50 PREEMPT Thu Oct 2 17:50:48 CDT 2008 armv4tl unknown
Regards,
Phil.
Hi Guys,
Lennert Buytenhek wrote:
The simple approach would be to just take all SRPMS in the f8/f9 distro, and do "rpmbuild --target armv4l foobar.src.rpm" for each of them.
I tried this with some core packages over the weekend, enough to chroot into and play around with. The resulting environment works in qemu, but when I copied the chroot over to the phone it give me an Illegal Instruction error. Seems some armv5 code has sneaked in - possibly through static linking - I don't know.
I suppose the solution could be to rebuild these packages within the chroot, but I don't have nearly enough armv4 packages built for this. A job for Koji?
Actually, I think Dennis has set up a koji instance for ARM, so if you want to try to use this to rebuild f8 for armv4l, that would probably be a good test of the system. And it should dramatically reduce the amount of work you'll need to do to get an ARMv4 Fedora up and running.
Would there be much work involved in getting this up and running?
-Phil
People,
Philip Heron wrote:
Hi Guys,
Lennert Buytenhek wrote:
The simple approach would be to just take all SRPMS in the f8/f9 distro, and do "rpmbuild --target armv4l foobar.src.rpm" for each of them.
I tried this with some core packages over the weekend, enough to chroot into and play around with. The resulting environment works in qemu, but when I copied the chroot over to the phone it give me an Illegal Instruction error. Seems some armv5 code has sneaked in - possibly through static linking - I don't know.
Another Aussie did some work on the arm4/arm5 problem to try and get Android working on the Neo 1973:
http://benno.id.au/blog/2007/11/21/android-neo1973
He is obviously more clued-up than I am about this low level stuff - I asked him if he had any experience with Fedora but he said no and thought that: "I would probably start looking at something like PokyLinux, or one of the embedded Linux distros."
and
"Well, the important thing here is that you want simply need to recompile the kernel, but all the user application as well. This is the problem I ran into with Android, recompiling the kernel is the easy bit, it is the applications which will kill you."
I suppose the solution could be to rebuild these packages within the chroot, but I don't have nearly enough armv4 packages built for this. A job for Koji?
Actually, I think Dennis has set up a koji instance for ARM, so if you want to try to use this to rebuild f8 for armv4l, that would probably be a good test of the system. And it should dramatically reduce the amount of work you'll need to do to get an ARMv4 Fedora up and running.
Would there be much work involved in getting this up and running?
-Phil (Heron)
I had a look at:
http://koji.fedoraproject.org/
and installed koji - it seems I need to do something like:
koji build dist-fc7-scratch 'cvs://cvs.example.com/cvs/dist?rpms/kernel/FC-7#kernel-2_6_20-1_2925_fc7'
I would need to be able to build a kernel/boot image and then come back to the root image?
Regards,
Phil.
-
Lennert Buytenhek -
Philip Heron -
Philip Rhoades