OESF Portables Forum
General Forums => General Discussion => Topic started by: spartan on October 29, 2005, 03:40:36 pm
-
Is there an English how-to for compiling any version of GCC that supports iWMMXt (not 2.95.3) for Tetsu's C1000/3000/3100 kernels for Sharp Rom? I'm using a clean Debian installation and have tried everything from Atty's walk-through to Crosstool. Nothing works, and it seems like there are an infinite number of patches to apply.
-
Open embedded builds its own tool chain if i am not mistaken, and cross tools should automate the process after a bit of text file hackery.
i had a problem with cross tools but it was a gcc problem and not the script (i belive, got a build failed)
lets see if we can get the cross tools stuff working, what exactly didnt work?
-
Is there an English how-to for compiling any version of GCC that supports iWMMXt (not 2.95.3) for Tetsu's C1000/3000/3100 kernels for Sharp Rom? I'm using a clean Debian installation and have tried everything from Atty's walk-through to Crosstool. Nothing works, and it seems like there are an infinite number of patches to apply.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=101288\")
Here is the toolchain, which can build Tetsu kernel with iwmmx patches.
[a href=\"http://cacko.oesf.org/downloads/iwmmx/arm-cacko-linux-gnu-2.95.3-2.2.5-hardfloat-19.50_21.09.05.tar.bz2]http://cacko.oesf.org/downloads/iwmmx/arm-...1.09.05.tar.bz2[/url]
-
Why does everyone keep using 2.95, i thoght we would be using a 3 series or even 4 by now.
-
Why does everyone keep using 2.95, i thoght we would be using a 3 series or even 4 by now.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=101582\"][{POST_SNAPBACK}][/a][/div]
That's the only way to build a working 2.4.x kernel for Zaurus.
-
so they are alright for those going to the 2.6 one right?
-
That's the only way to build a working 2.4.x kernel for Zaurus.
Though I have seen some patches floating about which might allow GCC 3.x.x to build that kernel - I don't think we don't use them in OZ though so there may be an issue with them still.
2.6.x kernels are built using GCC 3.x.x
Si
-
so they are alright for those going to the 2.6 one right?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=101624\"][{POST_SNAPBACK}][/a][/div]
Sure
-
Thanks for the replies. Sorry for the late response though: I've gone through maybe fifty compilations for something to post about.
My goal is to have a GCC compiler that outputs ARM code with iWMMXT instructions (the "--mcpu=iwmmxt" flag?), much like Atty compiles MPlayer with iWMMXT instructions. As much as I understand, the compiler outputs iWMMXT code the same way it outputs Thumb code: it expresses some C++ code as a different kind of instructions as an optimization. This precludes the need for GCC 3.4.0 or later.
I've been working on making crosstool (0.38) work, and I've tried the following configurations to no avail: GCC 3.4.0/3.4.1/3.4.2/3.4.3/3.4.4 with GLIBC 2.1.3/2.2.2 with binutils 2.15. Those configurations seem most appropriate, and while I've tried a GCC 4.0.0/GLIBC 2.2.2 configuration, it doesn't support iWMMXT without a patch, one that I can't figure out how to incorporate into the crosstool system. I've tried this in both Cygwin and a fresh Debian-Sarge installation with similar results.
As far as I know, anything GCC earlier than 3.4.0 won't optimize with iWMMXT instructions and any GLIBC later than 2.2.2/Kernel later than 2.4.6/18/20 won't work on the Zaurus. I also don't know how to make crosstool use Sharp's kernel headers (or in this case, C3000 kernel sources + Tetsu's patches) when compiling GCC.
Thanks for the help again.
-
Wait for sound support under 2.6, joke aside i would be intrested to know how well gcc takes advatage of the iwmmx instructions, does it even use them at the moment you could use the arm5 instruction set but i belive you are like me and wants to put performnace at the top of you list
with cross tools cant you kill it when it gets to the compile stage, apply the patch and then when it reruns it dosent download because you have the files localy or does it always downloaad the latest version
if it does you would probely have to work out where to put a readline statment to wait for user input once it has uncompiled so that in another shell you can jump in and apply the patch
-
found a fix, compile once using demo-arm-iwmmx.sh wait for it to bail, go to the directory with the broken file, edit the file in question (version-*.h) to fix delete the " that are on the line by themselves, then add \n\n" to the lines that dont end in a " and then compile
however leve a terminal in that directory so it cant be deleted, as the begining of each recompilation deltes everything. this will keep your changes but allow you to compile
have fun im in the middle of compile the tool chain now scince i didnt have much luck with OE
-
Thanks,
I've checked the build matrix, so my question now is how late of a GLIBC version is functional on the Zaurus? Meaning, will 2.2.5 or 2.3.5 work?
-
Thanks,
I've checked the build matrix, so my question now is how late of a GLIBC version is functional on the Zaurus? Meaning, will 2.2.5 or 2.3.5 work?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=103385\"][{POST_SNAPBACK}][/a][/div]
It depends on which Z distro you are targetting. Stock SHARP ROM uses 2.2.2, pdaXrom has moved on a bit but still is on the 2.2.x version. OZ is prolly on 2.3.x somewhere but I haven't checked. Debian arm is on 2.3.2. Not sure what the other distros are using...
-
ran into another problem that needs a patch, once ive compiled it i should have a 4.0.1 toolchain with glib 2.3.2 ready for compiling the 2.6.14 kernel tree. once that is done im posting it here so no one else has to go throgh the horrors i have to get it working
basically crosstool is not as easy to use as they make it out to be, everytime you run the script it deletes the files and starts again, meaning you have to redo any manually done patches, this is not normally a problem if everything goes right however if you are like me and everything goes wrong then this means you end up compiling the stuff that works 10 or more times and get stuck on the last thing to compile which forces you to start over agian
so i am thinking of compiling it by hand, more news in a couple of days, hopefully this works and my sanity dosent leave me
-
ok finally after about 20 attempts and a total combind time of 12 hours (at least, including faliures) i have a cross compiling toolchain, --with-cpu=iwmmxt gave some problems
at the moment its gcc 4.0.1 with glib 2.3.2 this means you cant compile the 2.4 kernels far zaures's you will need a 2.95 gcc which is avalible
file size is 41MB bzip2'ed and 28MB bzip2'ed and strip --strip-unneeded to remove debugging and other uneeded symodols, this means if you get an error dont even try to debug the toolchain, all i ahve to do is find somewhere to put it then i will post the links for the 2 versions, download the one that fits you download limit most approriatly
-
I have a working GCC 3.2.3 / GLIBC 2.2.5 toolchain for statically-linked binaries. That is pretty much useless, as it does not emit iWMMXT instructions.
However, what do I have to do to force the make command to use the arm toolchain?
-
I also have a working GCC 3.4.4 / GLIBC 2.2.5 iWMMXt toolchain, build without patches through crosstool.
Testing the hello and hello2 applications, both linked and static, yielded the following results:
$ ./hello1
Hello, world! LONG_MIN is -2147483648, PATH_MAX is 4096
$ ./hello1static
Illegal instruction
$ ./hello2
./hello2: error while loading shared libraries: libstdc++.so.6: cannot load shared object file: No such file or directory
$ ./hello2static
Illegal instruction
What does this mean?
-
did you issue your ./configure with a --build="your tool chain name here" and added CC="-mcpu=iwmmxt -march=iwmmxt" to tell it to use the iwmmx instruction,
just a side note but a program has to be written to use the iwmmxt instructions as they dont make up part of the default instruction set (its actually a co processor hanging off the coprocessor bus and interfaced using the coprocessor minipulation instructions for arm processor) all the march and mcpu will do is take into acount the instructions avalible and cache sizes as well as perfromace info for the iwmmxt platform to get more perfromance out ot it, ie you dont want you compiler assuming you have 64KB of cache when you CPU has only 32KB for Instructions