MPlayer for Kindle 4 Touch

[knc1]

Originally Posted by elRicharD

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

Thanks!

The ones I wrote should work on both ARMv6 and ARMv7 (Kindle Touch).
Usually, hardware floating point is faster than doing it in software.

- - - -

No, not added to the ./configure step

Sorry, didn't notice that you where using an autotools package.

After the configure step, when you do the "make" you should be able to pass the extra compiler flags at the same time.
OR
Set them in the Makefile after it has been generated by ./configure.

On the command line (may not be honored by the Makefile):

If it is a C program:
CFLAGS='the extra options' make

If it is a C++ program:
CCFLAGS='the extra options' make

OR
Just set the extra options in the Makefile wherever CFLAGS and CCFLAGS is first defined.

Note: These are just general directions. A person would have to have the actual text of the Makefile in front of them to give specifics.

- - - -

If all of the above is a mystery - don't worry about it - someone else will check it out when they have time.

[NiLuJe]

@knc1: I think the 'l' refers to the endianness, LE, in our case, although it's a weird syntax, and I may be wrong, since the 'j' in armv6j was for the jazelle thingy... Where did you see that syntax?

[geekmaster]

The thread title is self-contradictory. There is not any Kindle 4 with a touchscreen, and there is not any Kindle 5 without a touchscreen, AFAIK.

The thread owner should request that it be renamed by a site moderator (click the button to the right of the KARMA button on the first post)...

[elRicharD]

knc1, the executable works as a charm with the additional compiler flags.

[knc1]

Originally Posted by NiLuJe

@knc1: I think the 'l' refers to the endianness, LE, in our case, although it's a weird syntax, and I may be wrong, since the 'j' in armv6j was for the jazelle thingy... Where did you see that syntax?

cat /proc/cpuinfo

When I get a chance, I'll browse the kernel sources and see what the comments have to say about what they think they are describing.

[knc1]

Originally Posted by elRicharD

knc1, the executable works as a charm with the additional compiler flags.

That's good.
It should have failed horribly if the hardware floating point and the fpu options did not match.

What are you running it on?

The Kindle Touch? (K5)
That one has even more hardware help that you could option in (but then it wouldn't run on the earlier Kindles - would have to build two flavors).

The Kindle Non-Touch? (K4)
Not sure of that one. @GM: is that one a i.MX3* or a i.MX5* SoC?

The Kindle Keyboard (K3)?

The options I gave should let your build run on all, all with at least some hardware help.

Edit: We should probably re-build Lua for the Kindles. Internally, the only number type it has is Double. Hardware floating point ("Double") makes a big difference to Lua.

[knc1]

Originally Posted by NiLuJe

@knc1: I think the 'l' refers to the endianness, LE, in our case, although it's a weird syntax, and I may be wrong, since the 'j' in armv6j was for the jazelle thingy... Where did you see that syntax?

The ARMv6l in the K3 does have Jazelle (java vm in hardware).
Both have Thumb, the KT (ARMv7l) has VFPv3, Thumb-2 and NEON, but no java vm.

You may have noticed that the kernel for the KT has video drivers and V4L modules. Seems like lab126 is thinking of giving us video. Too bad members here beat them to it, without the hardware help of the more powerful core.

I am working on a "cheat sheet" of gcc-options vs Kindle model -
But the ARM naming scheme - - - well, I am not sure even the ARM engineers understand it.

[geekmaster]

Originally Posted by knc1

The Kindle Non-Touch? (K4)
Not sure of that one. @GM: is that one a i.MX3* or a i.MX5* SoC?

K3 is i.Mx35. K4 and K5 are both i.Mx508.

The K4 mostly emulates the K3 when booted from main, but when booted from diags it is more like the K5 (different kernels and different drivers). But the K4 uses the same SoC as the K5.

[elRicharD]

knc1, Kindle Touch, latest firmware.

[knc1]

Originally Posted by geekmaster

K3 is i.Mx35. K4 and K5 are both i.Mx508.

The K4 mostly emulates the K3 when booted from main, but when booted from diags it is more like the K5 (different kernels and different drivers). But the K4 uses the same SoC as the K5.

That was the knowledge I was missing, when it comes to code generation options of gcc - K4 and K5 have the same (options and processor core).

if elRicharD wanted to maintain two flavors of mpeg123 (K4 & K5; Others)...
Then the K4&K5 build could use the gcc options to use VFPv3+Neon (which I would need to look up for gcc-4.6).
That would get his media stream mostly crunched in hardware.
Should make Lua move right along also (for our Kpdf application).

Since I am asking, and you have one of everything ever built....

When you get a chance, would you do a:
cat /proc/cpuinfo
on a K2 and a DX(G) please?

[knc1]

Originally Posted by knc1

That was the knowledge I was missing, when it comes to code generation options of gcc - K4 and K5 have the same (options and processor core).

if elRicharD wanted to maintain two flavors of mpeg123 (K4 & K5; Others)...
Then the K4&K5 build could use the gcc options to use VFPv3+Neon (which I would need to look up for gcc-4.6).
That would get his media stream mostly crunched in hardware.
Should make Lua move right along also (for our Kpdf application).

Since I am asking, and you have one of everything ever built....

When you get a chance, would you do a:
cat /proc/cpuinfo
on a K2 and a DX(G) please?

Edit: They are both i.MX3* SoC but I would still like to see the cpuinfo from the kernel.

[geekmaster]

Originally Posted by knc1

That was the knowledge I was missing, when it comes to code generation options of gcc - K4 and K5 have the same (options and processor core).

if elRicharD wanted to maintain two flavors of mpeg123 (K4 & K5; Others)...
Then the K4&K5 build could use the gcc options to use VFPv3+Neon (which I would need to look up for gcc-4.6).
That would get his media stream mostly crunched in hardware.
Should make Lua move right along also (for our Kpdf application).

Since I am asking, and you have one of everything ever built....

When you get a chance, would you do a:
cat /proc/cpuinfo
on a K2 and a DX(G) please?

I have a DX and DXG, but no K2 (or K1)... I will do the DX later when I plug it in. I have work now...

[NiLuJe]

The K2 and the DX use the same CPU as the K3 (arm1136jf-s / vfp), with a slightly older Kernel (~2.6.22) (and half the RAM, if I remember correctly?).

EDIT: AFAIR, the cpuinfo is indentical (DX/DXG/K2/K3), but I may be wrong .

Keep in mind that I had some weird surprises when building lua/kpdf with a hardfloat TC (namely, a completely messed up lua interpreter). I never investigated much further than that, so it may be a stupid mistake on my part .

EDIT: On the other hand, it works flawlessly with my latest softfp TC, so, there's that .

(Check the kindle-x-compile-tc.tar.gz tarball for more details on my K2/K3 TC).

[baf]

Originally Posted by knc1

Then the K4&K5 build could use the gcc options to use VFPv3+Neon (which I would need to look up for gcc-4.6).

Building crosstool chain I set "-mfpu=neon -mfloat-abi=softfp" options for gcc-linaro-4.7 compiler.

Cross-compiled binaries have VFPv3+Neon support.

[kindle]# readelf -A hello 
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_VFP_arch: VFPv3
  Tag_NEON_arch: NEONv1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align8_needed: Yes
  Tag_ABI_align8_preserved: Yes, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_unknown_34: 1 (0x1)

EDIT: full set of used CFLAGS is "-mlittle-endian -march=armv7-a -mcpu=cortex-a8 -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp"
This is for K5. I don't know about the others. I use crosstool-ng/scratchbox chain.

[knc1]

Originally Posted by baf

Building crosstool chain I set "-mfpu=neon -mfloat-abi=softfp" options for gcc-linaro-4.7 compiler.

Cross-compiled binaries have VFPv3+Neon support.

[kindle]# readelf -A hello 
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_VFP_arch: VFPv3
  Tag_NEON_arch: NEONv1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align8_needed: Yes
  Tag_ABI_align8_preserved: Yes, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_unknown_34: 1 (0x1)

Try a Hello World with some 'Double' math.
If it doesn't fault on 'illegal instruction' (or some such obvious thing) - call it done.
If those options test out, I will make them the defaults for K4&K5 in DIY-KeK

That should do it for the K4 & K5 at least.

Just don't forget to over-ride those defaults built into the compiler when building for the K1, K2, K3 and DX