Qtopia Rom 2.1.1

[lpotter]

Disclaimer: I don't know more than you do, I'm just making educated guesses and stating personal opinions.

TT is in a dilemma with this ROM. They couldn't base it on anything newer than OpenZaurus 3.3.5 because that was the last release I did and then we abandoned the OZ buildroot. The OpenEmbedded buildroot was from the start tailored for modern base libraries and modern compilers. Up to date, no one of the core team was interested to do any work to include support for gcc 2.95.3 to OpenEmbedded - and since the ROM creator didn't/couldn't want to do this as well this is the reason why OE couldn't and can't be used for so called "compatible" ROMs.

This also means that TT can't easily add support for more machines, especially not the 6000, because OpenZaurus 3.3.5 didn't support it. This not only is a problem for the base machine support but also for the GUI, which you can evidently see when looking at the DocTab. TT doesn't have the source code from Sharp, so they would have to reinvent all the clever things Sharp did to Qtopia 1.5 (which is ironically the same situation we have with Opie).

I don't see much of a point in such a ROM. It's compatible to the 3rd party apps, yes, fine - but that's about it. IMO it would be much more wise to add Qtopia to OE or to add some of the Qtopia apps to OE or to Opie. This ROM just adds up to the fragmentation.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=73962\"][{POST_SNAPBACK}][/a][/div]

oe/bitbake is not the Holy Grail to Embedded devices that you think it is. It is silly to have to use oe/bitbake for simple application development, where one cross compiler and qtopia sdk can do. Oe/bitbake uses _way_ too much memory, and is way too slow.

As far as fragmentation, OZ does more fragmentation than anybody - oz using softfloat caused more fragmentation than anything, and talk of opie getting rid of it's qtopia base also fragments things, especially with devices that actually ship with linux/Qtopia. So just think about whos causing fragmentation...

TT is not in any dilemma. You have a lot of wrong suppositions of why Trolltech did this, and the reason why we did this. Buildroot works, and it is stable, and doesn't have crap I won't ever use, and doesn't use a gig of RAM!

If you don't like this rom, don't use it. No one is forcing you. It is for individuals who like Qtopia, or want to demo Qtopia 2.1.1 and want to actually be able to sync their data easily.

[lpotter]

no way to delete posts

[adf]

Well..it is for individuals who don't use 6000's anyway. I haven't heard from 3k/1k crowd in here. Does it work for them?

I don't mean to make too much of an issue of this...  I've been reading potter and mickey squabble over the advantages of various systems for a while now.
the basic argument has always seemed to me that
OE (mickey) is in favor of using recent software develpment applied to a large platform base, (and that the obvious intricacy of such a thing has made OE complex and OZ, as yet imperfect--as indicate by the clearly marked unstable status of the releases)
(TT)lpotter has argued in favor of slower development and better retention of backward comatibiluity through use and mainenance of the existing software base..a kind of "it works don't mess with it (too much)" approach.
OE has put out some really terrific packages (potters fm ironically is a good example), but had stability and compatibilyt-w/exisitng software issues
SharpRom has been stable with a large base, but not kept up w/ linux development at large in many respect.

The strange thing here is that the TT argument re stability is belied by this ROM. It doesn't support hardware supported by Sharp--making it definitely a contender for the "unstable fork" label."  and... if it was going to be unstable/imperfect anyway, it seems to me it might as well have been more up-to-date and been built on OE. If it was intended to be stable, it should have been built on something that actually worked on the hardware.--like a sharp (or tetsu kernel)

[anonuk]

any 7x0 version? the c700 one doesnt seem to work on my 860...

[ev1l]

If you don't like this rom, don't use it. No one is forcing you. It is for individuals who like Qtopia, or want to demo Qtopia 2.1.1 and want to actually be able to sync their data easily.

Why do I feel that normal users are always the last people developers think about when arguing about this
I'm not blaiming you (or TT, for that matter) in particular, it's just that going about things this way users will never get something that's feature-complete and reasonably bug-free.

[lpotter]

Well..it is for individuals who don't use 6000's anyway. I haven't heard from 3k/1k crowd in here. Does it work for them?

This rom does not support the newer Sharp devices.

I don't mean to make too much of an issue of this...  I've been reading potter and mickey squabble over the advantages of various systems for a while now.
the basic argument has always seemed to me that
OE (mickey) is in favor of using recent software develpment applied to a large platform base, (and that the obvious intricacy of such a thing has made OE complex and OZ, as yet imperfect--as indicate by the clearly marked unstable status of the releases)
(TT)lpotter has argued in favor of slower development and better retention of backward comatibiluity through use and mainenance of the existing software base..a kind of "it works don't mess with it (too much)" approach.
OE has put out some really terrific packages (potters fm ironically is a good example), but had stability and compatibilyt-w/exisitng software issues
SharpRom has been stable with a large base, but not kept up w/ linux development at large in many respect.

The strange thing here is that the TT argument re stability is belied by this ROM. It doesn't support hardware supported by Sharp--making it definitely a contender for the "unstable fork" label."  and... if it was going to be unstable/imperfect anyway, it seems to me it might as well have been more up-to-date and been built on OE. If it was intended to be stable, it should have been built on something that actually worked on the hardware.--like a sharp (or tetsu kernel)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=74121\"][{POST_SNAPBACK}][/a][/div]

Works fine for me. If you are talking about the 6000's wifi not working, I don't have a lot of time to devote to this. Patches/fixes welcomed

[adf]

I am glad for anyone who is happy with this or any other setup they are using.
I understand that I am perfectly free to make patch or modify any opensource package i want. In fact the first thing i did with this was try to do a quick replacement of the kernel.
That you are suggesting i patch an old OZ to support a new device is not suggestive of that old " it is important that users have a system that works" position you take when discussing options other than Qtopia.  In fact the harried "I don't have time" bit sounds like someone from OE talking about backwards sharp, or old gcc support. Very funny.
Let's imagine I had the skill to fix this, though. ( I am not a programer, and don't have the skill) how would i go about it?

would i :
a): rewrite an old buildroot that was abandoned that uses a 2.4 kernel and gcc 2.9?
. compile for a known good 2.4 kernel gcc 2.9 setup?
c). add it to a modern, supported, but awfully complicated build system (maybe 2.6) gcc 3.4?

Not A.
If I wanted solid backwards compatibility, Not A or B
If I wanted better floating point performance and current library support Not A or C.

I feel like i am being drawn into a rather confrontational position here. The thing is, that wasn't where i set out to go.  I set out to point out that the rom was interesting but unuseable, and to look into why it seemd to be unuseable. The answer was very weird: Old OZ system on new hardware is not a good solution for the sufficient reason that the hardware doesn't work. never mind the very bleak future of such an arrangement. It seemed to me that a different solution would be better, if it it...worked.
When asked why a new linux handheld should use Qtopia potter immediately replies--because it works. Fair enough. But when something Qtopian does not work, that has to be admitted too. And "it works for me- if you don't like it fix it yourself" isn't really reasonable, nor is it fair play.
I gather there is indeed no interest in making anything but a demo here. OK. I won't try to use a demo as my UI. Nice demo. I appreciate the feature showcase. Anyone planning to pull this stuff into a ROM?

[lpotter]

I am glad for anyone who is happy with this or any other setup they are using.
I understand that I am perfectly free to make patch or modify any opensource package i want. In fact the first thing i did with this was try to do a quick replacement of the kernel.
That you are suggesting i patch an old OZ to support a new device is not suggestive of that old " it is important that users have a system that works" position you take when discussing options other than Qtopia.  In fact the harried "I don't have time" bit sounds like someone from OE talking about backwards sharp, or old gcc support. Very funny.
Let's imagine I had the skill to fix this, though. ( I am not a programer, and don't have the skill) how would i go about it?

would i :
a): rewrite an old buildroot that was abandoned that uses a 2.4 kernel and gcc 2.9?
. compile for a known good 2.4 kernel gcc 2.9 setup?
c). add it to a modern, supported, but awfully complicated build system (maybe 2.6) gcc 3.4?

Not A.
If I wanted solid backwards compatibility, Not A or B
If I wanted better floating point performance and current library support Not A or C.

I feel like i am being drawn into a rather confrontational position here. The thing is, that wasn't where i set out to go.  I set out to point out that the rom was interesting but unuseable, and to look into why it seemd to be unuseable. The answer was very weird: Old OZ system on new hardware is not a good solution for the sufficient reason that the hardware doesn't work. never mind the very bleak future of such an arrangement. It seemed to me that a different solution would be better, if it it...worked.
When asked why a new linux handheld should use Qtopia potter immediately replies--because it works. Fair enough. But when something Qtopian does not work, that has to be admitted too. And "it works for me- if you don't like it fix it yourself" isn't really reasonable, nor is it fair play.
I gather there is indeed no interest in making anything but a demo here. OK. I won't try to use a demo as my UI. Nice demo. I appreciate the feature showcase. Anyone planning to pull this stuff into a ROM?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=74135\"][{POST_SNAPBACK}][/a][/div]

I do not have all Sharp devices here for testing, thus.. only some Sharp devices are usable. If you would like to help me out, and be a beta/beta tester, I do have roms for other devices - c760,c860, but I will not release anything that is completely not tested.

As for the addage that buildroot is old and abandoned, and that kernel 2.4 and gcc 2.95 are too old for being used because they are old, is just silly.

[adf]

argh. No, it isn't that I am contending that 2.95 and 2.4 are too old... it is that the old OZ buildroot is too....weird--and the result seems like the worst of both worlds.

I'd be happy to you make this work... though I am pretty unskilled and only have a 6k.

What it looks like to me is that the issue is the kernel/modules, NOT QT 2.1.

Would it be feasable to use a different set of kernel sources?

guylhem has a tetsu-based "unified kernel source (pxa)" on his site at externe.net/zaurus that supports a number of Z's (not the 5500 though )the kernel itself is pretty up-to-date for its version, and has a really nice set of floating point options. the whole thing seems pretty sharp compatible--I use sharp software, 3rd part software for sharprom and stuff off the cacko 1.22 feed maybe something can be done with this? Incidentally..he is updating the kernel and reorganizing the NAND with an eye to making a 6k rom.  Maybe there is a way to get some useful collaboration going? (since I am pretty much the weak link here?)

I use a monolithic version of that kernel most of the time.

When I ftried 2.1, I eventually tried to use an updater to flash my version of the kernel into the z. the flash went well, but the gui didn't load. ( I tried this same thing on gpe OZ3.5.2 to see what would happen. went great worked, but no touchscreen---this had also happened on earlier versions of zvncserver) If that helps. is there a patch to the kernel you are using that is missing in the one I am using?  is there just something qtopia looks for that wasn't there?  I can certainly set up a small server to work on this...

[ev1l]

I can help test on the 860, whenever the bickering stops.

[adf]

Ok. this thing has hostap. good if it can be made to work.
the usb modules have to me installed manually. the p80211b isn't there. I used one of mine. it seems to load ok.
So manuall starting usb core usb_ohci... and p80211b seems to work.  what else should be staerted to fire up the wireless? and does anyone remember how to work hostap if it is anything other than ifup wlan0?  

somebody with a 6k w/ working wireless?

reboots real fast

i

[nilch]

The strange thing here is that the TT argument re stability is belied by this ROM. It doesn't support hardware supported by Sharp--making it definitely a contender for the "unstable fork" label."  and... if it was going to be unstable/imperfect anyway, it seems to me it might as well have been more up-to-date and been built on OE. If it was intended to be stable, it should have been built on something that actually worked on the hardware.--like a sharp (or tetsu kernel)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=74121\"][{POST_SNAPBACK}][/a][/div]

Sharp and Trolltech are two different entities - and ironic though it may sound - that the Sharp devices use Trolltech Qtopia (the older versions), but Trolltech will not be able to replicate the same type of ROM's for all Sharp devices since a lot of Sharp's modifications have not been released outside of Sharp. Actually without any other consideration, Sharp has really done some good work in modfying the base system and building over that to make major enhancements.
Be it TT or the OZ gorup, everybody have to create the wheel from scratch (I am talking about the enhancements only) again by themselves since Sharp will not help evidently.

So really TT's ROM (they are not basically in the ROM business) unstability is not becuase they are 'forking' the Qtopia build (as some others are), but because they dont have the source to 'propraitary' enhancements made by Sharp. Lets not confuse Sharp with TT here.

Now having said that as a matter of fairness, I think if TT really wants to bring out ROM's for the new Qtopia - they had better do it in earnest or not at all. I am prepared to give them time and I beleive they will be able to bring out a stable ROM if they seriously want it ... but again what is they interest in bringing out a ROM - apart from building the Sharp compatible ROM community further ? Its not like Sharp - who had a Zaurus to sell.

I wouldn't venture into the argument of which buildroot sucks and which is better - since I am neither knowledgeable nor skilled in those aspects -
but I agree with what adf says

I gather there is indeed no interest in making anything but a demo here. OK. I won't try to use a demo as my UI. Nice demo. I appreciate the feature showcase. Anyone planning to pull this stuff into a ROM?

So be it the community, or TT (or even Sharp - in my wildest dreams   ) who delivers this - with a degree of backward compatibility to the large existing base (yes I am all for it) - I say go for it.

[_Psycho]

Quick question, since my USB seem to be a problem on my c700, does the 6k rom usb / sync work fine ?

[adf]

dunno. I have been trying to get the wireless to turn on.
It locks up coming out of suspend though.... sigh. These are suspiciously ozish bugs...  initial 3.5.2 did weird wireless stuff and had suspend issues.

i can't help but think it is the kernel.

How do you drop out of qtopia in 2.1?  I could at least test apm -s..

as to what nilch said.
I actually knew the sharp qtopia issue it had been brought up re video acceleration last winter....
What I was thinking was that on the 5600, 6000, 700, 750.760.860and I think the 1000 and 3000, there are 3rd party kernels with backported enhancements that can replace the sharp kernel and be useable with the rest o the rom.  Apparently my notion that the ui is compiled more or less against kernel headers and that it is the kernel that does the communication between the hardware and the rest of the software falls short.
My theory has been that  since these very good 3rd party kernels exist (and are of a largely common origin, I think) then the kernel/hardware communication is essentially solved already...and that the only remaining issue was to get the ui components to compile and to communicate with the kernel(s). Thus by using extant "known-good" kernel sources (and the compilers that build them?) we would not be seeing what appear to be hardware support problems.  ie suspend resume/wireless on the 6k. Maybe my view on this is naive?   the build systems usually don't interest me (oe does because the attempt to become "universal" is pretty amazing) except that i do care whether what is built runs.
If some genius out there found a way to build a killer os on a computerized lego block running LOGO I'd be happy...
So.. the question remains..where are these hardware issues coming from? could a dfferent zImage be THE WAY.. or compiling on a different chain....or sacrificing a pigeon....etc.

[Mickeyl]

You have a lot of wrong suppositions of why Trolltech did this, and the reason why we did this.

Go ahead and educate us!

Buildroot works, and it is stable, and doesn't have crap I won't ever use, and doesn't use a gig of RAM!

Uhm... it is a major misconception to use the term 'stable' for 'no one does any more work on it'.

Building stuff based on buildroot is a waste of time - it has no future, it suffers from extreme bitrot. I don't know how many hours you put into it, but if it's just about compatiblity and syncing, IMNSHO that time would've been spent more wise to improve syncing on modern OE-based OZ releases.