Tosa Development Plan

[xjqian]

Maybe just some tedious experimentation with trying to flash the OpenZaurus kernel along with rest of pdaxrom?  To me, that's the real beauty of pdaxii13 ; the blatant combination of elements from the various distros.  Hell, isn't that the real overall beauty of open source to begin with?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=158096\"][{POST_SNAPBACK}][/a][/div]

This idea (OZ kernel + pdaXrom) occured to me. I may give it a spin sometime later next week. Although the current Angstrom test kernel has lots of advantages over the 2.4 kernel, several key components are missing (e.g., screen, headphone, etc). Frankly, I think the most usable kernel so far is still the sharp kernel and its derivatives (e.g. tetsu). There is still a long way for 2.6 kernels to get every hardware working correctly in Tosa. (I'd like to get a deep understanding of how sharp got everything working together.) As for kernel dev plan, I don't think I am qualified to vote. I'd be glad to learn and tweak on either 2.4 or 2.6 kernels

[xjqian]

2.6 OZ/Angstrom--would mean doing the OE thing, but hardware works so it would just be tweaking
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

not quite, not everything is working as for the latest Angstrom build, see here: [a href=\"http://www.do13.de/openzaurus/]http://www.do13.de/openzaurus/[/url].  

tested stumbling blocks (known bugs)
# Alarms wouldn't wake the device when suspended.
# Audio works only via internal speaker (no headphone).
# vertical yellow/blue lines on screen trailing moving objects
# unreliable suspend/resume
(internal wifi works very reliably now)
OZ team is doing a great job on the 2.6 kernel. But honestly this is far from a daily usable zaurus.

I don't know about 2.6 pdaXrom, but I would expect similar result.

[radiochickenwax]

2.6 OZ/Angstrom--would mean doing the OE thing, but hardware works so it would just be tweaking
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

not quite, not everything is working as for the latest Angstrom build, see here: [a href=\"http://www.do13.de/openzaurus/]http://www.do13.de/openzaurus/[/url].  

tested stumbling blocks (known bugs)
# Alarms wouldn't wake the device when suspended.
# Audio works only via internal speaker (no headphone).
# vertical yellow/blue lines on screen trailing moving objects
# unreliable suspend/resume
(internal wifi works very reliably now)
OZ team is doing a great job on the 2.6 kernel. But honestly this is far from a daily usable zaurus.

I don't know about 2.6 pdaXrom, but I would expect similar result.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=158163\"][{POST_SNAPBACK}][/a][/div]

As far as OZ is concerned, my touch screen is almost completely garbled in  3.5.4.2-rc2... seems to be sampling *way* too slowly.  I spend a lot of time drawing with my Z's, so this is kinda important for me.

I do really like that you don't have to kill X just to recalibrate however, and I'd really like to add this to pdaxrom, but that's pretty low priority.  In all honesty, I don't even know where OZ keeps the sources, but that shouldn't be too big of a problem.

I've never really spent the time with OZ to get it anywhere near the point of usability that I can get with pdaxrom.  I know it's capable, but I just haven't done it.  It's too bad too, because I'd really like to take advantage of some of its many features that are missing in pdaxrom.

As to the unreliable suspend/resume: this is a fairly large issue for me with pdaxrom beta1 also.  I actually get better results in OZ.  In pdaxrom, I'm fumbling with mounting/unmounting my CF microdrive between suspends. Roughly half of the time I end up rebooting.

It's good to see that you guys are interested in cleaning up a ROM for tosa.

[adf]

Maybe we should have a look at what HRW does with the upcoming Angstrom release?  Or is it out, and if so has anyone spent any time using it?

[xjqian]

Maybe we should have a look at what HRW does with the upcoming Angstrom release?  Or is it out, and if so has anyone spent any time using it?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=158197\"][{POST_SNAPBACK}][/a][/div]

I'm testing the latest Angstrom. I think the kernel part is almost the same as the latest OZ. Not much new development on Tosa. Hence, same bugs as mentioned before.  OZ people are more concerned about the maintainability of the code base rather than the usability of an individual device. (just stating a fact)

I'm fine to work with pdaXrom team on sourceforge (SVN and bugtrackers), if they agree to open a branch for Tosa, setup a mailing list for tosa and allow us to share the bugtracker (which is long overdue).

[koen]

OZ people are more concerned about the maintainability of the code base rather than the usability of an individual device. (just stating a fact)
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

That's actually not true, since OZ (and OE) doesn't have any active developers with a tosa device, so we have to rely on people like you to test things and report (or even fix) bugs.

And talking about bugs: see rule #5 at [a href=\"http://www.angstrom-distribution.org/]http://www.angstrom-distribution.org/[/url]

[radiochickenwax]

I'm fine to work with pdaXrom team on sourceforge (SVN and bugtrackers), if they agree to open a branch for Tosa, setup a mailing list for tosa and allow us to share the bugtracker (which is long overdue).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=158228\"][{POST_SNAPBACK}][/a][/div]

IMO we can't share the bugtracker until we can get the tosa up to the current SVN that the other clamshells are using.  In order to do that, we'd need to port u-boot. I'm sorry,  I still haven't given much time towards this.

I really think we'd need a separate project just to bring tosa to the level where it could share SVN with pdaxrom.  Any chance of someone setting up a bugtracker and mailing list in this regard?

[adf]

So what we are really looking at is either a tidied up 2.4 based pdaxrom

or

Tidying up Angstrom

Or

Hacking Sharprom

My view is that the easiest would be to fix up sharprom w/ pdaxqt or pocketworkstation

the option with the most likely future seems like Angstrom, though it would meant some bug reporting.  Anyone know if xfce4 is up on angstrom?

with 4 gig sd at less than 40 usd, a 2.6 tosa seems pretty attractive.  If we could get the wireless stuff into a simple point'n'click app...

[radiochickenwax]

So what we are really looking at is either a tidied up 2.4 based pdaxrom

or

Tidying up Angstrom

Or

Hacking Sharprom

My view is that the easiest would be to fix up sharprom w/ pdaxqt or pocketworkstation

the option with the most likely future seems like Angstrom, though it would meant some bug reporting.  Anyone know if xfce4 is up on angstrom?

with 4 gig sd at less than 40 usd, a 2.6 tosa seems pretty attractive.  If we could get the wireless stuff into a simple point'n'click app...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=158276\"][{POST_SNAPBACK}][/a][/div]

Hmm.  I can't use sharp ROM.  It's got some great stability, but so too does a brick, and I need a computer instead.  Sharp ROM is mostly dead in my humble opinion.  PdaXQT and PWS breathe some life into it, but that's fairly cleaned up already I'd think isn't it?  

I guess *all* of the distros could use some help and development/testing. Sorry if this isn't helpful.  Just my two cents.  I'd really like to help, however.  I was somewhat thinking that we could agree on a distro and form a team, but that may be asking too much.  They're all going to make progress.  Even Sharp ROM, although that would be very slow progress from my point of view.

I've been seriously considering going the Linux From Scratch method just to get a totally customized system.  I realize I wouldn't be alone in going that route, but it would be nice to be able to contribute efforts to *all* of the distros if they could find it useful.

[radiochickenwax]

An update:

U -boot seems to flash properly on the tosa. I say *seems* because I don't really know what it's supposed to be doing.  Now as to the next step of loading the 2.6 pdaxrom, I haven't gotten this to work yet.  (Almost every time I reflash,  my palms get a little sweaty, and I'm afraid I've bricked my Z.)  

An additional issue with the 2.6 kernel series of pdaxrom is that I haven't been able to restore from NAND backups on my 3200, without first doing a NAND backup to Sharp ROM.  Yet another bonus point for Sharp ROM.  This  seems to be the case for me on Tosa also.  So I'm currently back to Sharp ROM, debating whether to NAND restore back to pdaxrom beta1 or not.

What's really preventing me from going the Linux From Scratch route is the boot loader.  In their method, everything is geared towards building for an x86 computer.  So, in order to build from scratch, I'd probably want to be sure that I've got a working bootloader.  So far, for me that consists of 3 bootloaders:

1.) Sharp
2.) Alt-boot
3.) U-boot

...and I'd mostly like to use them in that order until I really get the hang of how a bootloader works.

As to LFS:  I've mostly already begun this.  They suggest as a first step to rebuild:
link to Chapter 5
#

    *
          o Binutils-2.16.1 - Pass 1
          o GCC-4.0.3 - Pass 1
          o Linux-Libc-Headers-2.6.12.0
          o Glibc-2.3.6
          o Adjusting the Toolchain
          o Tcl-8.4.13
          o Expect-5.43.0
          o DejaGNU-1.4.4
          o GCC-4.0.3 - Pass 2
          o Binutils-2.16.1 - Pass 2
          o Ncurses-5.5
          o Bash-3.1
          o Bzip2-1.0.3
          o Coreutils-5.96
          o Diffutils-2.8.1
          o Findutils-4.2.27
          o Gawk-3.1.5
          o Gettext-0.14.5
          o Grep-2.5.1a
          o Gzip-1.3.5
          o M4-1.4.4
          o Make-3.80
          o Patch-2.5.4
          o Perl-5.8.8
          o Sed-4.1.5
          o Tar-1.15.1
          o Texinfo-4.8
          o Util-linux-2.12r
          o Stripping
          o Changing Ownership

#


Which I've mostly done (at a quick glance) without a whole lot of flaws.  I have yet to rebuild the kernel, and glibc however.  GCC (version 3.4.5 not 4.0.3) is also incompatible with my various versions of pdaxrom.  I suppose trying to pull the sources from pdaxrom's SVN would be a possible way to resolve this.

Also, I haven't made a new partition to hold all of this stuff either.  Rebuilding these packages is only a small part of the process from what I gather. It's making them all fit that's a little intimidating.

[speculatrix]

And talking about bugs: see rule #5 at http://www.angstrom-distribution.org/
[div align=\"right\"][a href=\"index.php?act=findpost&pid=158260\"][{POST_SNAPBACK}][/a][/div]

flashback to Red Dwarf, rewritten: OZ developer with false teeth should not attempt bug fixing in zero gravity.

[adf]

I can agree to a distro...any distro.  The thing is I'm really not a developer. The point I was making is that to put serious effort into tosa development/polishing, especially looking at using it like a real computer, seems to imply that some 2.6 version. Simply having 4 gigs of cheap sd to put a system on is a tremendous improvement, nevermind the speed and futureproofing that should come with 2.6
Basically, for 2.4, I'll likely stick with sharp/xqt.  That is in part due to the need for my tosa to be easy to use as a light browser/mobile media player.. with the ability to do a bit more, if slowly.  A useable X/gtk system would be better..but I don't really see that living up to my uses in 2.4

[xjqian]

That's actually not true, since OZ (and OE) doesn't have any active developers with a tosa device, so we have to rely on people like you to test things and report (or even fix) bugs.

And talking about bugs: see rule #5 at http://www.angstrom-distribution.org/
[div align=\"right\"][a href=\"index.php?act=findpost&pid=158260\"][{POST_SNAPBACK}][/a][/div]

I think Hrw has a tosa. But I understand he is probably bogged down by various other projects (e.g. openmoko). And the tosa is just sitting as a compiling druid. Talking about bugs, most of them are already in the bug tracker. I just added comments to all the pertinent bugs I experience on tosa (wait to see what hrw has to say). I don't think I could help much at this stage (still learning to catch up with the developers), but yes at least I could help testing. As I said, the fact that OE code base prefers maintainability to usability doesn't imply a negative sense (well, depends on how you slice this fact...). Frankly, the tidiness and well-documented/maintained OE is very attractive, at least to me.

I really think we'd need a separate project just to bring tosa to the level where it could share SVN with pdaxrom.  Any chance of someone setting up a bugtracker and mailing list in this regard?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=158274\"][{POST_SNAPBACK}][/a][/div]

I'm fine with that too. Do you think I should register a project on sourceforge? The potential problem is forking from pdaxrom source tree, which is not desirable. Maybe we should only checkin and maintain Tosa patches with hope to merge back with pdaxrom later.

We can use this thread and the OESF forum to discuss about the plan for as long as necessary.

So what we are really looking at is either a tidied up 2.4 based pdaxrom
[div align=\"right\"][a href=\"index.php?act=findpost&pid=158276\"][{POST_SNAPBACK}][/a][/div]

The following is my vision of the future for Tosa

2.4 kernel based:
easily achievable: cleaned up pdaXrom beta1
achievable: a fast kernel (e.g. tetsu kernel) + Cacko ROM

2.6 kernel based: (still fairly long way to go)
substantial testing and bug-fixing: Angstrom (since the latest OZ 3.5.5 will be very similar to Angstrom (kernel almost identical) I'm not distinguishing Angstrom with OZ)
nonexistent yet (needs uboot): pdaXrom rXXX

PdaXQT and PWS breathe some life into it, but that's fairly cleaned up already I'd think isn't it? 

I guess *all* of the distros could use some help and development/testing. Sorry if this isn't helpful.  Just my two cents.  I'd really like to help, however.  I was somewhat thinking that we could agree on a distro and form a team, but that may be asking too much.  They're all going to make progress.  Even Sharp ROM, although that would be very slow progress from my point of view.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=158278\"][{POST_SNAPBACK}][/a][/div]

Agreed. PdaXQT and PWS is pretty clean.

I partly agree with the statement that Sharp ROM is dead. But the fact every hardware function correctly in Sharp rom still has value for the user. Btw, why we can't do hardware button rotation/record/backlight in pdaXrom or OE? This always puzzles me, is it because poor documentation of the hardware?

I would pick Tetsu-kernel + Cacko rom, if it's availabe on Tosa, over any other rom for my daily pda use.

U -boot seems to flash properly on the tosa. I say *seems* because I don't really know what it's supposed to be doing.  Now as to the next step of loading the 2.6 pdaxrom, I haven't gotten this to work yet.  (Almost every time I reflash,  my palms get a little sweaty, and I'm afraid I've bricked my Z.) 

An additional issue with the 2.6 kernel series of pdaxrom is that I haven't been able to restore from NAND backups on my 3200, without first doing a NAND backup to Sharp ROM.  Yet another bonus point for Sharp ROM.  This  seems to be the case for me on Tosa also.  So I'm currently back to Sharp ROM, debating whether to NAND restore back to pdaxrom beta1 or not.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=158281\"][{POST_SNAPBACK}][/a][/div]

Thanks for the update. Looking forward to a 2.6 pdaXrom

I can agree to a distro...any distro.  The thing is I'm really not a developer. The point I was making is that to put serious effort into tosa development/polishing, especially looking at using it like a real computer, seems to imply that some 2.6 version. Simply having 4 gigs of cheap sd to put a system on is a tremendous improvement, nevermind the speed and futureproofing that should come with 2.6
Basically, for 2.4, I'll likely stick with sharp/xqt.  That is in part due to the need for my tosa to be easy to use as a light browser/mobile media player.. with the ability to do a bit more, if slowly.  A useable X/gtk system would be better..but I don't really see that living up to my uses in 2.4
[div align=\"right\"][a href=\"index.php?act=findpost&pid=158287\"][{POST_SNAPBACK}][/a][/div]

Agreed. As I thought more about my Tosa usage senario, 2.4 kernel pdaXrom developement is ironic in a sense that it defeats the purpose of the existence of pdaXrom in the first place. So we don't have to do more than clean-up or customization for pdaXrom beta1.
But I want to stress it again (to see if anybody agree with me), some development effort towards 2.4 kernel sharp bases (e.g. cacko) rom does make sense to me.

[radiochickenwax]

I agree that there are definite advantages to a Sharp based ROM in the short term.  However, thinking in the long term, I'd really like to see those advantages obsoleted, and I'd prefer the long term to be as short as possible.  Again, that's probably too idealistic.

Concerning Cacko, I recall a version for tosa being put together with some elements from the Guylhelm ROM somewhere on this forum by DrWowe.  I don't know what ever became of that if it ever saw the light of day... but at the very least, that's a proof of concept.  

I'd start searching now, but I'm kinda busy.  Just wanted to add two more cents.

[adf]

cacko never quite worked right. Guylhem was trying to clean up the linking and put the qte envirenment in a single separate directory.  It kinda stalled.
If you could get cacko to live on sd/cf that might be interesting. Otherwise my hacked shaprom looks pretty nice right now--though it'd be a major pain to redo.

My personal view has been that OZ is pretty close, and that most of what is needed is a lil scripting for the wireless.  Something that ran detection and piped options even to a ncurses menu would be fine, imho.  I think that doing some gui picking and tweaking (ice and xfce come to mind here) would get you a pretty decent setup--especially with altboot to a 4 gig sd. there is still a little bit of a clored line problem, but it isn't the issue that it once was, and is pretty liveable.  I guess making sure lall the buttons worked a labeled would be nice, too.

I dunno---  pick a direction and I'll at least comment on it...might even flash my Z and test.