OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3  
Reply to this topicStart new topic
> Tosa Development Plan, where should dev effort go
radiochickenwax
post Apr 13 2007, 03:29 PM
Post #31





Group: Members
Posts: 158
Joined: 21-November 04
Member No.: 5,548



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.
Go to the top of the page
 
+Quote Post
adf
post Apr 13 2007, 07:11 PM
Post #32





Group: Members
Posts: 2,821
Joined: 13-September 04
From: Wasilla Ak.
Member No.: 4,572



Angstrom sounds hopeful, at least. I haven't played with it yet.
Go to the top of the page
 
+Quote Post
Hrw
post Apr 20 2007, 05:52 AM
Post #33





Group: Members
Posts: 1,376
Joined: 11-January 04
From: Poznań, Poland
Member No.: 1,413



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.
Go to the top of the page
 
+Quote Post
adf
post Apr 20 2007, 04:11 PM
Post #34





Group: Members
Posts: 2,821
Joined: 13-September 04
From: Wasilla Ak.
Member No.: 4,572



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
Go to the top of the page
 
+Quote Post
radiochickenwax
post Apr 20 2007, 07:25 PM
Post #35





Group: Members
Posts: 158
Joined: 21-November 04
Member No.: 5,548



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.
Go to the top of the page
 
+Quote Post
koen
post Apr 20 2007, 08:21 PM
Post #36





Group: Members
Posts: 1,014
Joined: 4-January 05
From: Enschede, The Netherlands
Member No.: 6,107



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!"
Go to the top of the page
 
+Quote Post
Hrw
post Apr 20 2007, 11:03 PM
Post #37





Group: Members
Posts: 1,376
Joined: 11-January 04
From: Poznań, Poland
Member No.: 1,413



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.
Go to the top of the page
 
+Quote Post
Meanie
post Apr 22 2007, 12:31 AM
Post #38





Group: Members
Posts: 2,808
Joined: 21-March 05
From: Sydney, Australia
Member No.: 6,686



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.
Go to the top of the page
 
+Quote Post
radiochickenwax
post Apr 22 2007, 02:48 PM
Post #39





Group: Members
Posts: 158
Joined: 21-November 04
Member No.: 5,548



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.
Go to the top of the page
 
+Quote Post
adf
post Apr 22 2007, 08:45 PM
Post #40





Group: Members
Posts: 2,821
Joined: 13-September 04
From: Wasilla Ak.
Member No.: 4,572



that could be very interesting
Go to the top of the page
 
+Quote Post
radiochickenwax
post Apr 23 2007, 04:01 PM
Post #41





Group: Members
Posts: 158
Joined: 21-November 04
Member No.: 5,548



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.
Go to the top of the page
 
+Quote Post
adf
post Apr 23 2007, 07:25 PM
Post #42





Group: Members
Posts: 2,821
Joined: 13-September 04
From: Wasilla Ak.
Member No.: 4,572



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
Go to the top of the page
 
+Quote Post
radiochickenwax
post Apr 24 2007, 10:19 AM
Post #43





Group: Members
Posts: 158
Joined: 21-November 04
Member No.: 5,548



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 post has been edited by radiochickenwax: May 1 2007, 09:25 AM
Go to the top of the page
 
+Quote Post

3 Pages V  < 1 2 3
Reply to this topicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st October 2014 - 07:10 PM