Yes, the packages in the feeds are all arm4 because OZ supports a range of hardware and only uses one feed. What does pdaX do (it supports the 5500 I thought)? That said, if you build your own packages for a given machine, they are optimised for that arch automatically.
You're right about that, OE does support a lot more machines. But the point is, why one single armv4 feed (well, convenience for maintenance and disk space may be reasons, but still.) Building the whole OE is not something everyone will want to do. I can tell because I actually did it once, and only the bootstrap image. It took time, and a lot of disk space. I just wanted a 121MB / partition.
Yes, fpa vs vfp - vfp is probably faster (I'd be interested to see benchmarks actually) and certainly makes programming/cross-compiling easier (the floating point data have the same endianness as the processor with vfp, with fpa they are always little endian iirc). vfp will be supported once th eabi toolchain is up and running. I must look at the patches that pdaX uses to implement vfp for its toolchain when I have some time.
Once again, you're right, there won't be a big improvement (in a 0~10% range, is fp is used at all of course), but still it would be better if we could have everything running vfp, which is the recommanded option for the platform. Having "Cannot link /tmp/X.o because libc6... uses FPA while ... does not" is not a friendly error, it means "go and rebuild your whole toolchain" (my mistake trying to make a working and optimized GCC4.1.0 vfp toolchain...)
My understanding was that this is a hack that is 2.4.x only? Still, something is probably necessary under 2.6.x (I don't have one of these machines so I don't know much about it.)
I don't think so... I even found a enable_iwmmxt-r0.patch for 2.6.16 somewhere in the OE commits, but everything is so "complicated", sashz working alone doesn't have those problems. While we're at it, you made mention of EABI toolchains. The iwmmxt EABI in GCC 4.1.0 (and CVS) with glibc 2.4 is supposed to be improved, according to changelogs. You have to edit a little bit to get vfp working. I couldn't make it work with the OE build system, but I just probably don't know exactly how it works. But it would be great if someone could manage to build the armv5te iwmmxt EABI toolchain.
Interesting!? Did you try to run the resulting binary on a pdaX system? This might be the cause of the problems.
No, in fact it was with OZ 3.5.4.1-alpha2. But I might have played a bit with -mfloat as well, maybe to try making vfp work. I will test it again to find the exact cause of the problem.
Standard .tgz? What crack are you on? ipkg has been using ar-wrapped tarballs for years now, so the *standard* is what OZ is using. pdaX is using a *non*-standard ipkg format. Please get your facts straight before posting nonsense. (ask the ipkg author if you don't believe me)
You are being disrespectful.
http://www.handhelds.org/moin/moin.cgi/Ipkg doesn't impose ar wrapped ipks at all. It only says gzipped ipks are a waste of CPU, which is true. By "standard", I only meant the most used. The Sharp ROM and Cacko used targz ipks last time I checked. Do not forget that OE isn't the only ROM around. And I'm not on crack, I'm just on patching GCC and glibc (is that worst ?)
