OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: Miami_Bob on December 23, 2005, 03:11:43 pm
-
Trivial but I'm curious. I understand that the "v5tel" has something to do with being for pdaXrom, but EXACTLY what makes a package a "v5tel" vs one that is not?
TIA!!
Happy Holidaxe of your choice!
-
v5tel is part of the Xscale/Arm arch.
v5 means 9 so it is ARM9 there also ARM7 and ARM11 but ARM9 is the most popular on pda and smartphones
-
v5tel is part of the Xscale/Arm arch.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=108252\"][{POST_SNAPBACK}][/a][/div]
Thanks muchly, urielka! And QUICK! Wow.
I thought it would be something along that line. So a plain "Package.ipk" might be actually no differrent than a "Package_v5tel.ipk" where as the latter is specificly (according to the packager) for the ARM5 line of processors. Not necesarily for pdaXrom itself?
Thanks again & Seasons Greetings.
-
if v5tel is not metion it could mean anything either the packager didn`t put the arch or it is for all arm(ARM7+)
-
So a plain "Package.ipk" might be actually no differrent than a "Package_v5tel.ipk" where as the latter is specificly (according to the packager) for the ARM5 line of processors. Not necesarily for pdaXrom itself?
Reminds me of the thread from ages back just after the PXA machines were introduced where we tried to establish some naming conventions for the myriad files floating about. Since then most of the images have moved to using feeds so there's less of a problem.
Depending on your version of ipkg, the name of the file itself may or may not make any difference (newer versions are generally more fussy which is good imho). There is also an 'arch' field inside the ipk file in the control file which should match the arch in the ipkgfile name.
I don't know what the significance of the 'l' is on v5tel. OZ packages built specifically for the c7x0 (PXA) have the suffix 'armv5te'. I seem to remember that packages built for the Nokia 770 have a 'j' somewhere in the suffix.
Si
-
v5 means 9 so it is ARM9 there also ARM7 and ARM11 but ARM9 is the most popular on pda and smartphones
(I think) This is a slight confusion between the core (ARM7/9/11) which is a chip design, and the instuction set which the core runs (armv4 for StrongARM cores, armv5 for PXA and later cores and possibly for some earlier ones too).
It suddenly dawned on my what the 'l' means - littleendian, in the same way that a 'b' would mean bigendian. (I wonder why my OZ toolchain produces armv5te with no 'l')
I presume the 't' stands for 'thumb', the 'e' I'm not sure about, but perhaps 'extended'?
I think the 'j' on the Nokia 770 stands for 'Jazelle' which is an ability of the processor to execute Java bytecode directly (though looking at my gpe build for the Nokia, I have armv5te with no 'j', I wonder where I saw it).
If anyone has a definitive list that would be interesting (I imagine the arm related GCC docs will be the place to look for those who might be interested).
Si
Edit: It would appear that armv5te is correct according to the GCC docs as it matches one of the allowable -march settings. Still not too sure about the meaning of the 'e' though
-
I believe E indicates it has been DSP enhanced.
-
armv5 says that it will work on arm9+
armv4 says that it will work on arm7+
for xscale+ there something else.(i don`t remember but it is connected to iWWMX)
-
all the above are pretty much correct, however it gets tricky when you come up against the arm 7 and arm 9
arm 1 to 7 is a family of processors/instruction sets
arm 9 to 11 are implmentations of the above
arm 11 is capable of SMP (multi cpu up to 666Mhz) whereas arm 7 is aimed at you typical mp3 player and tops out at about 100Mhz (aprox, some vendors ship faster thatn that) arm 9 sits in the middle
xscale is a funny beast and a hated one in the market, it has the best performance and the lowest performance to watt ratio. the standard arm chips are nothing compared to it . this is due to intel trying out the 90nm process and low leakage transistors on the Xscales before it makes its way to the pentium series
anyway keeping this short, xscale should run arm 4 and arm 5 binaries that do not use the jazzelie or enhanced dsp instructions (intel uses iwmmxt to do that), where as iwmmxt will run the above AND allow you to use iwmmxt binaries
iwmmxt = integer SSE and MMX roled into one with some extra instructions, think of a usefull mmx on steriods and you will be close
and no there is no floating point processor for xscales by defualt, intel wont make one (i have asked) and for the 3rd party ones linux dosent support them , convert your code to integer instead
-
or use soft-foalt but converting to integer will give you alot more preformance.
iwmmxt could be use as a fast way to use a fast emulated floating point.
-
Thank you all, each & every one. Just the sort of info that I wanted.
There is also an 'arch' field inside the ipk file in the control file which should match the arch in the ipkgfile name.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=108274\"][{POST_SNAPBACK}][/a][/div]
Have noticed that many of the fields that should be in control are often missing, Si. However, since I have such a knowledgable crowd (G) this brings me off topic to another question that has been on my mind.
I have seen packages where the depends field in control is blank, yet the installer says the package has depends (no list of what they are, of course). Since the data are not in control, where exactly does the installer get the info from?
The only way that I can figure is that the installer is looking inside the files in the package in some way.
Anyone know the correct answer?
THANKS! Happy Holidaze!
-
I have seen packages where the depends field in control is blank, yet the installer says the package has depends (no list of what they are, of course). Since the data are not in control, where exactly does the installer get the info from?
It may be that ipkg only looks inside the files if it has too (though this is just a guess). All of the data from each control file should also appear in the Packages(.gz) file in the feed. It may be that the feed you're using has a complete Packages file (which it's using), but incomplete control files.
Just a guess.
Si
-
It may be that ipkg only looks inside the files if it has too (though this is just a guess). All of the data from each control file should also appear in the Packages(.gz) file in the feed. It may be that the feed you're using has a complete Packages file (which it's using), but incomplete control files.
Just a guess.
Si
[div align=\"right\"][a href=\"index.php?act=findpost&pid=108585\"][{POST_SNAPBACK}][/a][/div]
Hey, Si. Can't be feed cause my Zs do not go on line by themselves. I'm on a 56K dial up & have never bothered to go to the work (or $) of giving the C860s an outside connection. So all the ipks that they have seen are from CF card.
Tnx for the idea, though.
-
according to this post:
http://slashdot.org/comments.pl?sid=34661&cid=3750803 (http://slashdot.org/comments.pl?sid=34661&cid=3750803)
The new XScale parts are ARMv5te, the T is for the 16-bit Thumb
instruction set, which no one seems to care about. The "E" adds
some DSP oriented instructions that are pretty interesting for
media codecs and such. They are the MMX equivalent for the ARM
world. They likely won't improve performance of the general
purpose aspects of the platform.
From what I could gather while searching around the "l" seems to mean
little-endian (armv5teb would mean big-endian)
-
according to this post:
http://slashdot.org/comments.pl?sid=34661&cid=3750803 (http://slashdot.org/comments.pl?sid=34661&cid=3750803) ........
From what I could gather while searching around the "l" seems to mean
little-endian (armv5teb would mean big-endian)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=108636\"][{POST_SNAPBACK}][/a][/div]
Thanks muchly, pgas, for taking the time & trouble to find that ref. Very informative thread!
But, if the "i" means "little-endian", I guess we can never aspire to becomming Chiefs, eh?
(yes, yes; I really do know what it means ..... G)
Prosperous 2006!!
-
This thread actually brings another question to my mind : I compile loads of stuffs for iWMMX PXA270 but always name them armv5tel. Does anyone know if there is another suffix for such extensions (like the "j" for java insctructions mentioned earlier) ? It would avoid a few Cx60 users some "Illegal Instructions" errors ...
-
you should be using Xscale for -march=xscale and iwmmxt for -march=iwmmxt compiled programs
most iwmmxt programs should work on the xscale processors without problems as all it adds are the iwmmxt instruciotns and diffrent cache sizes, and as programs have to be written for iwmmxt support it shouldnt be a problem for 99.999999999999999999999% of linux programs out there (only one i can think of is the iwmmxt mplayer)
but if the cx60 guys are getting problems try compiling for xscale or use the iwmmxt tag
-
you should be using Xscale for -march=xscale and iwmmxt for -march=iwmmxt compiled programs
most iwmmxt programs should work on the xscale processors without problems as all it adds are the iwmmxt instruciotns and diffrent cache sizes, and as programs have to be written for iwmmxt support it shouldnt be a problem for 99.999999999999999999999% of linux programs out there (only one i can think of is the iwmmxt mplayer)
but if the cx60 guys are getting problems try compiling for xscale or use the iwmmxt tag
[div align=\"right\"][a href=\"index.php?act=findpost&pid=109001\"][{POST_SNAPBACK}][/a][/div]
gcc 3.4 with turned iwmmx uses iwmmxt ops for 64bits (long long) math, so if program uses it it will hang on non wmmx cpus.
-
Yes, yes but it is not the point. The problem here is the naming convention. Should we name the IPK of a iwmmx compiled program armv5tel, or something else (like armv5teli ?) so that Cx60 users don't download packages that will not work on their zaurus.
-
you should be using packagename-xscale for -march=xscale and packagename-iwmmxt for -march=iwmmxt compiled programs