[maemo-developers] Maemo 2.0 C binaries do not run on N770
Hi, I'm new to the whole Maemo/Scratchbox/N770 thing. I have set up the Maemo 2.0 following this tutorial: http://www.maemo.org/platform/docs/tutorials/Maemo_tutorial.html. My goal is to write a bluetooth application in C inside Maemo/Scratchbox and send the binaries over to the N770. So I followed exactly what's on the tutorial. After the installation, I wrote a little helloworld.c with a printf statement. The binary runs in the emulation fine. But when I scp and run the binary in my N770, it doesn't. This is the error it generated. -sh: ./hello: not found So I checked the binary version by: #file hello and this is the output. hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.4.17, dynamically linked (uses shared libs), not stripped I also have a standard ARM tool chain outside of the scratchbox. I compiled the same helloworld using that tool chain and ran the binary on the N770. The binary ran. So I'm convinced my N770 is working. When I do this: #file hello2 hello2: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped I am suspecting that my N770 may be running the old 2005 OS and the Maemo is based on the new 2006 OS. Did anyone have the same problem? Thanks a million for your help! ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] defective memory? (was: problem with dspmp3sink)
Siarhei Siamashka a écrit : On Sunday 10 September 2006 11:36, Olivier ROLAND wrote: Your test work fine on my device. I see that you run it from /media/mmc1so I guess you format your memory card with ext2. Mine still vfat so I can't. If you got same error when running from internal memory then your device is broken. Thanks a lot for finding time and running the test. Today in the morning I could not reproduce this bug. The device battery just was recharged during night. As nothing else was changed (I checked uptime to be sure that it did not reboot or something), I see three possible explanations (may be wrong, I'm not hardware expert): * page with the faulty memory bit was allocated to some other process * cpu or memory chip was just overheated because of heavy use and the bug disappeared as the temperature got back to normal * maybe the bug is somewhat related to low battery charge level, maybe the battery was unable to provide enough voltage or something for reliable operation I did some search and found this utility for testing memory on non-x86 hardware: http://pyropus.ca/software/memtester/ For those who are lazy to compile it, the binary is here: http://ufo2000.xcomufo.com/files/memtester.gz After playing with the device for some time, I got the same problem with lzma program this evening. And memtester also confirms that the memory is really defective :( # ./memtester 20 memtester version 4.0.5 (32-bit) Copyright (C) 2005 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xf000 want 20MB (20971520 bytes) got 20MB (20971520 bytes), trying mlock ...locked. Loop 1: Stuck Address : testing 0FAILURE: possible bad address line at offset 0x0037e9a5. Skipping to next test... Random Value: FAILURE: 0xdeb98374 != 0xdeb9 at offset 0x000fe9a4. FAILURE: 0xd04629fc != 0xd046aa88 at offset 0x000fe9a4. Compare XOR : FAILURE: 0x50467c54 != 0x5046 at offset 0x000fe9a4. Compare SUB : FAILURE: 0xb069e1c0 != 0xdc20 at offset 0x000fe9a4. ... By the way, I have seen some reports about random device reboots, maybe these people also suffer from defective memory problem. So maybe it is a good idea for everyone to test their memory. Though use it at your own risk, I can't be sure that this test program is working correctly and always provides valid results (I only found it today). Well, as now the problem is identified, it is time to think how to solve it. The first task is making a proper memory testing utility. As memtester needs to allocate memory for testing and lots of memory is already taken by IT OS software and libraries, we can only test a small part of memory (only ~1/3 in the test above). Maybe it is possible to patch kernel (or it already provides such functionality) to allocate any physical memory page for us (relocating its data to some other place if it is already occupied by some other process). If it is possible, we would be able to check all the physical memory except for probably the part occupied by the kernel itself. The next task would be to make some way to use BadRAM kernel patch on Nokia 770: http://rick.vanrein.org/linux/badram/ Preferably physical addresses of the defective parts of memory should be stored somewhere so that they survive reflashing (r&d mode and other flags are stored in such a way, right?). If BadRAM patch becomes a part of standard Nokia 770 kernel, it can help to make use of the memory chips that otherwise would have to be replaced. I wonder how much does Nokia 770 memory chip cost? By the way, maybe Nokia already has some utility for hardware diagnistics and it could become available for download? There would be no need to reinvent the wheel in this case. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers Hum ... very interesting memtester give non reproductible result on my device. and now lzma test failed also ... Battery is low. We definitively need to investigate this a little more. The good news is that your device is probably not broken. (or mine is also ;-) ) All this should definitively interest Nokia people ... ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: gtkmm and scratchbox: Gtk::DrawingArea problem
Really, it would be far more sensible to rewrite the code for the slightly different API that is available in the maemo version of gtkmm, as I described. The maemo version of gtkmm offers considerable code size and runtime memory savings, at the cost of this small inconvenience. [snip] Alrighty, are the depedencies fixed now in repository? and another thing, where's this API documented? I'm sorry, I have worked with Maemo and Gtkmm only for a short period so I wasn't aware of these differencies. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] defective memory? (was: problem with dspmp3sink)
On Sunday 10 September 2006 11:36, Olivier ROLAND wrote: > Your test work fine on my device. > I see that you run it from /media/mmc1so I guess you format your memory > card with ext2. > Mine still vfat so I can't. If you got same error when running from > internal memory then your device is broken. Thanks a lot for finding time and running the test. Today in the morning I could not reproduce this bug. The device battery just was recharged during night. As nothing else was changed (I checked uptime to be sure that it did not reboot or something), I see three possible explanations (may be wrong, I'm not hardware expert): * page with the faulty memory bit was allocated to some other process * cpu or memory chip was just overheated because of heavy use and the bug disappeared as the temperature got back to normal * maybe the bug is somewhat related to low battery charge level, maybe the battery was unable to provide enough voltage or something for reliable operation I did some search and found this utility for testing memory on non-x86 hardware: http://pyropus.ca/software/memtester/ For those who are lazy to compile it, the binary is here: http://ufo2000.xcomufo.com/files/memtester.gz After playing with the device for some time, I got the same problem with lzma program this evening. And memtester also confirms that the memory is really defective :( # ./memtester 20 memtester version 4.0.5 (32-bit) Copyright (C) 2005 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xf000 want 20MB (20971520 bytes) got 20MB (20971520 bytes), trying mlock ...locked. Loop 1: Stuck Address : testing 0FAILURE: possible bad address line at offset 0x0037e9a5. Skipping to next test... Random Value: FAILURE: 0xdeb98374 != 0xdeb9 at offset 0x000fe9a4. FAILURE: 0xd04629fc != 0xd046aa88 at offset 0x000fe9a4. Compare XOR : FAILURE: 0x50467c54 != 0x5046 at offset 0x000fe9a4. Compare SUB : FAILURE: 0xb069e1c0 != 0xdc20 at offset 0x000fe9a4. ... By the way, I have seen some reports about random device reboots, maybe these people also suffer from defective memory problem. So maybe it is a good idea for everyone to test their memory. Though use it at your own risk, I can't be sure that this test program is working correctly and always provides valid results (I only found it today). Well, as now the problem is identified, it is time to think how to solve it. The first task is making a proper memory testing utility. As memtester needs to allocate memory for testing and lots of memory is already taken by IT OS software and libraries, we can only test a small part of memory (only ~1/3 in the test above). Maybe it is possible to patch kernel (or it already provides such functionality) to allocate any physical memory page for us (relocating its data to some other place if it is already occupied by some other process). If it is possible, we would be able to check all the physical memory except for probably the part occupied by the kernel itself. The next task would be to make some way to use BadRAM kernel patch on Nokia 770: http://rick.vanrein.org/linux/badram/ Preferably physical addresses of the defective parts of memory should be stored somewhere so that they survive reflashing (r&d mode and other flags are stored in such a way, right?). If BadRAM patch becomes a part of standard Nokia 770 kernel, it can help to make use of the memory chips that otherwise would have to be replaced. I wonder how much does Nokia 770 memory chip cost? By the way, maybe Nokia already has some utility for hardware diagnistics and it could become available for download? There would be no need to reinvent the wheel in this case. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: gtkmm and scratchbox: Gtk::DrawingArea problem
On Sat, 2006-09-09 at 22:29 +0300, Jarkko Palviainen wrote: > On Sat, 09 Sep 2006 22:10:58 +0300, Murray Cumming <[EMAIL PROTECTED]> > wrote: > > > On Sat, 2006-09-02 at 13:14 +0300, Jarkko Palviainen wrote: > >> Hi, > >> I'm trying to build simple drawing app for Nokia 770 IT2006 but here's > >> the > >> problem: > >> When compiling and running some example, like this > >> http://www.gtkmm.org/gtkmm2/docs/tutorial/html/ch14s03.html#id2524813 > >> it goes well but just doesn't draw anything on Xephyr emulator, just > >> blank > >> window. Compiling and running in normal Debian Sarge is fine, I can see > >> those lines drawn. The problem seems to be related to on_expose_event() > >> which is not called as I tested by debug printing in it. I can't use > >> cairo > >> as I have to use glimm 2.8.9. > > > > Yes, the version of gtkmm that is in the maemo repository uses some > > special optimizations. The most obvious change is that there are no > > default signal handlers, so you must connect a signal handler instead of > > just overriding the default one. > > > > Yep it seems to be something like that. I solved the problem using > different libraries pointed out in > http://home.comcast.net/~3rdshift/articles/Nokia770/Maemo.html (direct > link: > http://home.comcast.net/~3rdshift/articles/Nokia770/Nokia770-IT2006/deb/deb-index.html). > > Now they work the usual way. Really, it would be far more sensible to rewrite the code for the slightly different API that is available in the maemo version of gtkmm, as I described. The maemo version of gtkmm offers considerable code size and runtime memory savings, at the cost of this small inconvenience. [snip] -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problems installing Sardine SDK
- Kalle Vahlman <[EMAIL PROTECTED]> wrote: > 2006/9/9, Adi Roiban <[EMAIL PROTECTED]>: > > - Marius Vollmer <[EMAIL PROTECTED]> wrote: > > > True, I can reproduce this here. You can try to start the > control > > > panel from the shell like so: > > > > > > $ /usr/bin/controlpanel > > > > > > This will hang indefinitely. > > > > > > I don't know why yet. Please stay tuned... (but it can be a week > or > > > so.) > > OK. I will wait. > > I just wanted to know that i am not the only one with these > problems. > > While waiting, you might try to delete the file called "1.0" with the > contents of "EOF" in /tmp/osso-appl-states/controlpanel/ Done. Now controlpanel is working.I had a "0.1" file there. Thank you for your help. > That did the trick for me in a similar situation. And no, I don't > have > a clue what is going on there :) > > -- > Kalle Vahlman, [EMAIL PROTECTED] > Powered by http://movial.fi > Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] defective memory? (was: problem with dspmp3sink)
Your test work fine on my device. I see that you run it from /media/mmc1so I guess you format your memory card with ext2. Mine still vfat so I can't. If you got same error when running from internal memory then your device is broken. Siarhei Siamashka a écrit : Hello All, I'm sorry for a long chunk of quoted text at the end of this message (it describes the sympthoms of the problem), but looks like I got an almost reliable proof that there is something wrong with the hardware of my device :( I tried to find some software that could be used for benchmarking and LZMA SDK (http://www.7-zip.org/sdk.html) looked like an interesting option for doing it. But when run on Nokia 770, it sometimes works normally and sometimes fails with the following error message: /media/mmc1 $ time ./lzma b -d19 LZMA 4.43 Copyright (c) 1999-2006 Igor Pavlov 2006-06-04 CompressingDecompressing Error: CRC Error Command exited with non-zero status 1 real1m 37.14s user1m 36.10s sys 0m 0.74s As you see, it failed internal test and was unable to decompress data back correctly. LZMA is an advanced compression algorithm and uses quite a lot of memory (it shows ~20MB memory usage in top with '-d19' option). If any of the bits within this memory block has problems, it can affect data integrity and cause incorrect compression or decompression. So probably lzma can be also used as some kind of memory checker. But it may be also some problem in LZMA code and not in my Nokia 770 hardware, so I would like to ask somebody to run the same test and check if the same problem can be reproduced. You can download the sources of LZMA SDK using this link: http://prdownloads.sourceforge.net/sevenzip/lzma443.tar.bz2?download Decompress this archive, change to 'C/7zip/Compress/LZMA_Alone' directory and run 'make -f makefile.gcc' to compile it. Alternatively you can use my compiled binary: http://ufo2000.xcomufo.com/files/lzma.gz Considering that this test program works fine in scratchbox with qemu, LZMA SDK page mentions performance on ARM and the existence of LZMA debian package for ARM, I think that software bug theory is not very relevant, but it still needs to be confirmed. I will wait for feedback in order to confirm if the problem really exists in my hardware. But looks like it is a high probability that I will have to make some kind of more advanced memory checker, try to identify faulty memory physical address and experiment with badram kernel patch. On Wednesday 23 August 2006 23:09, you wrote: Also I noticed that gstreamer is not very reliable, at least when using it from mplayer. It can freeze or reboot the device sometimes. That's not something that should be expected from high level API. If I detect some reliable pattern in reproducing these bugs, I'll report it to bugzilla for sure. But right now just using mplayer and lots of seeking in video can cause these bugs reasonably fast. ... Earlier I noticed problems with sound output getting blocked that could be fixed by bult-in audio or video player. When trying to play anything it first shows error message. After the second attempt either the sound got fixed or the device rebooted. I suspected that something could get wrong with dsp and standard audio player is able to reset it. That was observed when using fdsrc element for feeding data to the decoder in mplayer. On stopping/resuming playback, probably partial audio frames could be feeded to mp3 decoder and that might result in its misbehaviour. ... Now only complete mp3 audio frames can be sent to dspmp3sink. Anyway, first everything was ok and I even suspected that I will not encounter any problems at all. But after a few hours I got several reboots. After the last reboot even wifi started working strange (could not connect using ssh, it just showed various errors). Turning the device off, waiting for a few minutes and turning it on again got everything back to normal. Now I suspect that it could probably be overheating or some other hardware problem (the device worked with wifi on and heavy cpu usage because of decoding video for a long time). I'll keep an eye on it and will report again if the problems keep showing up and if their source becomes more clear. ... I tried swap a long time ago on IT2005, that was done in order to make gcc work on Nokia 770 to try compiling something before I installed scratchbox :) Anyway, I did not like the stability as gcc started to fail with internal compiler errors. So I decided not to use swap as long as it is enough memory for what I need. Also there was some swap related report about the problem with mplayer: http://www.internettablettalk.com/forums/showpost.php?p=20068&postcount=96 But maybe I should give swap another try on IT2006 and see if it helps to improve stability. By the way, I already asked this question in the mail
Re: [maemo-developers] Problems installing Sardine SDK
2006/9/9, Adi Roiban <[EMAIL PROTECTED]>: - Marius Vollmer <[EMAIL PROTECTED]> wrote: > True, I can reproduce this here. You can try to start the control > panel from the shell like so: > > $ /usr/bin/controlpanel > > This will hang indefinitely. > > I don't know why yet. Please stay tuned... (but it can be a week or > so.) OK. I will wait. I just wanted to know that i am not the only one with these problems. While waiting, you might try to delete the file called "1.0" with the contents of "EOF" in /tmp/osso-appl-states/controlpanel/ That did the trick for me in a similar situation. And no, I don't have a clue what is going on there :) -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
