MPlayer for Kindle 4 Touch

[elRicharD]

Originally Posted by NiLuJe

Stupid question: Did you link against libasound statically or dynamically? In any case, which version of libasound did you build against?

Try to build (dynamically) against the same version as the one shipped on your target, the ALSA API/ABI can be tricky sometimes...

I am not absolutely sure, I just kept as many defaults as I could. The libraries I linked against were the ones I found on my Kindle, which I duly copied to the gcc library path and reran. Anyway both attempts (with libasound cross-compiled by me and with libasound taken from the Kindle) were the same: app runs but no sound, and straces looked very much the same.

[elRicharD]

I am downloading Kindle src for my fw version and also the Sourcery stuff, there is only one version there to get. I will see what I can come up with now.

[knc1]

Originally Posted by elRicharD

I am not absolutely sure, I just kept as many defaults as I could. The libraries I linked against were the ones I found on my Kindle, which I duly copied to the gcc library path and reran. Anyway both attempts (with libasound cross-compiled by me and with libasound taken from the Kindle) were the same: app runs but no sound, and straces looked very much the same.

I just installed (Ubuntu) scratchbox2 (already had qemu installed) and have started asking google for help.

Will start out by trying to install the KT, v5.1.0 system image in a scratchbox2 instance plus a CS (a.k.a: MG) toolchain and see how far I get on this learning curve.

Hmm...
Will use the source for strace as a test victum. Should be a lot easier than cross-compiling mplayer.

Don't anyone hold their breath here, I am old and work very, very slowly.
(But I do take good notes - so that may (someday) help someone.)

[elRicharD]

knc1, you might try with mpg123, it didn't cause trouble at all to me on compilation time, I just had to find the right options in configure and move the libasound lib files to the libpath for the compiler.

I really want to discover what is wrong. If you happen to build a nice environment to test this please document it the best you can, I will gladly follow and update any documentation you might generate, it would be of great use for the community for sure. Thanks!

[knc1]

Originally Posted by elRicharD

I really want to discover what is wrong. If you happen to build a nice environment to test this please document it the best you can, I will gladly follow and update any documentation you might generate, it would be of great use for the community for sure. Thanks!

Slowly but surely working on it. This answers the "what compiler" question (/bin/umount in KT-5.1.0 image):

bin $ objdump -sx umount
. . . .
Contents of section .comment:
 0000 4743433a 20284c69 6e61726f 20474343  GCC: (Linaro GCC
 0010 20342e35 2d323031 312e3035 2d302920   4.5-2011.05-0) 
 0020 342e352e 34203230 31313035 30352028  4.5.4 20110505 (
 0030 70726572 656c6561 73652900 4743433a  prerelease).GCC:
 0040 20285562 756e7475 2f4c696e 61726f20   (Ubuntu/Linaro 
 0050 342e342e 342d3134 7562756e 74753129  4.4.4-14ubuntu1)
 0060 20342e34 2e352032 30313030 39303920   4.4.5 20100909 
 0070 28707265 72656c65 61736529 00        (prerelease).   
. . . .

And it is built agains the Kernel Headers version 2.6.16 not against the 2.6.31-rt kernel version that is running the KT.
(This is not an 'error' - __Linux__ maintains backwards compatibility - regardless of what lab126 likes to do to the e-ink drivers).

[NiLuJe]

@knc1: https://www.mobileread.com/forums/sho...7&postcount=22

Linux 2.6.16 is the minimum kernel version that the glibc was built to support. (Even when dynamically linked, trying to run a binary targeting a newer kernel than your host will not work, the loader will shout at you and abort ). (It's set via glibc's --want-kernel configure arg [it does require that the kernel headers you build against be at *least* equal to that, but you can safely build against more recent headers]).

(I usually use readelf over objdump, readelf -n usually does the trick to check the ABI, and readelf -p.comment to check the GCC tag if it exists)

NPTL apparently requires 2.6.9, so that's probably what's used on most current distros (it's gentoo's default). I tweak it on my boxes, that's why the kindletool builds require Kernel 2.6.38/2.6.39.

It's also configurable when building a toolchain via crosstool-ng, and I usually set it to the oldest Kernel used on the Kindle series the toolchain targets (2.6.22 in the case of the K2/K3 cpu).

[knc1]

Originally Posted by NiLuJe

It's set via glibc's --want-kernel configure arg [it does require that the kernel headers you build against be at *least* equal to that, but you can safely build against more recent headers]

Just as long as you don't expect to access kernel services newer than those that are defined in your glibc build.

And 2.6.16 did not do dynamic device creation, one of the things we could see in the strace that the application was expecting.

A path to getting this working might be to use the sources from the Amazon source archive (old versions) rather than the "newest and best" versions.

I suppose that you have noticed that JP's terminal emulator (and other projects here) are still being built using pthreads.
NPTL came to ARM EABI very late in the game.

[NiLuJe]

@knc1: Well, of course I'm assuming you're running a kernel >= your kernel headers .

I was speaking mostly from an x86/x86_64 POV, so I may be missing some stuff on the embedded/ARM front. (And I do use NPTL threading in my ARM TC, linux threads haven't been supported in the main glibc release tarballs since quite a while, if I remember correctly).

And pthreads doesn't necessarily means !NPTL, it supports both LT & NPTL, but it's been a while since I've seen a system with both threading implementation installed...

[knc1]

Originally Posted by NiLuJe

@knc1: Well, of course I'm assuming you're running a kernel >= your kernel headers .

Have been thinking a bit more about what I wrote . . . .
That was probably a poor example to have used as an example.

But the principle remains, if your c library has no connection to a feature, your code can't use it because of the missing code path in the library.

And for the case of the KT-v5.1.0 the kernel is newer (I.E: supporting of) the older header defined functions.
I don't expect any problems on this front.

Unless we build something against 3.0 headers and expect it to work on 2.6.31

[elRicharD]

Today I spent a little more of my time trying to compile mpg 123.

First I uncompressed the alsa package the kindle uses and compiled that version of alsa with this command:

./configure CC=/home/richard/Desktop/arm-2011.09/bin/arm-none-linux-gnueabi-gcc --host=x86_64 --target=arm-linux && make

Then I copied the src/.libs files I found into the /lib/gcc/arm-none-linux-gnueabi/.libs folder.

Then I compiled mpg123:

./configure CC=/home/richard/Desktop/arm-2011.09/bin/arm-none-linux-gnueabi-gcc --host=x86_64 --target=arm-linux --with-default-audio=alsa --with-cpu=generic_nofpu --enable-modules=no && make

I copied it to the Kindle and voilá! It worked without doing anything!

This was probably the alsa lib I was using to compile mpg123... But the good thing is that it works. The bad thing is that it stops playing after a while when I suspend the Kindle. I think I saw an app or something that prevented that from happening somewhere.

I am uploading the mpg123 executable, I deployed it in /mnt/us aka the root folder of the kindle and ran it.

Thanks to everyone for their help and support!

[knc1]

Please post the full output of:

/home/richard/Desktop/arm-2011.09/bin/arm-none-linux-gnueabi-gcc --version

[elRicharD]

Originally Posted by knc1

Please post the full output of:

/home/richard/Desktop/arm-2011.09/bin/arm-none-linux-gnueabi-gcc --version

richard@EliteBook-8530p:~/Desktop/arm-2011.09/bin$ ./arm-none-linux-gnueabi-gcc --version
arm-none-linux-gnueabi-gcc (Sourcery CodeBench Lite 2011.09-70) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[elRicharD]

The ubuntu one returns


richard@EliteBook-8530p:~$ arm-linux-gnueabi-gcc-4.6 --version
arm-linux-gnueabi-gcc-4.6 (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[knc1]

Both of those are new enough that you should be able to use:
-mfloat-abi=softfp -mfpu=vfp
And still run on either the ARMv6l (VFPv2) or the ARMv7l (VFPv3) even with the rest of the Kindle libraries built as 'softfloat'.

If you have a chance, give that a try on your compile command line and see if the resultant binary will still run on your Kindle.
It should make a difference to mpeg123 when you use the floating point hardware.

Edit: Still haven't found a reference to that: 'l' (ell) but the only thing I have found so far is that it probably indicate VFPlite (the 'slow' VFP hardware - which trades silicon area for clock cycles).

And I am not sure if even gcc-4.6 has instruction scheduling for the VFPlite (slow FPU) hardware. Need to RTFM but I don't expect to find it before gcc-4.7

[elRicharD]

Originally Posted by knc1

Both of those are new enough that you should be able to use:
-mfloat-abi=softfp -mfpu=vfp
And still run on either the ARMv6l (VFPv2) or the ARMv7l (VFPv3) even with the rest of the Kindle libraries built as 'softfloat'.

If you have a chance, give that a try on your compile command line and see if the resultant binary will still run on your Kindle.
It should make a difference to mpeg123 when you use the floating point hardware.

I will. Does that add any compatibility/performance improvement? Should I add those directives to the ./configure on mpg123?

Thanks!