* 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