crux-armhf for efikamx
I got it. This first (internal) release built on EfikaMX is ready. This full hardware floating point release still includes only core packages (and some opt too) and it has been started from scratch 'cause ABI incompatibility. Here the full work: http://cruxppc.org/~acrux/arm/2.7-HARD/ crux-armhf-2.7-test0-2G_image.xz (935M) - it's a full working MMC image of my machine that does use ilenia as ports manager and overlay supervisor. Thus a 'man ilenia' could help. It has the serial console and sshd enabled and a static IP (192.168.0.211). The 'root' pasword is 'cruxppc' as i've a lot of devel machines from CRUX PPC project and we use to have the same root password everywhere. The arm ports tree overlay is located 'as local' in /usr/ports/arm . arm-ports.tar.bz2 (634K) - it's an archive with ports from the arm overlay core.tar.bz2 (95M) opt.tar.bz2 (20M) pkg.list (3.0K) - they're archives with the built packages to install as chroot. crux-armhf-rootfs-2.7-test0.tar.bz2 (107M) - it's a clean system like the official way. linux-2.6.31.14.23-efikamx_20110610.tar.bz2 (63M) linux-2.6.31.14.23-efikamx.config (57K) - it's the last kernel from genesi git uImage (3.3M) bootkernel-modules.tar.bz2 (1.7M) - they'are boot kernel and modules/firmware Known issues: 1) wrong file-5.07's output (like on PowerPC) for some kind of files type. e.g. root@efikamx:/mnt/DEVEL# file mio mio: DOS-executable ( root@efikamx:/mnt/DEVEL# md5sum mio ba52d7e6f0c41a7bcaf49a216864e34a mio instead it should be.. acrux@killer:~$ file mio mio: Linux rev 1.0 ext2 filesystem data acrux@killer:~$ md5sum mio ba52d7e6f0c41a7bcaf49a216864e34a mio 2) alsa-utils does build but segfault cheers, --nico -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/
eglibc sources and some patches are located here http://cruxppc.org/~acrux/arm/sources/ --nico -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/
hi all, i'm sorry for the long silence. I've uploaded some stuff thus you can review and start to play with. It seems really stable and, now, the only trunk is binutils-(20110627). Now the toochain has Graphite support built-in. binutils-2.21.52, gcc-4.6.1, eglibc-2.14 gmp-5.0.2-2, mpfr-3.0.1-p4, mpc-0.9 ppl-0.11.2, cloog-0.16.2 Only the kernel is dirty as it's built using a mix of some unreleased patches[1] but is good enough to work on and to use un updated udev. Known issues: 1) sdma doesn't work properly. Broken kernel. 2) alsa-utils does build but segfault. Broken kernel. Here there is the latest toolchain and system: http://cruxppc.org/~acrux/arm/2.7-HARD/1/ http://cruxppc.org/~acrux/arm/sources/ crux-armhf-2.7-test1-2G_image.xz (901M) - it's a full working MMC image of my machine that does use ilenia as ports manager and overlay supervisor. Thus a 'man ilenia' could help. It has the serial console and sshd enabled and a static IP (192.168.0.211). The 'root' pasword is 'cruxppc' as i've a lot of devel machines from CRUX PPC project and i use to have the same root password everywhere. The arm ports tree overlay is located 'as local' in /usr/ports/arm . arm-ports.tar.bz2 (635K) - it's an archive with ports from the arm overlay core.tar.bz2 (99M) opt.tar.bz2 (21M) pkg.list (3.2K) - they're archives with the built packages to install as chroot. linux-2.6.39.2-efikamx.config (57K) - it's the kernel config i used to build the "dirty" bootkernel uImage (3.5M) bootkernel-modules.tar.bz2 (779K) - they'are boot kernel and modules/firmware [1] http://git.rtp-net.org/?p=efika.git http://git.pengutronix.de/?p=imx/sdma-firmware.git --nico -- acrux <acrux_it@libero.it>
* acrux (acrux_it@libero.it) wrote:
hi all, Hey acrux,
i'm sorry for the long silence. I've uploaded some stuff thus you can review and start to play with.
No problem. We are making some other things too. I just took a look to your files this last week. You did a very good job. I'd like to propose a meeting for this next week to talk about some things. Hardfp could be a good topic, because I would like to see your work together with our work too.
It seems really stable and, now, the only trunk is binutils-(20110627). Now the toochain has Graphite support built-in. binutils-2.21.52, gcc-4.6.1, eglibc-2.14 gmp-5.0.2-2, mpfr-3.0.1-p4, mpc-0.9 ppl-0.11.2, cloog-0.16.2
Only the kernel is dirty as it's built using a mix of some unreleased patches[1] but is good enough to work on and to use un updated udev.
Known issues: 1) sdma doesn't work properly. Broken kernel. 2) alsa-utils does build but segfault. Broken kernel.
With a right setup, we can start a hardfp toolchain and fill related bugs into that project at flyspray.
Here there is the latest toolchain and system: http://cruxppc.org/~acrux/arm/2.7-HARD/1/ http://cruxppc.org/~acrux/arm/sources/
crux-armhf-2.7-test1-2G_image.xz (901M) - it's a full working MMC image of my machine that does use ilenia as ports manager and overlay supervisor. Thus a 'man ilenia' could help. Ilenia can be another topic to talk, if not in the first meeting, at least in another one soon too.
It has the serial console and sshd enabled and a static IP (192.168.0.211). The 'root' pasword is 'cruxppc' as i've a lot of devel machines from CRUX PPC project and i use to have the same root password everywhere. The arm ports tree overlay is located 'as local' in /usr/ports/arm .
arm-ports.tar.bz2 (635K) - it's an archive with ports from the arm overlay
These ports can be great to have them in the overlay collections. Sepen created another one collection for the efikamx, where I need to upload soon (I need to rebuild all related imx driver ports again, because I lost all the work made in the SD cad...) the imx driver ports.
core.tar.bz2 (99M) opt.tar.bz2 (21M) pkg.list (3.2K) - they're archives with the built packages to install as chroot.
linux-2.6.39.2-efikamx.config (57K) - it's the kernel config i used to build the "dirty" bootkernel
uImage (3.5M) bootkernel-modules.tar.bz2 (779K) - they'are boot kernel and modules/firmware
I think that trying to keep all the work together would be better. But we are fighting yet with the 2.7 release. Which seems to be right. Here I have it tested on both machines and it works right. I would like to finish this task, closing the perl problem and releasing it. This should be finished to start making a good hardfp work.
[1] http://git.rtp-net.org/?p=efika.git http://git.pengutronix.de/?p=imx/sdma-firmware.git
I hope we can meet soon and try to make a clear way to go ahead. Best regards, Victor. --- Learning bit by bit Victor Martinez | http://lokalix.dyndns.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi all, about crux armhf... - From this email: http://crux-arm.nu/pipermail/crux-arm/2011-July/000086.html i only did some minor updates. And my work was still focused on the new toolchain that is really advanced and actually better than cruxppc one i used as start point (and it already has graphite support from 2.6 release). Everything is always available, the server was offline a couple of weeks ago 'cause a disk failure but i successfully repaired it and the raid5 helped me a lot. - From July Just some minor update i did: *) binutils is now 2.21.53-20110722 and we always must wait for the upcoming 2.22 stable release ; *) file-5.09 fixes arm/ppc bugs thus no fedora's patches are needed anymore ; *) cloog is now 0.16.3 ; *) i rebuilt gcc and binutils against the new cloog-0.16.3 (ABI changed) ; *) i've updated the kernel to 3.1.0-rc6+ but audio and sdma are still unable to work and rtc is not perfect. If you like at once to work on hardfp i'll upload asap the new cloog,gcc and binutils packages. About the kernel (from pengutronix+rtp patches). Here attached my test config (with sdma disabled) and the dmesg and here how i did to save your time when you'll give a try. git clone git://git.pengutronix.de/git/imx/sdma-firmware.git cd sdma-firmware/ make cp sdma-imx51-to3.bin /lib/firmware/ git clone git://git.rtp-net.org/efika.git git clone git://git.pengutronix.de/git/imx/linux-2.6.git cd linux-2.6/ git checkout origin/for-next now you can apply all the RTP's patches as reported in the series file make mrproper patch -p1 < ../efika/mx53_ahci_v7_1.patch etc... following the order from the 'series' file. As i've understood if rtp's patches were rediffed/reworked at the same time of the last 'for-next' commit you'll have a perfect experimental kernel. [1] http://git.pengutronix.de/?p=imx/linux-2.6.git;a=summary [2] http://git.pengutronix.de/?p=imx/sdma-firmware.git [3] http://git.rtp-net.org/?p=efika.git cheers, - --acrux - -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk579JQACgkQxq34tDeO7LjaKACfZsrMzaqw8L69MigIqbhsLGeY 6tIAn1A1jrSdmGaGs45BzXbSIZb5saqr =dKz1 -----END PGP SIGNATURE-----
* acrux (acrux_it@libero.it) wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hi all,
Hello there,
about crux armhf...
- From this email: http://crux-arm.nu/pipermail/crux-arm/2011-July/000086.html i only did some minor updates. And my work was still focused on the new toolchain that is really advanced and actually better than cruxppc one i used as start point (and it already has graphite support from 2.6 release).
This can be a good start point, but I would like to discuss some things between all developers. We need to put a direction to follow. I mean, that we need to talk about which versions we should use, if we should stick with glibc (which I think is the way to go but not the only one), which support we can add in the toolchain (cloog, graphite, ...) and how we can improve the toolchain to gain the best hardfp support.
Everything is always available, the server was offline a couple of weeks ago 'cause a disk failure but i successfully repaired it and the raid5 helped me a lot.
Yeah, I tried to get some info this summer (here) and it was impossible. It's great to have it up again.
- From July Just some minor update i did: *) binutils is now 2.21.53-20110722 and we always must wait for the upcoming 2.22 stable release ;
Agreed with this. I like the idea to use stable releases (and try to be together with CRUX versions too)
*) file-5.09 fixes arm/ppc bugs thus no fedora's patches are needed anymore ; *) cloog is now 0.16.3 ; *) i rebuilt gcc and binutils against the new cloog-0.16.3 (ABI changed) ; *) i've updated the kernel to 3.1.0-rc6+ but audio and sdma are still unable to work and rtc is not perfect.
If you like at once to work on hardfp i'll upload asap the new cloog,gcc and binutils packages.
Well, I want to start the development... with a new toolchain-hardfp repo. Packages at the moment aren't important. We need to start putting hands on the enviroment, letting others build their own hardfp toolchain, like is done in all releases. May be this way to do things, isn't enought (or you just don't like it) but I think it's the more confortable for all, developer and users.
About the kernel (from pengutronix+rtp patches). Here attached my test config (with sdma disabled) and the dmesg and here how i did to save your time when you'll give a try.
git clone git://git.pengutronix.de/git/imx/sdma-firmware.git cd sdma-firmware/ make cp sdma-imx51-to3.bin /lib/firmware/
git clone git://git.rtp-net.org/efika.git
git clone git://git.pengutronix.de/git/imx/linux-2.6.git cd linux-2.6/ git checkout origin/for-next
now you can apply all the RTP's patches as reported in the series file make mrproper patch -p1 < ../efika/mx53_ahci_v7_1.patch etc... following the order from the 'series' file.
As i've understood if rtp's patches were rediffed/reworked at the same time of the last 'for-next' commit you'll have a perfect experimental kernel.
This is a very good info too, but like we talk yesterday, I think we need to start from a stable point. Making some tests with the "stable" kernel and putting newers/testing kernels to a side until we'll have a strong base (toolchain). If we need this kernel (or another one) to give better hardfp support, then this is another history.
[1] http://git.pengutronix.de/?p=imx/linux-2.6.git;a=summary [2] http://git.pengutronix.de/?p=imx/sdma-firmware.git [3] http://git.rtp-net.org/?p=efika.git
cheers, - --acrux
Regards. --- Learning bit by bit Victor Martinez | http://lokalix.dyndns.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 23 Sep 2011 13:16:37 +0200 Victor Martinez <pitillo@crux-arm.nu> wrote: _omissis__
- From this email: http://crux-arm.nu/pipermail/crux-arm/2011-July/000086.html i only did some minor updates. And my work was still focused on the new toolchain that is really advanced and actually better than cruxppc one i used as start point (and it already has graphite support from 2.6 release).
This can be a good start point, but I would like to discuss some things between all developers. We need to put a direction to follow. I mean, that we need to talk about which versions we should use, if we should stick with glibc (which I think is the way to go but not the only one), which support we can add in the toolchain (cloog, graphite, ...) and how we can improve the toolchain to gain the best hardfp support.
Please give a try with the provided image (well, it's just my smarttop) and testing some ilenia features (/etc/ilenia.conf is the pre-configured file). Without a binutils-2.22 there isn't a stable hardfp release. I switched from glibc to eglibc because glibc doesn't support hardfp and you should apply a good numbers of patches (maybe from MeeGo project they are available). Anyway altough glibc-2.14 is available from June the glibc-ports-2.14 archive there isn't yet. About graphite support and is new cloog (with isl built-in backend instead cruxppc still uses the old clogg-ppl now deprecated from gcc developers) gcc's interface. A guess a modern os should avoid to remove from gcc his own best and innovative (and now stable) feature.
Everything is always available, the server was offline a couple of weeks ago 'cause a disk failure but i successfully repaired it and the raid5 helped me a lot.
Yeah, I tried to get some info this summer (here) and it was impossible. It's great to have it up again.
eh,eh... here in Italy there was CRUX PPC interview on an important Mac magazine and the website was down.. LOL, such a shame. We lost a lot of contacts and new potential users.
- From July Just some minor update i did: *) binutils is now 2.21.53-20110722 and we always must wait for the upcoming 2.22 stable release ;
Agreed with this. I like the idea to use stable releases (and try to be together with CRUX versions too)
thus you should wait for the next CRUX 3.0 to be aligned with the main project. But I'd say CRUX ARMHF is simpled unaligned becouse is unstable without a stable toolchain so nevermaind.
*) file-5.09 fixes arm/ppc bugs thus no fedora's patches are needed anymore ; *) cloog is now 0.16.3 ; *) i rebuilt gcc and binutils against the new cloog-0.16.3 (ABI changed) ; *) i've updated the kernel to 3.1.0-rc6+ but audio and sdma are still unable to work and rtc is not perfect.
If you like at once to work on hardfp i'll upload asap the new cloog,gcc and binutils packages.
Well, I want to start the development... with a new toolchain-hardfp repo. Packages at the moment aren't important. We need to start putting hands on the enviroment, letting others build their own hardfp toolchain, like is done in all releases. May be this way to do things, isn't enought (or you just don't like it) but I think it's the more confortable for all, developer and users.
I uploaded the updated packages and ports: http://cruxppc.org/~acrux/arm/2.7-HARD/1/update/ if, instead, you prefer to update by yourself cloog then you must remeber to do some symlinks to fix the abi changes and rebuild gcc/binutils (about 15h). Then remove the symlinks that are now only garbage. To build an environment with the 'Makefile' you need to already have the working hardfp environment. I was obliged to start from scratch to build a clean and native environment. I started updating the CRUX ARM 2.7rc1 toolchain to a modern one (not aligned to the now obsolete 2.7 main project) then the following step was a simple toolchain without graphite because ppl (Parma Polyhedra Library) is really long to compile i.e. about 20h on 1GHz cpu. Then i successfully built a new toolchain with graphite support. Really really stable. Btw, every toolchain related Pkgfile has 'make check' . _omissis__
As i've understood if rtp's patches were rediffed/reworked at the same time of the last 'for-next' commit you'll have a perfect experimental kernel.
This is a very good info too, but like we talk yesterday, I think we need to start from a stable point. Making some tests with the "stable" kernel and putting newers/testing kernels to a side until we'll have a strong base (toolchain). If we need this kernel (or another one) to give better hardfp support, then this is another history.
yes, it's a valid solution of course. cheers, - --nico - -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk58hnEACgkQxq34tDeO7LhsKwCfWlSsg24LoPM4iwFong5NNgn+ bWwAn23Ud7hcAPZpSglVuY+dHLvvA+J5 =rQZx -----END PGP SIGNATURE-----
[...]
This can be a good start point, but I would like to discuss some things between all developers. We need to put a direction to follow. I mean, that we need to talk about which versions we should use, if we should stick with glibc (which I think is the way to go but not the only one), which support we can add in the toolchain (cloog, graphite, ...) and how we can improve the toolchain to gain the best hardfp support.
Please give a try with the provided image (well, it's just my smarttop) and testing some ilenia features (/etc/ilenia.conf is the pre-configured file).
ummmm let's see how can I explain without sound hard. I hope my words aren't picked in a bad sense. About the image, I think it's really good to personal use (may be to make some tests too, but I can't see any good point about it) but not for development purposes, that's why we try to keep the development in git, from toolchain* to *-cross ports. Having the hardfp development done in a image, can give us a little feedback about performance or stability, but we avoid the fact of letting others do the same. They need to download a full image instead of building it in their own, giving the lot of possibilities we have with the "enviroment". About ilenia, I think it could be really easy to start working with it. Why dont we use a port for it? and then, we can start putting hands on it and verify if it can be an interesting/helpfull app.
Without a binutils-2.22 there isn't a stable hardfp release.
Great. This is interesting, because may be we need to wait a bit more to see all toolchain components more "stable" with hardfp.
I switched from glibc to eglibc because glibc doesn't support hardfp and you should apply a good numbers of patches (maybe from MeeGo project they are available). Anyway altough glibc-2.14 is available from June the glibc-ports-2.14 archive there isn't yet.
True, glibc and glibc-ports are a big problem atm (it happened too with eabi/noeabi toolchain in the past). We can make both options in the same git repo, letting the user choose between both of them, but this will give two scenarios, and this implies two developments (because we can find problems cross-building (or native builing) depending in that choice).
About graphite support and is new cloog (with isl built-in backend instead cruxppc still uses the old clogg-ppl now deprecated from gcc developers) gcc's interface. A guess a modern os should avoid to remove from gcc his own best and innovative (and now stable) feature.
Agree, we can put hands on those new and stable features. They are there to make use of them. If this implies more performance/stability then these are enought reasons to put our efforts in try to make the best. [...]
Yeah, I tried to get some info this summer (here) and it was impossible. It's great to have it up again.
eh,eh... here in Italy there was CRUX PPC interview on an important Mac magazine and the website was down.. LOL, such a shame. We lost a lot of contacts and new potential users.
Sorry, it sounds really a pity. [...]
Agreed with this. I like the idea to use stable releases (and try to be together with CRUX versions too)
thus you should wait for the next CRUX 3.0 to be aligned with the main project. But I'd say CRUX ARMHF is simpled unaligned becouse is unstable without a stable toolchain so nevermaind.
Yes, this was discussed some time ago too, between Jose and me, and we were lucky when the 2.6 release was done and really synced with CRUX 2.6 toolchain components. Now we have more knowledge and we can put hands on another components filling our needs. [...]
Well, I want to start the development... with a new toolchain-hardfp repo. Packages at the moment aren't important. We need to start putting hands on the enviroment, letting others build their own hardfp toolchain, like is done in all releases. May be this way to do things, isn't enought (or you just don't like it) but I think it's the more confortable for all, developer and users.
I uploaded the updated packages and ports: http://cruxppc.org/~acrux/arm/2.7-HARD/1/update/ if, instead, you prefer to update by yourself cloog then you must remeber to do some symlinks to fix the abi changes and rebuild gcc/binutils (about 15h). Then remove the symlinks that are now only garbage.
This sounds hard for me in this moment. I need to repick again the hardfp toolchain info I had some time ago and start reading about those components. I don't know so much about them (here I see your knowledge and experience)
To build an environment with the 'Makefile' you need to already have the working hardfp environment. I was obliged to start from scratch to build a clean and native environment. I started updating the CRUX ARM 2.7rc1 toolchain to a modern one (not aligned to the now obsolete 2.7 main project) then the following step was a simple toolchain without graphite because ppl (Parma Polyhedra Library) is really long to compile i.e. about 20h on 1GHz cpu. Then i successfully built a new toolchain with graphite support. Really really stable. Btw, every toolchain related Pkgfile has 'make check' .
Sorry my lack of knowledge, but I don't understand why we need a hardfp enviroment to build a hardfp enviroment with ppl support. May be this can be explited in some steps and documentation. For example, if we can use the "Makefile" to build a hardfp toolchain with "some" components (like cloog) and then, document it to rebuild it to give ppl support it's better than provide an image IMHO. Being "synced" with obsolete CRUX toolchain isn't a problem. We need other versions to have hardfp, then there is no reason to don't pick the needed ones with the needed patches too. Compiling time isn't a problem really, if it was, then we weren't using CRUX-ARM and we should pick another package oriented distro. [...]
This is a very good info too, but like we talk yesterday, I think we need to start from a stable point. Making some tests with the "stable" kernel and putting newers/testing kernels to a side until we'll have a strong base (toolchain). If we need this kernel (or another one) to give better hardfp support, then this is another history.
yes, it's a valid solution of course.
The best solution is comunication (with my bad english can be a pain but I'm trying to make as best as I can) when a project is managed with more than two hands. I really appreciate your work and effort Nico, don't pick my words wrong, or in a bad sense please. I try to explain my point of view to look for the best solution for developers and users. Thank you very much for all your info, work, feedback, help... in resume we really appreciate all you are giving to this little project.
cheers, - --nico
Regards, Victor. --- Learning bit by bit Victor Martinez | http://lokalix.dyndns.org
On Mon, 26 Sep 2011 16:47:01 +0200 Victor Martinez <pitillo@crux-arm.nu> wrote: _omissis__
ummmm let's see how can I explain without sound hard. I hope my words aren't picked in a bad sense. About the image, I think it's really good to personal use (may be to make some tests too, but I can't see any good point about it) but not for development purposes, that's why we try to keep the development in git, from toolchain* to *-cross ports. Having the hardfp development done in a image, can give us a
it's fine, don't worry. I choose to release it as image, source and ports archive only to avoid the feeling of "official release" of something other like a fork.
little feedback about performance or stability, but we avoid the fact of letting others do the same. They need to download a full image instead of building it in their own, giving the lot of possibilities we have with the "enviroment".
i did it to save your time while you were working on (high priority) 2.7 release. You can use it as start environment to bootstrap a new clean system as you use to do with the 'Makefile' practice.
About ilenia, I think it could be really easy to start working with it. Why dont we use a port for it? and then, we can start putting hands on it and verify if it can be an interesting/helpfull app.
there was an ilenia port but the author removed it when he went out from CRUX members group. Then he joined to CRUX PPC project and added some nice features to manage our arch overlay. He also did our first biarch (ppc and ppc64) toolchain. You can find actual ilenia's port here: http://cruxppc.org/viewvc/core/branches/2.7/ilenia/
From long time I don't use any GNU/Linux distro (i only need/use MS Windows) on my x86_64 workstation/laptop thus i'll never share my ports with CRUX main project as i cannot test them on x86. That's why i maintain some ports only on CRUX PPC. E.g., CRUX PPC always had ports to build gnash, icedtea or openoffice.
Without a binutils-2.22 there isn't a stable hardfp release.
Great. This is interesting, because may be we need to wait a bit more to see all toolchain components more "stable" with hardfp.
binutils-2.21.90 is out thus i guess a stable release is in the next future...
I switched from glibc to eglibc because glibc doesn't support hardfp and you should apply a good numbers of patches (maybe from MeeGo project they are available). Anyway altough glibc-2.14 is available from June the glibc-ports-2.14 archive there isn't yet.
True, glibc and glibc-ports are a big problem atm (it happened too with eabi/noeabi toolchain in the past). We can make both options in the same git repo, letting the user choose between both of them, but this will give two scenarios, and this implies two developments (because we can find problems cross-building (or native builing) depending in that choice).
too much complicated to handle for a small team. And to be realistic a standard enduser doesn't care too much if there is glibc or eglibc... The situation, today with 2.14 release, is simple... with eglibc you can release eabihf/eabi/noeabi with glibc only eabi/noeabi. But it's always possible to wait for a new glibc release.
About graphite support and is new cloog (with isl built-in backend instead cruxppc still uses the old clogg-ppl now deprecated from gcc developers) gcc's interface. A guess a modern os should avoid to remove from gcc his own best and innovative (and now stable) feature.
Agree, we can put hands on those new and stable features. They are there to make use of them. If this implies more performance/stability then these are enought reasons to put our efforts in try to make the best.
cloog/ppl are modern features that you can optionally enable with appropriate compiler flags. I say, you can have toolchain's components (gcc/binutils) with these features but simply avoiding to use them. _omissis__
Yes, this was discussed some time ago too, between Jose and me, and we were lucky when the 2.6 release was done and really synced with CRUX 2.6 toolchain components. Now we have more knowledge and we can put hands on another components filling our needs.
as my experience (with ppc) sometimes you are obliged to not be totally aligned 'cause, as common example, the toolchain needs different love on your own arch. cheers, --nico -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/
* acrux (acrux_it@libero.it) wrote:
On Mon, 26 Sep 2011 16:47:01 +0200 Victor Martinez <pitillo@crux-arm.nu> wrote:
_omissis__
ummmm let's see how can I explain without sound hard. I hope my words aren't picked in a bad sense. About the image, I think it's really good to personal use (may be to make some tests too, but I can't see any good point about it) but not for development purposes, that's why we try to keep the development in git, from toolchain* to *-cross ports. Having the hardfp development done in a image, can give us a
it's fine, don't worry. I choose to release it as image, source and ports archive only to avoid the feeling of "official release" of something other like a fork.
Yeah I understand it, but without knowing about how to replicate it, it's hard for others to start working with it. This is the reason why we try to manage with those "Makefiles", letting others build in their own and look for build problems (or test problems too).
little feedback about performance or stability, but we avoid the fact of letting others do the same. They need to download a full image instead of building it in their own, giving the lot of possibilities we have with the "enviroment".
i did it to save your time while you were working on (high priority) 2.7 release. You can use it as start environment to bootstrap a new clean system as you use to do with the 'Makefile' practice.
Well, that's a very good effort, but we can't see how do you managed it. In other sense, it would be great to let you work directly in a git repo dedicated for hardfp. We were working in the old 2.6 release (looking for problems, building ports and packages) and we had in the other hand the start point to the 2.7 release development. I can't see a problem there, if you had begun a work in hardfp while we were putting hands on closing 2.7 release. This is the reason to have Makefiles, we can keep track of the work progress, we have revision control, others can pick the work and start from there...
About ilenia, I think it could be really easy to start working with it. Why dont we use a port for it? and then, we can start putting hands on it and verify if it can be an interesting/helpfull app.
there was an ilenia port but the author removed it when he went out from CRUX members group. Then he joined to CRUX PPC project and added some nice features to manage our arch overlay. He also did our first biarch (ppc and ppc64) toolchain. You can find actual ilenia's port here: http://cruxppc.org/viewvc/core/branches/2.7/ilenia/
Well, it's a really interesting app to manage ports and packages. We are trying to avoid the package generation and management, letting it to users directly (there are lot of options to use packages in a farm enviroment for example, but it's known that CRUX is source oriented, and ilenia can make things more confortable to a group of users in this sense) It could be great to add it to our ports collection. But overlays are managed like is done in CRUX x86_64b, having some "love" needed ports splitted in the current *-arm ports collections.
From long time I don't use any GNU/Linux distro (i only need/use MS Windows) on my x86_64 workstation/laptop thus i'll never share my ports with CRUX main project as i cannot test them on x86. That's why i maintain some ports only on CRUX PPC. E.g., CRUX PPC always had ports to build gnash, icedtea or openoffice.
Sounds reasonable.
Without a binutils-2.22 there isn't a stable hardfp release.
Great. This is interesting, because may be we need to wait a bit more to see all toolchain components more "stable" with hardfp.
binutils-2.21.90 is out thus i guess a stable release is in the next future...
We can give some more time to it without problem. I have other things between hands too but I'm excited about the performance bump got with hardfp support.
I switched from glibc to eglibc because glibc doesn't support hardfp and you should apply a good numbers of patches (maybe from MeeGo project they are available). Anyway altough glibc-2.14 is available from June the glibc-ports-2.14 archive there isn't yet.
True, glibc and glibc-ports are a big problem atm (it happened too with eabi/noeabi toolchain in the past). We can make both options in the same git repo, letting the user choose between both of them, but this will give two scenarios, and this implies two developments (because we can find problems cross-building (or native builing) depending in that choice).
too much complicated to handle for a small team. And to be realistic a standard enduser doesn't care too much if there is glibc or eglibc... The situation, today with 2.14 release, is simple... with eglibc you can release eabihf/eabi/noeabi with glibc only eabi/noeabi. But it's always possible to wait for a new glibc release.
And while we wait, we can start the development based on eglibc and verify how compilation ports go. We can check if we find concrete ports build or something else.
About graphite support and is new cloog (with isl built-in backend instead cruxppc still uses the old clogg-ppl now deprecated from gcc developers) gcc's interface. A guess a modern os should avoid to remove from gcc his own best and innovative (and now stable) feature.
Agree, we can put hands on those new and stable features. They are there to make use of them. If this implies more performance/stability then these are enought reasons to put our efforts in try to make the best.
cloog/ppl are modern features that you can optionally enable with appropriate compiler flags. I say, you can have toolchain's components (gcc/binutils) with these features but simply avoiding to use them.
If they can give something good (performance, security, stability...) then those are things to take care and we need to think about adding them to the current toolchain (in case it can be done directly at toolchain level and study the possibilities to add more support from the ports collection, in case of ppl like you said)
_omissis__
Yes, this was discussed some time ago too, between Jose and me, and we were lucky when the 2.6 release was done and really synced with CRUX 2.6 toolchain components. Now we have more knowledge and we can put hands on another components filling our needs.
as my experience (with ppc) sometimes you are obliged to not be totally aligned 'cause, as common example, the toolchain needs different love on your own arch.
There is no problem to go ahead without being "synced" with CRUX components. Let's try to put hands on hardfp from scratch and build a custom toolchain based on the "needed/current" components version and study this possibility.
cheers, --nico Regards, Victor.
--- Learning bit by bit Victor Martinez | http://lokalix.dyndns.org
On Tue, 27 Sep 2011 09:22:00 +0200 Victor Martinez <pitillo@crux-arm.nu> wrote: _omissis__
ummmm let's see how can I explain without sound hard. I hope my words aren't picked in a bad sense. About the image, I think it's really good to personal use (may be to make some tests too, but I can't see any good point about it) but not for development purposes, that's why we try to keep the development in git, from toolchain* to *-cross ports. Having the hardfp development done in a image, can give us a
it's fine, don't worry. I choose to release it as image, source and ports archive only to avoid the feeling of "official release" of something other like a fork.
Yeah I understand it, but without knowing about how to replicate it, it's hard for others to start working with it. This is the reason why we try to manage with those "Makefiles", letting others build in their own and look for build problems (or test problems too).
ok, that's just a small abstract about what i did in June to bump from gnueabi (crux arm) to gnueabihf (crux armhf). I hope that my sum-up can help you to "normalize" my work in a Makefile. 1) after a fresh crux arm 2.7-test1 installation (i always worked natively i.e. directly using the efikamx) i bumped the toolchain to gcc-4.6.x and glibc-2.13 here used ports and sources: http://cruxppc.org/~acrux/arm/2.7-SOFT/ports.tar.bz2 http://cruxppc.org/~acrux/arm/2.7-SOFT/src/ 2) i now started from scratch (CLFS way) to bump to gnueabihf that's totally incompatible with gnueabi. Ok, my bad i did't keep a trace of my steps neither i did a Makefile like your ones (i'm lazy and i'm not a coder thus i don't use to write scripts for every kind of task i've in my mind...). Anyway i did like an updated CLFS for ARM. I know i'd have written it as it isn't yet in existence i guess because only now ARM achieved enough strenght and a "desktop status" capable to autonomously build sources. Well this is the point, to bump to gnueabihf i used to do like CLFS that's quite different from a CLFS-sysroot as your standard Makefile does. Or i simply misunderstood your modus operandi and i was in lack of a step using the Makefile approach. Ok, the step that i needed for was to build a temporary system. From CLFS book: [...] The tools in this chapter are cross-compiled using the toolchain in /cross-tools and will be installed under the ${CLFS}/tools directory to keep them separate from the files installed in Installing Basic System Software and the host production directories. Since the packages compiled here are temporary, we do not want them to pollute the soon-to-be CLFS system. [...] After which i was able to succesfully build my full working gnueabihf CLFS system. As i wasn't sure to have a stable system i didn't include graphite support in that toolchain. 3) i transformed that CLFS in a CRUX system. here used ports and sources: http://cruxppc.org/~acrux/arm/2.7-HARD/arm-ports.tar.bz2 http://cruxppc.org/~acrux/arm/2.7-HARD/src/ Well, from CLFS i already choosed to use eglibc as this ARM ABI's flavour is better supported. 4) i updated the system and i added the graphite support (with isl built-in backend). here used ports and sources: http://cruxppc.org/~acrux/arm/2.7-HARD/1/arm-ports.tar.bz2 http://cruxppc.org/~acrux/arm/2.7-HARD/1/update/arm-ports.tar.bz2 http://cruxppc.org/~acrux/arm/2.7-HARD/1/src/ 5) about this toolchain: a stable toolchain for ARM isn't really yet available... http://sourceware.org/ml/binutils/2011-09/msg00162.html http://gcc.gnu.org/ml/gcc/2011-09/msg00361.html cheers, --nico -- acrux <acrux_it@libero.it>
* acrux (acrux_it@libero.it) wrote: [...]
it's fine, don't worry. I choose to release it as image, source and ports archive only to avoid the feeling of "official release" of something other like a fork.
Yeah I understand it, but without knowing about how to replicate it, it's hard for others to start working with it. This is the reason why we try to manage with those "Makefiles", letting others build in their own and look for build problems (or test problems too).
ok, that's just a small abstract about what i did in June to bump from gnueabi (crux arm) to gnueabihf (crux armhf). I hope that my sum-up can help you to "normalize" my work in a Makefile.
This last week I put hands on hardfp and there is a little development born from the first Makefile with hardfp suppport I did in May and a mix with your patches.
1) after a fresh crux arm 2.7-test1 installation (i always worked natively i.e. directly using the efikamx) i bumped the toolchain to gcc-4.6.x and glibc-2.13 here used ports and sources: http://cruxppc.org/~acrux/arm/2.7-SOFT/ports.tar.bz2 http://cruxppc.org/~acrux/arm/2.7-SOFT/src/
You know that we are trying to let other people (may be none will use it, but we try to give the option to all users/developers outhere) build their custom toolchain and then crosscompile at least the core ports. We now provide a cross-build for hardfp too. It needs to be tested directly in the toys (task for this weekend). You can find all the info directly in gitweb and here (prebuilt RC and kernel) http://crux-arm.nu/files/devices/efikamx/hardfp/
2) i now started from scratch (CLFS way) to bump to gnueabihf that's totally incompatible with gnueabi. Ok, my bad i did't keep a trace of my steps neither i did a Makefile like your ones (i'm lazy and i'm not a coder thus i don't use to write scripts for every kind of task i've in my mind...). Anyway i did like an updated CLFS for ARM. I know i'd have written it as it isn't yet in existence i guess because only now ARM achieved enough strenght and a "desktop status" capable to autonomously build sources.
Well, about coding, I can tell you that I'm not a coder either. The Makefiles are the same, or at least really similar. It's a good way to keep things homogeneous and it's good to have a "pattern" to follow to improve them. Your work could be done with some little changes. We follow the "CLFS way" to build the toolchain and it can be seen directly in all toolchain Makefiles. The eglibc discussion is a good one to think about (at least IMHO). Having options is a good thing for developers and users (I tried to start a uclibc toolchain but there is no interest by other people to help/test/develop)
Well this is the point, to bump to gnueabihf i used to do like CLFS that's quite different from a CLFS-sysroot as your standard Makefile does. Or i simply misunderstood your modus operandi and i was in lack of a step using the Makefile approach.
Ok, the step that i needed for was to build a temporary system. From CLFS book: [...] The tools in this chapter are cross-compiled using the toolchain in /cross-tools and will be installed under the ${CLFS}/tools directory to keep them separate from the files installed in Installing Basic System Software and the host production directories. Since the packages compiled here are temporary, we do not want them to pollute the soon-to-be CLFS system. [...]
CLFS really provide a good way to build a custom toolchain and a copuple of needed software to boot a minimal system. We took the toolchain info and built a custom one. For the minimal system, we use CRUX core ports using this toolchain.
After which i was able to succesfully build my full working gnueabihf CLFS system. As i wasn't sure to have a stable system i didn't include graphite support in that toolchain.
3) i transformed that CLFS in a CRUX system. here used ports and sources: http://cruxppc.org/~acrux/arm/2.7-HARD/arm-ports.tar.bz2 http://cruxppc.org/~acrux/arm/2.7-HARD/src/
Well, from CLFS i already choosed to use eglibc as this ARM ABI's flavour is better supported.
Here I have been fighting with glibc and seems to be built right but the real test will be when we boot the system.
4) i updated the system and i added the graphite support (with isl built-in backend). here used ports and sources: http://cruxppc.org/~acrux/arm/2.7-HARD/1/arm-ports.tar.bz2 http://cruxppc.org/~acrux/arm/2.7-HARD/1/update/arm-ports.tar.bz2 http://cruxppc.org/~acrux/arm/2.7-HARD/1/src/
This is really interesting. Now with a hardfp release, may be it can be possible to make an overlay for this kind of optimizations and provide a document where we can explain how to act (updating ports and rebuilding the necessary) This will be the next step, but really I need to focus first in getting the system running in a "stable" state.
5) about this toolchain: a stable toolchain for ARM isn't really yet available... http://sourceware.org/ml/binutils/2011-09/msg00162.html http://gcc.gnu.org/ml/gcc/2011-09/msg00361.html
Yes, it's quite new and this will need to be improved. Let's see if the custom toolchain built by our side can give sight to hardfp implementation in any sense. Thank you very much for all your work. It provided a good way to follow in versions and patches used. You can check the Makefile and look that it's really similar to the eabi/noeabi/uclibc ones.
cheers, --nico
Regards, Victor. --- Learning bit by bit Victor Martinez | http://lokalix.dyndns.org
participants (2)
-
acrux
-
Victor Martinez