SIG-ARM December 2011

sig-arm@lists.ipfire.org

1 participants
2 discussions

[SIG-ARM] Building IPFire 2.x armv5tel on armv7l hardware
by Michael Tremer 11 Dec '11

11 Dec '11

Hello, this is me (again) talking about some development stuff: The IPFire project received two Pandaboards because they have a much faster hardware than the Dreamplug. Unfortunately, they are not such a good router like the DP, because the come only with one network interface and without a case. We use them for building packages, because the estimated speed of the CPU is three times faster. Yeah! :D An issue building with a much more recent hardware is that it does not identify anymore as armv5tel and so, when building some packages they go crazy and think something like "oh, cross-compile!". In fact, that is not what we want from them because the target architecture is still armv5tel. The issue is quite the same when building i586 code on i686 or x86_64. Although they are backwards-compatible, build processes mess up sometimes. The solution is to fake the personality of the system, which works very nicely with linux32(8) on x86_64 but does not on ARM. The solution we now came up with is to overload the uname(3) function in the glibc and modify the output. A simple example would be: root@armbuilder01:/build/ipfire-2.x# uname -a Linux armbuilder01.ipfire.org 3.0.0-1205-omap4 #10-Ubuntu SMP PREEMPT Thu Sep 29 03:57:24 UTC 2011 armv7l armv7l armv7l GNU/Linux root@armbuilder01:/build/ipfire-2.x# ./make.sh shell Resetting our nice level to 10 [ DONE ] Checking if we're running as root user [ DONE ] Checking for necessary space on disk [ DONE ] Entering to a shell inside LFS chroot, go out with exit root:/# uname -a Linux armbuilder01.ipfire.org 2.6.32.45 #10-Ubuntu SMP PREEMPT Thu Sep 29 03:57:24 UTC 2011 armv5tel GNU/Linux As you can see. Inside the chroot, the build machine identifies as arm5tel instead of armv7l and also fakes the kernel version, because some packages have trouble to build with kernel versions >= 3.0. As already said in the introduction, we overload the function with a modified one in a new lib that is loaded by the runtime linker by using LD_PRELOAD=/tools/lib/libpakfore_preload.so. root:/# ldd /tools/bin/uname /tools/lib/libpakfire_preload.so (0x40076000) libc.so.6 => /tools/lib/libc.so.6 (0x40124000) libdl.so.2 => /tools/lib/libdl.so.2 (0x4001c000) /tools/lib/ld-linux.so.3 (0x400ff000) The library lives in the toolchain, because we don't need it in the final system. Why am I telling you all this stuff that is really boring? I did not build the whole distribution because my Pandaboard is quite busy compiling IPFire 3.x and so I am searching for a volunteer who will do the job for me. Any other machine like Beagleboard is working as well. The branch can be found in my personal git repository: http://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=shortlog;h=refs/heads/f… If the test succeeds, Arne may merge the branch into the main development trees. I already built and uploaded the toolchain, so you may start at that point. Happy testing, Michael

1 0

[SIG-ARM] Porting IPFire 3.x to ARM
by Michael Tremer 05 Dec '11

05 Dec '11

Hello guys, I would like to announce a (not yet finished) port of IPFire 3.x to the ARM platform. In this post, I will give you a short summary about what has been done and why. IPFire 3.x ARM will come in two flavours. The first one is armv5tel and the second one is armv7hl. armv5tel: Is an older version of the ARM platform that does not necessarily has an FPU and so we must use software floating-point operations. This is the way we have chosen to build IPFire 2.x and as a lot of hardware is out there, we need to support that as well for IPFire 3.x BUT we may drop support for that one time. armv7hl: armv7hl is much newer than armv5tel and brings an FPU. So we can expect it to be much faster. As most of the new hardware comes with an Cortex-A9 CPU or higher, we should support that as well. armv6* and armv8* are also there, but currently I have no interest in supporting these. I guess it is like back in days of i486 and i586. There is a difference between these architectures, but generally i586 CPUs can run older code. In fact, we build the main version of the distribution for i686 without MMX, SSE and all that fancy stuff and so it will be for ARM as well. What has been done? Until now, I have only built a very limited number of packages which create a small toolchain for armv5tel only: http://people.ipfire.org/~ms/testingbay-armv5tel/ It takes quite a while to compile that stuff on my Dreamplug and so I am not making very fast progress due to the lack of faster ARM hardware. We will see how we can improve that in the next few weeks. An example: GCC took more than 5 days to compile. What will be done? As we gained some experience from porting IPFire 2.x to ARM I would like to build all packages that are currently in IPFire 3.x and fix the bugs we will have. For the moment, a package that is building is sufficient. How can you help? It would be great if you (all the guys who have ARM hardware) install pakfire on their machines and go ahead by building random packages and send me patches to fix builds that might break. Hardware donations will improve the speed of this whole thing a lot. I would love to hear your comments on this topic. Michael

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

SIG-ARM December 2011