Re: Easy Debian Fremantle Beta Testing
 

Estel: Did you upload your configuration files for your image to anywhere else?

Re: Easy Debian Fremantle Beta Testing
 

Sorry for bothering, but, I'm with a problem:

What am I doing wrong? The img file works just ok...

Re: Easy Debian Fremantle Beta Testing
 

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.

Re: Easy Debian Fremantle Beta Testing
 

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

Re: Easy Debian Fremantle Beta Testing
 

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?

Re: Easy Debian Fremantle Beta Testing
 

@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.

Re: Easy Debian Fremantle Beta Testing
 

Frankly I'm no expert either.

Are you sure about that?
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.

Re: Help me please
 

LXDE with the one title "Lament ..."
Does anybody know which that song is ?...
Please Help me...
I really need that Song..:(

Re: Easy Debian Fremantle Beta Testing
 

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:

Re: Easy Debian Fremantle Beta Testing
 

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