NSLU2

From Tuxisalive

Jump to: navigation, search

Contents

[edit] Porting of the tuxdroid toolsuite to the NSLU2

[edit] Intro

http://en.wikipedia.org/wiki/NSLU2 if you don't know what's about

[edit] Personal experience

(by Philippe Teuwen) 

First I installed Debian on it this evening.
Then I tried the various tuxdroid bits.
Here are the very first conclusions:

 * compiling tuxdaemon *OK*
 * running tuxdaemon *FAIL*
       o USB part seems ok (displays tux events properly) but not TCP
         part, seems not to be listening on port
 * compiling tuxup *OK*
 * compiling dfu-programmer *OK*
 * compiling svncrev *OK*
 * compiling tuxcore tuxaudio *OK*
 * flashing tuxcore.hex tuxcore.eep tuxaudio.hex tuxaudio.eep *OK*
 * sound *PARTLY*
       o ALSA and OSS-emulation layers are up
       o tests with mpg321 and aplay: the sound is quite hashed and
         lot of "alsa underrun" msgs, slightly better results through
         oss than alsa
       o recording at 8000 Hz mono is very poor (played on host)
       o playing at 8000 Hz mono is poor (recorded on host)
       o madplay -b8 -R8000 ...mp3 is correct

Note that madplay is a fixed point mp3 player.

So we can compile and flash the tux, try to get audio running better and
we definitively need to work on the daemon part.
Of course I couldn't try the tts daemon.
BTW does Acapela allow you to compile on ARM with your current
agreements and does it support fixed point mode?

[edit] Daemon

I ran the tuxdaemon on the slug and took control with gtdi from my laptop (simply edit gtdi.py and add the IP or machine name as arg to tux.daemon.auto_connect(True,'<IP/name>'))

[edit] Problems

  • I can do some actions but after a while the gui "slows down", feedback takes always 1 second when I do sth and the actions aren't performed anymore. If I restart the daemon the gui recovers very nicely till the next freeze, probably always on the daemon side.
  • It looks like all threads still go through the main code at exit time and I get: 
Daemon closed
Daemon closed
Could not delete PID file
Daemon closed
Could not delete PID file

-> one of the three already deleted the PID file and the 2 other complain that they cannot do it themselves.
Looks like all processes inherited the signal(SIGINT, on_close_daemon); while normally only one of them should handle the signal.

  • I could not use yet pthread_cond_wait(), I had to comment it otherwise TCP server never starts
    FIXED
  • Only one of the threads/processes actually changed its UID to nobody while on i686 the three threads are actually changed to UID nobody
    FIXED
  • Florent Vuillemin tried on OpenWrt with uClibc but faced problems to compile due to the dependancy on libgthread.

[edit] Reasons

On my PC:# getconf GNU_LIBPTHREAD_VERSION 

NPTL 2.3.6

On NSLU2:# getconf GNU_LIBPTHREAD_VERSION 

linuxthreads-0.10

So the Etch for ARM seems to still use linuxthreads and from wikipedia:
The LinuxThreads project used this system call to simulate thread support entirely in userland.
Unfortunately, it had a number of issues with true POSIX compliance, particularly in the areas of signal handling, scheduling, and inter-process synchronization primitives.

Immediate conclusion is that tuxdaemon requires NPTL to work properly which means it is necessary (but not sufficient) to have a 2.6 kernel.

[edit] TODO

  • To help debugging, you can force usage of the linuxthreads instead of NPTL 
 LD_ASSUME_KERNEL=2.4.28 tuxdaemon
  • What I propose as first step is to use only the libpthread from the GNU libc (glibc, pkg libc6) and to not mix them with the libgthread from the Gnome lib (glib, pkg libglib2.0).
    So stick only to the pthread_xxx() fcts described in glibc-doc. uClibc should support pthreads properly.
  • Reorder the operations so setuid is before creating threads/forking and I don't need TCP server to wait anymore:
    DONE
    • (in main) USB enumerate
    • USB open handler
    • setuid nobody
    • create USB and TCP threads
  • From some posts on the net, NPTL will be available on ARM with glibc 2.5 and on Debian apparently libc6 unstable is 2.5-3
    I could give a try but the I've basically to upgrade all the distro to unstable and i'll do that only if I can mirror the current setup to another external harddrive.
  • Make tuxdaemon backward compatible with the slightly less POSIX compliant linuxthreads.
    cf http://pauillac.inria.fr/~xleroy/linuxthreads/ and its readme and faq
Retrieved from "http://wiki.tuxisalive.com/index.php/NSLU2"
Personal tools