Hey sashz,

I played with OZ/bitbake a few weeks ago and while the userspace stuff has a long ways to go, Linux 2.6 seemed a lot snappier and included a GPL version of the SDMMC driver (solving the I/O error on resume once and for all).

Is it a huge deal to get pdaXrom running on top of it instead of 2.4? Admittedly I haven't tried yet but I recall there being at least a video patch or something in there for the X server, and doubtless others.

Hi, a few month ago I tried to run pdaxrom using the kernel. I replaced in the updater files from pdaxrom the files related to the kernel with the ones from OZ, but at boot time I got a error about a missing terminal.


CF

You mean you used the OpenEmbedded (OE) buildsystem powered by bitbake to build OpenZaurus (OZ)?

Exactly. I built the gpe-image of OZ 3.5.4. While the system was more robust (more packages, Linux 2.6.14-rc1, seemed to track more closely to debian) all of the graphical stuff was years behind pdaXrom. Everything just works better on pdaXrom. Faster X server, special keys work, etc. Which makes sense because pdaXrom really only targets Zaurus, and mostly the clamshells.

So I gave up and went back to pdaXrom, and the only thing I *really* miss is 2.6. I still have the recurring problem of I/O errors every 3rd or 4th resume. My patch helps a little, but the sharp driver is *very* broken.

Well I'm not too worried about these problems.. I'm more worried about there being a bunch of pdaXrom-specific stuff in the kernel that needs to be ported to 2.6.

Getting the boot sequence right is just a matter of trial and error.

How much faster is the X server? And why? Iirc it's linked against the w100 stuff isn't it - I thought we had this with GPE now, I must check...

Regarding the special keys - yes this is lacking, but there really aren't many of us with c7x0 machines who use GPE so it's a gradual process unfortunately,

Keep up the good work,


Si

The default Xserver for c7x0 in OE (not OZ) is regular kdrive from fdo cvs. The framebuffer device in 2.6 is slightly smarter than the one in 2.4, but it's still unaccelerated. Thanks to pre-emptive multitasking and improved memcopy support it feels a lot faster (response time is lower) but it still draws a lot slower (no blit/fill/rect accel) than the Xserver from pdaX.
I did read in a pdaX thread that 2.6 was nonsense since the Z wasn't a smp machine. I really hope that was an uninformed nitwit and not a pdaX dev....
As it is right now, 2.6 is at least 30% faster in benchmarks than 2.4, so I hope pdaX will use it so more people can test it.

i hear that it handels memorey a bit better and has more support for embbeded devices. if you want an accelerated frame buffer you really need somthing like directFB with XdirectFB running on top of it.

alll it is is a libary of graphical functions for 2D operations, for the pxa250's you probelly couldnt optimise it that much but for the newer generation with pxa270's you could (IWMMX ) but you never know, you might be able to potimse some more performace out ot it (dont know if the default FB uses DMA but that would speed things up if its not bieng used)

Sash will be starting some testing with the 2.6 kernel today :-) But we will probally stay focussed on finishing the current one and good and stable before changing kernel.

I keep asking this.... it is always a little off topic, sorry.
BUT, has anyone looked into 2gig sd/mmc cards running in 2.6? afaik the sharp 2g sd issues are a kernel/driver problem which might conceivably be fixable. Does any one know? has anyone tried? does it not seem worthwhile (at least to c-7 & 800 series and 1000 and 6000 owners?) Or am I barking up the wrong tree entirely??

Don't forget gcc-4 (and qt4).

and libc6 2.3.x

Send me one and I'll tell you if it works.


Si

2G cards don't work on any Zaurus yet. It's not clear whether this is just a timing problem (larger SD cards need additional timeout) or something else.

Ah.
Thanks

Any further progress on 2.6 running under pdaxrom?