Help - Search - Members - Calendar
Full Version: Tosa Development Plan
OESF Forums > Distros, Development, and Model Specific Forums > Model Specific Forums > 6000 - Tosa
xjqian
As most of your know the 6000L is an odd breed compared to other Zauri, esp the clamshells, where availability and dev activities are high. Hence Tosa ROM version is behind others except for OZ/Angstrom where the key dev. Hrw has the device.

Current Tosa ROM status in the other popular rom is pretty disappointing

PdaXrom: beta1
Cacko: None

I've been whining for a long time without contributing. Part of the reason is that I don't know where should my effort go. I have to admit that I'm not even close to software engineer in trade and pretty inexperienced in the whole thing. But I'm pretty confident in my learning ability to get some Tosa dev going.

For a starter, I'm interested to advance PdaXrom to a stable/usable 2.4 kernel, similar to what Meanie did for pdaXii. (weed out bugs, etc. ) Who else is interested and have time to contribute? We probably need some sort of infrastructure (svn, emaillist, bugtracker, etc.) Could we borrow what's available in the PdaXrom site? Should we get together and form a team?

Btw, anybody interested in a Cacko ROM for Tosa?

I can probably commit half an hour per day for the project after my thesis defense.
gfdsa
QUOTE
We probably need some sort of infrastructure (svn, emaillist, bugtracker, etc.)

n/p to bring it up and manage as soon as there will be a team to use it
adf
my .02 us would be to:
work on the pdax kernel (is beta 1 missing anything from beta3? patch it?)

see if big SD support can be done

work on using the hdimage from pdaxii13 on sd (or cf if necessary)

get the wifi working with the wifi applet (or script up another one--ncurses even would do, if it was effective)

then all would be well..


besides the kernel and the sd module and the wireless.... what really would need a major overhaul? wink.gif

I take it Angstrom for the 6000 isn't looking hopeful?
xjqian
QUOTE(adf @ Mar 15 2007, 03:05 AM)
my .02 us would be to:
work on the pdax kernel (is beta 1 missing anything from beta3? patch it?)
*

That's exactly what I want to start with, patch beta1 with beta3, then diff beta3 with Meanie's pdaXii and squash bugs. I don't want to overhaul, it's just there're too many pesting bugs in beta1.
adf
that sounds about right. It occurred to me after I posted that redoing the wifi appplet in qt (from what I saw in dinorex post) might be a good idea. when I use pdax on my tosa, I don't use the default wm-- I use xfce-- partly for the window sizing; partly because it is so easy to add wifi menus
gagware
QUOTE(adf @ Mar 15 2007, 10:05 AM)
I take it Angstrom for the 6000 isn't looking hopeful?
*


I don't have any experience (yet) with Angstrom, but it looks very promising. Furthermore I just was browsing through the images and I saw this morning a new (testing) version was added...for the SL-6000 a.k.a. Tosa!

Can be found here:

http://www.angstrom-distribution.org/unsta.../20070331/tosa/

When I find time to test it on my unit I'll post the results...this won't be very soon unfortunately though. I'm anxious to hear what you guys find out about it.

Actually, now I think of it - can anybody tell me whether or not I need to change the partitions before flashing? I think from looking at the files it's not necessary (i.e. it looks very much like the OZ install files), but you can never be too sure. Right now it runs OpenZaurus 3.5.4.rc2, I never changed my partitions myself. Before it just ran the stock Sharp rom.
I already found the unit needs to have standard flash partitioning (from installation instructions from another model), but I am not sure if OZ changed anything.
xjqian
QUOTE(gagware @ Apr 1 2007, 05:55 AM)
Actually, now I think of it - can anybody tell me whether or not I need to change the partitions before flashing? I think from looking at the files it's not necessary (i.e. it looks very much like the OZ install files), but you can never be too sure. Right now it runs OpenZaurus 3.5.4.rc2, I never changed my partitions myself. Before it just ran the stock Sharp rom.
I already found the unit needs to have standard flash partitioning (from installation instructions from another model), but I am not sure if OZ changed anything.
*

You don't have to repartition (i've tested from both OZ and stock rom).

The current Angstrom file system may be broken as we speak (see the Angstrom dev maillist). I can't boot after flashing. I've sent an email to Koen.

Edit: response from Koen:
QUOTE
The integrity is OK, the problem is that the images seem to be using LZO compression for
jffs2, while the 2.6.17 kernel used on tosa doesn't support that.
A solution may be underway.

Update: images re-generated and uploaded. The X11 image boots fine now, but still missing libesd for gpe programs. The console image flashes fine but won't boot pass the "open embedded" screen.
radiochickenwax
QUOTE(xjqian @ Mar 15 2007, 05:30 AM)
Who else is interested and have time to contribute? We probably need some sort of infrastructure (svn, emaillist, bugtracker, etc.) Could we borrow what's available in the PdaXrom site? Should we get together and form a team?

I can probably commit half an hour per day for the project after my thesis defense.
*



I'd be interested in such a thing, but I could only contribute about the same amount of time unfortunately.. possibly slightly more so, depending.



QUOTE(xjqian @ Mar 15 2007, 08:24 AM)
QUOTE(adf @ Mar 15 2007, 03:05 AM)
my .02 us would be to:
work on the pdax kernel (is beta 1 missing anything from beta3? patch it?)
*

That's exactly what I want to start with, patch beta1 with beta3, then diff beta3 with Meanie's pdaXii and squash bugs. I don't want to overhaul, it's just there're too many pesting bugs in beta1.
*




Some unorganized thoughts on the matter:

Personally, I'm not very happy with beta3 compared to beta1. Having gotten a 3200 expecting beta3 to be much better than beta1 on a 6000, I was sorely disappointed.
Furthermore, pdaxii13 is largely a set of patches for problems that AFAIK exist *only* in beta3 (i.e clamshells,), so a lot of these problems are not applicable to beta1 on the tosa.

The 2.6 kernel series is a whole different story, and it's where the "official" bug fixes are headed as far as I can tell. It's really won my vote so far over beta3 with or without Meanie's patches. If we could at least get the tosa to *run* a 2.6 kernel in pdaxrom, then we'd all be on the same page as far as the ROM is concerned. And there's a considerable number of problems to face even if anyone were to get that far.

However variety is the spice of life, and many people prefer the "stability" of the 2.4 kernel to the enhancements that come with 2.6.

IMHO, trying to get u-boot to load on the tosa would usher in the 2.6 kernel series, and would solve many problems. It's also the path that pdaxrom sorely needs. This could be a good start to solve a lot of problems missing in the 2.4 series, notably the large SD support. That's unfortunately beyond me right now as the 3200 has nearly taken away all of my 'zaurus time' from the 6000... I'm still trying to find a good balance in this respect.

A Suggestion:

We'd need a more stable host for enhancements than this forum: perhaps pdaxrom.org or tyrannozaurus.com? pdaxrom has moved it's SVN to sourceforge.net.... that might be a good place to start as well.

Is anyone still interested in this?
adf
Interested? Definitely. Able to port uboot to the 6000---well it is theorically possible that I could do it...kind of in the way an infinite number of monkeys can produce shakespeare, only it might take longer because I'm doing other stuff, too. biggrin.gif
radiochickenwax
QUOTE(adf @ Apr 6 2007, 01:01 AM)
Interested? Definitely. Able to port uboot to the 6000---well it is theorically possible that I could do it...kind of in the way an infinite number of monkeys can produce shakespeare, only it might take longer because I'm doing other stuff, too. biggrin.gif
*



Okay well, I'm sure you could get the monkeys to act out the scenes even if they can't write the sonnets. smile.gif U-boot doesn't have to be the *only* way to get it working. Someone took the time to do it for the clamshells, and someone *could* take the time to do it for the tosa as well.

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?

I have a nagging suspicion that there may be silent tosa users lurking about in the dark spaces of these forums with immaculately customized ROMs, that simply aren't sharing many of the tricks they've picked up for who knows what reasons.
adf
I think the way softfloat is done on the OZ kernel is different enough from what is done on pdaXrom that it won't work.

Getting the pdaX dev team to compile a 2.6 version for the 6000 and working it out from there might be more hopeful. Or trying to make an OZ or ANgstrom release work the way we want it to.

I've never really worked with kernels in pdaX. I've recompiled 'em for sharprom, and done some OE stuff a while back. How hard would it be to tale the r121 2.6 source and configure it for tosa... then test that?
radiochickenwax
QUOTE(adf @ Apr 6 2007, 04:19 AM)
How hard would it be to tale the r121 2.6 source and configure it for tosa... then test that?
*


As far as the newer pdax kernels go: I don't really know. I'm certainly no kernel hacker, but that doesn't mean I don't want to be, or am unwilling to try.

QUOTE(adf @ Apr 6 2007, 04:19 AM)
I think the way softfloat is done on the OZ kernel is different enough from what is done on pdaXrom that it won't work.
*


As far as the floating-point stuff is concerned, it's really frustrating. I've been trying half-heartedly to rebuild gcc for some time now, and every step I make it's still just a little further out of my reach.


QUOTE(adf @ Apr 6 2007, 04:19 AM)
Getting the pdaX dev team to compile a 2.6 version for the 6000 and working it out from there might be more hopeful.  Or trying to make an OZ or ANgstrom release work the way we want it to.
*



As you probably know, InSearchOf is doing most of the official building lately. He suggested to me that U-boot is the way to go for now on the tosa, and I haven't really given it a solid effort. I don't really understand the need for this new bootloader, or how it interacts with the rest of the ROM, but I'd really like to find out.

I guess I'd be willing to guinea pig a test build of a vanilla 2.6 kernel in pdax and start logging some of the problems I come across, but it wouldn't be for a few more days at least, since my tosa's currently working on compiling some other stuff. (gimp, emacs, clisp, and some perl modules). Honestly I'd probably want a new thread for trying to rebuild a patched 2.6 pdax kernel.

I gotta admit that it's a little intimidating. I haven't even gotten around to trying the tetsu kernel for tosa.

Finally as far as cleaning up a ROM, we'd probably want to decide which ROM to pick then. Personally, I think any of them could be tailored to fit a single user's wants within reason, but first things first I guess: (at the very least, a bugtracker)

QUOTE(gfdsa @ Mar 15 2007, 07:29 AM)
QUOTE
We probably need some sort of infrastructure (svn, emaillist, bugtracker, etc.)

n/p to bring it up and manage as soon as there will be a team to use it
*

adf
Yeah-- I kinda hate to mess with mine-- the tetsu/pdaxqt setup works ok, my wife can use it, etc--but to get all the software I wanted on board I had to move stuff, like /home/zaurus, I think, to SD and link it in unusual(and undocumented) ways.

As to picking a rom. If we are going to let ourselves in for any substantial pain, we may as well go fullon 2.6 based--but it is beyond me to accomplish, I think

We could try a beta1 reroll and add the missing libs, meanie's gtk hacks, etc from the beta 3 feeds-- do an optimal wm and call it good. That might be something I could help with.

The thing is, 2.4 will be slower than 2.6 on a Tosa. There will be no big sd support. Both major concerns in making the most of the thing.

My vote would be(in order)--if we can muster the skill---
2.6 pdaX using icewm or xfce

2.6 OZ/Angstrom--would mean doing the OE thing, but hardware works so it would just be tweaking

2.4 beta1 reroll easiest, but slower and with only 1G sd

OR I could just leave the sharprom well enough alone, which is kinda tempting especially given pdaXqt and /or pocketworkstation
speculatrix
one thing I'd like to see is unionfs support built in; so that the base install is cramfs or squashfs read only, and then any changes to the system are in an overlay file system. This avoids all the nasty hacks with simlinks. It also means you could have your overlay FS on an SD card, and thus much reduce the number of reads and writes to the zaurus's internal flash.
adf
QUOTE(speculatrix @ Apr 6 2007, 09:12 AM)
one thing I'd like to see is unionfs support built in; so that the base install is cramfs or squashfs read only, and then any changes to the system are in an overlay file system. This avoids all the nasty hacks with simlinks. It also means you could have your overlay FS on an SD card, and thus much reduce the number of reads and writes to the zaurus's internal flash.
*

That'd be unbelievably nice
xjqian
QUOTE(radiochickenwax @ Apr 5 2007, 11:13 PM)
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?
*

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
QUOTE(adf @ Apr 6 2007, 12:47 AM)
2.6 OZ/Angstrom--would mean doing the OE thing, but hardware works so it would just be tweaking
*


not quite, not everything is working as for the latest Angstrom build, see here: http://www.do13.de/openzaurus/.

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
QUOTE(xjqian @ Apr 7 2007, 10:03 AM)
QUOTE(adf @ Apr 6 2007, 12:47 AM)
2.6 OZ/Angstrom--would mean doing the OE thing, but hardware works so it would just be tweaking
*


not quite, not everything is working as for the latest Angstrom build, see here: http://www.do13.de/openzaurus/.

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.
*




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
QUOTE(adf @ Apr 7 2007, 02:18 PM)
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?
*

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
QUOTE(xjqian @ Apr 8 2007, 03:13 AM)
OZ people are more concerned about the maintainability of the code base rather than the usability of an individual device. (just stating a fact)
*


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/
radiochickenwax
QUOTE(xjqian @ Apr 8 2007, 03:13 AM)
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).
*


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
QUOTE(adf @ Apr 8 2007, 08:18 PM)
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...
*


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
QUOTE(koen @ Apr 8 2007, 04:14 PM)
And talking about bugs: see rule #5 at http://www.angstrom-distribution.org/
*


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
QUOTE(koen @ Apr 8 2007, 10:14 AM)
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/
*


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.


QUOTE(radiochickenwax @ Apr 8 2007, 03:06 PM)
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?
*

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.

QUOTE(adf @ Apr 8 2007, 03:18 PM)
So what we are really looking at is either a tidied up 2.4 based pdaxrom
*

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

QUOTE(radiochickenwax @ Apr 8 2007, 03:31 PM)
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.
*

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.

QUOTE(radiochickenwax @ Apr 8 2007, 04:40 PM)
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.
*

Thanks for the update. Looking forward to a 2.6 pdaXrom

QUOTE(adf @ Apr 8 2007, 06:09 PM)
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
*

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.
radiochickenwax
QUOTE(adf @ Apr 11 2007, 02:52 AM)
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.
*



Do you know of a download link for the cacko images?

QUOTE(adf @ Apr 11 2007, 02:52 AM)
  pick a direction and I'll at least comment on it...
*




Here's my current plan: (suggestions, etc are more than welcome)


1.) Get Angstrom to "Work"


I started a new thread for making angstrom work on tosa.

http://www.oesf.org/forums/index.php?act=S...t=0#entry158768

There are additional links to the mailing lists there. I'll edit this post to include them if I find time. Personally, I prefer this forum to the mailing list format for various reasons.

As for OpenZaurus on tosa, there is already a pinned thread for this:

Open Zaurus on tosa




2.) Get A Newer Version of pdaxrom for Tosa

Still haven't gotten u-boot to load pdaxrom > beta1. Gonna keep trying, but slowly. Inbetween flashes, I'll try getting Angstrom to work, and compiling stuff on pdaxrom beta1.

I started another thread for making pdaxrom work on tosa.

Making pdaxrom work on tosa



3.) Use the temporary bug tracker for pdaxrom beta1 until an updated version works

There have been some efforts to start a bug tracking list for pdaxrom beta1 in the pdaxrom forum, but these mostly get bumped off the first page in that highly active thread. They might serve their purpose better in this tosa specific page.

For now, that link is here:

Temporary pdaxrom 6000 Bug Tracker


4.) Find Source Packages to Build for x11 based Tosa Roms


Still haven't gotten open embedded to work, or found out where the sources are kept. A link to the open zaurus sources would be appreciated. I'd like to try compiling some of the programs for the tosa natively in both open zaurus and pdaxrom. In my opinion, both distributions could benefit a lot from the other, and this can be broken into a lot of small tasks. I'm not going to attempt to list them here. A new thread might be a good idea, but where exactly to put this, I'm not sure.

QUOTE(xjqian @ Apr 10 2007, 08:20 AM)
QUOTE(radiochickenwax @ Apr 8 2007, 03:06 PM)
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?
*

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.

*



I don't know about registering a project on sourceforge just to bring tosa up to par. I've never registered a sourceforge project, so I don't know how that would work. I guess for now this forum will work fine as well as the bugtracker mentioned below.

I never really intended on forking the pdaxrom tree, simply building the newer stuff (that hasn't yet been built) specifically for tosa.
adf
Angstrom sounds hopeful, at least. I haven't played with it yet.
Hrw
Ok. Let me write few words.

Yes, I have a tosa here. It is OpenEmbedded project device which can be sent to other developer (EU preferred) which will work on getting Ångström working on it. I am too buried in other projects to take care of it.

Any work on kernel 2.4 is waste of time and resources. Even unfinished 2.6.17 is better then 2.4.18 ever was. It has ugly vertical lines artifacts but each system other then original SharpROM has it. http://bugs.openembedded.org/show_bug.cgi?id=490 contain some information why the problem exists.

Under 2.6 every part of hardware is working. WiFi need to be off before suspend but same problem existed under 2.4 because drivers are SHIT. Hardware buttons are recognized and working - any functionality can be attached to keypress.

Speaking about u-boot... It is nice bootloader but I would keep sharp crap instead. The reason is simple: USERS. When pdaXrom switched to u-boot we have many users which complained that they bricked their devices etc.
adf
I've flashed to Angstrom- it seems to work. need to set up altboot, though.

edit: I tend to think HRW is on the money here--despite his sounding like users are an inconvenience (which I'm pretty sure isn't what he meant)-- we can probably tweak a very usable angstrom/altboot for tosa, and it really would be better on 2.6
radiochickenwax
Here are some funny links related to this thread:

Why Users Should Not Exist

UNIX Hater's Handbook

Help Wanted For CLISP


The following is quoted from the last link above:
QUOTE
The prizes for handling these issues:

    * handle one issue and you will get CVS write access;
    * handle two issues and you become an admin of the CLISP project;
    * handle three or more issues and you become the principal maintainer.

This reminds me of a joke: after the 1991 Russian coup attempt (which lead to the final downfall of communism), the Communist Party was very unpopular and tried to increase the membership by asking its members to recruit new members, with the following incentives:

    * if you bring one new member, you don't have to pay membership dues
    * if you bring two new members, you may resign from the Party
    * if you bring three new members, you may resign and you will also receive a certificate that you have never been a member of the Party!"


Please note, I'm not trying to be negative about this, I just found all of the above humorous. I'm still very much committed to the idea of an open source ROM for tosa that would combine the stability of OZ and Sharp with the usability of pdaXrom.

Personally, I'm not very happy with angstrom or OZ out of the box. GPE has never worked all that well for me as a window system compared to pdaXrom's more standard setup. It's a great idea for a PDA, but I didn't buy the zaurii to run an open source version of WinCE which IMHO is probably the worst interface I've ever used.

What I'd like to know is how to make OZ/Angstrom "feel" more like a standard desktop system. pdaXrom does the best job of that task, but there are obviously a lot of issues with the rom beyond that point, which is why we even have this thread in the first place.

For me, I'm still harboring this notion that I should be able to build the whole rom from scratch natively, with a minimal amount of patching of the original author's sources, something like the slackware distribution.

I suppose angstrom/OZ might be more to my liking if I were to try to start at least with the console image, and try to roll my window system from there, but building the x-window system has always been something of a nightmare for me.
koen
QUOTE(radiochickenwax @ Apr 21 2007, 03:25 AM)
I suppose angstrom/OZ might be more to my liking if I were to try to start at least with the console image, and try to roll my window system from there, but building the x-window system has always been something of a nightmare for me.
*


As opposed to pdaX, angstrom and OZ already have a shitload of packages in the feeds[1], so no need to compile or build sutff, just 'ipkg install <whatever>' and be happy.

[1] and everything is in a central place as well, so no need to add a zillion feeds and open a zillion forum threads with "can't find dep <foo> PLZ ADD!!!!11!11!one!"
Hrw
QUOTE(adf @ Apr 21 2007, 02:11 AM)
edit: I tend to think HRW is on the money here--despite his sounding like users are an inconvenience (which I'm pretty sure isn't what he meant)--  we can probably tweak a very usable angstrom/altboot for tosa, and it really would be better on 2.6
*


Users are not inconvenience for me - u-boot is. Instalation should be easy if not easier - thats why last OZ releases provided 'install kits' which user just need to unpack to card to get all files for flashing.

About those CLISP texts - I am open to give upload access to feeds for developers so official feeds can be updated and contrib feeds can be created - for example with 3.5.4 we had contrib feed with emacs (built on Zaurus). And anyone can join us - if you are good in tweaking system image and can provide patches but do not know how to use OE you are welcome too - we can work together to create something working for you and other users.
Meanie
QUOTE(radiochickenwax @ Apr 21 2007, 01:25 PM)
Here are some funny links related to this thread:

Why Users Should Not Exist

UNIX Hater's Handbook

Help Wanted For CLISP


The following is quoted from the last link above:
QUOTE
The prizes for handling these issues:

    * handle one issue and you will get CVS write access;
    * handle two issues and you become an admin of the CLISP project;
    * handle three or more issues and you become the principal maintainer.

This reminds me of a joke: after the 1991 Russian coup attempt (which lead to the final downfall of communism), the Communist Party was very unpopular and tried to increase the membership by asking its members to recruit new members, with the following incentives:

    * if you bring one new member, you don't have to pay membership dues
    * if you bring two new members, you may resign from the Party
    * if you bring three new members, you may resign and you will also receive a certificate that you have never been a member of the Party!"


Please note, I'm not trying to be negative about this, I just found all of the above humorous. I'm still very much committed to the idea of an open source ROM for tosa that would combine the stability of OZ and Sharp with the usability of pdaXrom.

Personally, I'm not very happy with angstrom or OZ out of the box. GPE has never worked all that well for me as a window system compared to pdaXrom's more standard setup. It's a great idea for a PDA, but I didn't buy the zaurii to run an open source version of WinCE which IMHO is probably the worst interface I've ever used.

What I'd like to know is how to make OZ/Angstrom "feel" more like a standard desktop system. pdaXrom does the best job of that task, but there are obviously a lot of issues with the rom beyond that point, which is why we even have this thread in the first place.

For me, I'm still harboring this notion that I should be able to build the whole rom from scratch natively, with a minimal amount of patching of the original author's sources, something like the slackware distribution.

I suppose angstrom/OZ might be more to my liking if I were to try to start at least with the console image, and try to roll my window system from there, but building the x-window system has always been something of a nightmare for me.
*




I think that at the moment, if you want to build a new distro for Tosa, the best combo would be to use OE and build the latest OZ or Angstrom system and then hack the shit out of it to make it usable.

OZ/Angstrom have a nice build system (if you want to cross-compile) and can generate shitload of packages with all the required dependencies. However, many of the generated packages are literally shit as well. They install and resolve dependencies, etc... but they just don't work or crash...

However, if you have the time to put together a working native compiler (one that is ready to build and compile real apps, not just - oh, gcc is installed and it can compile helloworld) or hack the stuff bitbake produces to make things actually work, then OZ/Angstrom would probably be the easiest way forward since there are indeed a lot of packages available, but you just need to spend some time to fix some of them to make them work. Just get the packages for essential apps work first and then gradually fix them all up...

The other thing is that the default theme in OZ/GPE really looks ugly. However, changing the theme results in some applications to crash due to missing icons, etc... so you will need to spend some time to create a proper good looking and working replacement theme (or steal one from pdaXrom).

One good thing about OZ is that it is compatible with the default Sharp bootloader and hence NAND backup/restore still works. Forcing people to use u-boot is just a big inconvennience for most ordinary users. Most users dont need to dual boot and hence don't need u-boot. Some advanced users may want to dual boot and those can add u-boot if they so desire. The same scenario exist on the PC. Most PCs come with just one OS and they boot straight into that one OS. Advanced users can then choose to install a bootloader that allows them to dual boot, and install whatever they want...

The OZ installer on the other hand is quite stupid. it just assumes a standard partition layout and flashes the ROM/distro. The pdaXrom installer is much better in this regard. it has options to allow user to resize partitions, etc..., the best would be to have an option in the installer to restore the original / generate the required partition table.

Alternatively, you could also use the OZ kernel and customise the OZ installer, and build a custom pdaXrom rootfs and make a initrd.bin file from that instead of using the OZ rootfs.
radiochickenwax
QUOTE(Meanie @ Apr 22 2007, 08:31 AM)
Alternatively, you could also use the OZ kernel and customise the OZ installer, and build a custom pdaXrom rootfs and make a initrd.bin file from that instead of using the OZ rootfs.
*


This sounds like the best option for me personally.

QUOTE(Meanie @ Apr 22 2007, 08:31 AM)
The OZ installer on the other hand is quite stupid. it just assumes a standard partition layout and flashes the ROM/distro. The pdaXrom installer is much better in this regard. it has options to allow user to resize partitions, etc..., the best would be to have an option in the installer to restore the original / generate the required partition table.
*



So, to follow this path, we could use your build tools to customize the following:

updater.sh = need to modify versiion of pdaxrom's updater.sh
zImage.bin = OZ or angstrom kernel image (untouched?)
initrd.bin = need to put elements from pdaxrom's jffs2 and OZ's jffs2 filesystems.
adf
that could be very interesting
radiochickenwax
Yeah, I've been wanting to do something like that for awhile. The trouble is which elements to put into the jffs2 filesystem, and that seems a matter of personal preference.
To some extent it doesn't even matter, I'd be happy right now just to get the pdaxrom rootfs to boot with the OZ kernel. I'll try this a little later today, and post some results.
adf
QUOTE(radiochickenwax @ Apr 24 2007, 12:01 AM)
Yeah, I've been wanting to do something like that for awhile.  The trouble is which elements to put into the jffs2 filesystem, and that seems a matter of personal preference. 
To some extent it doesn't even matter, I'd be happy right now just to get the pdaxrom rootfs to boot with the OZ kernel.  I'll try this a little later today, and post some results.
*



I'd think putting fairly little in the jffs2, and including altboot, or configuring uboot or doing a pivot root to sd or cf would be the best bet
radiochickenwax
This sorta reminds me of the etched marble experiments

I downloaded the build tools mentioned before:
http://www.tyrannozaurus.com/feed/pdaXii13...Xii13-build.tgz

I decoded the updater.sh scripts from pdaxrom beta1 and OZ 3.4.5 rc2 with the edecsh.c program. I'll try attaching them to this post in a little while.

Meanie's build tools have endecsh compiled already.
QUOTE
Grab an updater.sh file (I used the one from pdaXrom C3000 beta2) and use the endecsh utility to decode it into a normal shell script and customise the script.
# endecsh -d updater.sh updater.txt

Then use endecsh to encode the updater.sh script.
# endecsh -e updater.txt updater.sh

You can compile endecsh yourself or extract it from the updater-tools.bin file.

updater-tools.bin

The updater-tools.bin file is a tar file. It contains utilities from the pdaXrom tools.tar file.


... and indeed the endesch program is there.


QUOTE(adf @ Apr 24 2007, 03:25 AM)
I'd think putting fairly little in the jffs2, and including altboot, or configuring uboot or doing a pivot root to sd or cf would be the best bet
*


Altboot to SD would be my option of choice, since CF seems to have problems between suspends on Tosa in my experiences with PocketWorkstation. Hopefully, the larger SD support with the OZ kernel will bypass the 1GB limitation, and ipkg-link will still work for the CF slot.

I'm a little confused about how altboot works, so that might take awhile to figure out. Also, as mentioned before, and from what I can see so far, the two versions have very different installer scripts, which is a little intimidating, but I feel like I'm getting at least a little closer to patching them together, or at least understanding whether the OZ 2.6 kernel will flash with the pdaxrom rootfs.

Another thing that's troubling me is that pdaxii13 uses the 2.4.20 kernel, (from pdaxrom beta2) and OZ3.4.5 uses a 2.6 kernel... not sure which version off-hand. I think that choice was made mainly because pdaxrom beta4 (with the 2.6 kernel) seemed so buggy compared to beta3 (with the 2.4 kernel) , but there might be more technical reasons as well.

Edit:
Gonna try to work on the initrd.bin files with the jffs2 filesystems next. (maybe later today, or tomorrow... turns out I didn't have any time for a couple weeks, but I'd really like to get back to this sooner than later).
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.