OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: enodr on April 20, 2006, 04:17:14 pm
-
I was wondering if pdaxrom apps would run under openzaurus gpe and vice versa?
If my understanding is good, the two roms are running x11, so they sould be able to run the same apps?
-
I was wondering if pdaxrom apps would run under openzaurus gpe and vice versa?
If my understanding is good, the two roms are running x11, so they sould be able to run the same apps?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=123946\"][{POST_SNAPBACK}][/a][/div]
I would think that you would typically have to recompile pdaXrom apps (and it's dependancies) for OZ's newer kernel. Someone correct me if I'm wrong.
-
I was wondering if pdaxrom apps would run under openzaurus gpe and vice versa?
If my understanding is good, the two roms are running x11, so they sould be able to run the same apps?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=123946\"][{POST_SNAPBACK}][/a][/div]
I would think that you would typically have to recompile pdaXrom apps (and it's dependancies) for OZ's newer kernel. Someone correct me if I'm wrong.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=123953\"][{POST_SNAPBACK}][/a][/div]
I think that problem is not kernel but newer glibc in OZ
-
From what I have seen OpenZaurus has a glibc compatibility library to run original Sharp ROM apps.
That would be so fantastic to have a common app feed for OZ GPE and PdaXrom. Don't you agree?
-
That 'compatibility library to run original sharp rom apps' are libqte/libqpe which are not even supposed to work correctly due to hardfloat/softfloat change.
Feed for OZ/GPE and PdaX... OZ/GPE can probably run pdaX stuff (if you install all deps by hand due to lack of dependencies info in some of pdax packages) but not vice-versa due to glibc difference.
-
I think Oz and pdaxrom also use different softfloat libraries
PS:
hrw please stop this, lack of dependencies exist for packages contributed by users but dependencies do exist in the pdaxrom feed....
I can also point you to Oz threads about packages installation and dependencies problem if you want
You're progaganda will be much more effective if you spend your time documenting the strong points of OZ (and OE) rather than trying to bash other distributions on things that people can easily notice are not true (when they care about those things)
-
hrw please stop this, lack of dependencies exist for packages contributed by users but dependencies do exist in the pdaxrom feed....
The main issue I've met when trying to install pdaX ipks is that the control file format is different - afair it lacks fields that the OZ version of ipkg requires. In addition, iirc, the arch setting is either not present or not right (for OZ) to allow the files to install without hacking them around.
With that said, things may have changed with pdaX since I last tried this (probably two minor releases ago.)
Regarding hrw's point - iirc the names of packages under pdaX sometimes differ from the OZ names - this does cause problems and means that the deps will probably need to be hacked.
Si
-
I'd say the problem is IPKG v0.99 in OZ (painfully SLOW ! not standard targz ipks !). But on the other hand the strong point of OZ is the 2.6 kernel and the newer glibc.
You're right about floating point format too. I found that glibc from OZ uses FPA, while pdaX is all softvfp (a very logical choice if you ask me). OZ builds arm- targets rather poorly optimized, but it's because they need compatibility with old zaurus OZ was originally created for. There are -mtune xscale but no -mcpu targets, and no iwmmxt. This is all because of untested bitbake configs (don't they have a single SL-Cxx00 ?). Softfloat seems totally messy to me as well. With GCC from the OZ devel/ feed, a simple printf("%f \n", 5/2); will print 3.0000000000 (!!) if you try any PXA270 optimization flags (-mcpu xscale or -mcpu iwmmxt or softvfp). The best thing to do would be to have the same GCC build settings, and softvfp everywhere, because it's what will work best on XScales.
Do not be hard on OZ, though. Their 2.6.16 kernel is far better, it probably required a lot of work, and it suspends PERFECTLY well, and very fast with that.
-
I'd say the problem is IPKG v0.99 in OZ (painfully SLOW ! not standard targz ipks !).
I think, though may be wrong, that this is probably related to the size of the feed databases for OZ compared with pdaX. I'm pretty sure that OZ has more packages listed which just means that it takes longer to parse them, etc.
You're right about floating point format too. I found that glibc from OZ uses FPA, while pdaX is all softvfp (a very logical choice if you ask me). OZ builds arm- targets rather poorly optimized, but it's because they need compatibility with old zaurus OZ was originally created for.
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.
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.
and no iwmmxt
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.)
With GCC from the OZ devel/ feed, a simple printf("%f \n", 5/2); will print 3.0000000000 (!!) if you try any PXA270 optimization flags (-mcpu xscale or -mcpu iwmmxt or softvfp). The best thing to do would be to have the same GCC build settings, and softvfp everywhere, because it's what will work best on XScales.
Interesting!? Did you try to run the resulting binary on a pdaX system? This might be the cause of the problems.
Si
-
I'd say the problem is IPKG v0.99 in OZ (painfully SLOW ! not standard targz ipks !).[div align=\"right\"][a href=\"index.php?act=findpost&pid=124028\"][{POST_SNAPBACK}][/a][/div]
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)
-
The main issue I've met when trying to install pdaX ipks is that the control file format is different - afair it lacks fields that the OZ version of ipkg requires. In addition, iirc, the arch setting is either not present or not right (for OZ) to allow the files to install without hacking them around.
With that said, things may have changed with pdaX since I last tried this (probably two minor releases ago.)
Regarding hrw's point - iirc the names of packages under pdaX sometimes differ from the OZ names - this does cause problems and means that the deps will probably need to be hacked.
Si
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124014\"][{POST_SNAPBACK}][/a][/div]
Didn't think my question would raise such an interesting thread. I am new to the Zaurus and didn't understood well what where the real differences between all those ROMs. It's interesting to have all those technical details about the "internals" of OZ, pdaXrom or other.
As for the ipk format, as a user, but also as a hobbyist developper, I would love that the two ipks feeds could be compatible; I see apps available in pdaXrom feed that I would like to run under OZ, and I am sure it's true on both sides for many users.
It would be a real progress if I could compile an app and package an ipk that both OZ and pdaXrom users could use.
I'd like to read some comments about this from you guys the OZ and pdaXrom developpers. Would it be really to much complicated to unite the ipk feeds and solve those (small?) details pointed out above (cf quote)?
-
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 (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 ?)
-
You are being disrespectful. http://www.handhelds.org/moin/moin.cgi/Ipkg (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 ?)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124059\"][{POST_SNAPBACK}][/a][/div]
1) OE isn't a ROM
2) your 'ROM" isn't even a ROM, but writeable flash
3) sharprom and cacko are *really* small compared to the other ipkg based distros in wide use, so yes, ar wrapped tarballs are the standard, not the 5 year old crap the sharprom is using.
-
Koen: As always you make good and polite comments/statements which are well thought out and explained in a friendly manner.
Again look at pgas posting above...
-
Koen: As always you make good and polite comments/statements which are well thought out and explained in a friendly manner.
Again look at pgas posting above...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124100\"][{POST_SNAPBACK}][/a][/div]
I'm just responding to the lies you pdaX people are spreading. It's really easy to avoid my snide remark: STOP SPREADING LIES
-
I like koen comments! Write more pleaze!
-
There is absolutely no sense behind his comments. He is just so "intelligent" that he knows what a ROM really is (or should be) but not that there are no lies and an OS for zaurii is generally called "rom"... not because of the "Read Only Memory".
-
We all probally know what ROM is - thats just a problem that has rissen. The same is happing on emul scenes and stuff where ROMs and Diskimages etc. are mixed up. The pdaXrom name was choosen because we thought it sounded cool and i just rendered an X in 3D studio Max ;-)
But the problem is the tone in the comments - and what lies are we spreading Koen??? And why the constant badgering of pdaXrom and trolling in our forums - basically you should be trying to tell what good about the OZ instead of flaming all the others distros/solutions - it seems like the fact we are trying to make a userfriendly and easy to use ROM which also tries to make it easy for developers are upsetting many of the OZ/OE people. Why not just leave us and the pdaXrom users alone then - if the OZ/OE has something to offer they will probally make the switch themselves without the need for a flame of pdaXrom, right?
OZ/OE has many good things and so does the pdaXrom - users can choose and some people are even trying to combine the best of the different "worlds" - why all the hate and anger against our stuff. Okay so maybe some of the pdaXrom solutions and workarounds are not perfect or we don't use the lastest cutting edge stuff - but again it something is working okay why to fix - koen you remind me of a friend of mine who tried to flash his bios because it had a new feature (a feature he had no use for) - he ended up destroying his bios - if it ain't broke don't try to fix it.
That being said we are working on implementing the latest kernel and stuff like that and we sometimes look and learn at what you guys have implemented. Like you guys probally do at other distros - but isn't that the ideas behind Open Source/GPL etc.?
-
but isn't that the ideas behind Open Source/GPL etc.?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124126\"][{POST_SNAPBACK}][/a][/div]
True.
Nothing on this earth is perfect, including GPL and people. Let's all cool down, wait a day to respond, consider being more tolerant of our differences, not egging each other on, and keep our focus.
-
Let's all cool down, wait a day to respond, consider being more tolerant of our differences(.)
I second that.
-
it seems like the fact we are trying to make a userfriendly and easy to use ROM which also tries to make it easy for developers are upsetting many of the OZ/OE people.
No one in the OE/OZ team is "upset" that you use your own buildroot / environment and create your own images + feeds. However, the steps to setup and use your build-env would involve reading up on how to do that and "getting into it".
It is the same with OE. It's not hard or difficult to setup (pdaxrom guys usually make it sound it is, don't deny it, you just did ) but you have to sit on your butt and read the docs. It is in no way different than learning how to use your build environment if you never came in touch with it before.
Also some of us feel it is a sort of "waste" of ressources to create and maintain two different build environments / patch sets / whatever considering the few Zaurus devs available. But that's basically it, really.
Why not just leave us and the pdaXrom users alone then - if the OZ/OE has something to offer they will probally make the switch themselves without the need for a flame of pdaXrom, right?
OZ/OE has many good things and so does the pdaXrom - users can choose and some people are even trying to combine the best of the different "worlds" - why all the hate and anger against our stuff. Okay so maybe some of the pdaXrom solutions and workarounds are not perfect or we don't use the lastest cutting edge stuff - but again it something is working okay why to fix
You know, you *could* use OE to compile pdaXrom. While a few things might be missing currently, it wouldn't be much of a problem integrating them (as you already have all patches required for the missing bits anyway).
With OE you *could* have cutting edge stuff (or not, you can hard-wire the version of each single package if desired) while beeing binary compatible to the large OZ feeds. I believe pdaXrom users would benefit greatly from that move.
At the same time, the pdaXrom devs would benefit from the work of OZ devs and vice versa, eleminating the splitt of ressources in our community.
But I fear the bad feelings between OZ/OE and pdaXrom sort of rule that out, which is a pity, really.
That being said we are working on implementing the latest kernel and stuff like that and we sometimes look and learn at what you guys have implemented. Like you guys probally do at other distros - but isn't that the ideas behind Open Source/GPL etc.?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124126\"][{POST_SNAPBACK}][/a][/div]
Exactly, and using identical build environments would simplify that a lot
-
You are all realy talented people and I belive you will continue to do great thing for this Zaurus community.
-
So where are we going from here? The Zaurus community would really benefits from a move towards compatibility, but apart from flame wars I don't see anything constructive... Too bad. I guess I have now to "choose" my camp between PdaXrom and OZ (ok OZ has my vote but I would have really loved to install those ipks contributed by pdaXrom users...).
-
So where are we going from here? The Zaurus community would really benefits from a move towards compatibility, but apart from flame wars I don't see anything constructive... Too bad. I guess I have now to "choose" my camp between PdaXrom and OZ (ok OZ has my vote but I would have really loved to install those ipks contributed by pdaXrom users...).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124228\"][{POST_SNAPBACK}][/a][/div]
Ångström (the successor of OZ) will use EABI, which is as compatible as you can be in the ARM world. We are working with the debian-arm and maemo people to fix eabi issues and to be compatible with them as well.
And if you take a look at OE you see that >90% of the pdaX contrib feed is in OE as well. It shouldn't be much work to add the remaining 10%.
pdaX team: please stop saying stuff like this:
That being said we are working on implementing the latest kernel and stuff like that and we sometimes look and learn at what you guys have implemented.
You've been harassing our developers about that and imposing silly demands on our kernel hacker, so essentially *we* are implementing 2.6 for pdaX, so stop being jerks and give us the credit we deserve.
-
You've been harassing our developers about that and imposing silly demands on our kernel hacker, so essentially *we* are implementing 2.6 for pdaX, so stop being jerks and give us the credit we deserve.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124245\"][{POST_SNAPBACK}][/a][/div]
As a modest sponsor to both OZ and pdaXrom I would in no way benefit from a flame war, really now.
But I feel that remark of yours needs further clarification.
Please substantiate and be constructive and polite.
Peace.
-
when koen dream, we make and use it. Koen where in OZ overlays, overcloking, different screenmodes, optimized X, etc? So its not pdaXrom uses old software, but OZ. When koen says they will use softvfp, we already use it more than year. Koen talking bot.
So where are we going from here? The Zaurus community would really benefits from a move towards compatibility, but apart from flame wars I don't see anything constructive... Too bad. I guess I have now to "choose" my camp between PdaXrom and OZ (ok OZ has my vote but I would have really loved to install those ipks contributed by pdaXrom users...).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124228\"][{POST_SNAPBACK}][/a][/div]
Ångström (the successor of OZ) will use EABI, which is as compatible as you can be in the ARM world. We are working with the debian-arm and maemo people to fix eabi issues and to be compatible with them as well.
And if you take a look at OE you see that >90% of the pdaX contrib feed is in OE as well. It shouldn't be much work to add the remaining 10%.
pdaX team: please stop saying stuff like this:
That being said we are working on implementing the latest kernel and stuff like that and we sometimes look and learn at what you guys have implemented.
You've been harassing our developers about that and imposing silly demands on our kernel hacker, so essentially *we* are implementing 2.6 for pdaX, so stop being jerks and give us the credit we deserve.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124245\"][{POST_SNAPBACK}][/a][/div]
-
I have also contributed in the past, and will do so again.
In return I want the best software possible for my Zaurus, with full understanding of the limited resources available to the various developer teams.
That might happen a bit quicker, and the donations come more often, if you would cut this "my dick is bigger that yours" crap, and cooperate.
Thanks,
Mike.
-
Uhm.... i think that now that i' m understanding more and more the Sash work, there are many differences of implmentation between OZ and PdaXrom.
Version of libraries used, kernel, more and more.
Now, as all envs are fortunately opened you have only to choose your favourite depending on what you want to do and contribute in that env.
The reasons of my choice are 2.
1) I would like to use the same distribution for all the devices.
2) Packages for PdaXrom are easy to cross-compile and ROM builder is understandable and usable for a beginner like me thx to Sash.
Probably if OZ-GPE was like that, i would have chosen that way.
So for the OZ-GPE and other ROM developers, do not feel upset if someone does a interoperability or cross-ROM questions, but, please, only answer people questions, right or wrong they could be.
Remember that you all are using software developed from other people too and only ported for a 80% of time.
So doing this kind of war is something ridicolous.
We have to thank all from LinuS to GPE-Guys instead.
This is what i think.
-
when koen dream, we make and use it. Koen where in OZ overlays, overcloking, different screenmodes, optimized X, etc? So its not pdaXrom uses old software, but OZ. When koen says they will use softvfp, we already use it more than year. Koen talking bot.
Sashz: you got working 2.6 kernel from OZ team as a base and started hacking on it. Without our kernel hackers you would not get it at all... Our way is to get working kernel first, push as-much-as-possible into mainline and then add some features which are not available/enabled.
Soft-float is used in OZ since few months before OZ 3.5.1 was released.
-
when koen dream, we make and use it. Koen where in OZ overlays, overcloking, different screenmodes, optimized X, etc? So its not pdaXrom uses old software, but OZ. When koen says they will use softvfp, we already use it more than year. Koen talking bot.
Sashz: you got working 2.6 kernel from OZ team as a base and started hacking on it. Without our kernel hackers you would not get it at all... Our way is to get working kernel first, push as-much-as-possible into mainline and then add some features which are not available/enabled.
Soft-float is used in OZ since few months before OZ 3.5.1 was released.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124444\"][{POST_SNAPBACK}][/a][/div]
softfpa which OZ use not the same as softvfp.
RP already got my patches back.
-
OMG, c'mon enough, all the builds are really nice builds, all have thier benefits, and I thank all of you for them. While the arguements go on, M$ grabs more of the market, and eventually Sharp will drop linux as an OS for Zaurii, thats fairly apparent because the differences between the C1000 to the new 3200 are barely noticeable. Dont get me wrong, I am no developer(in the sence of linux app. dev'ing)
Bottom line, doesnt matter what team said what, be professional about comments. Because being rude or not-very-professional will turn off a user to try your 'version', even if it is the best one out there.
-
OMG, c'mon enough, all the builds are really nice builds, all have thier benefits, and I thank all of you for them. While the arguements go on, M$ grabs more of the market, and eventually Sharp will drop linux as an OS for Zaurii, thats fairly apparent because the differences between the C1000 to the new 3200 are barely noticeable. Dont get me wrong, I am no developer(in the sence of linux app. dev'ing)
Bottom line, doesnt matter what team said what, be professional about comments. Because being rude or not-very-professional will turn off a user to try your 'version', even if it is the best one out there.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124453\"][{POST_SNAPBACK}][/a][/div]
Right Bam, concentrate your effort in porting Linux to other beautiful machines as the tool i bought now, i.e. NTT Docomo Sigmarion III, instead of fighting like that.
No matter ROM is, developing toghether is better than fighting.
As an example, for my Jornada i use Familiar 0.8.2 that is an excellent distribution too and supports many hardware devices with a big feed, i used this on my Ipaq 3970 time ago.
I would really thanks again all people developing for their efforts who has brougth me to this beatuiful world of Embedded devices.
BYEZ!
-
As an example, for my Jornada i use Familiar 0.8.2 that is an excellent distribution too and supports many hardware devices with a big feed, i used this on my Ipaq 3970 time ago.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124476\"][{POST_SNAPBACK}][/a][/div]
You do know that was built using OE by me, right?
-
As an example, for my Jornada i use Familiar 0.8.2 that is an excellent distribution too and supports many hardware devices with a big feed, i used this on my Ipaq 3970 time ago.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124476\"][{POST_SNAPBACK}][/a][/div]
You do know that was built using OE by me, right?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=124491\"][{POST_SNAPBACK}][/a][/div]
It' s another brick in the wall i would like to contribute to, so stop this kind of war pleeze, it' s useless.
-
No matter ROM is, developing toghether is better than fighting.
Amen to that.
-
How OZ people hate me / pdaXrom - get the facts:
They calls my patches ugly unprofessional hacks etc.. Than RP adds untested and with more ugly stuff (based on the same intel patch) inside, and that is cool - now OZ have cool nice professional path ( http://www.rpsys.net/openzaurus/patches/px...verlay-r0.patch (http://www.rpsys.net/openzaurus/patches/pxa27x_overlay-r0.patch) ) !