Active Topics
-
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 2 days, 22 hrs ago -
TLS 1.2 for N9 is ready (28)
to MeeGo / Harmattan by smartblu9 - 2 days, 23 hrs ago -
Maemo repository (3)
to Community by torsen - 3 days, 15 hrs ago -
Error after installing Leste on sdcard (11)
to Maemo 7 / Leste by Maemish - 4 days, 12 hrs ago -
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 5 days, 19 hrs ago - more...
 |
|
2012-02-25
, 01:20
|
|
Posts: 323 |
Thanked: 189 times |
Joined on Oct 2010
@ Brazil
|
#2622
|
Originally Posted by Estel
Sorry for bothering, but, I'm with a problem:
1. Mount (empty) dedicated partition that You've just created
2. Mount Your ED image (mount -o loop /path/to/ed-squeeze-final.ext3 /path/to/mountpoint)
3. cp -a /path/to/image/file/mountpoint/* /path/to/partition/mountpoint/
4. Edit /home/user/.chroot, to make it point into Your partition, instead of image file (for example, /dev/mmcblk0p4, if Your dedicated ED partition is 4th on eMMC).
Code:
~$ debian-lxde Starting Debian echo "chroot is now open!" Chroot dir specified: /.debian /dev/mmcblk0p5 specified in ~/.chroot Mounting... using device: /dev/mmcblk0p5 Using ext3 file system mounting device: /dev/mmcblk0p5 . .. ... .... Updating the /etc/mtab file... Everything set up, running chroot... chroot is now open! Starting Debian /usr/bin/Xephyr :1 -screen 800x480 -br -ac Chroot dir specified: /.debian /dev/mmcblk0p5 specified in ~/.chroot /.debian has a qmount already! /dev/mmcblk0p5 already mounted on /.debian... Everything set up, running chroot... /usr/bin/Xephyr: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory
__________________
Love and Goodness are not a property. Are not a franchising. They are present in each one of us, and must be cultivated with KNOWLEDGE.
Love and Goodness are not a property. Are not a franchising. They are present in each one of us, and must be cultivated with KNOWLEDGE.
Last edited by Temporal; 2012-02-25 at 04:30.
|
|
2012-02-26
, 20:36
|
|
Posts: 323 |
Thanked: 189 times |
Joined on Oct 2010
@ Brazil
|
#2623
|
Ok, I believe I have a bug report:
1)Every time I reboot, the only way to be able to mount by "loop" is first running sudo debian. I don't know why;
2)The only way to run debian-lxde is by first mounting the partition (in my case, mmcblk0p5) to /.debian;
Now I just need to mount using event.d files to be able to run lxde (so I don't need to manually mount every time I run lxde), so, at least for now this works for me.
1)Every time I reboot, the only way to be able to mount by "loop" is first running sudo debian. I don't know why;
2)The only way to run debian-lxde is by first mounting the partition (in my case, mmcblk0p5) to /.debian;
Now I just need to mount using event.d files to be able to run lxde (so I don't need to manually mount every time I run lxde), so, at least for now this works for me.
__________________
Love and Goodness are not a property. Are not a franchising. They are present in each one of us, and must be cultivated with KNOWLEDGE.
Love and Goodness are not a property. Are not a franchising. They are present in each one of us, and must be cultivated with KNOWLEDGE.
 |
|
2012-02-28
, 20:53
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#2624
|
Sorry for late reply, I've just gone through through 2,5 weeks of posting. I'll filter out and publish /home/user config files ASAP, then, I'll create new image containing required config files and replace old one with it.
/Estel
/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
|
|
2012-03-04
, 14:16
|
|
Posts: 915 |
Thanked: 3,209 times |
Joined on Jan 2011
@ Germany
|
#2625
|
I just tested a Debian Wheezy chroot in armhf. In principle it works but there are some odd things that I don't understand.
To check whether there is any performance gain I ran nbench. For reference I first did this in in an armel chroot. The result is as follows:
Then I did the same in the armhf chroot:
The first thing you'll notice is the "illegal instruction" error. I repeated the test maybe a dozen times and the error did not always occur at the same point. Mostly it happened after the STRING SORT (never before) or BITFIELD test but there was no pattern that seemed to make sense. The above run that even completed the ASSIGNMENT test was the very first try. Each of the following runs failed one test earlier until the 5th one failed after the STRING SORT test. After that the pattern was completely random. Because there is no pattern I believe the reason is not Maemo or the N900 being armhf incompatible but some strange effect of other Maemo kernel settings or programs similar to the watchdog.
Does this make sense to anybody? I'm running KP49 without DSP profile and without CSSU btw.
The second thing you'll notice is that the result of the armhf FOURIER test is more than 4 times as high as the one of the armel test which in theory should come in handy in multimedia related tasks. On the other hand the FP EMULATION test dropped by 45%. Does anybody have an idea why the FP EMULATION result changed or does someone know the practical implications of that change?
To get more practical results I made a video decoding benchmark with mplayer and youtube's 240p version of the big buck bunny video:
armel:
armhf:
As you can se there is virtually no difference, which I don't understand either. Obviously it works in armhf at all, so the nbench "illegal instruction" error doesn't affect mplayer. On the other hand I'd expect either a noticeable increase due to the better FOURIER test results or a decrease due to the worse FP EMULATION results, depending on how mplayer decodes the video. But the result suggests that there aren't any FP operations involved at all. Is that normal for this codec?
To check whether there is any performance gain I ran nbench. For reference I first did this in in an armel chroot. The result is as follows:
Code:
\h:\w$ ./nbench
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 311.04 : 7.98 : 2.62
STRING SORT : 48.123 : 21.50 : 3.33
BITFIELD : 1.4078e+08 : 24.15 : 5.04
FP EMULATION : 94.282 : 45.24 : 10.44
FOURIER : 355.5 : 0.40 : 0.23
ASSIGNMENT : 5.8009 : 22.07 : 5.73
IDEA : 771.67 : 11.80 : 3.50
HUFFMAN : 517.72 : 14.36 : 4.58
NEURAL NET : 0.52156 : 0.84 : 0.35
LU DECOMPOSITION : 16.355 : 0.85 : 0.61
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 18.351
FLOATING-POINT INDEX: 0.660
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU :
L2 Cache :
OS : Linux 2.6.28.10-power49
C compiler : gcc version 4.4.5 (Debian 4.4.5-8)
libc : libc-2.11.3.so$W5 (Debian 4.4.5-8)
MEMORY INDEX : 4.581
INTEGER INDEX : 4.578
FLOATING-POINT INDEX: 0.366
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder
Code:
\h:\w$ ./nbench
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 365.68 : 9.38 : 3.08
STRING SORT : 47.982 : 21.44 : 3.32
BITFIELD : 1.6907e+08 : 29.00 : 6.06
FP EMULATION : 51.779 : 24.85 : 5.73
FOURIER : 1512.4 : 1.72 : 0.97
ASSIGNMENT : 6.0761 : 23.12 : 6.00
Illegal instruction
Does this make sense to anybody? I'm running KP49 without DSP profile and without CSSU btw.
The second thing you'll notice is that the result of the armhf FOURIER test is more than 4 times as high as the one of the armel test which in theory should come in handy in multimedia related tasks. On the other hand the FP EMULATION test dropped by 45%. Does anybody have an idea why the FP EMULATION result changed or does someone know the practical implications of that change?
To get more practical results I made a video decoding benchmark with mplayer and youtube's 240p version of the big buck bunny video:
armel:
Code:
\h:\w$ mplayer -benchmark -nosound -vo null /root/bbb.flv MPlayer 1.0rc3-4.4.4 (C) 2000-2009 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing /root/bbb.flv. libavformat file format detected. [lavf] Video stream found, -vid 0 [lavf] Audio stream found, -aid 1 VIDEO: [FLV1] 400x226 0bpp 24.000 fps 256.8 kbps (31.3 kbyte/s) ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffflv] vfm: ffmpeg (FFmpeg Flash video) ========================================================================== Audio: no sound Starting playback... VDec: vo config request - 400 x 226 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is undefined - no prescaling applied. VO: [null] 400x226 => 400x226 Planar YV12 V: 596.4 0/ 0 5% 0% 0.0% 0 0 BENCHMARKs: VC: 31.237s VO: 0.117s A: 0.000s Sys: 16.393s = 47.748s BENCHMARK%: VC: 65.4215% VO: 0.2452% A: 0.0000% Sys: 34.3334% = 100.0000% Exiting... (End of file)
Code:
\h:\w$ mplayer -benchmark -nosound -vo null /root/bbb.flv MPlayer svn r34540 (Debian), built with gcc-4.6 (C) 2000-2012 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing /root/bbb.flv. libavformat version 53.20.0 (external) Mismatching header version 53.19.0 libavformat file format detected. [flv @ 0x40a06b10]Estimating duration from bitrate, this may be inaccurate [lavf] stream 0: video (flv), -vid 0 [lavf] stream 1: audio (mp3), -aid 0 VIDEO: [FLV1] 400x226 0bpp 24.000 fps 256.8 kbps (31.3 kbyte/s) Clip info: starttime: 0 totalduration: 596 totaldatarate: 317 bytelength: 23668451 canseekontime: true sourcedata: BADC20661MH1320360564963154 purl: pmsg: Load subtitles in /root/ ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family libavcodec version 53.34.0 (external) Mismatching header version 53.32.2 Selected video codec: [ffflv] vfm: ffmpeg (FFmpeg Flash video) ========================================================================== Audio: no sound Starting playback... Movie-Aspect is undefined - no prescaling applied. VO: [null] 400x226 => 400x226 Planar YV12 V: 596.4 0/ 0 5% 0% 0.0% 0 0 BENCHMARKs: VC: 32.116s VO: 0.116s A: 0.000s Sys: 15.791s = 48.023s BENCHMARK%: VC: 66.8774% VO: 0.2411% A: 0.0000% Sys: 32.8815% = 100.0000% Exiting... (End of file)
|
|
2012-03-05
, 09:22
|
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#2626
|
@sulu,
I'm no expert, but the only difference between armhf vs armel (or rather, hardfp vs softfp) is in the use of FP registers as a calling convention (as opposed to using the stack).
Both hardfp and softfp will use the floating point unit in exactly the same way.
So, if most of the work done by mplayer is done within a single function (perhaps with other functions inlined), you should see no difference.
I'm no expert, but the only difference between armhf vs armel (or rather, hardfp vs softfp) is in the use of FP registers as a calling convention (as opposed to using the stack).
Both hardfp and softfp will use the floating point unit in exactly the same way.
So, if most of the work done by mplayer is done within a single function (perhaps with other functions inlined), you should see no difference.
|
|
2012-03-05
, 09:45
|
|
Posts: 915 |
Thanked: 3,209 times |
Joined on Jan 2011
@ Germany
|
#2627
|
Frankly I'm no expert either.
If I read [1] correctly then there are ARM devices out there that have no FPU at all and armel works on them. So this either means that armel doesn't use the FPU at all (and instead emulates FP operations using integer functions) or can detect if there is a FPU and make use of it. As I understand it the latter would require quite some overhead during runtime which makes me believe the former is true.
Under this assumption my understanding was that armhf requires an FPU which will then run FP operations much faster than armel using its integer emulation. This might also explain armhf's poor FP EMULATION test result since it simply wouldn't need to be optimized for that.
Anybody, please correct me if I'm wrong!
[1] http://wiki.debian.org/ArmHardFloatPort#Rationale
btw: As you can see I ran the armel test under Squeeze and the armhf test under Wheezy. I will repeat the armel test under Wheezy to see if the "illegal instruction" error is architecture or release related.
Edit:
I'd welcome any suggestion for a real world FP benchmark! I guess some of the (de)compression algorithms of different archive types make heavy use if it. But I don't have the knowledge which one would be suitable.
Last edited by sulu; 2012-03-05 at 09:52.
Originally Posted by reinob
Are you sure about that?
the only difference between armhf vs armel (or rather, hardfp vs softfp) is in the use of FP registers as a calling convention (as opposed to using the stack).
If I read [1] correctly then there are ARM devices out there that have no FPU at all and armel works on them. So this either means that armel doesn't use the FPU at all (and instead emulates FP operations using integer functions) or can detect if there is a FPU and make use of it. As I understand it the latter would require quite some overhead during runtime which makes me believe the former is true.
Under this assumption my understanding was that armhf requires an FPU which will then run FP operations much faster than armel using its integer emulation. This might also explain armhf's poor FP EMULATION test result since it simply wouldn't need to be optimized for that.
Anybody, please correct me if I'm wrong!
[1] http://wiki.debian.org/ArmHardFloatPort#Rationale
btw: As you can see I ran the armel test under Squeeze and the armhf test under Wheezy. I will repeat the armel test under Wheezy to see if the "illegal instruction" error is architecture or release related.
Edit:
I'd welcome any suggestion for a real world FP benchmark! I guess some of the (de)compression algorithms of different archive types make heavy use if it. But I don't have the knowledge which one would be suitable.
Last edited by sulu; 2012-03-05 at 09:52.
|
|
2012-03-05
, 14:41
|
|
Posts: 1 |
Thanked: 0 times |
Joined on Mar 2012
|
#2628
|
Originally Posted by rebhana
I didn't have any need for sound in Easy Debian so far - Maemo satisfies all my needs there - but just out of curiosity: should the Music Player in LXDE with the one title "Lament ..." work out of the box? It doesn't for me. Also youtube videos don't play sound in iceweasel during the short intervals the videos are played at all. I'm just wondering whether I broke something by installing a lot of additional (and actually useful) stuff.
LXDE with the one title "Lament ..."
Does anybody know which that song is ?...
Please Help me...
I really need that Song..
|
|
2012-03-05
, 22:19
|
|
Posts: 915 |
Thanked: 3,209 times |
Joined on Jan 2011
@ Germany
|
#2629
|
I repeated nbench under Wheezy armel which worked fine.
Then I tried it under armhf again but changed the compiler to build nbench. First I tried with gcc-4.4 which resulted in a segmentation fault after the FP EMULATION test instead of gcc-4.6's Illegal instruction.
Then I tried nbench compiled with gcc-4.5 which even completed the IDEA test but then rebooted the phone. So it seems something is terribly unstable here. Either it's the compiler under armhf or some component in the underlying FP hardware/Maemo software.
Can somebody who has any other armhf-compatible device please try if nbench completes reliably if compiled with any of Debian Wheezy's armhf gccs?
Just for completeness, this is the gcc-4.5 result as far as it worked:
Then I tried it under armhf again but changed the compiler to build nbench. First I tried with gcc-4.4 which resulted in a segmentation fault after the FP EMULATION test instead of gcc-4.6's Illegal instruction.
Then I tried nbench compiled with gcc-4.5 which even completed the IDEA test but then rebooted the phone. So it seems something is terribly unstable here. Either it's the compiler under armhf or some component in the underlying FP hardware/Maemo software.
Can somebody who has any other armhf-compatible device please try if nbench completes reliably if compiled with any of Debian Wheezy's armhf gccs?
Just for completeness, this is the gcc-4.5 result as far as it worked:
Code:
\h:\w$ ./nbench
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 415.04 : 10.64 : 3.50
STRING SORT : 45.57 : 20.36 : 3.15
BITFIELD : 1.1854e+08 : 20.33 : 4.25
FP EMULATION : 51.798 : 24.86 : 5.74
FOURIER : 1461.6 : 1.66 : 0.93
ASSIGNMENT : 5.8777 : 22.37 : 5.80
IDEA : 1206.9 : 18.46 : 5.48
|
|
2012-03-06
, 15:52
|
|
Posts: 1,163 |
Thanked: 1,873 times |
Joined on Feb 2011
@ The Netherlands
|
#2630
|
Estel, did you already upload your new image with the files from /home/user/ ?
My ED image got corrupted so I am forced to download a new image
Then I started wondering if you had fixed your image
My ED image got corrupted so I am forced to download a new image
Then I started wondering if you had fixed your image
| The Following User Says Thank You to mr_pingu For This Useful Post: | ||
 |
| Tags |
| beta, debian, easy debian, extras-devel, fremantle, i <3 qole, squeeze |
«
Previous Thread
|
Next Thread
»
| Thread Tools | |
|
All times are GMT. The time now is 08:58.