Messages

151

Zaurus - pdaXrom / What\'s going on (CF problem)?

« on: April 27, 2004, 05:54:06 pm »

Hello!
cardmgr: mount: wrong fs type, bad option, bad superblock on /dev/hda1.
cardmgr              or too many mounted file systems

I use ext2 on CF and get the same messages all the time, but it actually mounts ok
Try \'ls /mnt/cf\' to see if the files are there...

152

Zaurus - pdaXrom / Software floating point as a library versus kernel emulation

« on: April 27, 2004, 01:32:47 pm »

We all know that Z has no floating point unit. Therefore, all floating point operations have to be emulated.

The current pdaxrom kernel still uses Netwinder floating point emulation. It works fine and all, but it is quite slow. While there is an option to use alternative in-kernel floating emulation, which is faster but doesn\'t always work, there is a better way to cope with floating point issues.

There is a possibility to tell gcc to use library functions to emulate floating point operations, rather than to emit floating point instructions which are then emulated by the kernel. This approach would be much more faster. The relevant gcc option is \'-msoft-float\'.

Unfortunately, when I try using it with SDK, gcc complains about crtn.o / crtend.o using hardware FP, while the program itself uses software FP. It looks like the current environment needs to be reconfigured and recompiled by the pdaXrom team to make this work.

Answering the question about whether it really works or not: it does. Once upon a time I had a natural Debian running on my Zaurus. I tried that trick there with a simple program and I got 2x floating point speedup. The \'-msoft-float\' option just worked there. The only thing it needed was \'libfloat\' library (it was apt-get\'able).

Unfortunately, it doesn\'t seem to work in pdaXrom. It would be very good to move to the in-library software floating point entirely, as it is the most natural way of execution, and, most notably, it is significantly faster.

This is a call to pdaXrom developers. I would very much like you people to look at this issue. This may be a great improvement to the much beloved pdaXrom.  That would help us all.

///

p.s. I abandoned all attempts to get natural Debian working acceptable on Z since then -- the main issue was poor X server. I had my breath hold when I found the pdaXrom project. Now I switched to it entirely and enjoying the thing. I just would very much like to have floating point support improved though

153

Zaurus - pdaXrom / Quick questions

« on: April 23, 2004, 05:38:22 pm »

Some general questions :  
1. What is the difference between dillo and dillo xft ?

Xft version gives you nicely antialiased fonts. They will not be antialiased without xft. That\'s the main difference

154

Zaurus - pdaXrom / Playing video in 320x240 fullscreen

« on: April 18, 2004, 02:01:54 pm »

Does this mode work on the 5600?
Playback is already possible with 320x240 on the 5600 outside of Qtopia so I dont know if there is any benefit to creating the fbmode.

There is no benefit from creating the fbmode on 5600. It only benefits SL-C7x0, and possibly 6000. Anyway, we\'re talking about pdaXrom\'s supported devices here, and they are currently limited to SL-C7x0 only.

155

Zaurus - pdaXrom / Playing video in 320x240 fullscreen

« on: April 18, 2004, 10:03:38 am »

mplayer first complained about libmad, which I grabbed from the pdaXrom feed. Next it complained about libvorbisidec which isn\'t on the pdaXrom feed.

Note that it\'s easier to let zaurus download everything it needs itself, either from the graphical package manager, or by ipkg install \'package name\' (not by file name, but rather by a package name).

Any pointers to libvorbisidec (also needed by xmms)

I\'m using mplayer_0.91_armv5tel.ipk from the pdaXrom feed.

The package you need is called \'tremor\'.

156

Zaurus - pdaXrom / New pdaXrom installer (to have just Root partition)

« on: April 17, 2004, 03:04:12 pm »

Ok, now I know what\'s happening with SL-C750. Just look at Sharp\'s kernel source:

$ cd linux/fs/jffs2/

(Note that SL-C760 is codenamed \'husky\')
$ grep -r HUSKY *

build.c:#ifdef CONFIG_ARCH_PXA_HUSKY
build.c:#ifdef CONFIG_ARCH_PXA_HUSKY
fs.c:#ifdef CONFIG_ARCH_PXA_HUSKY
nodelist.h:#ifdef CONFIG_ARCH_PXA_HUSKY
super.c:#ifdef CONFIG_ARCH_PXA_HUSKY
super-v24.c:#ifdef CONFIG_ARCH_PXA_HUSKY

All these #ifdefs (except one) say that for C760 we should use consistent_alloc, for all other models kmalloc should be used instead. Now it becomes apparent: only C760 has two large (64Mb) partitions, so large that kmalloc can\'t live with them.

The remaining one #ifdef says to increase reserved bad blocks from 24 to 80 for husky. The larger partitions, the bigger possible amount of bad blocks. Or maybe C760 flashes are worse than on other models

The outcome: you can\'t use standard maintenance kernel on C750 to create one big root partition. You will have to reflash it.

How to fix the kernel: remove the aforementioned conditional statements there, leaving only the C760 code. This way it will most probably work

157

Zaurus - pdaXrom / New pdaXrom installer (to have just Root partition)

« on: April 17, 2004, 01:06:26 pm »

So mtd2 formats fine with \"eraseall -j\", but when I try mounting it I get this error:

  [span style=\'font-size:16pt;line-height:100%\']# cd /tmp1
  # mkdir foo
  # mount -t jffs2 /dev/mtdblock2 /tmp1/foo
  mount: Mounting /dev/mtdblock2 on /tmp1/foo failed: Invalid argument
  #[/span]

Is anything additional showing up in \'dmesg\' after you issued a failing mount command? How long does it take for the mount command to fail?

From my experience, there were two problems with jffs2 I stumbled upon. First, when the flash is dirty, you have to have at least one valid inode for the mount to succeed. Second, when the partition size is quite big, jffs2 fails to allocate enough memory, because it uses kmalloc, and the required allocation size is bigger than 128k (the maximum that kmalloc can allocate). The latter problem is fixed by changing the code to use vmalloc instead of kalloc, but anyway, it shows up only with bigger partitions (say, 256M or 512M with the appropriate erasesize). It doesn\'t show up even on 128M with the 16k erasesize, as in SL-C760. So I do not really know what to suggest at the moment, further investigation is needed. Wells, inserting tons of printk\'s to the kernel always helps, but there may be a more simple solution

158

Zaurus - pdaXrom / Playing video in 320x240 fullscreen

« on: April 17, 2004, 12:30:29 pm »

Here are the steps needed to play videos in 320x240 fullscreen:

1) First, install mplayer from the pdaxrom feed. No other additional software is needed.

2) Next, create the file /etc/fb.modes with the following contents:

mode \"qvga\"
    geometry 320 240 320 240 16
    timings 1 2 3 4 5 6 7
endmode

Now, to play your file, you must first exit from X if you\'re running it (issue \'killall X\' in terminal). You can only play fullscreen video from the console at the moment.

3) When you\'re in console, run mplayer with the following command:

mplayer -vo fbdev -fbmode qvga -vm -ac mad file.avi

assuming \'file.avi\' is the file you want to play. You can supply any other options as well, or put them in your ~/.mplayer/config file. The only relevant options are

-fbmode qvga, which instructs mplayer to switch to the mode \'qvga\' described in /etc/fb.modes, and

-vm, which enables video mode switching

After the playback is finished, your screen becomes garbled. Issuing \'startx\' command to get back to X works ok, but when you quit it back, the console is unfortunately still garbled. No solution for this yet, apart from reboot that will surely help

159

Zaurus - pdaXrom / Playing Video on pdaXrom

« on: April 17, 2004, 11:48:15 am »

my goal is to play advmame in 320x240 full screen without using mame to \"zoom\" or \"fat bit\" the display -- as that
seems to slow it down to a CRAWL!
Scott

Well, does it utilize SDL? If it does, you can run it from console. SDL supports frambuffer and can automatically switch to 320x240, and even cleanly restore back to 640x480 upon exit.

Now, people, on the mplayer in 320x240 fullscreen: it is actually possible to achieve the same result without any external \'fbset\' tool, as the needed functionality is actually already present in mplayer itself. I\'m making a separate thread about it so more people would know.

160

Zaurus - pdaXrom / Screen rotation applet

« on: April 15, 2004, 06:34:28 pm »

terminate,

it works nicely, but I would rather have auto-rotation.

When it comes to me, I would rather like to have auto-rotation with the ability to override it; for instance, when I want to browse the web in the landscape orientation, but with the Zaurus closed. This was possible with qtopia, which incuded the manual rotation option in the menu. The ability to arbitrarily rotate the screen in four orientations would be an added bonus.

161

Zaurus - pdaXrom / My filesystems are read-write, and I\'m root! = ouch!

« on: April 15, 2004, 06:10:52 pm »

Am I the only one who is a little concerned that all the filesystems on pdaXrom are RW, plus I\'m running as root which is always a recipe for disaster (or accidental erasure of /bin)

Has anyone used a normal user accout, does everything still run ok?

I am also a little concerned that there is too much flash activity in the internal memory, I want the longest life possible for my Z, any ideas on that? I was thinking of moving temp files to my MMC card, are there any issues?

The underlying jffs2 filesystem is well aware of the flash aging, so it is deliberately designed with the so called \'wear leveling\' idea in mind. The idea is to evenly balance write operations across all flash space. That is, each time you write the same file, it occupies different physical space on your flash. Now just multiply the given 100,000 by the number of the erasesize blocks (8192 on a 128M flash), and you get total number of writes before the death of the flash. So just relax, it will last for quite some time

Btw, you can mount your /tmp to reside entirely in your RAM memory to somewhat lower flash usage. You\'ll get an increase of memory usage proportional to the amount of data in our /tmp though.

On the root issue: that\'s just a PDA, a small and typically single user environment, so all these unix full blown permissions will most probably bother you instead of helping. After all, remember that most users on a full blown Windows computers are root too, and somehow they survive

162

Zaurus - pdaXrom / Playing Video on pdaXrom

« on: April 15, 2004, 05:47:34 pm »

ikm, do I need to create a file with the modes? /etc/fb.modes?

You don\'t have to. It\'s more just a matter of taste. Instead of passing \'-xres 320 -yres 240\' each time, you can write /etc/fb.modes and put that info there under some short name, and do fbset \'your mode name\' instead.

163

Zaurus - pdaXrom / Playing Video on pdaXrom

« on: April 15, 2004, 03:28:53 pm »

Hi,

Thanks for yours command line, but ikm, should we use the new fbset package, because there is already one in pdaXrom.

I think ikm\'s point was, that the one supplied does not work.

Yes, that\'s right, the one supplied won\'t work since the required features are not compiled in.

hwkeye, have you received my mail?

164

Zaurus - pdaXrom / Playing Video on pdaXrom

« on: April 15, 2004, 12:52:20 pm »

fbset -xres 320 -yres 240 && ( mplayer -ac mad file.avi ; fbset -xres 640 -yres 480 ; clean )

Yep, that\'s better

165

Zaurus - pdaXrom / Playing Video on pdaXrom

« on: April 15, 2004, 10:36:24 am »

Hi ikm,

could you give us the right coammand line to play mplayer with fullscreen ?

which command you use starting from scratch ?

fbset -xres 320 -yres 240,
and ........

Yes, something like

fbset -xres 320 -yres 240 && mplayer -ac mad file.avi && fbset -xres 640 -yres 480

you can send me the package here richardtfr@yahoo.fr

Will you put it somewhere for public download? I don\'t like to be bothered with mass-mailing.

Btw, it\'s not the package, just one executable. To install, assuming it lies on your CF:

rm /usr/sbin/fbset
cp /mnt/cf/fbset /usr/sbin/fbset
chmod +x /usr/sbin/fbset