Tosa Development Plan, where should dev effort go Options

[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]

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?

I take it Angstrom for the 6000 isn't looking hopeful?

[xjqian]

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]

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]

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:

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]

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.

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.

[radiochickenwax]

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.

Okay well, I'm sure you could get the monkeys to act out the scenes even if they can't write the sonnets. 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]

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.

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.

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)

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]

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