OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Angstrom & OpenZaurus => Topic started by: dansawyer on January 12, 2004, 12:29:23 pm
-
All,
This is a follow-up roadmap question. I read the referenced material and am still confused.
1. What is the next planned OpenZaurus \'release\'? WIll it be 3.4?
2. What kernel will it provide? kernel 2.4.18 or kernel 2.4.21?
(I assume it will be based of the 3.3.6 pre1 libs??)
3. Will there be an intermediate relasese after 3.3.6 pre1?
4. If so what kernel will it support?
Thanks,
Dan
-
At first let me tell you that for some of your questions there are no definitive answers, as most things depend on the \"community\", i.e. if someone does anything, then there will be something. If not, then not. So it\'s really hard to talk about things before they actually happen
Now to my personal view of the questioned points:
1.) Since the old buildroot is dead, there most likely won\'t be any more releases - neither unstable (3.3.x) nor stable (3.4). The next release will be 3.5.1
2.) If things go on like before (noone joining us to do kernel work), we will have to stick with 2.4.18-embedix forever... We\'d really like to ship 2.4.21-cl, but we need people to finish kergoths kernel work.
3.) No. 3.3.5 was supposed to be the last release, but right after the release I found a few nice things which I could fix in no time, so I release 3.3.6-pre1. Since experience with 3.3.6-pre1 is very good, we consider this as the final buildroot release.
4.) see 2.)
-
Thank you. This is making more sense to me; I am sorry to be slow.
If I may:
1. 3.5 is planned to be the first release with the new build system.
2. it will incorporate an up to date Opie.
3. it may not contain an updated kernel beyond 2.4.18xx
The final questions:
What are the newer Sharp releases based on? kernel? libs?
What prevents 3.3.5 from being compatible with later Sharp releases?
With other releases? such as Kompany, etc
Thanks,
Dan
-
Correct.
As far as we can tell at this point, it seems the SL-6000 will be released with gcc 2.95, Kernel 2.4.18-embedix, QtE 2.3.2/Sharp, Qtopia 1.5.4/Sharp.
3.3.5 (and 3.3.6-pre1 for his matter) is using gcc3.3x hence it\'s incompatible to all SharpROM based ROMs - but you can use the compatibility libraries for most commercial applications. For the rest... hey it\'s Open Source - they can just be recompiled with gcc 3.x.
Compatibility will be broken totally as soon as OZ starts to use uclibc and Opie going to Qt 4 anyway.
-
Mickeyl -] so just to be clear, in the 3.3.6-pre1 release did you compile the kernel with gcc3.3?
-
What prevents 3.3.5 from being compatible with later Sharp releases?
Mickey, are you sure? I thought OZ3.3.5 was compatible with the Sharp apps as it was compiled with GCC 2.95.3 (for the Sl5500 at least, it may be different for all the other machines), at the very least I was able to run all of my normal apps (inc opera, hancom stuff) without the compat libs.
My general round-up of compatibility issues for those who might want to know (or correct me if I\'m wrong):
GCC 3.x uses a different name mangling scheme to that of GCC 2.95 for C++ binaries. Therefore GCC2.95 binaries can\'t use GCC3.x libs, nor can GCC3.x binaries use GCC2.95 libs (I guess, I\'m not sure on this). Note this all applies to C++ only, C is fine afaik. If your app doesn\'t use libs then it will run fine on either with the caveat below:
A secondary (minor) issue is that OZ3.3.6pre1 uses libc 2.3, so any apps (inc C) compiled for this ROM can\'t use used on the earlier ROMs which use libc 2.2, but earlier apps can be used on the newer ROM (ignoring name mangling issues).
That\'s my understanding of the situation.
Si
-
Yes, there is an OZ 3.3.5 for collie compiled with gcc 2.95.3 - but that version is flaky so I tend to forget about it.
-
Erm... so if I understand things correctly, the nearest stable release is 3.6, right? Seems quite a distant prospect.
Mind you, I have no problem running testing, unstable or toxic-and-extremely-flammable releases but it would be nice if there was a current release with some kind of stamp of approval saying \"use this with confidence\".
I know there are too few people etc., I\'m not complaining in any way. What I would like is a simple, verifiable check-list of things that separate us from the \"next stable release\", whatever its number might be.
Thanks for all the hard work, in any case.
z.
-
Minimal TODO for next stable release (3.6.0):
- migrate all (~100) missing packages from OZ buildroot to OE
- integrate kernels and deviceisms into OE
- finish work on kernel 2.4.21, integrate all Zaurus specifics into one kernel and rewrite a few drivers
Additional TODO:
- switch to need( 8 ) based init
- graphical init + bootmenu for cooperating GUIs on dedicated VTs
- ...
Projected date with the current amount of developer resources: Not before Q4/2004. More developers == earlier.
-
are u going to re-write the SD kernel module? because Sharp doesn\'t provide the source...
can I help on the kernel bit? if I\'ve got the skills obviously... ;-)
-
The plan is to implement the SD module based on the driver in the handhelds.org CVS using the documentation for the SD controller that kergoth has. The pxa zauruses apparently just use the pxa\'s onboard controller.
-
Sure, everyone can help on the kernel bits. Even kergoth (our kernel master) didn\'t know a thing about kernel programming when he started doing his Zaurus work.
Best would be to look @ the present state of 2.4.21-cl (linux-cl.bkbits.net), which already boots nicely on a Collie model. Next step integrate the embedix specifics for the other models (5600 and Cxxx) (and rewrite if they\'re insane - which they are ) into the 2.4.21-cl tree. Try to get that kernel booting on a C7x0/5600 and refine.
-
ok I\'ll contact Kergoth... is it only him that work on the kernel?
-
Yes. (actually kergoth is _not_ working on it, because he has a shitload of other things to do, but he is the one to contact anyway )
-
Mickey,
I\'m sorry to play the devil\'s advocate here but I find the Minimal TODO a bit short on specifics (like \"rewrite a few drivers\" - which ones exactly?). Of course, I don\'t know whether a detailed TODO for 3.6.0 is worth the effort (this is for you as an active developer to decide) and how much work it would involve to write one up. I just know that when I contemplate getting involved it all seems quite overwhelming and it would help me personally if I could focus on a well-defined smaller task.
Perhaps you could elaborate on this in OOO Newsletter 2004.01? Please :grin: ?
z.
-
Zenyatta, please coordinate this with kergoth. My own kernel experience is pretty limited and I really have no idea about which drivers exactly to rewrite (other than \"those which suck the most\" ). Myself I am working on (already) too much places in userland to have any time (and interest) to get involved in kernel work, so I must pass the ball here. kergoth can be reached via openzaurus-devel@lists.sf.net or directly in #openembedded on irc.freenode.net
A couple of people with enough motivation to do kernel work could get us finishing 2.4.21-cl in no time and since kergoth already did port a number of things to 2.5.x, a 2.6.x would be the next step then [in cooperation with handhelds.org].
Think of that, our own unified kernel for all Zaurii - with less battery consumption, better speed, etc. Isn\'t that worth getting into kernel land?
-
Well,
I don\'t think I\'ll go into kernel land just yet (lions, tigers and bears) but I can certainly bug people for information (what you so nicely call \'coordination\' :wink: ) and write up a detailed TODO.
z.
-
Rewrite a few drivers means rewrite the drivers that need rewriting and porting the ones that are ok as is. There is no list of which drivers to write because no one has looked at the code in detail.
-
I see. In any case, I have set up a wiki page (http://www.openembedded.org/phpwiki/index.php/OzTODO3.6.0) based on what Mickey wrote a few posts above. I will work to gradually flesh it out. Anyone else feel free to edit it.
z.