[maemo-developers] Python extension of C++ in Maemo
Hi all, I'm wondering if any has a good pointer for how to write Python extension of C++ in Maemo. What I want to do is pretty similar to what's described in this discussion: http://www.velocityreviews.com/forums/t353864-calling-c-function-from-python-script.html. The problem for me is that it requires SWIG wrapper library, which I don't know how to make it work with Maemo. Is there another wrapper that works with Maemo? Thanks a million for all your helps! Winston ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Python extension of C++ in Maemo
On 18-sep-2006, at 8:38, Winston Wu wrote: Hi all, I'm wondering if any has a good pointer for how to write Python extension of C++ in Maemo. What I want to do is pretty similar to what's described in this discussion: http://www.velocityreviews.com/ forums/t353864-calling-c-function-from-python-script.html. The problem for me is that it requires SWIG wrapper library, which I don't know how to make it work with Maemo. Is there another wrapper that works with Maemo? I think you can pre-generate the wrappers on any platform, then you only need to compile them for Maemo. The same is probably true for other wrapper generators such as sip. I know it's true for my own bgen wrapper generator, but as the C++ support isn't ready for prime time yet I won't offer it as an alternative:-) -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman smime.p7s Description: S/MIME cryptographic signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Porting L4-embedded kernel
I've now got my serial port connected with three spring-contacts - the type used on a bead-of-mails test station. This connected to a FTDI TF232BM usb-serial converter chip. A quick look around, I noticed /dev/mtdblock2 it where is seems the vmlinux image lives, starting at offset 0x800 /dev/mtdblock0 is the nolo 'Nokia Loader' code and /dev/mtdblock1 is the config partition? /dev/mtdblock3 is the initfs? Yst this is correct. Kernel lives in /dev/mtdblock2 but there appears to be header NOLO img + kernel image size an kernel stats at 0x800. 2. Modifiy the initfs such that very early on, before flash is mounted rw, have a bootmenu, much like the existing bootmenu program. This could on selection of L4, load a kernel module which contains the L4 kernel image, and then take over Linux and boot the L4 kernel. Just a thought, can this module with L4 kernel take over already running linux kernel but leave it running i.e. just hook into interrupt vectors, MMU or whatever? This is how colinux hooks into running NT/XP kernel and runs side by side with it. When done this way you won't need any boot or linux kernel loader. I don't want to keep Linux around in kernel mode. It is insecure and should not be priviledged when running on a kernel like L4. I'll run a copy of the Linux kernel para-virtualized as an L4 application. I think I'll take the kernel module option for now.. .its easier to implement for now and I can use my laptop to flash images onto the MMC card. -- Carl _ See their smiles, hear their laughter with Windows Live Messenger! http://messenger.live.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Install newest version of automake
Hi all, i m trying to install version 1.9.6 of automake in maemo but i cannot do it for some reason. First i downloaded version 1.9.6 from the web. I extracted itto a folder and then i logged in to scratchbox. I went to the root directory of automake-1.9.6 (through scratchbox)and i run the following commands. 1. ./configure 2. make 3. make install. Then i run the command automake --version and i see that the automake version is still the preinstalled 1.8.5 instead of the one that i just installed. I did the same thing for the linux platform (outside scratchbox) and it worked fine. What i m doing wrong? Does anyone have any idea? ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Install newest version of automake
Hi, Then i run the command automake --version and i see that the automake version is still the preinstalled 1.8.5 instead of the one that i just installed. Scratchbox will use host version of binaries if they exist. This is mainly for performance reasons, so they don't need to be run over ARM emulation or across network on real device, but there are sometimes also other reasons. If you want to override this, use something like: SBOX_REDIRECT_IGNORE=/usr/bin/automake Scratchbox actually offers you several versions of automake (1.4, 1.7, 1.8), you just need to use SBOX_DEFAULT_AUTOMAKE environment variable to select which one you want to use. For more info, see: http://www.scratchbox.org/wiki/EnvironmentVariables - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Install newest version of automake
On Mon, 2006-09-18 at 14:00 +0300, Dionysis Petromanolakis wrote: Hi all, i m trying to install version 1.9.6 of automake in maemo but i cannot do it for some reason. First i downloaded version 1.9.6 from the web. I extracted it to a folder and then i logged in to scratchbox. I went to the root directory of automake-1.9.6 (through scratchbox) and i run the following commands. 1. ./configure 2. make 3. make install. Then i run the command automake --version and i see that the automake version is still the preinstalled 1.8.5 instead of the one that i just installed. I did the same thing for the linux platform (outside scratchbox) and it worked fine. What i m doing wrong? Does anyone have any idea? Hi, I think you are doing nothing wrong, but Scratchbox has a override mechanism for using host side tools when ever those are available. You can use SBOX_REDIRECT_IGNORE to switch this off so that your binary will be used. I hope this example will enlighten this a bit: [sbox-SDK_ARM: ~] /usr/bin/dpkg --version Debian `dpkg' package management program version 1.13.18 (i386). This is free software; see the GNU General Public License version 2 or later for copying conditions. There is NO warranty. See dpkg --license for copyright and license details. [sbox-SDK_ARM: ~] export SBOX_REDIRECT_IGNORE=/usr/bin/dpkg [sbox-SDK_ARM: ~] /usr/bin/dpkg --version Debian GNU/Linux `dpkg' package management program version 1.13.13 (armel). This is free software; see the GNU General Public Licence version 2 or later for copying conditions. There is NO warranty. See dpkg --licence for copyright and license details. First you will use actually host side dpkg from scratchbox even though you are inside armel target. When redirect ignore is set it will execute the actual armel binary. -- Miko Nieminen [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Launching browser at startup
We are developing a Flash application to run on Nokia 770 devices and we would like this application to be launched automatically when the device is switched on. How can we launch opera browser (in fullscreen mode) at startup? We've tried editing .profile and .ashrc but it does not work. Any help would be appreciate. Thank you in advance. Tomàs ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Launching browser at startup
2006/9/18, [EMAIL PROTECTED] [EMAIL PROTECTED]: We are developing a Flash application to run on Nokia 770 devices and we would like this application to be launched automatically when the device is switched on. How can we launch opera browser (in fullscreen mode) at startup? We've tried editing .profile and .ashrc but it does not work. Any help would be appreciate. Thank you in advance. Tomàs The usual (linux/debian) way of startup scripts are in /etc/init.d and then a link to /etc/rc2.d (with name like S99xx). As you'll want it to run as user not root, you might want to add it to /etc/osso-af-init/ and edit real-af-base-apps to run the script so you'll get the environment setup for free. You can look at the other scripts there for examples. -- 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] Launching browser at startup
On 9/18/06, Kalle Vahlman [EMAIL PROTECTED] wrote: 2006/9/18, [EMAIL PROTECTED] [EMAIL PROTECTED]:We are developing a Flash application to run on Nokia 770 devices and we would like this application to be launched automatically when the device is switched on. How can we launch opera browser (in fullscreen mode) at startup? We've tried editing .profile and .ashrc but it does not work. Any help would be appreciate. Thank you in advance. TomàsThe usual (linux/debian) way of startup scripts are in /etc/init.d andthen a link to /etc/rc2.d (with name like S99xx). Actually, that would be the place to put system-wide daemon/services startup scripts that have no UI. There should be a script in there that runs the desktop manager and within the desktop manager there should be mechanisms in place to start things up in a particular users session so that all the proper environment variables and user contexts are set. The rc startup scripts are a very wrong place to put a command to start up the browsers in a user's desktop. .ashrc is also not entirely proper either as that is the script that is fired when an ash shell is started up to get a virtual terminal, AFAIK. Not something that happens automatically at Maemo desktop startup. As you'll want it to run as user not root, you might want to add it to /etc/osso-af-init/ and edit real-af-base-apps to run the script soyou'll get the environment setup for free. You can look at the otherscripts there for examples.That seems to be the place but that script system sure is package manager unfriendly. Other distros typically have a script that will call any script placed in an /etc/something.d/ directory. That way a .deb (or rpm or whatever) can add or remove their hooks into the main startup sequence without having to parse (and possibly corrupt) the main start script. Are there other mechanisms around like this or maybe some gconf-2 variables that can be poked that act on the session level rather than system level?/Mike ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] bug in ARM thumb usermode emulation
Running python 2.4 in qemu sometimes causes this assert Inconsistency detected by ld.so: rtld.c: 288: _dl_start_final: Assertion `info-l.l_tls_modid == 0' failed! The same error is present in all versions tested (0.8.1, 0.8.2 and CVS). I have been able to create a small ARM chroot that contais a test program and python 2.4. It is available at http://www.maemo.org.br/platform/rafael/qemu-bug.tar.bz2 The test program sets some environment variables and execs python. The test can be run with sudo chroot bug/ ./test An equivalent test program that skips qemu runs correctly in a real ARM device, so I thing that the bug is really in qemu. The bug is very dependent on the environment variables and argv. Small changes can hide the bug. Do you have any suggestions on how to debug this? Thanks, Rafael ___ 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 Monday 11 September 2006 00:34, Olivier ROLAND wrote: 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. ... [...] 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 ... Well, for the last days I tested memory occasionally and observed problem also with a fully recharged battery at least once :( An interesting observation is that you need to gradually increase the size of tested memory block. You need to start with testing 20MB first, then you can try 25MB and so on up to 43MB. If you try to allocate and test a large block of memory too early, memtester will just get killed. As for the failures, only the last two hex digits of faulty address always contain 'a5' and it is a bit strange. I expected that offset within a page would remain the same (I changed malloc to mmap in order to always allocate memory buffer at a page boundary ) and unless pages have size equal to 256 bytes, it is inconsistent. I also wanted to detect physical address of a faulty memory region. I tried to open '/dev/mem', read it one page at a time and compare its content with the data from a faulty page. Unfortunately this does not work on Nokia 770 and segfaults on reading from '/dev/mem'. The same code works fine on desktop x86 pc and has no problems identifying physical address for any page. Test programs were always run as root. Any other ideas? ___ 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 Tuesday 19 September 2006 00:03, you wrote: [...] An interesting observation is that you need to gradually increase the size of tested memory block. You need to start with testing 20MB first, then you can try 25MB and so on up to 43MB. If you try to allocate and test a large block of memory too early, memtester will just get killed. As for the failures, only the last two hex digits of faulty address always contain 'a5' and it is a bit strange. I expected that offset within a page would remain the same (I changed malloc to mmap in order to always allocate memory buffer at a page boundary ) and unless pages have size equal to 256 bytes, it is inconsistent. A small update. As I checked manual [1], a minimal page size for arm926ej-s cpu is in fact 1KB (tiny page). So inconsistency is now resolved. I have patched memtester to gradually allocate memory starting from 20MB to the size specified in a command line, so it is possible to check larger blocks without any extra tricks, you can download this modified memtester here: http://ufo2000.xcomufo.com/files/memtester-n770.tar.gz If you are going to try it (and it may be a really good idea), it should be run as root. The first argument is the size of memory block to be tested (in megabytes), the second optional argument is the number of passes. Here is a result of running it on my device: Nokia770-26:/media/mmc1# ./memtester 40 1 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 40MB (41943040 bytes) got 40MB (41943040 bytes), virtual address=0x40128000, trying mlock ...locked. Loop 1/1: Stuck Address : testing 0FAILURE: possible bad address line at offset 0x009899a5 (page offset 1a5). Skipping to next test... Random Value: FAILURE: 0x3f770c1e != 0x3f77 at offset 0x004899a5 (page offset 1a5). FAILURE: 0xc50dee8d != 0xc50d at offset 0x004899a5 (page offset 1a5). Compare XOR : FAILURE: 0x0e119ff2 != 0x0e10 at offset 0x004899a5 (page offset 1a5). Compare SUB : FAILURE: 0x7d558974 != 0x5ca0 at offset 0x004899a5 (page offset 1a5). Compare MUL : Compare DIV : ok FAILURE: 0x7febf0e8 != 0x7feb at offset 0x004899a5 (page offset 1a5). Compare OR : FAILURE: 0x7b69b068 != 0x7b69 at offset 0x004899a5 (page offset 1a5). Compare AND : Sequential Increment: ok Solid Bits : testing 1FAILURE: 0x != 0x at offset 0x004899a5 (page offset 1a5). Block Sequential: testing 1FAILURE: 0x01010101 != 0x0101 at offset 0x004899a5 (page offset 1a5). Checkerboard: testing 0FAILURE: 0x != 0x at offset 0x004899a5 (page offset 1a5). Bit Spread : testing 0FAILURE: 0xfffa != 0x at offset 0x004899a5 (page offset 1a5). Bit Flip: testing 0FAILURE: 0x0001 != 0x at offset 0x004899a5 (page offset 1a5). Walking Ones: testing 0FAILURE: 0xfffe != 0x at offset 0x004899a5 (page offset 1a5). Walking Zeroes : testing 0FAILURE: 0x0001 != 0x at offset 0x004899a5 (page offset 1a5). So faulty address is always reported to have offset 1a5 within a page on every run. Now the next thing to do is to identify physical address for use with BadRAM kernel patch. I also wanted to detect physical address of a faulty memory region. I tried to open '/dev/mem', read it one page at a time and compare its content with the data from a faulty page. Unfortunately this does not work on Nokia 770 and segfaults on reading from '/dev/mem'. The same code works fine on desktop x86 pc and has no problems identifying physical address for any page. Test programs were always run as root. I would really like to hear something from Nokia regarding this problem. There may be a few other devices with faulty memory considering some browser crash reports, reboots and instability for some people, a possible example can be seen here (though the reporter did not run the memory test as adviced): https://garage.maemo.org/tracker/index.php?func=detailaid=84group_id=54atid=269 That's not a tragedy and software solution can probably resolve this problem. As you know, bad blocks are common for flash and jffs2 file system handles this issue. RAM can be probably treated in a similar way by using something like BadRAM kernel patch [2] [1] http://www.arm.com/pdfs/DDI0198D_926_TRM.pdf [2] http://rick.vanrein.org/linux/badram/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
