Messages

1

Sharp ROMs / Cacko 1.24 - A Wishlist

« on: February 29, 2008, 03:49:08 pm »

integrating qt4/qtopia4 might be worthwhile IF you could be sure that you could, say, replace most of the standard apps with new qt4 ones, and yet have sufficient compatibility to still run the original Sharp apps. If you lose sharp compat, you might as well simply install angstrom with qt4 or opie2!

I agree that replacing as many of the kernel modules as possible with ones backported from later 2.4 kernels if possible, but that would be a lot of work; I think Anton did that when he build cacko1.23. And of course updating all the misc patches like ssh, busybox etc would be important - remembering that it all has to be gcc2.95.x compatible for the kernel and glibs!

So, actually, how many Sharp apps are actually worth keeping? Is it simply that cacko is a well-rounded system with working control panels for network, bluetooth, speed, overclocking, dialup, etc? How far off that is pdaXrom, Angstrom, Debian or Poky and would it be more worthwhile to make these work?

Hi all
It's possible to create a new set of libraries related to a new version of gcc (necessary for compiling qt4) in parallel with the original cacko ones, an analogy is how the different linux distros are dealing with the AMD64 architecture, they have a /lib64 directory for the new 64 bits libraries and a /lib for the old 32 bit ones.

2

pdaXrom Development / Pdaxrom Developement

« on: December 21, 2007, 01:09:21 pm »

Ouch, this hurts!
Well, first I have to show my admiration for all of you that have kept (and I hope will keep) pdaXrom running. I understand how big task is it.
I should say that the zaurus is a kind of "travel laptop" for me, a laptop I can carry in my pocket. I don't use it as a PDA, I already have a pdaphone that I use for all my PIN needs, I use the zaurus as a pocket unix machine, this makes it unique.
Looking at the future I think it would be a very good idea having Angstrom as the base for the a new pdaXrom, there are advantages:
-- They provide a very good, clean and clear build system, why don't use it?
-- They write kernel code and add functionality, I suppose that if something different is needed for pdaXrom, it is easier to add only that functionality than trying to put together 150 patches and trying to make some sense from them...

Basically pdaXrom would build an easy to use system over the (strong) shoulders of Angstrom (look at how well Ubuntu stands on the shoulders of Debian).  

Maybe pdaXrom need more contributers as well, here I can speak in my own name: I've been trying to contribute since I bought my zaurus in Akihabara more than 2 years ago, but I have a very big problem, my time. I am sure this is a problem pdaXrom devs have as well, but I cannot make it better.That does not mean I cannot contribute: I can do small things in the short periods I have some free time, and I think there are many people like me.
Maybe it would be a good idea to have the problems listed in one place,  broken down in very small, self contained pieces, with some kind of difficulty scoring (difficult, average, easy) and a "tutor", somebody who knows how to solve it and give hints of how to do it. People could take the piece they want, ask to the tutors if they have any problem, solve it and commit afterwards.... learning in the process as well. This way you can "morph" a tecchy Angstrom in a more friendly pdaXTrom...

I don't know, I just wanted to be useful.

E

3

Linux Applications / Xlib Assistance, Please

« on: December 17, 2007, 11:41:23 am »

Doesn't work for you painting on the root directly as an usual window?
haven't tried that, but I think you are allowed to use the "normal" xlib routines to draw on it like it were another, non-root, window.
There is a very simple example in:
http://zez.org/article/articleprint/87/
The only thing you may need to change in that example is the creation of an application window, you don't need it so you can try to paint directly on the root.
I repeat I haven't tried that, but it should work

4

pdaXrom Development / 4.2.1 Gcc Update

« on: October 08, 2007, 06:59:52 am »

Only asking with curiosity, is anything wrong in the gcc 4.2.1 toolchain I prepared some time ago? if the there is, just tell me and I will try to fix it (not right now because I am very busy at the moment, but will do it with time)

Cheers
E

5

pdaXrom Development / Release Included Packages

« on: September 11, 2007, 09:56:41 am »

Too much work for InSearchOf, isn't it?
I had a look at the roadmap:
http://www.pdaxrom.org/?q=node/228
And basically everything is made by InSearchOf, I hope he survives!

Cheers
E

6

pdaXrom Development / Who Does What In Pdaxrom?

« on: September 04, 2007, 06:35:45 am »

Well, who is doing what in pdaXrom?

I am glad to contribute, but my spare time comes in bursts, so I have to be careful choosing what subject can I work on so I can finish it before the burst is gone. That makes difficult for me to start a whole new project, I prefer to do small contributions I can finish spending  some evenings along one week (like the toolchain I ported but that looks like no one is using, I don't have any bug report   ).

I will be very pleased if the developers say something about their problems and share a little the problems they are facing.

Cheers
E

7

Zaurus - pdaXrom / Some Questions To Pdaxrom Developers

« on: August 28, 2007, 03:42:32 pm »

I've been searching in the forums but I cannot make a clear idea, so I ask here.

pdaXrom builder:
I've tried to download it from the links I've found, but all of them look down. Is there any place I can download it from?

pdaXrom milestones:
Do you keep a place with the desired milestones for the project?

Which XScale features don't have support in the kernel yet?

/dev/bvdd aka bulverde:
I downloaded the XScale programming manual from the old intel website, an I think this device refers to the YUV overlay it has, is this point right?.
I understand it can accelerate video (it's not necessary to make any YUV->RGB conversion), but how can it accelerate the SDL? are the people talking about something else? Is it ported to the 2.6 kernel? Is the potatoes price going to raise?

Although I have a zaurus since more than one year ago, it was not more than a brick on my desk for all that time...  

Thanks in advance to all you who put your effort on such a fine piece of software.

8

Zaurus - pdaXrom / Gcc-4.2.1+glibc-2.6.1 Cross Toolchain Available

« on: August 27, 2007, 12:34:38 pm »

I'm here -- pdaXrom doesn't have a lot of activity -- so I no longer check it daily.

I'm slurping down the files now and I'll post a link when it completes ... at 9% now.

Scott

ok:

http://zaurus.spy.org/tc/

should be faster to dl ...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=166659\"][{POST_SNAPBACK}][/a][/div]

Thanks a lot.

9

Zaurus - pdaXrom / Gcc-4.2.1+glibc-2.6.1 Cross Toolchain Available

« on: August 24, 2007, 04:35:42 am »

Well, I suppose ScottYelich is busy doing something else, well here are the links:

http://sandia.homelinux.net/public/storage...bc-2.6.1.tar.gz   ( Warning 70MB!)
http://sandia.homelinux.net/public/storage/HowToInstall.txt

Be patient when downloading, this is my home server and I have a very crappy ADSL connection  (you are lucky if having more than 40KB/s)

I would appreciate if somebody mirrors those files.

It would be a good idea if somebody checks the compiler in these areas:

-- Is NPTL working correctly? I had to do some header gymnastics to make it compile.

-- Can you compile to IWMMX? I think the support is in, but I might be wrong.

-- Does it support non EABI platforms?

I am not very familiar with the xcale family, I don't know if I chose the proper parameters.

with your feedback I will be able to launch another iteration.

After the bank holidays (maybe Tuesday or Wednesday) I will start preparing a native environment, compiled optimizing for size instead of speed, so we can use this compiler in the zaurus as well.

E

10

Zaurus - pdaXrom / Gcc-4.2.1+glibc-2.6.1 Cross Toolchain Available

« on: August 23, 2007, 10:28:55 am »

linuxthreads being deprecated

use nptl - it is a lot faster.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=166615\"][{POST_SNAPBACK}][/a][/div]

The issue is I wasn't able to compile without linuxthreads, even enabling nptl (I know is faster and it has other advantages as well). GLIBC 2.6.1 comes without linuxthreads, and the compilation error was telling me preciselly this: I needed a linuxthread library that wasn't there.

The tarball contains a nptl enabled version of glibc 2.6.1, it was quite tricky to achieve, because as I said, glibc 2.6.1 does not come with linuxthreads.

Have anyone had a look at the compilation parameters? I've built this for pdaXrom and I would like to know if they are compatible with it.

If someone is interested, I also compiled a 64bit version of the toolchain, that is the one I am really using in my desktop. Just ask for it and I will make it available.

E

11

Zaurus - pdaXrom / Gcc-4.2.1+glibc-2.6.1 Cross Toolchain Available

« on: August 22, 2007, 04:04:38 pm »

I will gladly mirror to provide a location for people to make copies.
let me know where to grab the items and I will post here with their new location.

Thanks!

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

Thanks Scott, I've sent you the links in a private message.
The only test I've done to the compiler is a self compiling test and a binutils build. both where okay.

Cheers.
E

12

Zaurus - pdaXrom / Gcc-4.2.1+glibc-2.6.1 Cross Toolchain Available

« on: August 22, 2007, 09:11:29 am »

UPDATED:
I've just logged in my server at home: glibc-2.6.1 build has finished correctly, it was quite tricky. So the toolchain is gcc-4.2.1 + glibc-2.6.1 (both the very latest).

I will make it available for downloading from my home server, be aware, its about 70Mb, and I have a crappy ADSL connection (not more than 40KB/s uploading). May I leave the package somewhere?

Cheers.
E

13

Zaurus - pdaXrom / Gcc-4.2.1+glibc-2.6.1 Cross Toolchain Available

« on: August 22, 2007, 06:58:53 am »

[Updated, see next message in thread, old thread title was "Gcc 4.2.1 + Glibc 2.5 Cross Toolchain Available"]

Hi people.

I've just come back from my holidays (3 weeks in Japan, what a marvellous country, what marvellous people!) and I've retaken this personal project of having Qt4 in pdaXrom, see:
https://www.oesf.org/forums/index.php?showtopic=24389

Well, I've built a new toolchain based on gcc 4.2.1 (the latest one) and glibc 2.5 (not so current, 2.6.1, the latest, gives a lot of problems due to linuxthreads being deprecated in glibc 2.6).

I ended up with a 250Mb monster in my /opt directory . Hopefully the tar.gz package is about 70Mb.

The major drawbacks is that glibc didn't compile with kernel 2.4.x headers (at least I didn't manage to find any way to do that). I am afraid this thing is going to run on the new 2.6 kernel only (there are some more restrictions, like I had to use the headers from the kernel 2.6.16 to achieve a complete build).

Anyway, can somebody tell me where to put a tar.gz of this? I would like the people test it.

The package content::
binutils-2.17
gdb-6.6
glibc-2.5 (bootstrapped in gcc-4.1.2, not in a 3.x series as is usual in arm architectures)
gcc-4.2.1 (c and c++ support, planned fortran and pascal)
libstdc++ v3

and the other misc thing to keep all those programs running.

I didn't have too much idea about the correct parameters for the architecture, so these are the configure command lines, just I leave them here so someone can tell me if I should drop or add something:

gcc configure command line: \"'--cache-file=./config.cache' '--build=i686-host_pc-linux-gnu' '--host=i686-host_pc-linux-gnu' '--target=arm-softfloat-linux-gnueabi' '--prefix=/opt/cross/arm/gcc-4.2.1-glibc-2.5/arm-softfloat-linux-gnueabi' '--with-float=soft' '--with-headers=/opt/cross/arm/gcc-4.2.1-glibc-2.5/arm-softfloat-linux-gnueabi/arm-softfloat-linux-gnueabi/include' '--with-local-prefix=/opt/cross/arm/gcc-4.2.1-glibc-2.5/arm-softfloat-linux-gnueabi/arm-softfloat-linux-gnueabi' '--disable-nls' '--enable-threads=posix' '--enable-symvers=gnu' '--enable-__cxa_atexit' '--enable-shared' '--enable-c99' '--enable-long-long' '--enable-languages=c,c++' '--program-transform-name=s,^,arm-softfloat-linux-gnueabi-,; ' '--srcdir=/srv/sources/z/src/crosstool-0.43/build/arm-softfloat-linux-gnueabi/gcc-4.2.1-glibc-2.5/gcc-4.2.1/gcc' 'CC=gcc' 'CFLAGS=-g -O2' 'GMPINC=' 'GMPLIBS=-lmpfr -lgmp' 'LDFLAGS=' 'build_alias=i686-host_pc-linux-gnu' 'host_alias=i686-host_pc-linux-gnu' 'target_alias=arm-softfloat-linux-gnueabi'\"

glibc:
\"'--prefix=/usr' '--build=i686-pc-linux-gnu' '--host=arm-softfloat-linux-gnueabi' '--without-fp' '--with-tls' '--with-__thread' '--enable-kernel=2.6.0' '--enable-kernel=2.6.4' '--without-cvs' '--disable-profile' '--disable-debug' '--without-gd' '--enable-shared' '--enable-add-ons=yes' '--with-headers=/opt/cross/arm/gcc-4.2.1-glibc-2.5/arm-softfloat-linux-gnueabi/arm-softfloat-linux-gnueabi/include' '--cache-file=config.cache' 'CC=arm-softfloat-linux-gnueabi-gcc ' 'CFLAGS=-O ' 'build_alias=i686-pc-linux-gnu' 'host_alias=arm-softfloat-linux-gnueabi'\"

Any comments on those parameters?

Do the kernel people think this thingy is useful for them?

Any hints what to do next to have Qt4 running?

Btw, completing Qt4 would close the feature request described in case number  200-40:
http://www.pdaxrom.org/?q=node/220

Cheers
E

14

Zaurus - pdaXrom / My Attempts To Build Qt4

« on: July 23, 2007, 10:39:53 am »

I am quite sure the problem is related to the unexistence of glibc-linuxthreads-2.6

Linuxthreads was removed. Use NPTL instead of it.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=165283\"][{POST_SNAPBACK}][/a][/div]

Yes, I do, but the compilation then fails because of undeclared symbols that I think are related to linuxthreads. Maybe I need a header or something like that.

I will post the precise error tonight.

15

Zaurus - pdaXrom / My Attempts To Build Qt4

« on: July 23, 2007, 05:21:02 am »

Some problems compiling glibc
=========================

Well, I managed to compile:
1 - The last binutils,
2 - The last GCC (4.2.1, released just 4 days ago, without glibc support)

so the two other steps needed to have the complete toolchain are:

3- Compiling glibc (this is the problematic point read more)
4- Compiling GCC 4.2.1 again with glibc support (to be honest, once point 2 has succeeded, I don't expect problems here)

The amazing case of the problematic point 3
----------------------------------------------------------------

Well, when the build of glibc failed I thought it was related to GCC 4.2.1, many times, the latest compiler is not able to compile glibc, so I tried to build it with the 3.4.6 tool chain available somewhere in the forum, with the same result.

I am quite sure the problem is related to the  unexistence of glibc-linuxthreads-2.6, does anyone know what happened to it, I cannot find it anywhere? I am tempted to use the one for glibc 2.5 instead (will try this evening), but I am reluctant to do so, because of the possible stability issues (may trigger very difficult to find bugs, thread related issues are very hairy matters)

I may go back to glibc 2.5 (but, this is not the COOLEST, LATEST and GREATEST release)

Choosing the target
----------------------------

Another question, I've built the compiler with options for softfloat and xscale, there is another very interesting one iwmmx:
- does anyone know what is the difference of compiling for a iwmmx target insead of a xscale one? both are exclusive, OR you compile for a xcale target OR you compile for a iwmmx target, not both. My guess is that choosing the iwmmx target may produce code able to run in iwmmx enabled PXA's but not in others, but I may be wrong.
- how can it render the compiler incompatible with older pxa devices?

Any hint is appreciated.

thanks all
E