sd performance tests, bonnie++ with different filesystems.
Hi, list. Unexpectedly, seems it's time for me to repartition my sd card. So i decided to find which filesystem is best for current kernels, and to share my results as this topic should be interesting to everyone who is using sd card as storage for data. The participants - btrfs nilfs2 ext2 ext3 ext4 reiserfs jfs xfs. The old well-know test is bonnie++. Resulting html table, with 2 runs: http://www.bsdmn.com/openmoko/fstest/fstestresults.html The test script: http://www.bsdmn.com/openmoko/fstest/fsbench.sh Results are really hard to interpret, all filesystems has weak and strong sides, but i'll try to do some summary now, for whoose who is interested. 1. sequental io, this is quite rare now, so not really matter. 1.1 sequental output per char reiser, btrfs is non-usable in this respect. ext3 is close to unusable, xfs is almost ok. all others same. 1.2. sequental input per char all almost the same - latency +-25%, expect btrfs, which is 30% slower and have extraoridinary latencies. xfs is not good at speed too. 2. block io, most important thing. 2.1 8k blocks write here is most surprise - ext4 and ext2 are slowest. almost 50% slower than xfs, jfs. ext3 have outstandingly bad latency. 2.2 most important thing for fs - block read. they all the same, except btrfs, which is much slower. 2.3. rewrite all almost same, expect btrfs and ext3. 3. random seeks. it's seek+read or write. useful operation. only test where btrfs is relatively good in performance. 4. create/delete tests 1. Create (random) great difference here, ext2, ext4, xfs, are bad. ext3, btrfs, reiser 5-10 times better. 2. delete (random) ext2,ext3,ext4,reiser,btrfs are good, jfs and xfs 10 times slower. my conclusion here is that good filesystems: ext2 and ext4 have same performance in this test. reiserfs is best, despite of name of it's creator. ext2 is good except file creation and remove. xfs is good except file creation and remove. ext3 is good _for_ file creation and remove. so, my choise of fs will be: /boot -> ext2 for compatibility /, /usr -> xfs, need fast block r/w. /home -> reiser, need fast file create/remove, and overall balance /var -> reiser, 'append fs', need good overall balance. i wanted to test nilfs2 (and use it for /var), but it didn't pass testing - out of free space. All tests were done on .34, yesterday git (with FIFO LCM patch). Short tests algorithm: for each fs: create fs on same mmc partition, mount (with noatime) and run bonnie in mounted directory, then umount. I did two runs to ensure results are sane. plain dd read speed of my sd card is 2.7Mb/s. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
sd performance tests, bonnie++ with different filesystems.
Hi, list. >It's good to see someone doing tests on this, but more info is needed on what fs creation and mount options were applied by default. all fses were created with default options, you can check published script, which has mkfses line-by-line. > Of particular interest would be whether btrfs used the ssd option by default. i'll do next run with both ssd and non-ssd versions of btrfs. > and how the compress option would affect the results - does the cpu overhead of compression outweigh the reduction of bus traffic between cpu and glamo? hm, from my POV it depends now much it loads CPU, hm... need to add this on next run. Al, thanks for suggestions, next run is not priority for me, as i already choosen filesystems for my freerunner, but a bit later i'll do it, as a minimum to check your suggestions about btrfs. >Is it possible to tune these file systems to achieve better results? If someone has suggestions about other filesystems, they are welcome. Sure, it's possible, but i didn't want to spend a week studiing all kinds of options for all kind of filesystems just to repartition my sd, just wanted to choose fs intelligently :) but topic is interesting in general (we all have USB flashes not only sd in moko). >What does "% CPU" field name stands for? Is it CPU load or idle? this is standard table for bonnie++, it stands for cpu load of course. >Interesting how bad results you got for brtfs (I guess that MeeGo people also did some benchmarks, before selecting is as default fs). Maybe because rather slow cpu in freerunner? i didn't bury in detatils, to answer this question it's better try first to optimize btrfs. but all i read about btrfs were some bad details, like this http://lkml.org/lkml/2010/6/3/313 it's strange to choose something experimental, in development fs with unstable disk format for production system, also it's entirely possible that MeeGo people choose it because 'it's cool', 'it's cool for target audience', "our devs participate in btrfs development and they say ...", or something like this. also, by guess is that btrfs is more complex than others. anyway using significatly more cpu is bad for embedded, as it eats more power. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
sd performance tests, bonnie++ with different filesystems.
Hi, > XFS is not prone to power failures anymore or it's not an issue on uSD (without big cache as normal drives)? i thought it is same to btrfs? i am using xfs on desktop for storing data like films, audio and other big and non-critical data, have no problems for 5 years. i've heard about 0 files, after power failure, which were somehow intelligently described (and seem fixed http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F ) i think this is only on writes. i took that into accout, using to for / and /usr, which are changed only on system upgrades. why do you think xfs is less proof to to power failures that others? >> - flash dying >no big problem on replacable uSD yeah, it's much better to replace sd once in year for example but have +30% r/w speed during year. >> - problem with bootloaders >if you load kernel from different partition then I don't see any problem with brtfs rootfs. yeah, I used ext2 for /boot -> uboot is happy. i even used GPT for fun, so finally my partitions numbered 1,2,3,4,... without 'extendeds' so far, i didn't notice some significant difference except it only fsck /boot for a long time. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
cpu reclocking to 500Mhz, overclocking to 533Mhz, performance tests and bootloader images
Hi, list. This time i decided to try to look at performace from other side: check clocking, sdram timing and other things, so here is my report. I already "announced it" on IRC. Foreword: WARNING!!! Do it at your own risk nobody will be responsible in any case of problems, Only thing i can say: all configurations were at least tried here. Some were also tested. I will use something of 533/88/clk2 or 465/116, or finally 500/83/clk2 in case of any troubles. I'm not hw engineer. Foreword 2: I hope some hardware expert review my findings. ---> Theory: 1. CPU Facts: In BOM, it is stated our CPU is stated as '500mhz 1.7v'. Unfortunately I have only manual for 400Mhz version, so i can't tell for sure which voltage range can be applied to it. Voltage: according to schematic, voltage is used only to feed CPU. So.. conclusion: 500mhz and 1.7 voltage is native for our cpu so this never will hurt it, but board were not designed for 1.7V. may be some hw expert may review this. 2.Memory. Facts: We have 2 sdram modules - 1 inside cpu and 1 outside. both have same timings. both are clk3 at up to 133Mhz, and clk2 at up to 83mhz. Idea: So, conclusion: at 100Mhz, memory not show all it's potential, as we have to run it on clk3 and (according tests) 88mhz/clk2-2-2 is same speed to 100mhz/clk3-3-3. Also it SDRAM itself should run up to 133Mhz without troubles. Bus: Memory is on same bus as: part of glamo, nand (internal), wifi. sdram (internal), nor flash, and may be something else so it's generally bad idea to increase it's voltage. If we need to rise memory voltage it will not be really good idea, and i in fact didn't checked all harware for compatibility, but here is what i checked: sdram in cpu -> up to 1.95 ok sdram -> up to 1.95 ok cpu -> up to 1.95 ok glamo -> up to 1.9 ok nand "voltage on any pin relative to Vss" -> -0.5-2.45 unsure, but sounds ok ok. 3. USB usb have separate clock, so forget it. 4. overall frequency CPU freq may be to almost any value, but it is limited to rate 1:3:6 or 1:4:8 or 1:6:12. no 1:5. (ratings CPU/MEMORY/PERIPHERIAL). ---> Practice: i saved different uboots which sets differents speed: www.bsdmn.com/openmoko/uboot500 many of them are not working, all were tried here. once i even thought my fr i dead, but at the end i found that it is just my AUX desoldered. so i fixed AUX and continue tests bravely :) if you not planning to dive deep in this topic i consider you be interested in slightly overclocked: www.bsdmn.com/openmoko/uboot500/u-boot.udfu_533_88_1.7_1.8_CLK2 you need nothing to test it. in case of troubles it will be useful to try non-overclocked, in-spec version: www.bsdmn.com/openmoko/uboot500/u-boot.udfu_500_83_1.7_1.8_CLK2 for whoose who like a bit more speed, risk to hardware and work, assume your fr is fried before trying this, but this works here and is fastest config: www.bsdmn.com/openmoko/uboot500/u-boot.udfu_465_116_1.65_1.9 and in case of trouble a bit slower: www.bsdmn.com/openmoko/uboot500/u-boot.udfu_450_112_1.65_1.9 default u-boot is 400_100_1.5_1.8_CLK3. so, CPUCLOCK_MEMCLOCK_CPUVOLTAGE_MEMVOLTAGE. if something not mentioned in file name - it is default. as you see last 2 configs use modified memory voltage. to use it you need patch to the kernel. by default kernel will reset voltage to 1.8. patched kernel allow 1.8-1.9 range, see patch and end of mail. I tested all working configs to Xorg, on .34 kernel. decoded some videos on both u-boot.udfu_465_116_1.7_1.9_sdmax and u-boot.udfu_533_88_1.7_1.8_CLK2 ---> u-boot setup help for whoose who not familiar with u-boot setup i provided www.bsdmn.com/openmoko/uboot500/u-boot_env.in flash it with: dfu-util -D u-boot_env.in -a u-boot_env use power -> wait 0.3s ->hold aux for nand uboot menu. ---> Power consumption: sorry, no tests :( may be someone? ---> Performance testing: i tested several working configurations with lmbench: www.bsdmn.com/openmoko/uboot500/lmbench.txt as you can see, 462/116 version seem best from kernel subsystem point of view. of course, pure computation will be better with 533/500Mhz. 550Mhz is excluded as it requires 1.75V CPU, and CLK2 version also 1.9V mem and were not 100% stable. for whoose who not familiar with u-boot: you may flash setting partition, use file u-boot_env and flash it with -a u-boot_env. press power and and 0.5 sec aux for NAND uboot menu. ---> Patches uboot clk2:http://www.bsdmn.com/openmoko/uboot500/CLK2.patch uboot frequency setting sample:http://www.bsdmn.com/openmoko/uboot500/500_83_1.7.patch kernel patch to allow 1.9v on memory/other peritherials bus:http://www.bsdmn.com/openmoko/uboot500/kernel_memvoltage.patch Hope you'll have fun with faster fr :) Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Profiling on openmoko (or ARM generally)
Hi, mobi phil, I am using oprifile. It is excellent profiled, even no need to recompile anything. It is way better. You you want more details/help/examples you can find me on irc. Currently i am planning some optimizations based on profiling data. Result is something like this (this is for mplayer): TIMER:0| samples| %| -- 3782 48.7057 vmlinux_b13 2316 29.8261 mplayer TIMER:0| samples| %| -- 1136 49.0501 libavcodec.so.52.20.1 682 29.4473 libswscale.so.0.7.1 168 7.2539 ld-2.11.2.so 109 4.7064 vmlinux_b13 97 4.1883 mplayer 93 4.0155 libc-2.11.2.so 11 0.4750 libfontconfig.so.1.4.4 5 0.2159 libfreetype.so.6.3.22 4 0.1727 libX11.so.6.3.0 2 0.0864 libgcc_s.so.1 2 0.0864 libpthread-2.11.2.so 2 0.0864 libexpat.so.1.5.2 2 0.0864 libxcb.so.1.1.0 1 0.0432 libdl-2.11.2.so 1 0.0432 libncurses.so.5.7 1 0.0432 libopenal.so.1.12.854 1419 18.2743 Xorg TIMER:0| samples| %| -- 1376 96.9697 libc-2.11.2.so 31 2.1846 vmlinux_b13 7 0.4933 glamo_drv.so 5 0.3524 Xorg 99 1.2750 bash TIMER:0| samples| %| -- 45 45.4545 vmlinux_b13 38 38.3838 bash 14 14.1414 libc-2.11.2.so 1 1.0101 xfs 1 1.0101 ld-2.11.2.so 67 0.8628 oprofiled TIMER:0| 3782 48.7371 (no location information) vmlinux_b13 vmlinux_b13 /vmlinux_b13 1374 17.7062 memcpy.S:60 libc-2.11.2.so Xorg memcpy 1136 14.6392 (no location information) libavcodec.so.52.20.1 mplayer /usr/lib/libavcodec.so.52.20.1 682 8.7887 (no location information) libswscale.so.0.7.1 mplayer /usr/lib/libswscale.so.0.7.1 109 1.4046 (no location information) vmlinux_b13 mplayer /vmlinux_b13 108 1.3918 dl-lookup.c:82 ld-2.11.2.so mplayer do_lookup_x 450.5799 (no location information) vmlinux_b13 bash /vmlinux_b13 430.5541 memset.S:25 libc-2.11.2.so mplayer memset 380.4897 (no location information) bash bash /bin/bash 370.4768 (no location information) vmlinux_b13 oprofiled/vmlinux_b13 310.3995 (no location information) vmlinux_b13 Xorg /vmlinux_b13 220.2835 (no location information) reiserfs oprofiled/reiserfs 140.1804 strchr.c:46 ld-2.11.2.so mplayer index 130.1675 dl-lookup.c:132 ld-2.11.2.so mplayer check_match.8383 130.1675 vo_x11.c:525mplayer mplayer draw_slice 130.1675 m_config.c:185 mplayer mplayer m_config_add_option 130.1675 font_load_ft.c:958 mplayer mplayer read_font_desc_ft 130.1675 (no location information) vmlinux_b13 grep /vmlinux_b13 110.1418 (no location information) libfontconfig.so.1.4.4 mplayer /usr/lib/libfontconfig.so.1.4.4 9 0.1160 strcmp.c:38 ld-2.11.2.so mplayer strcmp 9 0.1160 (no location information) vmlinux_b13 cat /vmlinux_b13 8 0.1031 dl-load.c:1958 ld-2.11.2.so mplayer _dl_map_object 8 0.1031 skeleton.c:395 libc-2.11.2.so bash __gconv_transform_ascii_internal 8 0.1031 vd_ffmpeg.c:452 mplayer mplayer draw_slice 8 0.1031 input.c:1357mplayer mplayer mp_input_get_cmd 8 0.1031 (no location information) vmlinux_b13 id /vmlinux_b13 7 0.0902 (no location information) glamo_drv.so Xorg /usr/lib/xorg/modules/drivers/glamo_drv.so 7 0.0902 malloc.c:4765 libc-2.11.2.so mplayer _int_free 7 0.0902 strncpy.c:36libc-2.11.2.so mplayer strncpy 7 0.0902 mplayer.c:2505 mplayer mplayer main Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Profiling on openmoko (or ARM generally)
Hi, mobi phil, heh, sent again occasionally :) I am using oprofile. It is excellent profiler, even no need to recompile anything. It is way better than grof. If you want more details/help/examples you can find me on irc. Currently i am planning some optimizations based on profiling data. Result is something like this (this is for mplayer): TIMER:0| samples| %| -- 3782 48.7057 vmlinux_b13 2316 29.8261 mplayer TIMER:0| samples| %| -- 1136 49.0501 libavcodec.so.52.20.1 682 29.4473 libswscale.so.0.7.1 168 7.2539 ld-2.11.2.so 109 4.7064 vmlinux_b13 97 4.1883 mplayer 93 4.0155 libc-2.11.2.so 11 0.4750 libfontconfig.so.1.4.4 5 0.2159 libfreetype.so.6.3.22 4 0.1727 libX11.so.6.3.0 2 0.0864 libgcc_s.so.1 2 0.0864 libpthread-2.11.2.so 2 0.0864 libexpat.so.1.5.2 2 0.0864 libxcb.so.1.1.0 1 0.0432 libdl-2.11.2.so 1 0.0432 libncurses.so.5.7 1 0.0432 libopenal.so.1.12.854 1419 18.2743 Xorg TIMER:0| samples| %| -- 1376 96.9697 libc-2.11.2.so 31 2.1846 vmlinux_b13 7 0.4933 glamo_drv.so 5 0.3524 Xorg 99 1.2750 bash TIMER:0| samples| %| -- 45 45.4545 vmlinux_b13 38 38.3838 bash 14 14.1414 libc-2.11.2.so 1 1.0101 xfs 1 1.0101 ld-2.11.2.so 67 0.8628 oprofiled TIMER:0| Gennady. CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples %linenr info image name app name symbol name 3782 48.7371 (no location information) vmlinux_b13 vmlinux_b13 /vmlinux_b13 1374 17.7062 memcpy.S:60 libc-2.11.2.so Xorg memcpy 1136 14.6392 (no location information) libavcodec.so.52.20.1mplayer /usr/lib/libavcodec.so.52.20.1 682 8.7887 (no location information) libswscale.so.0.7.1 mplayer /usr/lib/libswscale.so.0.7.1 109 1.4046 (no location information) vmlinux_b13 mplayer /vmlinux_b13 108 1.3918 dl-lookup.c:82 ld-2.11.2.so mplayer do_lookup_x 450.5799 (no location information) vmlinux_b13 bash /vmlinux_b13 430.5541 memset.S:25 libc-2.11.2.so mplayer memset 380.4897 (no location information) bash bash /bin/bash 370.4768 (no location information) vmlinux_b13 oprofiled/vmlinux_b13 310.3995 (no location information) vmlinux_b13 Xorg /vmlinux_b13 220.2835 (no location information) reiserfs oprofiled/reiserfs 140.1804 strchr.c:46 ld-2.11.2.so mplayer index 130.1675 dl-lookup.c:132 ld-2.11.2.so mplayer check_match.8383 130.1675 vo_x11.c:525mplayer mplayer draw_slice 130.1675 m_config.c:185 mplayer mplayer m_config_add_option 130.1675 font_load_ft.c:958 mplayer mplayer read_font_desc_ft 130.1675 (no location information) vmlinux_b13 grep /vmlinux_b13 110.1418 (no location information) libfontconfig.so.1.4.4 mplayer /usr/lib/libfontconfig.so.1.4.4 9 0.1160 strcmp.c:38 ld-2.11.2.so mplayer strcmp 9 0.1160 (no location information) vmlinux_b13 cat /vmlinux_b13 8 0.1031 dl-load.c:1958 ld-2.11.2.so mplayer _dl_map_object 8 0.1031 skeleton.c:395 libc-2.11.2.so bash __gconv_transform_ascii_internal 8 0.1031 vd_ffmpeg.c:452 mplayer mplayer draw_slice 8 0.1031 input.c:1357mplayer mplayer mp_input_get_cmd 8 0.1031 (no location information) vmlinux_b13 id /vmlinux_b13 7 0.0902 (no location information)
[qtmoko] v24 & importing contacts
Hi, I noticed following bug in my qtmoko v22: If user is too slow to input pin, it doesn't load contacts. Also, afair were button somewhere to import contacts from sim. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
cpu reclocking to 500Mhz, overclocking to 533Mhz, performance tests and bootloader images
Hi, > have you been able to test for stability over a few days of normal operation? I am using mostly 533/88/clk2 now and over versions for may be 5 days. So far i have no problems. I run tests on all recommended versions, also run cpu-intensive video decoding without problems. But i'm on .34 and can't test some features, like suspend, sound, gsm, but things i tested works good (usb, glamo video and mmc, cpu). I tried qtmoko and it were working for 450 version. Freerunner feels warmer, so i measured temperature, but without opening that shielding. While 100% cpu load shield temperature is 32C. Also i noticed it can't stand overnight without usb and suspend due to bigger power consumption, but with suspend this should be ok. i know 3 people who tryed it. one were unable to run any clk2 versions, so he tried 533/clk3. but he very able to run 465 version with default 1.8 on memory bus. One man reported he is unable to suspend, may be kernel need some fixes to suspend/resume properly, but currently my .34 can't suspend more than once anyway, so i didn't test this. So far no unrecoverable errors reported. No fried frs. One man reported "flash error" but this turned out to be bad sector on NAND, and he begun experiments on NAND after changing clock, and we were unable to attribute this to overclocking. >I will need to patch/recompile my kernel besides flashing a new Uboot. No, you need to recompile/patch kernel only for versions with modified memory bus voltage (forth number, if prefent in file name and != 1.8), so 533/88, 500/83 versions may be tried without patches. If you not were familiar with u-boot, here is instruction: 1. flash u-boot environment: from nor u-boot on fr: sudo dfu-util -a u-boot_env -D u-boot_env.in 2. check if default u-boot can boot you system and become familiar with environment: power off, boot with pressing power and in 0.5 sec holding aux for a while. 3. flash reclocked u-boot: sudo dfu-util -a u-boot -D u-boot.udfu_533_88_1.7_1.8_CLK2 4. try to boot it in similar way. if not boots, try u-boot.udfu_533_88_1.7 , you may try also with more risk u-boot.udfu_465_116_1.65_1.9 this may work without kernel patch. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
cpu reclocking to 500Mhz, overclocking to 533Mhz, performance tests and bootloader images
Hi, >I couldn't resist to do some more testing, Thanks for testing :) > u-boot.udfu_450_112_1.65_1.9: won't boot (hangs on 'Starting kernel...') > u-boot.udfu_450_112_1.7_1.9_sdmax: won't boot (hangs on 'Starting kernel...') As i already told to use 450 or 465 you need kernel patch, and hang in 'Statring kernel ...' means exactly that you need kernel patch to test this kernels. so, to test it you need to get andy-tracking kernel from git and apply some similar patch on it (my patch is against .34). >but my phone doesn't wake up after suspend with any of the overclocked images; currently i am trying completely other optimization idea. then i'll finish with it I return to overclocking and try to fix resume or other bugs, also push all this to wiki. PS. Hm seem i were not right, as i didn't applied patchs to qtmoko kernel- so seem I tested 500mhz (not 450) with qtmoko, but i tried so many configs, that i can't recall which one exactly i tested with it. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: My N900 experience compared to my FR experience
Guys, thanks for your detailed reviews. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
cpu reclocking to 500Mhz, overclocking to 533Mhz, performance tests and bootloader images
Hi, > Do you have the PLL divider values (not sure if that is the correct term) for the other speeds? Here is values i used: Freq MDIV PDIV SDIV 450 142 21 465 147 21 480 152 21 500 117 11 533 125 11 549 175 21 564 133 11 Yeah, 549/CLK3 worked too, but it need a voltage of 1.75, and i have no idea is it in range. You may use s3c manual, which has formula to calculate dividers for almost any frequency. I tried to find good rounded values for some key frequnces like 500 or 533 or 450. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[qtmoko] build failed
Hi, Vinzenz I can say, that we were able to build qtmoko on Debian too. Only trouble i had once - inability to build in amd64 native env, but attempts to build in 386 chroot were ok. Also i were able to do more exotic build within amd64 env and debian apt-cross utils. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Glamo slowness question. Glamo transfer speed improvements (+33%). Video sofdecoding playing profile. Glamo dma transfer.
Hi, list. Here is my next rant to freerunner slowness :) Today, topic of discussion is freerunner's most famous beast - glamo. I want to show that it is much better than some people thinking about it. Also i propose different significant optimizations: usage of DMA, changing cpu<->glamo bus timings. Also you can find analysis of high resolution software video decoding. 1. --->>> Glamo bus speed The most famous problem about our beast is legendary mythical cpu <-> glamo bus slowness. Let's measure actual bus speed and fix it. 1.1. --->>> Current situation The older statement is that glamo should have 7Mb/s transfer speed. It's not easy to find out how this number were calculated. I hope someone who did glamo speed measurement can comment this mail if i am wrong somewhere. 1.2. --->>> Theory Actually bus speed of glamo is limited by settings of memory controller in our cpu. This speed can be calculated by formulae (HCLK/TWORD)*WORDSIZE, where HCLK is frequency of memory bus == 100Mhz (in normal conditions, without overclocking), WORDSIZE = 2 bytes, and TWORD is waiting period, by default we have TWORD=4+4+4 bus clocks. So, for default settings we have CPU<->glamo bus speed (100*10^6/(4+4 +4))*2/1024^2 Mb/s=15.8Mb/s. This speed may or may not be also influenced by nwait state of cpu. We'll measure actual practical speed in section 1.3. So, together with Thomas White we did review of memory contoller settings in s3c and found out that 4+4+4 setting seem not reasonable. according to Thomas analysis of timings in glamo documentation it should be 2+4+2, which is 33% less than default and gives us: (100*10^6/(2+4+2))*2/1024^2=23.8Mb/s. As you can see, both numbers are much more than 7mb/s. 1.3. --->>> Synthetic bus speed measurements. So i used simple tool to measure actual cpu<->glamo bus transfer speed. Tool opens framebuffer device and starts memcpy or memset session for whole video frame. it's speed measurement +-1 frame. so i tried to find how many frames may be displayed with each method (memcpy or memset) in 1 second for eash s3c memory controller settings (default 4+4+4 or better 2+4+2), and use formulae (640*480*2)*nr_frame to get transfer speed. Or course, memcpy is always slower than memset as cpu need first fetch 4byte burst of data from main memory and only after that send it to glamo, but memcpy is only most common operation with glamo (in both video and mmc transfer). So, after actual measurement i produced following table: theory (see 1.2) memsetmemcpy 4+4+4 speed: 15.8Mb/s 12Mb/s10.5mb/s 2+4+2 speed: 23.8Mb/s 17.5Mb/s 14.0mb/s So, as you can see both default and new settings are very far from 7Mb/s. Also you can see that glamo can really do 14mb/s which is 22 full screen 640*480 frames. Also one can notice that changing settings increase throughtput by 33%. 1.4. --->>> Profiling real application: mpeg2 video decoding with mplayer. To check effect of changing timings settings, i did complex profiling for different versions of mplayers, decoding 480x640 mpeg2 video at 5fps. Such frame rate used to avoid any case of overruns or framedrops. I tested default(AKA slow) and fast timing settings for -vo x11 and -vo fbdev. The settings with different vo's are not directly comparable, as different libc used occasionally, so only (slow/x11 and fast/x11) and (slow/fbdev and fast/fbdev) are comparable. The profiling setup is opcontrol --start; mplayer ... ; opcontrol --stop First, I recorded cpu usage values from mplayer: fbdevx11 slow 35/3140/35 fast 31/2242/26 So, here is comparison of slow/fast fbdev: www.bsdmn.com/openmoko/glamo/oprofile/mplayerfbdev.png And comparison of slow/fast x11: www.bsdmn.com/openmoko/glamo/oprofile/mplayerx11.png As you can see, libc memcpy call cpu usage decreased from 25.2% to 17.6% for fbdev. (i think most of this memcpys are memcpy to glamo) In x11 version, Xorg memcpy usage decreased from 19.1%->13.2%. in both cases, memcpy function from glibc is most time-consuming operation. Generally speaking about software video decoding, next by cpu consumption is yuv2rgb function. I checked mplayer code and found that this function seem not optimized specifically for arm, so it might be possible to do something with it. In general, cpu usage in 5fps mpeg2 decoding is following: 17% memcpy(probably to glamo)/9%(yuv2rbg)/3% mpeg_decode_slice/41% idle/11% oprofile/1.6%io/ + others. others 100% is all cpu. You may find full profile results at: www.bsdmn.com/openmoko/glamo/oprofile/profiles 1.5. --->>> Open questions Actually, out of glamo documentation, speed should be set to 1+4+2. But this seem not working, and we didn't found why. So this question is open for further unvestigation. 1.6. --->>> How to test/use it I used this settings by default for several days with qtmokoV24 and with debian on usd. I prepared u-boot to set new timings by default: www.bs
Glamo bus speed, testing of GLAMO_REG_LCD_A_BASE2 FIFO settings.
Hi list. I decided to do and share some additional tests related to glamo bus speed. This tests related to change found by Thomas White early this year to GLAMO_REG_LCD_A_BASE2 which change some kind of fifo. Goal of this test is to find out how this change influence glamo speed and how different different fifo settings. So, i did 20 frames of memsets to 480x640 framebuffer, here is test results. First i did tests with different FIFO settings and 2-4-2 timings, and go absolutely same results in each tests. So here is only test results for FIFO = 0 or FIFO = 1 (0x4000): FIFO 0 1 2-4-2, 10Mb/s17.5Mb/s 4-4-4, 8.1Mb/s 12.2Mb/s Also, please notice that with current settings, we still have huge diff between theoretical and real thoughtput: 23.8Mb/s vs 17.5Mb/s. May be it's possible to avoid that somehow. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Glamo bus speed, testing of GLAMO_REG_LCD_A_BASE2 FIFO settings
David, > According to your previous mail (Glamo slowness question...) it seems it is 1, am I right? Sure, by default we have 4-4-4 fifo 1 since beginning of 2010, this is just testing which may be interesting to whoose who wonder about FIFO depths. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Glamo slowness question. Glamo transfer speed improvements (+33%). Video softdecoding playing profile. Glamo dma transfer.
> When you get a WSOD (rotating screen) Fixes exist to fix this (for both xrandr rotation, resolution switch and screen blanking), this not related to timings. >When you get a WSOD (rotating screen), if you just reboot, you obtain a WSOD on every following reboot. You MUST halt device for getting it back to normality. I suppose something is not correctly initialized in glamo with modified uboot. Ah, known problem! but this seem somehow related to some state filesystem, not investigated to the final end. Not related to timing thing too. Here i have to just always reboot twice, or it reboots automatically on X11 startup. Solving this is in my todo list... Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Glamo slowness question. Glamo transfer speed improvements (+33%). Video sofdecoding playing profile. Glamo dma transfer.
One more thing, if cpu load look like too high for some exprienced mplayer users, this may be caused by my mplayer version - it is built with -fno-omit-frame-pointer and with run in parallel with _callgraph_ profiling, which seem adds some additional cpu load. For pure timings, here is cpu load result from .29 kernel from qtmoko for same 640x480 5fps mpeg2 movie: old timings: 16% 35% new timings: 16% 28% Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Glamo slowness question. Glamo transfer speed improvements (+33%). Video softdecoding playing profile. Glamo dma transfer.
Hi, David. >I'm now getting WSOD after a > _long_ >suspend. It's the very first time it happens to my FR (with any kernel). Very interesting. >Do you know if is there any fix to this problem? I din't face such problem. But we can try to investigate it. First, interesting, is it temperature-dependent stuff? To test this, can you put suspended fr in fridge for 5 mins? Second, can you try do you get same issue with default u-boot? http://downloads.openmoko.org/distro/unstable/daily/om-gta02/20100131/u-boot-gta02v5-1.3.1+gitr650149a53dbdd48bf6dfef90930c8ab182adb512-r1.bin Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Glamo slowness question. Glamo transfer speed improvements (+33%). Video sofdecoding playing profile. Glamo dma transfer.
Hi, Thomas. > I tried on SHR-u, booted on a beautiful "openmoko" logo, then nothing. > When I tried to boot on u-boot, a single" nokernel found" message is > shown ... I don't know about qi provided, but you should setup u-boot properly to boot you distribution. To not blame glamo timings, try first to setup usual u-boot (ensure your distribution works with it). If you need help in u-boot setup ping me (gena2x) at irc. > So here's a question : Is it only for QTmoko ? No it should work for any distribution. I am using debian and qtmoko, both work flawless. in qtmoko suspend/resume works well for me. I debian X11 with glamo driver working, but i didn't test it much. Other people reported android and qtmoko worked flawlessly. It works for shr also, but seem with some problems (unblanking and resume, not always). May be this problems are solvable and really cause by some kind of kms issues. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Flashing qi broke my freerunner
Hi, Helge. > On reboot, the screen went white, and nothing more happened. Try to remove all power sources from your fr, wait for 10 minutes, and boot device. i don't really know about qi, i can only tell about my uboots, so flash u-boot to nand, remove all power (battery, usb and so), and then try to boot. If your nor u-boot works, all should be good with your device. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Flashing qi broke my freerunner - SOLVED
Hi, guys, Glad to hear no FR fried :) But you not really right that this timings are influence only to graphic. They should influence (may be a bit, but still influence) to usd access speed/cpu load too. I didn't measure that. Here have one idea to check, may be it'll fix that WS and rotation issues together, i'll report later if it'll be ok. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
My guess about the WSOD
Hi, guys. I can attribute WS on boot and blank to changing version of compiler which builds kernel. Here, i have testing re: gcc_4.1.2gcc_4.4.6 2.6.34 kernel, configured for fb okWS on boot/unblank 2.6.32 shr kernel, configured for kms okWS on boot/unblank please, notice that something similar to unblank happens on rotation/mode change. but my kernels somehow lack of sound sound support (other kind of bug), all both shrs and .34, so they are unusable for daily usage (http://www.bsdmn.com/openmoko/glamo/242/shrkernel/) Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Mail Wrapping
Hi, Nikolaus, First, thanks for your work on next generation of free hardware, I hope to use it one day. Didn't came to conclusion how my next device should look like exactly, and i'm ok with fr so far. But about line wrapping - i am using web interface to read community-ml, so no way to control my 'client' parameters. To get idea how your mail look like in web interface, try this link: http://lists.openmoko.org/pipermail/community/2010-July/062609.html I think many people may find your letters this way, and it's really not easy to read sometimes. Just a note, all this wrapping topic is not really serious problem. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QI Bootloader with overclocked settings
Hi, Rashid > Did I read right, when you use the "lower" overcloking images you dont need to hack the kernel, you can just take an other bootloader, right? Yes, only bootloader, where were qi somewhere, but, check answers to that post. But i recommend you to try bootloader with tuned glamo instead (from http://lists.openmoko.org/pipermail/community/2010-July/062495.html ), where were qi also somewhere in answers. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Unable to boot with u-boot_glamo242.udfu
Hi, Giacomo. > At first I tried to flash it using the following commands: > #flash_eraseall /dev/mtd1 > #nandwrite -p /dev/mtd1 u-boot_glamo242.udfu As you already understood, nandwrite is highly not recommended, use dfu-util As i didn't fall to this pitfall, really can tell exactly how to go out of it. I am always using any uboot & envedit.pl to change environment and flash images. I think, this should work from scratch, and should be easy for anything except android (which has different NAND layout). In anroid case one should just tune that dynparts to match android layout. > I tried again, again with dfu-util, u-boot_glamo242.udfu, but it still > didn't work. Define 'didn't work' please. Can you reach menu? Can you hear 'click' on boot? To boot, hold power and then start holding aux, you should hold aux longer than usual (this seem like some latest-svn uboot bug). >If I edit u-boot_env (both with [5] and [6], which is a wrapper of [5] >I think) I can't get rid of some duplicated reboot/power off voices and >of the smile. Of course, you should edit environment.in and cut everything what you don't need. Mine current environment.in is not useful for anyone except me, so i'll not prove it (i am using xfs and ramconsole). > Have you got any suggestion? If you need a bit more help on topic, we can talk on IRC. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QI Bootloader with overclocked settings
Hi, Rashid > Hi I already use the tuned glamo. But I would like to speed reclock the cpu to 500 mhz too. I didn't tried to combine 500 or 533 mhz clk2 or clk3 with glamo242. It should work. Sebastian (dos1) tried to build 465/116Mhz qi, but it didn't work for him. Such things seem individual for each freerunner (unfortunately CLK2 seem not working for some people too), so i think it's possible to find some better than default value (may be 450, or play with voltage), but nobody did it ATM. May be i'll try to test it later. Currently, i am on 242 timings and it works perfect in all aspects - no wsods, no problems with I/O while booting or booted, except one annoyance - i have to boot it via menu because in 33% of cases uboot seem loading kernel image in some wrong way, so it not passes crc checking, so i have to select and boot kernel again in such cases. sometimes it will not boot from second time too, which is actually strange and quite annoying. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QI Bootloader with overclocked settings
Hi, Sebastian, Are this: > http://dos.openmoko.pl/overclock/ all glamo 2-4-2 qi's? According to patches, they are not. We talking now about combined 242 and changed clock settings. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko v25 - experimental with 2.6.34 kernel
Hi, Tha_Man, > I have a question about the (any) new QtMoko release. Have you tested > the new kernel(s) to support Gennady Kupava's overclocked settings [1] > (both using uboot and Qi)? Overclocking is not major thing really. I think only thing worth testing and using without any compromises is glamo 2-4-2 timing settings. Which is working without problems on .29 kernel with qtmoko V24, and works flawless with .34 kernel here. 500mhz especially clk3 version is not really of big value and not worth Radek time, as it increases power consumption significantly, but really faster on some tasks but slower in other. Exact numbers for power consumption are unknown, as nobody seem tested this so far. Whole overclocking/reclocking is a bit marginal as tradeoffs are quite big. May be useful only for heavy cpu-bound tasks, like compilation, which is not target for qtmoko for sure. Use glamo 2-4-2 instead, it brings noticeable graphic speed increase. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko v25 - experimental with 2.6.34 kernel
David, > Are there still WSOD with 2.6.32? I asked Martin to add workaround for this problem to SHR today, so it should not WSOD anymore. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko v25 - experimental with 2.6.34 kernel
> so it should not WSOD anymore. Of course, as soon as new kernel will hit shr repository. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko v25 - experimental with 2.6.34 kernel
Hi, David > It have also solved "rotate WSOD", is it possible? Yes. This patch _may_ also fix all kind of WSODs, in rotate, in switching to qvga, and on resume of course. We wanted to test it, but can't reliable reproduce that WSODs to see if they really fixed. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
please notice if any of your wsods gone with latest shr kernel upgrade [Was: QtMoko v25 - experimental with 2.6.34 kernel ]
Hi, list btw, i would be very interesting to hear if after this patch (which came with latest kernel upgrade in shr) any kind of wsods disappeared on 4-4-4 (default) glamo settings too. please write down. thanks, Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: please notice if any of your wsods gone with latest shr kernel upgrade [Was: QtMoko v25 - experimental with 2.6.34 kernel ]
Ah, i am a bit unclear. I am about 'patch which fixes WSOD for 2-4-2 timing', which were added few days ago. Please, write down here or somewhere (2 more reports will be enought of course) if it fixes some WSODs for you on usual timings too. I expected this, but were unable to check this. Gennady. В Чтв, 26/08/2010 в 13:20 +0200, Sylvain Paré пишет: > Is it in the feed right now ? > I don't see anything > > 2010/8/26 Gennady Kupava > Hi, list > > btw, i would be very interesting to hear if after this patch > (which came > with latest kernel upgrade in shr) any kind of wsods > disappeared on > 4-4-4 (default) glamo settings too. please write down. > > thanks, Gennady. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko Virtual Memory
В Срд, 01/09/2010 в 10:50 +0200, Nashvin Gangaram пишет: > trying to configure my Neo Freerunner with QtMoko v24 Update your system to v26 :) > * Is it possible for QtMoko to use a swap partition on the SD > Card? > * How can this be done? As qtmoko is usual debian system, you can enable swap in usual way, for example by adding appropriate settings to /etc/fstab and dedicating partition on uSD card. > * Does swap cause a significant performance increase with > QtMoko? No, i think it may cause significant performance decrease instead. But this just educated guess and it would be better to do some testing to prove this. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Community Updates] 2010-09-01 is out
Hi, list, Bit info about glamo timing settings. As for some people: >* Glamo timing improvements (= more speed without caveats) can be >done also in run time, and also pre-compiled Qi with settings set by >Qi are available: is someting new, i want to comment this a bit. 1. I beleive that default timings of 4-4-4 is a bug, which should be fixed. Where is no reason to keep default timings. 2. Because of (1), it should just be fixed. Proper way to set video and other memory timings is bootloader. So, bootloader should be fixed once and what's all. 3. So, I hope nobody of distributors will include settings change in runtime, as it will be maintaining one more hack and encouraging users not to use proper solutions. Keeping this things in mind i didn't publish this way to change settings in my original mail, publishing only way to check bootloader settings, not way to change them. Disadvantage is that i didn't allow people to quick check things, but i just attempted to avoid one more from being introduced. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Community Updates] 2010-09-01 is out
В Срд, 01/09/2010 в 14:08 +0300, Maksim 'max_posedon' Melnikau пишет: > Because of FR's NOR bootloader, better to have some hacks in kernel, imho. FR NOR bootloader should not be used for anything expect flashing. It has N other unfixed things. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko Virtual Memory
В Срд, 01/09/2010 в 12:38 +0200, David Garabana Barro пишет: > > It's not true for me, and it's a common misunderstanding IMHO. This is not misunderstanding, this is just one of questions which can't have only one answer. For some tasks swap is good, for others - bad. I have strong (enough for me) arguments too. Yours are strong for you, so this is just matter of situation. > > For testing, simply try to download tiles at zoom level 11, for the upper 6 > zoom levels in tangoGPS. Better if you make it twice (moving on the map) > > Without swap, it will catch all available memory, and FR will get really > slow, to the limit of appearing to hang, and even sometimes oomkill will > start killing some random process. > With swap, linux can swap unused pages (other daemon pages, not tangogps > ones) > and tangogps will continue running, and FR will be responsible. You only will > notice some 1-4 seconds slowdown from time to time, when pages are swapped out > > swap is not only for "creating" more memory. If FR starts to massively > trashing > pages to swap, it will really SLOW things a lot, for sure (the same is true > for > your PC) > > But it will help *a lot* to have more memory available for running apps. > Think on swap as a place where put unused memory pages, and use real RAM for > currently used apps or caching files from slow uSD > > Swap will *ALLWAYS* help, but will help a lot more on a limited memory > device, > as FR > > Here [1] you can read more about what I'm saying. > > [1] http://kerneltrap.org/node/3202 Thanks for description, now my position: First of all, i do not use swap on any Linux system i am using with amount of memory >=512Mb. I even do not use swap on desktop where i have tmpfs mounted to /tmp. Having something published on kerneltrap is not meant to be only possible answer, i can provide an example. Few years ago Linus believed that moving everything to userspace is good idea and this is way to go. Now i see everything is included to kernel (devfs vs udev, evdev vs tslib, kms vs userspace mode switching). But i am still at the point that every possible thing should be in userspace. I think, both points of view very extensivly published to mailing lists and both have strong grounds :) First, about swap in general. IMO, swap were introduced in absolutely different context. In 80's memory situation were completely different. --- now, real situations. 1. main swap problem is in it's nature. it will push to disk less-frequently used pages from memory but use 'freed memory'. But for me it turned out that it is impossible to predict which page is useful which is not _in future_, and it turns out that freed memory on all modern systems used to keep relatively useless huge disk cache. it's question (for me) is _huge_ disk cache is better than _meduim-sized_ disk cache in many situations. note that I found that using tmpfs is times faster than using such 'buffer' (i tested qtmoko build). having random process swapped-out also makes system very unpredictive. you may never know how long some application will start, this annoying for me, i like low latency. 1a. to apply (1) to FR. imagine you have phone app in background. it got swapped out as you did last call 8 hours ago. now, you recieve call and what? you should wait for your app to be paged back even to start hearing ring! considering fr sd io speed is 2.6M/s, and your app is for example 10M, this will take 4 seconds in best case. something have to be also discarded from memory too free up that 10M before loading your phone app. 2. situation (2) is described in [1] you pointed. i personally face it tons of times - some program (last were firefox and midming commander) just run out memory due to bug or other reasons and starts incrementally requesting swap. if you unlicky (and do not kill app in 30 seconds), you may get your terminal and most of X be unloaded to swap, and only thing you can do after that is hard reset. introducing limits will kill only really useful feature of swap - being able to load something larger than memory (3) 3. about your favorite gps application. i think it should create file and map it to memory instead of using extreme amounts of ram to store all data. In older day of swap not all systems had such ability. It's strange that sometimg became 'slow'. without swap it should never become slow, it should be just oomkilled. in fact, i do not understand this problem very well, as i think that just next malloc should return 0, or new throw bad_alloc. 4. swap on nand is special story. recently i saw really interesting article on this topic (by DocScrutinizer i think). as nand has block size of >4kb, writing (and reading) scatter pages (4k) to it may be very slow process. 5. if your distribution is on internal NAND, it may be several times faster to reload application from internal flash than to swap from sd. So, i can see that i only had problems with swap and never had real _need_
Re: [Community Updates] 2010-09-01 is out
В Срд, 01/09/2010 в 18:39 +0300, Timo Juhani Lindfors пишет: > Gennady Kupava writes: > > 1. I beleive that default timings of 4-4-4 is a bug, which should be > > fixed. Where is no reason to keep default timings. > > Hmm, wasn't there some WSOD problem that started to occur with 2-4-2? No, where is no WSOD, only WS, so you can boot your device and fix kernel in case of troubles. 2-4-2 just highlighted it, it existed for 4-4-4 too but visible only on rotation, etc, workaround exist. > > To support regression testing it would be nice to be able to boot > older kernels. However, if the WSOD is rare enough then maybe hard > coding could be ok. However, I don't see why u-boot couldn't just have > an environment variable for the timings. At least for the time being. > You can boot .29 kernel (from qtmoko or debian) without problems. What kind of old kernels you want to care of except this? > I don't see why u-boot couldn't just have > an environment variable for the timings. At least for the time being. So far, i see no reason to keep old state, my p(1) is about this, yes? What to do with qi? Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Using freerunner as webcam display
В Птн, 03/09/2010 в 19:03 +0200, Alexander Lehner пишет: > I think it's the CPU which is around 90% already at 2fps. > Another problem is, that the mpeg stream sometimes seems to be corrupt > which crashess mplayer after some time. > So I did a 'while true; do mplayer...; done' around and set codecs and > other parameters by hand to avoid the autodetection. > Hey, do not scarify this man with timings, theora, omhacks and etc. I can play 640*480 mpeg2 at 12fps, glamo can update 640x480 fullscreen at much higher fps ;) 2 fps is way too low, you should find what is missing. What is resolution? what is codec, can you rstp service send in different format (may be mpeg4 will be faster)? Do you sending sound with your image? Which part of system eats 90% of CPU? Caclulate your rate and find out why it is so slow, find out why it is so slow! Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Using freerunner as webcam display
В Пнд, 06/09/2010 в 12:54 +0200, Patryk Benderz пишет: > I have seen a note on wiki that says: > "The kernel is now (July 2010) configured to use kernel-mode switching > (kms) for glamo. The glamo video driver has no direct control over glamo > anymore and cannot use accelerated video playing until a new driver is > written." > Only shr distribution at this moment using kms-kernel. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[QTmoko] video of QTmoko v26
Hi, list. I did some video of qtmoko v26, if anyone interested how does it look like now, with 2-4-2 settings and some description. http://www.youtube.com/watch?v=KYZzmSicpyk Ignore description, it is intended more developers not familiar with QTmoko, but interested in finding something to hack. I had to cut it down from 15 mins to 8 mins due to youtube restrictions, so it has few glitches. Regards, Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] uSD hosed, on every unstable.
В Срд, 08/09/2010 в 10:17 -0700, jeremy jozwik пишет: > GTA02v6 # mmcinit > Card Type: SD 2.0 SDHC > Manufacturer: 0x02, OEM "TM" > Product name: "SD08G", revision 3.8 > Serial number: 3226732165 > Manufacturing date: 5/2009 > MMC/SD size:3MiB > GTA02v6 # > GTA02v6 # ext2ls mmc 0:1 /OSM > cmd 0x10, arg 0x200 flags 0x15 > Error after cmd: 0xfffb > bad MBR sector signature 0x > > did not copy full output, sorry. > SD initalisation in kernel look strange and fact that we need different rootwait/rootdelay in kernel, while u-boot can read SD card almost instantly seriously puzzles me. Also i can notice fact that I have 50% probability of successfull mmc read in u-boot wuth 2-4-2 timings, while 4-4-4 is 100% successfull, may be only in extremly rare cases. This makes me think that some delay (or proper sync) is needed in mmc sequence. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] uSD hosed, on every unstable.
В Срд, 08/09/2010 в 20:48 +0100, Al Johnson пишет: > On Wednesday 08 September 2010, jeremy jozwik wrote: > > On Wed, Sep 8, 2010 at 9:50 AM, Gennady Kupava wrote: > > > SD initalisation in kernel look strange and fact that we need > > > different rootwait/rootdelay in kernel, while u-boot can read > > > SD card almost instantly seriously puzzles me. > > > > > > Also i can notice fact that I have 50% probability of successfull mmc > > > read in u-boot wuth 2-4-2 timings, while 4-4-4 is 100% successfull, may > > > be only in extremly rare cases. This makes me think that some delay (or > > > proper sync) is needed in mmc sequence. > > > > are you eluding to u-boot accessing the SD card incorrectly? if so, > > how is it that previously locally saved u-boot version used to work. > > and i used to be able to read the SD card within shr. > > I think there are two separate issues here. > > I think Gennady is correct to say there is something wrong in the kernel > handling of mmc on the glamo, and probably also something wrong in u-boot. If > everything was correct we wouldn't need a list of compatible and incompatible > cards, or parameters to fiddle with delays and clock speeds. This may be z > another case where some study of the glamo documentation and the existing > code > can help. I have a 4G Kingston card that's on the non-compatible list if > someone wants to try this. > > I don't think that is the cause of your issue because your cards used to > work, > but don't any more, with software that used to work for you and still does > for > other people. > I can say mean exactly, i know following bugs: 1. u-boot 2-4-2 need fix to read kernel from sd, but kernel works perfect with this timings (never saw single read failure). 2. kernel can't access sd without large delay and this delay is different in different versions. but u-boot can access data instantly! Also, i know following things which is probably bugs: 3. sd card init in kernel look strange. some mess with voltage, some delays. Need investigation. 4. sd card read speed is somehow 7 times slower than for same sd card on host. glamo<->sd bus is 4 bit, same to host as far as i understand. no idea why it should be so much slower. card read speed bottleneck is _not_ cpu<-> glamo bus or glamo<->sd bus. Need more investigation, but entirely possible it is just something wrong with driver/hardware setup. 5. yes. supported and unsupported look strange and i do not believe glamo 'works' with some cards and do not with others. I never saw devices with such selectivity. Need more inverstigation, look like something wrong with hardware or may be glamo setup. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko apt sources.list configuration
В Птн, 10/09/2010 в 16:09 +0200, Alfa21-mobile пишет: > hi > i think it's not a good thing to hardcode the german apt mirror for > the standard configuration in the mass qtmoko distribution: > - almost every user will not configure the sources.list > - it's not always the best choice, eg if you are not in europe > - we could weigh down the .de mirrors (ok, maybe one day everyone in > the world will have a FR with qtmoko ;D ) > > what about apt-spy? > http://www.debianadmin.com/check-debian-archive-mirrors-bandwidth-using-apt-spy.html > > imho we should automatically run it before apt-update in R(apt)or... > what do you think about this? > I think it is not so mass at this moment to cause any problems. But proper solution may be just adding choise to installer. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Contacts lost in QtMoko v26
В Чтв, 09/09/2010 в 13:33 -0700, Brolin Empey пишет: > Rashid wrote: > > Hi guys, > > > > when i updated from v22 to v24 i lost my contacts but they showed up > > sometimes (when i called someone by number which was added before I flashed > > the device). > > New contacts were there. > > > > At the first start after flashing all contacts were there. No are all gone. > > Someone knows a way to fix the problem? > > Have you continued restarting QtEI to see if your contacts reappear? > > Have you used another phone or a SIM card reader to verify your contacts > are still on your SIM? > Yes, i something like this in qtmoko. I have to wait ~30 seconds after entering pin and after that contacts appear in list. Very rarely they do not appear, and i have to restart qtmoko. Also, in some older release (in june i think) i noticed that if i wait too long and pin question visible for may be 15 minutes, contacts always not loaded. To workaround try to delete 1 contact (last) on other phone and see if they reappear. (just guess) Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Boot selection
В Вск, 12/09/2010 в 19:21 +0200, Ed Kapitein пишет: > Is there a way to select where to boot from, nand or uSD? > and i need a software choice, no the obvious boot select with the aux > button, which requires physical access to the freerunner. > > So, given that i have no physical access to the freerunnner, how can i > select where to boot from? > Hi, with u-boot you should change u-boot environment... Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v26
В Втр, 14/09/2010 в 11:08 +0200, Christ van Willegen пишет: > I, too, have experienced QtMoko. The one thing that annoys me, is that > sometimes (well, more often than sometimes...) my FR turns on at > night, and stays on until it wakes me from sleep indicating it's > hungry... My wife doesn't approve :-( > > What could be wrong? hehe ThibG even had QTMoko booted then it were shut down! We found in IRC that this is someone spirit. It comes almost exactly at 2:00. But probably this is just alarm. And +2 seem just default timezone. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
Hi, Nicolaus. I have few ideas about about performance. Major bottleneck of freerunner is amount of memory, so please can you push as much memory to new device as possible. This will make device lightning fast. Second idea is related to memory too, but i am much less sure about it. Can we have some lightning fast sram on device? if bootloader will load kernel code into it - this may bring huge speed benefit. I hope i'll be able to buy successor of FR soon. Gennady. В Чтв, 16/09/2010 в 10:36 +0200, Dr. H. Nikolaus Schaller пишет: > > Am 16.09.2010 um 10:03 schrieb Sylvain Paré: > > > Hi, > > Thanks for these news! > > Some questions: > > Does Openmoko Inc. is involved in this right now ? > > > Not directly. We hope they can become more involved > in the future, e.g. as a distributor for Asia (the project is > run in Europe) or when we really reach mass production. > For development and producing small quantities it is > easier and less expensive to have all people in one place. > > > and which are the next steps between this and a real future GTA04 > > end-user phone? > > > For the hardware, we have to test the PCB and see if it smokes or the > Tux smiles on the screen. Then, we have to get RF certifications > and get components for building more than some samples. > > > It is still a long way to go. > > > Software should be quite less challenging. We have Debian Lenny > running on our demonstrator (i.e. with kernel drivers for display and > touch screen). So distributions like SHR and QtMoko should be > available right from day one (even before?). > > > Nevertheless there are many areas for experimenting with software: > * WLAN, Bluetooth > * use the built in sensors (compass and GPS etc.) > * make the audio subsystem work to allow phone calls > * power management > * etc. > > > > Again thanks for your work! > > BR > > > > Sylvain (aka GarthPS) > > > > > > 2010/9/16 Dr. H. Nikolaus Schaller > > Am 12.08.2010 um 14:12 schrieb RANJAN: > > > > > Hi, > > > > > > When is the next and more powerful openmoko (capable of > > > seamless 3D video and faster processor) is going to be > > > released??? > > > > > > Regards > > > Sriranjan > > > > > > I have good news to announce. We have again made progress > > towards our goals. > > > > > > The first step is that the Openmoko Beagle Hybrid [1] (which > > is our > > experimental and development prototype of such a new > > Openmoko) > > is now working on the BeagleBoard XM [2]. We had to find a > > new > > solution to solder the connectors (since the BB-XM already > > has some). And to do some minor software changes to U-Boot. > > But > > now it works. > > > > > > Here you can find some photos of the assembly process: > > > > > > > > http://projects.goldelico.com/p/ombeagle/page/ConnectToBeagleboardXM/ > > > > > > We now have a 1 GHz ARM Cortex A8 with 3D Video behind > > a Freerunner touch display! > > > > > > > > > > And there is also good news for the GTA04 OMAP/UMTS upgrade > > board. We have finalized the PCB layout and ordered (thanks > > to a > > bigger donation) 10 sample boards and a SMD stencil. They > > will > > arrive in 2-3 weeks. How it could look like is shown here > > (showing > > a 2-layer mockup board and some of the core components): > > > > > > http://download.goldelico.com/gta04/images/DSC00477.jpg > > > > > > Nikolaus > > > > > > > > > > [1]: http://www.handheld-linux.com/wiki.php?page=Openmoko% > > 20Beagle > > http://wiki.openmoko.org/wiki/Openmoko_Beagle_Hybrid > > [2]: http://beagleboard.org/hardware-xM > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
В Чтв, 16/09/2010 в 12:54 +0200, Dr. H. Nikolaus Schaller пишет: > Am 16.09.2010 um 10:05 schrieb Gennady Kupava: > > > Hi, Nicolaus. > > > > I have few ideas about about performance. Major bottleneck of freerunner > > is amount of memory, so please can you push as much memory to new device > > as possible. This will make device lightning fast. Second idea is > > The OMAP uses the Package-on-Package concept so we can install > different memory modules depending on what we want, what is available > and what it costs. There are chips with RAM only and chips with RAM/NAND > flash to choose from. > > But we will have at least 256 MByte (I think there aren't any smaller chips). 512 would be excellent. only possible problem is increased power consumption, but one may disable one chip if he case about consumption too much. > > > related to memory too, but i am much less sure about it. Can we have > > some lightning fast sram on device? if bootloader will load kernel code > > into it - this may bring huge speed benefit. > > The OMAP CPU is much faster and many interface controllers are also improved. 'much faster' is enemy of 'fast', so if it is possible to make something even better, why not. But please consider my last idea with great care - i am not hw deleloper just after learning memory subsystem i understood that such system may bring really big benefits. > And, we know that fast boot is possible. At least someone has done it for the > Beagle Board: > http://swiftbeagle.googlecode.com/files/beagleboard_project_hui_keji.pdf > They claim that they have achieved 3 seconds from power up to login: on > the serial console. Well, running X11 also needs some time. From my point of view, boot time especially if it is in 1 minute is not really important. More important how fast it will run while usual usage, how easy is boot system to understand and fix, and how much it deviates from desktop systems. I do not want use busybox shell under any conditions, but running all that services to boot up fully-functional system will take much more time than 3 seconds. (authors use uclibc and busybox, hack init scripts like disable log, disable u-boot menu, disable logs, remove everything from kernel) The way authors of paper archive such boot times influence later speed of device. For example, they propose to use XIP, which will cetrainly decrease kernel speed. Other example is that they 'compiling everything with -Os', it may greatly decrease performance in favor of boot time. PS. please notice your mailer producing doublicating mails (see http://lists.openmoko.org/pipermail/community/2010-September/date.html ) Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v26
Hi, Ori, > * GPS doesn't work. The longest I left it running to try and get lock > was 20 minutes - no luck with that. What should I look at? So far FPS worked in 100% of cases if you'll follow this procedure" 1. start nerongps. 2. cache maps 3. close nerogps 4. go to street (really) 5. start nerongps. 6. wait for 5(!) minutes (usually only 1-2minutes needed) 7. it should work. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
В Чтв, 16/09/2010 в 17:23 +0100, Al Johnson пишет: > kdbus is proof-of-concept at the moment, the idea being to reduce the number > of context switches needed for each dbus message. One synthetic benchmark > shows a 3x speed increase on the n900 but speedup in real world applications > seems much more modest. > > http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/ Oh, no! Linux kernel with analogue of windows messaging subsystem, but implemented in slower way... why not use Windows instead? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v26
В Чтв, 16/09/2010 в 10:52 -0600, Ori Pessach пишет: > Seriously? I think you and I might have different ideas about what > "works" mean. :) Seriously? Even my Garmin can't get fix indoors. Have you tried other devices? GPS is FR is not best one, but it is open for fixes. on qtmoko it is not less or more functional than in other distros. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v26
В Чтв, 16/09/2010 в 11:51 -0600, Ori Pessach пишет: > I don't think I explained myself very clearly. I don't expect the GPS > to get a fix indoors - only to get a fix outdoors without also being > indoors so it can pick up a WiFi signal which is required in my case > to go through the rest of the steps you listed. (caching the maps - is > this really necessary for getting a fix?) To get first fix, _stay at one position_ outdoor for a while (try 5 minutes, but you should get it 1-2 minutes). After you'll get a fix, it will work without problems. If not, try restart your nerongps. To debug, open GPS serial port in terminal but i don't know details. And yes, really i just told you to download map before going outdoor :) Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v26
В Чтв, 16/09/2010 в 11:51 -0600, Ori Pessach пишет: > (caching the maps - is this really necessary for getting a fix?) Of course not, just it is not fun to watch empty nerongps screen. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
> Regarding memory we currently plan to use this memory chip: > > http://www.micron.com/products/ProductDetails.html?product=products/mcp/multichip_packages/MT29C4G48MAZAPAKQ-5+IT > 2Gb @ 166MHz - nice! Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Testing freerunner's audio quality
Hi, list, Many gossips flying around about bad fr's audio subsystem quality. I promised to proove that FR audio subsystem is good, just default headphones quality below anything. As today finally i overcome my lazyness and soldered 2.5mm->3.5mm jack, and i am almost content with high sound quality of my Sennheiser CX300 II+FR, i decided to do some basic testing. Test environment I got 2 recodings - 60 seconds of white noise and 120 seconds of piano +voice, audacity to do spectrum analisys, cable 3,5mm<->3,5mm to connect my old m-audio revolution 7.1 card to line-in to freerunner. White noise === 1. White noise were generated by audacity original file: http://www.bsdmn.com/openmoko/audioquality/white.wav Spectrum: http://www.bsdmn.com/openmoko/audioquality/whitenoise.png 2. Same noise recorded then audio-out were connected to audio-in of sound card: http://www.bsdmn.com/openmoko/audioquality/rec_white_directcable.wav Spectrum: http://www.bsdmn.com/openmoko/audioquality/whitenoise_direct.png 3. Same noise played on FR, connected to line-in of sound card: http://www.bsdmn.com/openmoko/audioquality/rec_white_fromfrerunner.wav Spectrum: http://www.bsdmn.com/openmoko/audioquality/whitenoise_fr.png Conclusion on white noise: I see no frequency cut-offs. spectrograms look very well and close to original file. Only exception is fall below 20Hz in fr case, but i am unsure if any headset can reproduce such frequences very well. Real song = 1. Original piece of song (piano+voice): http://www.bsdmn.com/openmoko/audioquality/song.wav Spectrum: http://www.bsdmn.com/openmoko/audioquality/song.png 2. Same file played on freerunner and captured on line-in of sound card http://www.bsdmn.com/openmoko/audioquality/rec_song_fromfr.wav Spectrum: http://www.bsdmn.com/openmoko/audioquality/song_fromfr.png Conclusion on piano+voice: I can't distingush difference in quality while replaying original file or file recorded from freerunner. Spectrum show almost no difference. Overall conclusion == Seem audio quality completely depends on quality of headphones. You may try to distiguish original song and song from fr youself, only do not forget to normalize volume before attempting to do this. regards, Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v26 battery life
В Чтв, 23/09/2010 в 17:54 +0200, Tony Berth пишет: > when pressing the on/off button once and setting to suspend, the > battery doesn't last more than 8h! Is that supposed to be like > this? > Hi, Tony. No, 8h is far from being normal. Be sure your phone is actually suspended. #2349 should affect only .32 and .34 kernels. Does your phone have #1024 fix? If yes, check that in NEOTool you turned on deep sleep. Try to turn on/off all devices like GPS, bluetooth and wifi. Which bootloader you using? If u-boot, try qi. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing freerunner's audio quality
В Чтв, 23/09/2010 в 06:47 +0200, Dr. H. Nikolaus Schaller пишет: > Hi, > the problem is the bass. Initially, It was difficult to hear differences > by playing two sounds one after the other. So until you have listened > music on a bass fixed Freerunner, you would say it is quite ok. > > I was only able to hear the difference after taking one original Freerunner > and one with Bass-Fix applied. After a while you get that there *is* a > difference in low frequencies. > > What I have done is this test: create a sinus sweeping from 10 to 100 hz. > Without bass fix you can't hear it before it comes to the 50 hz range. > > sox -n -t wav - synth 10 sine 10-100 >file.wav > > This can be seen on scope outputs as shown here: > > http://freeyourphone.de/portal_v1/viewtopic.php?f=20&t=1723&p=17279&hilit=bass+fix#p17251 > > Can you please compare you device? > > One effect may also be the input impedance of your line card. Did you connect > it in parallel to a headset? > > BR, > Nikolaus > Yeah, big sorry - my freerunner has bass-fix made by Paul (many many thanks to Paul). I wanted but seem just forgot to mention it in my letter, as it took much longer than i expected and i had to finish it a bit in hurry. Re-thinking about it today, i found also few other flaws - white noise is actually 10 seconds and white noice spectrum is really about little bit different time interval for each sample. I had to cut white noise samples to right offset and right lenght to compare them in right way. But main test is perfectly correct - song output is of high quality. But anyway, about your oscillograms (google translate is nice thing!) - it seems that in unfixed case, you have 2 times voltage diff between 40hz and 100hz, this means 3dB. Yes, this will affect sound below 100Hz, but this influence will be less than effect from earpieces. Btw, Wolfson has bass controls. interesting is it possible to compensate bass-problem with it. Or is it possible to get frequency response and feed to some alsa-plugin equaliser to correct it. Common earpieces frequency response: http://www.thg.ru/video/cheap_headphones_2007/images/sennheiser_cx300_1.png You can see that it should influence sound quality much more than FR audio subsystem. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
Hi, Radek. > I have been testing 2.6.34 kernel for one week now and to me it looks ok. > There can be issues with SD card [6], > [6] http://www.shr-project.org/trac/ticket/1143 About this issue: here, recompiling shr-2.6.32 kernel, i can reproduce problems with sd-card. For example i have to recheck my xfs filesystem after _each_ time i mount it with shr's kernel. Contrary to this, my .34 which is very close to your version, never had any problems with sd card - boot from sd, mounting my xfses, suspending and powering down/up cycle is perfectly ok for last several months (from point of view of sd card). My wild guess that SHR's sd-card problems somehow related to kms changes. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: dbus moving into kernel?
В Птн, 24/09/2010 в 15:11 +0200, Marco Trevisan (Treviño) пишет: > Some days ago I've tried to port this patch to the Openmoko kernel, > after applying it to the SHR 2.6.32 kernel (patches at [1]), I got > these results (in average): > > dbus-ping-pong test: > Ping dbus-daemon (s) kdbus (s) speedup > 500 ping 3.332.1336.2% > 5000 ping 32.59 26.09 19.9% > 5 ping313.56 176.35 43.8% > > > Adrien Bustany’s ipc-performances tool with 6 random 10 char > strings: > > dbus-daemon query (s) kdbus query (s) speedup > 102.7574.71 27.29% > Interesting, how adding FCSE will influence this dbus test? Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v27
В Сбт, 25/09/2010 в 21:38 +0200, Alex Samorukov пишет: > 2) Syslogd replacement with debian`s busybox. Its already works for me, > i will try to send patches tomorrow. Why? Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fifteen pieces...
В Пнд, 27/09/2010 в 22:38 +0200, Radek Polak пишет: > urodelo wrote: > > > Well, not a big problem... > > After installing qtmoko v26, I've noted that the game fifteen pieces > > doesn't work anymore. I simply can't move the tiles. Mixing tiles from > > menu works. Resetting the game works too. > > I think it's because of touchscreen jitter which this game does not like. But > if you try touching it should be possible to play - at i least i was able to > do it. Wait, v26? jitter? Or, if you speaking about v27, > > I believe that the jitter will be possible to solve - either in userspace or > maybe backporting touchscreen filters. Or use my working idea to get jitterless input without filtering ;) Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] log of in/out SMS and calls
В Втр, 28/09/2010 в 14:42 +0200, Matthias Apitz пишет: > El día Tuesday, September 28, 2010 a las 02:15:26PM +0200, Patryk Benderz > escribió: > > Here is what I use of this brick: From what only I know, since 2009, graphic subsystem got x2 speedup (or x1.5 without 2-4-2), lost ability to WSOD on rotation, and overall system response increased greatly due to removing debugging and all major distros. Try some recent distro, like qtmoko v26 and you'll debrick you device. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sandisk 16GB SDHC not mountable
Hi, Christian, В Вск, 03/10/2010 в 13:11 +0200, Christian Rüb пишет: > [ 244.995000] mmcblk0: error -110 sending read/write command, response 0x0, > card status 0x400b00 > [ 244.995000] end_request: I/O error, dev mmcblk0, sector 170 > [ 245.01] glamo-mci glamo-mci.0: Error after cmd: 0x8120 You can try to add something like glamo_mci.sd_max_clk=1500 to you kernel options. Try different values until your card will start working. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sandisk 16GB SDHC not mountable
В Вск, 03/10/2010 в 14:38 +0200, Christian Rüb пишет: > > > [ 244.995000] mmcblk0: error -110 sending read/write command, response > > > 0x0, card status 0x400b00 > > > [ 244.995000] end_request: I/O error, dev mmcblk0, sector 170 > > > [ 245.01] glamo-mci glamo-mci.0: Error after cmd: 0x8120 > > > > You can try to add something like glamo_mci.sd_max_clk=1500 to you > > kernel options. Try different values until your card will start working. > > Tried these and also showing results: > 1500 -> partition skipped (led + vib) > 500 -> red led forever > 16373000 -> red led forever Strange. Are you booting from usd or NAND? if from nand how can it hang? Would be interesting to see kernel logs. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sandisk 16GB SDHC not mountable
Hi, Jeremy, В Вск, 03/10/2010 в 08:18 -0700, jeremy jozwik пишет: > On Sun, Oct 3, 2010 at 5:11 AM, Gennady Kupava wrote: > > Strange. Are you booting from usd or NAND? if from nand how can it > > hang? > > > > Would be interesting to see kernel logs. > > and so begins the might fall of the freerunner sd card reader... I think possible something just terrible wrong in kernel driver. From my point of view it is worth to investigate, may be we can get x4 uSD speedup. > life i bitter without one... Every thing has it's proper usage. FR is for learn, hack and experiments. Life depends on how you look to it ;) Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community Digest, Vol 204, Issue 8
Hey, Paul, disagree with your idea about impossibility of commercial success of opensource device. Declaimer: all things below is just my opinion, which is formed mostly by reading community ml from time to time in past. It would be interesting to read where and why i am wrong. :) В Срд, 06/10/2010 в 22:31 +0400, Paul Fertser пишет: > openm...@pulster.de (Christoph Pulster) writes: > > an intelligent marketing idea. My idea on the later is, to point the > > finger in the Apple direction and naming the evil by name. It already has at least 1 good idea, no other smartphones have - OS and hardware separation. > On a related note, i think there's no commercial future with such a > device. > Openmoko proved that. Sorry, but openmoko proved only that it is really possible to make open phone. > Too few interested people, really too few. Now imagine, linus tovalds wrote linux initially... alone. yeah. it wrote it while big DOSes, Solarises, BSDs, MacOSes, mimixes, already existed and were fully functional. Yeah, OS he did lack of all features, had no chances to compete with that big giants, it were complete crap. Were this 'too much people'? > Despite Freerunner still being the only one. Bwware, big portion of critics below: Why freerunner commercially failed (is it truth at all btw?), my version: 1. People got scarified with tons of grave software bugs (WSOD, partition table corruption, sd card speed, graphical subsystem speed, overall FR speed, events/0, debug kernel, that just _i_ know). All this were fixable, What would happen if all this were fixed in a week after FR release? 2. People scarified by core openmoko's own _developers_ who declare various subsystems are 'outdated' (CPU) or 'wrong' (glamo), and did nice PR. And all this were not really true. HW is good enought to do many things. 3. Community managment may be much better. I am usure if openmoko had dedicated guy to spend all time managing community. I saw some mails from people who offer help, unanswered. Yes, may be some offers were funny, may be 50% of that people will do nothing, but other 50% may easily build excellent community and greatly help project. I guess this is main cause of 'few people'. 4. Team were too small to handle such huge innovative project as freerunner (completely new software stack, adapt linux from almost 0 to be usable on such multifunctional device) from almost 0 to commercial success in reasonable time. One man did qt/x11. Other man did whole kernel and bootloader. One more man did testing. Yeahhh. One more whole graphical subsystem. 5. Tons of hardware bugs on initial release. And knowing that all them were fixed... just proves that it were possible to fix that faster, with bigger team. 6. Openmoko's team fixed problems is complete weird way. They did one interface, found it has some problems and instead of fixing problems they used qt interface, then instead of fixing problems of qt they switched to fso&e17, which i bet, still has problems on it's own. Instead of careful calculation why their device is slow and how fast it should be, then solved boot speed problem with disabling logs. Instead of fixing grave issues they draw fancy boot pictures. Instead of fixing u-boot Qi were implemented. (just things _i_ noticed) 7. Raster need special mentioning. Being smart and very professional man, he thought only about his own project, refusing to optimize latest interface for FR, injecting myths about hw slowness (320x200, 16 bit graphics, glamo bus speed, etc) and injecting that myths in _smart way_. This scarified poor community even more. All this bad PR were magnified greatly by openess of project (_magnified_), open ML, open communications. So, as you can see, not much in this list is related to word 'open' or open source at all. And problems with community size are not related to word 'open', i can say all this sounds more as problem of small team attempting to do huge thing in commercial way. And, as a conclusion - as it's possible to evade most of problems in list, and do not create others: all depends on people who making project, and bit of luck, and i think, it's perfectly possible to do nice opensource device. One may disagree and say that direct communication between developers and customers created varous problems like (2) (man say something in public, then should stand to death on his position), but this is only small part of question and depends on personalities. This mail look like hardcore rant to openmoko and FR, but in fact i think that people did great job - now several opensource stacks exist and very open phone exist, and community exist. This is great and very hacky :) > I'd tend to agree > with Raster who says "Let's get an open enough consumer device that > can be sold to the masses and hack on it". Keyword is 'sold to masses'. All other words are not important, you may rephrase Raster's idea "Let's do ... device that can be sold to the masses ... ". I bet such device wil
Re: qtmoko v28
В Срд, 20/10/2010 в 14:20 +0200, Radek Polak пишет: > On Wednesday 20 October 2010 12:52:05 giacomo 'giotti' mariani wrote: > > > Thank you very much! > > This new version looks very cool, but I have a small problem: I'd like > > to keep using uboot (gena2x one). > > Is there some way to boot ubifs with it? > > You would need patch or change u-boot environment like this commit [1]. Or i > can do also jffs2 image, but i would like to avoid it, since it's more work > and > testing. > > Regards > > Radek > > http://github.com/radekp/qi/commit/0c2d3c3e35c9edb7d1de00b5fcb739bf02afc582 > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community Hi, Radek. Thanks for new release! Always wanted to test ubifs, so joining experimental branch to test this. Just installed it, working well so far. - rootfstype=jffs2 root=/dev/mtdblock6 + fstype=ubifs ubi.mtd=6,2048 root=ubi0:om-gta02-rootfs U-boot environment change above is working well. Regards, Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v28
В Чтв, 21/10/2010 в 20:57 +0200, David Garabana Barro пишет: > Gennady > > Is your "242-glamo-timings uboot" ubifs capable? > > I cannot boot qtmoko v28 with it, even after changing bootargs... > Hi, David. Sure, it works ok here. Basically, u-boot's job on nand is only load kernel from fsless partition, transfer boot params to it, and execute kernel, so it is completely indefferent to kind of fs you have. glamo timings has no relation to NAND at all too. Recheck your env params and you downloaded everything in right way (kernel, u-boot env). My updated u-boot env (xfs on sd card): Source: http://www.bsdmn.com/openmoko/glamo/242/ubienv/environment.in Binary: http://www.bsdmn.com/openmoko/glamo/242/ubienv/u-boot_env.in3 Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v28
Hi, Ed, Ah, yesterday i were thinking 'interesting, where is my NAND/jffs2 option?' but forgot about it today :) Sure, typo. Updated. But beware, you should consider my env only as example - it boots sd card by default, limits sd clock to values appropriate to my card. Gennady В Чтв, 21/10/2010 в 21:37 +0200, Ed Kapitein пишет: > Hi Grennady, > > I notice two times "menu_1=" , is that intenional or just a typo? > Kind regards, > Ed > > On 10/21/2010 08:21 PM, Gennady Kupava wrote: > > В Чтв, 21/10/2010 в 20:57 +0200, David Garabana Barro пишет: > > > >> Gennady > >> > >> Is your "242-glamo-timings uboot" ubifs capable? > >> > >> I cannot boot qtmoko v28 with it, even after changing bootargs... > >> > > Hi, David. > > > > Sure, it works ok here. Basically, u-boot's job on nand is only load > > kernel from fsless partition, transfer boot params to it, and execute > > kernel, so it is completely indefferent to kind of fs you have. glamo > > timings has no relation to NAND at all too. > > > > Recheck your env params and you downloaded everything in right way > > (kernel, u-boot env). My updated u-boot env (xfs on sd card): > > > > Source: http://www.bsdmn.com/openmoko/glamo/242/ubienv/environment.in > > Binary: http://www.bsdmn.com/openmoko/glamo/242/ubienv/u-boot_env.in3 > > > > Gennady > > > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
В Птн, 22/10/2010 в 05:36 -0700, RANJAN пишет: > Hello, > > Recommendations for better hardware on Openmoko. > > 1)A 600 Mhz processor is minimally required to run the OS at usable > speeds.An 800 Mhz processor would be good across all OSes.A 1Ghz > processor would be too costly Hi, Ranjan. I just want to say that memory subsystem speed is much more important for speed than cpu speed. While testing freerunner, i've found that performance of system primitives of 500/83 CPU is similar to 400/100. So, really it is much more important to have fast memory subsystem. So, for example, 600/100 will be really not so far from to freerunner's at 440/110. Memory subsystem speed become extremly important if CPU lack of L2 cache. What is cache(s) size(s) of GTA04's CPU? Regards, Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qmoko v28 with jitterless kernel
В Птн, 22/10/2010 в 22:45 +0100, giacomo mariani пишет: ... > But, yes there is a but, I can't ssh to the mobile. > Looking, in qterminal, at the output of ifconfig everything looks as usual, > but demsg givs some strange error when the USB cable is attached: > g_ether gadget: full speed config #2: RNDIS > is followed by a groing (maybe one per second) list of > s3c24xx-ts s2c2440-ts: stylus_irq: count=1 Interesting problem! First of all, both kernels work ok here in ssh and touchscreen aspects. So, few questions to handle this: 1. Have you tried 2 kernels - with jitterless patch and without one and found that jitterless one has not working usb ethernet and in other one usb ethernet is working? 2. jitterless patch has no relation to ethernet and has no way to activate expect touching touchscreen. 3. the "s3c24xx-ts s2c2440-ts: stylus_irq: count=1" means just that we recieved expected touchsreen release event (ie you releasing you finger from ts). Is this message appears without touching touchscreen? if yes, this is very interesting. just debug message, It would be normal to just remove it, but it's quite rare (once per release-touch), so nobody just bothered to remove it. Some problems with TS not really impossible, I got some strange unexpected interrupts before. But despite of handling consequences of such interrupts, causes are still unclean. Would be good to see full kernel log also. > g_ether gadget: full speed config #2: RNDIS 4. RNDIS is something related to windows network. Can you try to connect FR to linux box? Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qmoko v28 with jitterless kernel
В Вск, 24/10/2010 в 18:46 +0100, giacomo mariani пишет: > > > But, yes there is a but, I can't ssh to the mobile. > > > Looking, in qterminal, at the output of ifconfig > > everything looks as usual, but demsg givs some strange error > > when the USB cable is attached: > > > g_ether gadget: full speed config #2: RNDIS > > > is followed by a groing (maybe one per second) list of > > > > > s3c24xx-ts s2c2440-ts: stylus_irq: count=1 > > > > Interesting problem! > > > > First of all, both kernels work ok here in ssh and > > touchscreen aspects. > > > > So, few questions to handle this: > > > > 1. Have you tried 2 kernels - with jitterless patch and > > without one and > > found that jitterless one has not working usb ethernet and > > in other one > > usb ethernet is working? > > > I've only tried the patched one... Ah, ok. I thought it is about problems specific to jitterless kernel because of subject :) > > > 2. jitterless patch has no relation to ethernet and has no > > way to > > activate expect touching touchscreen. > > > I trust you :-) > > > 3. the "s3c24xx-ts s2c2440-ts: stylus_irq: count=1" means > > just that we > > recieved expected touchsreen release event (ie you > > releasing you finger > > from ts). Is this message appears without touching > > touchscreen? > You are completely right, it appears only if I touch the screen but yesterday > I didn't argued it :-( So, forget about touchscreen and jitter, both ts and are ok (i just started thinking so because of 'one per second'). > > > if yes, this is very interesting. just debug message, It would be > > normal to just > > remove it, but it's quite rare (once per release-touch), so > > nobody just > > bothered to remove it. > > > I've a loglevel=4 variable in uboot-env, may I set it to 0? Normally this should be changed in kernel code. > > > Some problems with TS not really impossible, I got some > > strange > > unexpected interrupts before. But despite of handling > > consequences of > > such interrupts, causes are still unclean. > > > > Would be good to see full kernel log also. > > > It's quite difficult with no connection... will try with wi-fi as soon as I > can. No need, as your problem not related to touchscreen. > > > > g_ether gadget: full speed config #2: RNDIS > > > > 4. RNDIS is something related to windows network. Can you > > try to connect > > FR to linux box? > > > I use freebsd (tried 6.x and 8.x). I will try linux as soon as I can. Probably this may help to identify problem. Regrads, Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: backup battery and case screws questions
В Пнд, 25/10/2010 в 11:14 -0400, Benjamin Deering пишет: > It looks like I will be following your advice. The hazmat shipping for > the lithium batteries was going to be 175% of the price. I just ordered > some supercaps instead. > > Ben > > On 10/24/2010 12:51 PM, Martix wrote: > > I suggest using double-layer super capacitor* intead of Lithium backup > > battery. These capacitors stores energy for a long time, like a > > battery and they have much longer lifetime. 0,2 F capacity should be > > enough for RTC backup on several hours, maybe days. > > > > * > > http://cz.farnell.com/jsp/search/browse.jsp?N=1002210+5117013+5087727+5400445&No=0&getResults=true&appliedparametrics=true&locale=cs_CZ&catalogId=&prevNValues=1002210+5117013&filtersHidden=false&appliedHidden=false&originalQueryURL=%2Fjsp%2Fsearch%2Fbrowse.jsp%3FN%3D1002210%26No%3D0%26getResults%3Dtrue%26appliedparametrics%3Dtrue%26locale%3Dcs_CZ%26catalogId%3D%26prevNValues%3D1002210 > > I noticed in PCF manual: "Save" [about power states] In save state is supplied from either system voltage ... or backup battery ... . Only ... and real-time click will be active. __The GPIOs will maintain their state__ . Can 'maintaining GPIO state' be cause of our poor backup battery performance? Please, do not forget to share results. I'm not hw engineer guy, but read about this capacitors and they sound exactly what's needed! Personally i desoldered backup battery long ago (easy btw), found it is dead and still can't find any replacement. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v28
В Втр, 26/10/2010 в 17:06 +0200, Patryk Benderz пишет: > [cut] > > Yes, the package in debian lenny has stupid dependencies on python and i > > wanted to avoid it, so i am installing slighlty modified alsa-utils with > > dpkg > > to avoid this dependency. > damn... I have a habit to upgrade everything just after installation... > well, I assume I can live with that alsa-utils version? > Anyway nowhere to upgrade, anyway qtmoko based on stable debian. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] Strange display on v28 with jitterless kernel
В Чтв, 28/10/2010 в 12:35 +0200, Vinzenz Hersche пишет: > Hello all, > > i've got a strange problem which is descriped here: http://death- > head.ch/blog/2010/10/strange-effects-on-my-openmoko-display-with-qtmoko-v28- > and-jitterless-kernel/ (with video) Hm, this should not happen. This is just slow refresh, which means that glamo remain in slowed down state. But problem seem that you touchscreen somehow hang, so ts driver can't restore normal refresh rate. Hm, this may happen if suspend happens while you holding touchscreen. Let me try YES. So. Ops, qtmoko has not xrandr. > The problem seems to came up randomly. So, did you suspend just before this issue? I know how to fix suspend and rotation and will prepare patch soon. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] Strange display on v28 with jitterless kernel
В Чтв, 28/10/2010 в 21:19 +0400, Gennady Kupava пишет: > В Чтв, 28/10/2010 в 12:35 +0200, Vinzenz Hersche пишет: > > Hello all, > > > > i've got a strange problem which is descriped here: http://death- > > head.ch/blog/2010/10/strange-effects-on-my-openmoko-display-with-qtmoko-v28- > > and-jitterless-kernel/ (with video) > > Hm, this should not happen. > > This is just slow refresh, which means that glamo remain in slowed down > state. But problem seem that you touchscreen somehow hang, so ts driver > can't restore normal refresh rate. > > Hm, this may happen if suspend happens while you holding touchscreen. > Let me try YES. So. Ops, qtmoko has not xrandr. > > > The problem seems to came up randomly. > > So, did you suspend just before this issue? > > I know how to fix suspend and rotation and will prepare patch soon. > > Gennady > Hm, this seem more general problem with ts driver, not really related to jitterless patch - if you suspend while holding ts, ts driver seem hang. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: qtmoko lagging after 2nd boot - was: qtmoko v28
В Срд, 27/10/2010 в 23:48 +0200, Ugo Raffaele Piemontese пишет: > Thank you everyone for your tips! > > Here you are some logs taken via ssh during a slowdown: > > 1 (see attachments) - dmesg output > 2 (see attachments) - interrupts output (only s3c24xx-adc is growing fast) > - time frame between them: 1 second > 3 - top screenshot: http://img168.imageshack.us/img168/2848/topmt.png > top, and interrupts seem fine. s3c24xx-adc count is ok too. I don't know what's this: [ 210.165000] AR6000 disconnected [ 220.17] AR6000 disconnected [ 230.165000] AR6000 disconnected May be it is ok, but why not to try to disable wifi and check if problem remain? Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Wikipedia
В Птн, 29/10/2010 в 11:59 +0100, Al Johnson пишет: > > I also wonder if it's the first commercial phone(or not) that permitted > > the installation of native applications(I wonder if the app store for > > the iphone came before or after the openmoko) > > It missed that one by a long way. WinCE/WinMo handsets had native > applications > from the start. They were possible with Symbian too, but less common. > I don't know about WinCE/WinMo, but once somewhere in 2006 i tried to build small app for my former Symbian phone... Ok, using gcc.exe and make.exe on Linux is special fun. But it turned out that you can use full abilities of your device until you get developer sertificate and/or sign your application. This is done to protect users from malware, but in the end seem you just can't just write big set of apps for your phone. So, vendor controlled which application you can install and which can't. In case of uncontrolled environment you'll just be able to copy commecial apps from root to other phone. Here is example how to 'sign' app for particular phone: http://www.gosymbian.com/forum/viewtopic.php?t=757 http://www.simplysymbian.com/2007/12/18/how-to-symbian-sign-your-freeware-applications-so-you-can-install-stuff-like-rotateme/ My expierence with Symbian were one of reasons to buy Freerunner. Here i can run and compile anything without any troubles. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] Strange display on v28 with jitterless kernel
Hi, Vinzenz, Ok, i updated jitterless patch, now it should handle rotation/qvga properly and also fix this issue. Can you please check if following kernel really fixes issue: http://bsdmn.com/openmoko/jitterless/modules-b2.tar.gz http://bsdmn.com/openmoko/jitterless/uImage-b2.bin To test, 0.boot qtmoko 1.copy modules to / on FR 2.on neo - cd /;tar xzvf modules-b2.tar.gz 3.depmod -a 2.6.34b2-v28 4.poweroff 5.boot to u-boot 6.do dfu-util -a kernel -D uImage-b2.bin 7.check it This kernel is from v29, with only change is ts issue, so you may stick to it afterwards and help testing HZ100 kernel. It works well here so far, but who knows. Gennady В Птн, 29/10/2010 в 10:43 +0200, Vinzenz Hersche пишет: > Mh, i'm not able to suspend my openmoko while use the ts. But if i do the > suspend-action and "use" the ts while it's go to suspend, this effect cames, > you're right :) > > Yes, it was always after wake up from suspend. But i didn't know that the > using of ts while suspending do this effect, so it was a random thing for me. > > Because of the jitterless-kernel: i just write this because i just used my > openmoko since v28 with this kernel. It's nice if this isn't the problem.. > > Many thanks for the patch! :) > --- > Gennady schrieb am Donnerstag 28 Oktober 2010: > В Чтв, 28/10/2010 в 12:35 +0200, Vinzenz Hersche пишет: > > Hello all, > > > > i've got a strange problem which is descriped here: http://death- > > head.ch/blog/2010/10/strange-effects-on-my-openmoko-display-with-qtmoko-v28- > > and-jitterless-kernel/ (with video) > > Hm, this should not happen. > > This is just slow refresh, which means that glamo remain in slowed down > state. But problem seem that you touchscreen somehow hang, so ts driver > can't restore normal refresh rate. > > Hm, this may happen if suspend happens while you holding touchscreen. > Let me try YES. So. Ops, qtmoko has not xrandr. > > > The problem seems to came up randomly. > > So, did you suspend just before this issue? > > I know how to fix suspend and rotation and will prepare patch soon. > > Gennady > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Android] Froyo (Android 2.2) on Freerunner????
With usual linux, i can say 'do profiling, find out what is really so slow and optimize critical places'. And I know what tools to use to each task. But with android... Same, but how to profile? how to compile? how to communicate, etc. Gennady. В Вск, 07/11/2010 в 20:15 +0100, Atilla Filiz пишет: > My gf runs Froyo on her Geeksphone. It has definitely more powerful > hardware than FR but it is defeinitely /not/ 1GHz. It is around > ~500MHz, and no 3d acceleration because the hardware vendor refused to > deploy 3d firmware in an open device. > > On Fri, Sep 3, 2010 at 5:59 PM, Serdar Dere > wrote: > Who asked my images are not real?? ;) > > The problem is, that Froyo ARMv5 optimized but not for ARMv4, > that makes > it hard for us. > The other problem is, that Jim Ancona is our only developer. > We are looking for developers. Everybody is welcomed to help > (contribute, test etc.) > > MfG Serdar > > Am 03.09.10 11:12, schrieb Steven Le Roux: > > > On Fri, Sep 3, 2010 at 12:48 AM, Leonty > Belskiy wrote: > >> Is'n Froyo supposed to be super-fast? > > It's fast on a 1GHz processor with at least 512MB RAM and > hardware > > acceleration of OpenGL, etc... > > > > V8 is embedded, but if you can't even run webkit... ;) > > > > > >> I it faster than Cupcake? > > It's relative to the device. If a device have capabilities > to run > > froyo, so yes it will be faster. But froyo won't run on the > most > > lightweigh devices. And android 3 will run on devices with > at least > > 2Ghz processor, etc... > > > > > >> -- > >> Leonty > >> > >> On Wed, Sep 1, 2010 at 5:55 PM, Thomas > HOCEDEZ wrote: > >>> Le 01/09/2010 14:31, Atilla Filiz a écrit : > >>> > >>> AFAIK Serdar Dere is actively developing Android for FR, > so I am sure the > >>> images are real. How (close to being)usable they are, that > is to wonder. > >>> > >>> On Thu, Aug 5, 2010 at 5:06 PM, David Garabana > Barro > >>> wrote: > On Thursday 05 August 2010 16:52:24 Jan Girlich wrote: > > Am Donnerstag, den 05.08.2010, 16:42 +0200 schrieb David > Garabana Barro: > >> http://serdar-dere.net/~serdar/daily/ > >> > >> Are these images real? > >> > >> Are there Android 2.2 images for Freeruner? > > I doubt these images are of any use (yet). Look at the > filesizes. > > They're just about 7MB, way too small for a real image. > Yes, but first one size is 67 MB. > > On the thread Nelson posted minutes ago, you can see they > are real, but > they > only compile and boot. Not useful by the moment > :) > > > >>> Hi ! > >>> > >>> Of course the images are real (those> 7Mo!). I flashed my > FR with it, it > >>> boots, starts, and ... Worked ! Ok you have to be Really > patient because of > >>> the slowlyness of the interface, but everything works ! > >>> -- > >>> > >>> Thomas HOCEDEZ / Asthro, Openmoko-fr.org > >>> > >>> ___ > >>> Openmoko community mailing list > >>> community@lists.openmoko.org > >>> http://lists.openmoko.org/mailman/listinfo/community > >>> > >>> > >> ___ > >> Openmoko community mailing list > >> community@lists.openmoko.org > >> http://lists.openmoko.org/mailman/listinfo/community > >> > > > > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > > > > -- > - > Atilla Filiz > Eindhoven University of Technology > Embedded Systems, Master's Programme > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Backup "batteries" installed
Hi, Benjamin and list Yesterday i followed suggestion about capacitors and installed them. Huge thanks for suggestion - one big annoyance fixed for me too! Now my time is kept while i am replacing battery without any troubles, for far i tested only few minutes of life without battery. I did some measurements, that according to our pcf setup (qtmoko v28, uboot), charge current is 200uA. According to my measurements with multimeter capacitor were fully charged after 6 minutes. Also it may be useful to note that self-discharge of capacitor is much higher than li-ion battery and actually it is chaged only than our PMU is in Active state (FR turned on or suspended). So it may discharge if it were laying for a while _with_ main battery installed and then main battery removed without turning on device. I think also my story of finding capacitors may be helpful. Given that digikey delivery for my country costs $120, i tryed some nearby shops and internet in attempt to find this part without any luck. But it turned out (from forums) that such capacitors are common in other phones (like N70 and btw common reason to problems). So, i finally just walk to nearby mobile repair service on nearby cheapest marketplace and bought 2 used capacitors from broken phones for $3. I left with feeling i payed too much :) Soldering were not really easy especially that after reading docs i understood that part should be heated with extreme care, but i followed suggestions, put it upside-down and cut some outputs. Thanks and regards, Gennady. В Чтв, 04/11/2010 в 21:23 -0400, Benjamin Deering пишет: > I have had the capacitors installed for a few days now and they are > still working well. I left the FR with a dead battery overnight and > when I plugged it in in the following day, it had the correct time. > > The digikey part number is: 728-1037-1-ND and the manufacturer's number > (seiko) is: XH414H-II06E. I would recommend looking around on the site > to see if you can find one with the correct bracket. > > Ben > > On 10/30/2010 03:03 AM, Dr. H. Nikolaus Schaller wrote: > > Am 29.10.2010 um 19:05 schrieb Benjamin Deering: > > > > > >> Hello, > >> > >> I finished installing capacitors as replacements for the dead backup > >> batteries in my Freerunners today at lunch. They seem to be working, > >> though I've only tried removing the main battery for under a minute so > >> far. Someone on the GTA-02-core list said a 220uf capacitor would power > >> the RTC for 2 minutes. If that is correct, the .07f caps I used should > >> work for about 10 hours. > >> > > Please report some test results. > > > > > >> The parts I got from digikey weren't an exact fit, but I was able to > >> make them work. > >> > > Looks interesting. Do you have the exact order num...@digikey? > > > > > >> Be sure to wear safety glasses if you try this, I had one of the old > >> batteries explode when I was removing it. > >> > > Oops! So it was not really dead an had enough energy inside. Maybe, > > just the voltage was too low to run the RTC? > > > > > >> Pictures: http://jeepingben.homelinux.net/index.php?level=album&id=20 > >> > > Good work! > > > > Nikolaus > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] Strange display on v28 with jitterless kernel
Hi Radek, Vinzenz,
Vinzenz, thank you for verifing a bit late, but anyway confirmed that
problem fixed.
Also, i want to clarify a bit of disorder here, Radek, you seem working
really hard as you recommend to use 28.1, but Vinzenz reported bug
against v28.1 kernel you recommend, and proposed to replace 28.1 with
new file.
We have:
1. kernel git (look into this log while reading my letter)
(https://github.com/radekp/linux-2.6/commits/qtmoko-v29 )
2. v28 kernel (in sourceforge:
http://sourceforge.net/projects/qtmoko/files/Experimental/uImage-v28.bin/download
)
this kernel is compiled with last patch 2010-10-15 ("
Enable leds and vibrator ")
3. v28.1 kernel (with ts patch version 1 against which you reported bug:
http://sourceforge.net/projects/qtmoko/files/Experimental/uImage-v28.1.bin/download
)
Last commit is version 1 of ts patch which had problem you describe,
from 2010-10-20
"s3c2410_ts: jitter less version for glamo"
4. Kernel i posted for you to confirm this bug is fixed (with ts patch version
2):
http://bsdmn.com/openmoko/jitterless/uImage-b2.bin
( + modules in my mail)
this is all branch up to 2010-10-25 (+HZ +guid) + updated jitterless patch
5. Now we have this patch committed to git (see 2010-11-08 commit) (ts patch
version 4, no user-visible diff to version 2)
So, 28.1 is actually different from kernel i asked to test and
difference is in bug fix for bug which you reported. So, you still have
to use my kernel to have fixed kernel and this is only kernel in qtmoko
which has this bug fixed :)
urghhh, i'll try to produce less versions next time,
Gennady.
В Чтв, 18/11/2010 в 17:08 +0100, Vinzenz Hersche пишет:
> oh, damn, my fault.. thanks !
> ---
> Radek schrieb am Donnerstag 18 November 2010:
> Vinzenz Hersche wrote:
>
> > wouldn't be it a good idea to upload this patched version as v28.1 or so on
> > sourceforge?
>
> I think it's nice idea. I already did it like 4 weeks ago ;-)
>
> Regards
>
> Radek
>
> [1] http://sourceforge.net/projects/qtmoko/files/Experimental/uImage-
> v28.1.bin/download
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] Strange display on v28 with jitterless kernel
Vinzenz, one more thing В Чтв, 18/11/2010 в 14:56 +0100, Vinzenz Hersche пишет: > Hi Gennady, > > i'm sorry, i've seen your mail just now.. a bit late.. :s > i try it for now, and have done everything of your instructions, except the > dfu-util-part, because it's on sd.. so i just replaced /boot/uImage-GTA02 by > your kernel.. > i tried to reproduce the bug but it doesn't appear.. :) > if you upload the hz100-kernel anywhere, i will help to test.. ah, i am very unclean. kernel i posted is WITH 100HZ patch, so using it you testing 100HZ kernel :) regards, Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v28
В Птн, 19/11/2010 в 17:12 +0100, David Garabana Barro пишет: > O Mércores, 20 de Outubro de 2010, Radek Polak escribiu: > > > Hi, > > > there is now new v28 release of qtmoko ready for downloading > flashing and > > > testing. You can download it from our sourceforge page under > "Experimental" > > > folder [1]. > > Is it possible to boot this version from uSD with u-boot? > > I can boot it with qi, but no matter what I try, couln'd boot from uSD > v28 with uboot > > -- Hi, David, Known (by me at least) bug - something wrong with u-boot, glamo242 and booting from SD. Here, it refuse to boot ~1/2 of times. I am aware of this and even did 1 attempt to fix it. Hope i'll squash it sooner or later. Please, try non-242 u-boot to test if this issue related to your problem. Overwise, i can boot from sd (debian) with u-boot without problems. Nothing special in qtmoko. Provide details - any errors, logs, place it stops booting. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] aplay/mplayer broken with pkg-fso linux-image-2.6.34-openmoko-gta02?
В Птн, 19/11/2010 в 17:48 +0200, Timo Jyrinki пишет: > 2010/11/19 Paul Wise : > > Is anyone else having broken audio on Debian with pkg-fso > > linux-image-2.6.34-openmoko-gta02? Timo Jyrinki can reproduce it with > > one GTA02 but not with another one. Here are some symptoms: > > And the one I can reproduce it with is up-to-date sid, while the one > where I have no problem is mostly pure Debian squeeze (only E17 and > Zhone from sid and kernel from pkg-fso) with 127 unupgraded packages > (ALSA among else). Paul mentioned he mostly has squeeze as well, so it > might be even something in testing, just recently migrated? > > Same kernel is used on each device, and same modules loaded (audio > support built-in). > > Mostly it would be good to hear from other Debian users if they are > seeing the problem, or if they are not seeing it. Maybe we could then > pinpoint what's causing the problem. My guess so far is that it > wouldn't be kernel related, since I at least have audio perfectly > functional on one device. I wouldn't have even noticed the problem if > I hadn't tested audio on my playground Neo after Paul mentioned it... > > I will try to upgrade my working Neo to latest squeeze a few packages > at a time at some point, but right now I don't have time and need that > phone to be working :) > Hi, Timo & list I've noticed problem with alsa too. Guess that this may be related to 100hz patch, probably need to review neo-specific code in kernel. I noticed arecord is not working here (in both debian and qtmoko v28 with same kernel based on qtmoko v29 sources), also aplay somehow is working in qtmoko v28(which is debian stable i think) but does not with debian unstable (all with same kernel). i can't really say then this stopped working - i didn't tried arecord for a while and didn't tried aplay on debian/unstable for a while too. Hope that 100hz patch will help us to fix some well-hidden bugs :) Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] aplay/mplayer broken with pkg-fso linux-image-2.6.34-openmoko-gta02?
Hi, Timo & list, It turned out that aplay problem is due to sound card controls misconfiguration, not some problem with kernel. Whoose who have this problem, please try following state file: http://www.bsdmn.com/openmoko/alsa_aplayfail/aplay34_working.state (with alsactl restore -f aplay34_working.state) arecord still not investigated. Best regards, Gennady В Сбт, 20/11/2010 в 10:50 +0200, Timo Jyrinki пишет: > 2010/11/19 Gennady Kupava : > > I've noticed problem with alsa too. Guess that this may be related to > > 100hz patch, probably need to review neo-specific code in kernel. > > Ok, if that's it, even though it seemingly depends on other factors as > well, please Debian users notice the following: > > * http://pkg-fso.alioth.debian.org/debian/pool/main/l/linux-2.6-openmoko/ > has also all the previous kernels > * If you hit this audio playback problem, install the previous kernel > http://pkg-fso.alioth.debian.org/debian/pool/main/l/linux-2.6-openmoko/linux-image-2.6.34-openmoko-gta02_20100921.gitec52149c-2_armel.deb ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v28
В Втр, 23/11/2010 в 20:41 +0100, David Garabana Barro пишет: > But this open an interesting question. > Why is uSD partition card recognised with Qi and not with uboot? > Maybe my I/O problems are also related to uboot? > Will try to boot SHR from NAND with Qi, and see if my card stops givin > I/O errors... Ah, kernel not recognise partition table, not u-boot fail to boot kernel... Then answer is simple, - cat /proc/cmdline for both qi and u-boot and check difference. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v28
В Срд, 24/11/2010 в 20:11 +0300, Gennady Kupava пишет: > В Втр, 23/11/2010 в 20:41 +0100, David Garabana Barro пишет: > > > But this open an interesting question. > > Why is uSD partition card recognised with Qi and not with uboot? > > Maybe my I/O problems are also related to uboot? > > Will try to boot SHR from NAND with Qi, and see if my card stops givin > > I/O errors... > > Ah, kernel not recognise partition table, not u-boot fail to boot > kernel... Then answer is simple, - cat /proc/cmdline for both qi and > u-boot and check difference. > And you can't do cat /proc/cmdline as you can't boot, ok. So, check your u-boot environment for right cmdline. Example of environment (mine): http://www.bsdmn.com/openmoko/gpsfix/env/ it can be flashed with dfu-util -a u-boot_env -D u-boot_env.in4, or recompiled by ./envedit.pl -c 262144 -f environment.in > u-boot_env.in you have to change it to match your qi command line and it should work. Regards, Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Interesting new 'Open' Hardware & how do I build shr for it?
В Пнд, 29/11/2010 в 01:24 -0800, c_c пишет: > Hi, > I was looking at arowboat.org - which is a project at getting Android > working on all TI OMAP series boards and I saw a link to opensourcemid.org. > Apparently, Embest (who also make the DevKit 8000 - a beagle board like > board) have made a 7" MID with GPS, camera, mini PCIe (they have a WCDMA > module), WiFi and bluetooth running on OMAP 3530. > I ordered a device and I find that :- > > 1. It's built quite well > 2. It's responsive and fast (running android 2.1 as of now) > 3. The hardware schematics are available online > 4. The source code for kernel 2.6.29, x-loader and u-boot are also > available online > 5. It has a lot of space between the board and the casing - I'm thinking > mods like the Freerunner Navigation board > 6. The company seems responsive enough > > I'm now looking at getting a custom kernel (something newer) running on > it. Also, I was aondering how do I get SHR ported onto such a device? I have > the entire openembedded based SHR build system (something I've been using to > build stuff for the FreeRunner) with me - but I'm not sure how to go about > changing the target system. > Hi, c_c! Thank you for link. Specifications ( http://www.armkits.com/product/k7.asp ) are not really promising fast speeds: it is only 600Mhz cpu, and 'up to' 256 Mb sdram volume is not really good for long term usage. Nothing told about graphic card, so i guess CPU managing LCD, that should eat cpu resources too. So, only caches size, memory type (unspecified) are different from FR. According to same page critical parts are missing from android like power management, bluetooth, usb device support, and mic(!) and device is mostly oriented to WinCE (notice also .asp in web address), this sounds too bad for anyone who want open device, or hackable device with linux on board at all. Regards, Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
small announcement, GPS u-boot one more fix Was: qtmoko v30
Hi, all, Inspired by this bug: > Bugs: > - GPS (I didn't try it yet, sorry) seems always powered on, or at least in > Neo Tool it is always "GPS: 1", also after powered it off with the Devtools. I decided to announce in ml that i setup small page on wiki about u-boot http://wiki.openmoko.org/wiki/U-boot-gena2x I am planning to post all u-boot binaries I am doing to that page. Page contains basic FAQ information how to setup u-boot, and link to git repository with all changes. I am planning to support this u-boot version as far as i can, please just write down links or short bug reports to wiki. Today i fixed one more problem with GPS power. In old version, u-boot powered GPS on, and kernel didn't really work well in this situation, to workaround that (and turn gps off), you had to do: #cd /sys/devices/platform/gta02-pm-gps.0/ #cat power_on 1 # echo 0 > power_on # cat power_on 1 # echo 1 > power_on # cat power_on 1 # echo 0 > power_on # cat power_on 0 With new version of bootloader, it is working just fine as expected. New u-boot: http://www.bsdmn.com/openmoko/uboot/binary/u-boot_g2x_2.udfu Sources: http://www.bsdmn.com/cgit/cgit/u-boot/ I tested gps with command-line tools, it seem working well, so kernel-side should work just fine in all cases (resume, boot). GPS seem powered up fine, but not powered down (i am using qtmoko v28). Some thing with NeronGPS (it powers up, not down) om tool working good. Regards, Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: small announcement, GPS u-boot one more fix Was: qtmoko v30
Hey, i didn't done proper separation or 2 unrelated questions. This part about u-boot and power-on-boot problem: > I decided to announce in ml that i setup small page on wiki about u-boot > http://wiki.openmoko.org/wiki/U-boot-gena2x > > I am planning to post all u-boot binaries I am doing to that page. Page > contains basic FAQ information how to setup u-boot, and link to git > repository with all changes. > > I am planning to support this u-boot version as far as i can, please > just write down links or short bug reports to wiki. > > Today i fixed one more problem with GPS power. In old version, u-boot > powered GPS on, and kernel didn't really work well in this situation, to > workaround that (and turn gps off), you had to do: > > #cd /sys/devices/platform/gta02-pm-gps.0/ > #cat power_on > 1 > # echo 0 > power_on > # cat power_on > 1 > # echo 1 > power_on > # cat power_on > 1 > # echo 0 > power_on > # cat power_on > 0 > > With new version of bootloader, it is working just fine as expected. > > New u-boot: http://www.bsdmn.com/openmoko/uboot/binary/u-boot_g2x_2.udfu > Sources: http://www.bsdmn.com/cgit/cgit/u-boot/ And this part about GPS-power-off bug in qtmoko (v30), i tested in v28: > > I tested gps with command-line tools, it seem working well, so > kernel-side should work just fine in all cases (resume, boot). > > GPS seem powered up fine, but not powered down (i am using qtmoko v28). > Some thing with NeronGPS (it powers up, not down) > > om tool working good. Regards, Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v30, GPS power off
В Втр, 07/12/2010 в 21:55 +0100, Francesco De Vita пишет: > >> Bugs: > >> - GPS (I didn't try it yet, sorry) seems always powered on, or at least in > >> Neo Tool it is always "GPS: 1", also after powered it off with the > >> > > I will take a look. > > > > Update: GPS is off after a suspend. If GPS is then turned on, "turn off > GPS" from devtools still seems to not work. Look like workaround. I did some measurements on topic, here is results for whoose who is interested: 1. kernel and bootloader perform well with GPS. 2. om (from omhacks) perform well 3. problem is that qtmoko puts gps to 'sleep' instead of 'off', but turs off before suspend if 'sleep', so yes, after suspend it should be back to 0. Here is power measurements log (with multimeter on dumb battery): test 1: after boot ~190mA, turn on GPS ~238mA(+-10), turn 'off' GPS - same~238(+-10) mA, om gps power 0 -> back to 190mA. suspend -> 10-13 mA + jumping to 30 (deep sleep on, gps off via om gps power 0), resumed 190mA, gps on 240mA, suspend 9-13mA(wtf?), again. resume 190mA, om gps power 0, gps on 240mA, suspend 57mA(ok), resume 250mA (checking gps: powered, serial ok), gps off 240mA, suspend 9-13mA, resume 190mA (om gps power returns 0) test 2: consumption with fix and without fix look like same. resume: 1) gps eat 50mA, adding 1/4 of consumption with full screen brightness and gsm. 2) gps off does nothing in terms of power consumption 3) in suspends gps eats 40mA, x4 times normal consumption 4) 'gps off' has effect of turning off gps in suspend Hope someone will find time to investigate this deeper and review power onsumption. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: The epoch is upon me.
Hi, John I replaced with cap too. It's easy to extract one from some old phone. Result is very good then you remove main battery. BUT > The last time my FreeRunner's battery died, the clock reset to epoch. > Now, it no longer keeps time during suspend either. I'm guessing this > means the clock battery has finally died. In suspend clock is powered by main battery not backup, as PMU remain in Active state. In fact in suspend backup battery is _charging_. So, i think you have some software trouble, probably you setting clock somehow in wrong way (they not saved to hw clock). Gennady. В Втр, 21/12/2010 в 08:50 -0500, Gay, John (GE Energy Services, Non-GE) пишет: > OK. I was a little confused about the mention of 2 super caps at the > time. That make more sense. > > I'll have to check for an American source and get one. I've got some > rusty soldering skills I can brush up before I attack my phone. > > Cheers, > > John Gay > > > __ > From: community-boun...@lists.openmoko.org > [mailto:community-boun...@lists.openmoko.org] On Behalf Of Benjamin > Deering > Sent: Tuesday, December 21, 2010 8:14 AM > To: List for Openmoko community discussion > Subject: Re: The epoch is upon me. > > > > Jon, > > I'm don't know how you can be sure the clock battery is to blame, but > I just wanted to mention that I replaced the battery with a single > supercap. The pair of supercaps was because I have two freerunners. > > Ben > > On 12/21/2010 07:55 AM, Gay, John (GE Energy Services, Non-GE) wrote: > > The last time my FreeRunner's battery died, the clock reset to > > epoch. Now, it no longer keeps time during suspend either. I'm > > guessing this means the clock battery has finally died. > > > > Someone recently commented that they replaced their battery with a > > pair of super caps. I just wanted to confirm my diagnosis before I > > take a soldering iron to my phone. > > > > Cheers, > > > > John Gay > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v30; UBIFS; can't boot
В Сбт, 25/12/2010 в 19:10 +0300, Ivan Matveev пишет: > Hello All, Radek > > Trying > > 2010-12-06 03:03 qi-v30.udfu > 2010-12-06 02:11 qtmoko-debian-v30.ubi > 2010-12-06 03:03 uImage-v30.bin > > qi complains that lzo compressor is mot compiled in ubifs. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community Hi, this means that kernel command line missing "rootflags=compr=zlib". qtmoko kernel has lzo support not compiled in, so you have to choose compressor in rootfs mount options. I recommend also to use "rootflags=compr=zlib,no_chk_data_crc" to make reads a bit faster. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v30; UBIFS; can't boot
Btw, don't know where this is set in qi, but you may try u-boot: http://wiki.openmoko.org/wiki/U-boot-gena2x Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v30; UBIFS; can't boot
Hi, > I don't want to go back to u-boot. I disagree - going to Qi is going back, going to u-boot is going forward :) > echo 'rootflags=compr=zlib' > p1/append-GTA02 Are you sure qi is really reading this? i am sure it is not. > No joy. > Same result: kernel complains that lzo is not compiled in. It is really not compiled in, and it is OK, you have no need in lzo ATM in qtmoko. > Maybe it misses some modules? Maybe I shell put them in "identity-ext2"? > Have to research more... No, you need ensure that this options REALLY passed to kernel somehow. I almost sure they not. > > BTW tried Gennadys script to decode u-boot > environment(http://www.bsdmn.com/openmoko/gpsfix/env/envedit.pl). > It complains that crc32 function is not defined. It is not mine, it is part of http://svn.openmoko.org/trunk/src/host/devirginator/ and uses crc32 from it, it's not good idea to get random files from server and complain they not working :) > Can I modify u-boot environment from QtMoko running from SD? u-boot can boot any known distro without problems, from sd, ubi or jffs2. in hard cases of unusual fses you can just put kernel to splash NAND partition (named 'depr' in your qi) and boot it with rootfs on sd. I think it is also possible to make such config that appends kernel params load from file on external fs, like in qi, but who needs this... If you need some help in u-boot setup, you can join #qtmoko at freenode irc. If you really enjoy Qi, use radek's qi from qtmoko site http://sourceforge.net/projects/qtmoko/files/Experimental or fix kernel parameters in qi source code and recompile it. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v30; UBIFS; can't boot
В Пнд, 27/12/2010 в 18:16 +0300, Ivan Matveev пишет: > On Mon, 27 Dec 2010 08:33:09 +0300 > Gennady Kupava wrote: > > > Hi, > > > > > I don't want to go back to u-boot. > > > > I disagree - going to Qi is going back, going to u-boot is going > > forward :) > > I like Qi's minimalism, automatic setup of many options and text config > files. "Automatic" setup is done by person who provide you with Qi. If someone start supply u-boot_env with distros, u-boot setup will be equally "automatic". It's also possible to setup u-boot like qi, 'read kernel first from sd part 1, boot if loads, then try from sd part 2, boot if loads, then from nand'. All with 10 lines in config file. Just noone need it. What 'text config files' in Qi you talking about? Does it have config files at all? If you mean ability to append kernel parameters this not like u-boot config files, only 1% of that flexibility. Minimalism? You mean that Qi works only on Freerunner, has no support to anything else? Or that you need to use NOR u-boot to flash something to NAND as qi can't do it? Or that nothing except kernel parameters may be configured without recompilation? Or that it can't display anything on screen so you have to decode errors by amount of blinks? Or that it adds 'quiet' kernel options by default, so you can't see boot logs? > I'v tried u-boot just to be shure. > Per istructions at > http://wiki.openmoko.org/wiki/U-boot-gena2x > I'v downloaded: > http://www.bsdmn.com/openmoko/uboot/binary/u-boot_g2x_1.udfu > http://www.bsdmn.com/openmoko/uboot/config/environment.in > http://svn.openmoko.org/trunk/src/host/devirginator/crc32.pl > http://svn.openmoko.org/trunk/src/host/devirginator/envedit.pl > > Didn't edit environment.in because don't know what to put there. You must edit it to boot, mine is only example suitable only for my custom setup. > From http://wiki.openmoko.org/wiki/U-boot-gena2x: > " > If you switching from qi, just run boot your distro with Qi, do > cat /proc/cmdline and compare/update parameters in config file. > " > Cant do that because I can only boot from SD but the params will be > different then? So lets use the sample environment.in as it is. > > ./envedit.pl -s 262144 -f environment.in > u-boot_env.in > > dfu-util -a u-boot -D u-boot_g2x_2.udfu > dfu-util -a u-boot_env -D u-boot_env.in > > A press on the power button. FR emits a barely audible click and then > nothing, the screen stays blank. This only may happen if you battery discharged or 'default' boot way is not setup properly. Try menu with power+aux like described on wiki. > OK, at least I'v removed supposedly offending options from u-boot_env > partition. > Lets try qi-v30.udfu again. TADA! It boots ubifs QtMoko from NAND. > So I think something was wrong with u-boot_env partition, params > stored in there or the partition size. I think qi is NOT reading u-boot_env, so you just had different Qi version before. > > > > echo 'rootflags=compr=zlib' > p1/append-GTA02 > > > > Are you sure qi is really reading this? i am sure it is not. > I agree. In Qi sources I could only find that it reads 'usb' file from > 'identity-ext2' partition. > > > No, you need ensure that this options REALLY passed to kernel > > somehow. I almost sure they not. > In this case I had to make sure some options are NOT passed to the > kernel :). All the right options are compiled in Qi. > > > > Can I modify u-boot environment from QtMoko running from SD? > > > > u-boot can boot any known distro without problems, from sd, ubi or > > jffs2. in hard cases of unusual fses you can just put kernel to splash > > NAND partition (named 'depr' in your qi) and boot it with rootfs on > > sd. > Thanks I'll keep that in mind in case of a hard case. > > > I think it is also possible to make such config that appends kernel > > params load from file on external fs, like in qi, but who needs > > this... > I think its not external fs that matters but u-boot_env > format. Seem i didn't describe my idea very well. I think it's possible to write such env for u-boot, that will read text 'append' portion of kernel params like qi does. So, you'll have similar fun of editing text files with kernel options, like you have in Qi. > > dfu-util -a u-boot_env -U u-boot_env.in > > Now we have u-boot_env.in file containing params. How do we study whats > inside? Strings? Errr. Oh yes we have envedit.pl. How do we use > it, and where is the doc? Run it with no params, it outputs > '���6'. >
Re: Qi vs U-boot (was Re: QtMoko v30; UBIFS; can't boot)
Hi, Ivan, В Втр, 28/12/2010 в 06:04 +0300, Ivan Matveev пишет: > Lets burn some linux.org.ru style flame! Hey, such foreword spoils good talk, so i'll try to be short. >> It's also possible to setup u-boot like qi, 'read kernel first from sd part 1, boot if loads, then try from sd part 2, boot if loads, then from nand'. All with 10 lines in config file. Just noone need it. > No one needs the good stuff :). Cause is that this stuff is not good :) > Does every FR user have to develop a bootloader? Process of changing configuration is not development. Process of looking up something in C sources of Qi is development ;) > Please tell me how to do this! I have no religious bind to Qi. To hell with minimalism, let us all use the bootloader that is standard, smart, configurable and well supported. I think easiest way is to use fw_setenv. I rethought, need relatively trivial modification to u-boot to support loading plain file to env variable with something like 'ext2loadvar location [var]'. But this brain-dead by design idea require bootloader to support all possible fses (how does qi reads ubifs for kernel parameters, if it has no support for ubi?) > I'm waiting for Radek's comment on this. Qi's sources are not easy, no stdlib functions. Local Qi pontiff is Paul Fertser. > Please do not be offended. I was frustrated by FR suddenly not booting. It's impossible to offend me with good arguments. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: grsecurity in kernel?
В Срд, 29/12/2010 в 23:28 +0100, Glenn пишет: > At 0:06 +0200 30/12/10, Timo Juhani Lindfors wrote: > >Glenn writes: > >> Maybe it might be a good idea to embed grsecurity in the kernel - for > >> two reasons: > > > >I think the main goal should be to upstream our changes, not add new > >changes that are not upstream. > > > >> * Debug programs and drivers (faster debugging?) > > > >What has grsecurity to do with debugging? > ... > > > On there home page they write: > > # Prevention of arbitrary code execution, regardless of the technique > used (stack smashing, heap corruption, etc) > # Prevention of arbitrary code execution in the kernel > # Randomization of the stack, library, and heap bases > # Kernel stack base randomization > # Protection against exploitable null-pointer dereference bugs in the kernel > > E.g. Some buffer overflows will be stopped. How do you see 'stopped buffer overflow'? Will it not overflow? I think it will still overflow, but no harm to security. Of course at cost of additional checks :) In general: This is just small phone, not super- secure device with highly secure data serving public available services. All this will have negative impact on performance and battery life. You welcome to research how it will work - just build kernel, run lmbench and see how much slower things will be, and use it if you like to build super-secure device, if would be interesting to read summary of your reserch, but FR stacks has thousands of software bugs, better fix em in normal way, not workaround by adding another chuck of self-checking. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
