Tosa Development Plan

[radiochickenwax]

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.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

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

  pick a direction and I'll at least comment on it...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=158459\"][{POST_SNAPBACK}][/a][/div]

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.

[a href=\"https://www.oesf.org/forums/index.php?act=ST&f=88&t=23742&st=0#entry158768]https://www.oesf.org/forums/index.php?act=S...t=0#entry158768[/url]

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.

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.

[div align=\"right\"][a href=\"index.php?act=findpost&pid=158391\"][{POST_SNAPBACK}][/a][/div]

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:

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]

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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=159437\"][{POST_SNAPBACK}][/a][/div]

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]

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[div align=\"right\"][a href=\"index.php?act=findpost&pid=159435\"][{POST_SNAPBACK}][/a][/div]

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]

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:

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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=159437\"][{POST_SNAPBACK}][/a][/div]

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]

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.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

This sounds like the best option for me personally.

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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=159496\"][{POST_SNAPBACK}][/a][/div]

So, to follow this path, we could use [a href=\"http://www.users.on.net/~hluc/myZaurus/pdaxii13.html#build]your build tools[/url] 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]

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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=159610\"][{POST_SNAPBACK}][/a][/div]

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.

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.

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
[div align=\"right\"][a href=\"index.php?act=findpost&pid=159616\"][{POST_SNAPBACK}][/a][/div]

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