Re: [maemo-developers] Huge bundle O' year-end questions
On Sat, Dec 31, 2005 at 02:53:19AM -0800, Jason Mills wrote: OMAP1710: * How does one get access to the hardware Random Number Generator? (Is that what /dev/urandom is pinned to?) Via the RNG driver. Look at drivers/char/hw_random.c as well as omap16xx-rng.c if you want to know how it's handled. * Would it, in that context, be advisable to separate the OMAP1710 from the earlier bretheren (OMAP16xx f'rexample) when dealing with the Linux - ARM9 - OMAP1xxx kernel branch, since they feature radically different cache sizes and value-add functionality? Why? The cache size is irrelevant, the same semantics apply to both. grep for cpu_is_omap1710(), there's incredibly few instances where 1710 differences matter. * I noticed that the kernel was compiled using optimize for size (-Os) rather than optimize for speed (-O2 or -O3), which seems to be the correct methodology for ARM9, assuming it has the same cache size issues that the IA-32 Centaur does... optimize for size actually yields faster code, since you end up with fewer cache-misses. Why isn't the same optimization recommended for ported applications? There's not much point, ARM9 has a non-coherent VIVT L1, so we have to write-back and invalidate the dcache on every context switch anyways, so applications will simply all miss after every context switch regardless of what kind of cacheline utilization they are after. Lack of proper ASID tags is a source of constant irritation. In the x86 case it's not too surprising that those sorts of optimizations would be meaningful, since there's variable length instruction encoding, and the alignment constraints are completely different. None of that applies to ARM, and the code density is already quite good. It might be worthwhile padding out some commonly used structures in userspace out to cacheline boundaries, but given the fact that it's all blown away after every context switch, it wouldn't be of much benefit. * I also noticed that the kernel had a number of debug features set, which (IIRC!) slow the kernel down and add bloat, no? (CONFIG_DEBUG, CONFIG_FRAME_POINTER, etc...) This isn't x86. Outside of x86 land there are plenty of architectures that require frame pointer support in order to do stack backtraces. ARM, sh64, and if I recall correctly, ia64, are all in this camp. Feel free to turn it off if you wish, but note that no one will take any bug reports ;-) Memory: * Why does RAM fragment -so- quickly and so badly? I can go from ~5% to ~60% by just launching a single application. How does this have anything to do with memory fragmentation? Unused memory is wasted memory. * Does the ARM9 architecture suffer a large performance penalty for fragmentation like this? (user perception says yes, but...) This also has nothing to do with ARM, but yes, the VM performance suffers when memory starts to fragment badly. If you're interested in playing around with some alternatives to warding off fragmentation, look at some of the work done by the memory hotplug guys. As an example, we currently need to pre-allocate physically contiguous page frames for the DSP early on in boot time in order to satisfy contiguity of a high order (for large shared buffers mapped through both MMUs into the DSP and ARM address spaces). After userspace applications start abusing the system (particularly certain applications that go out of their way to abuse overcommit), it's no longer possible. One could logically infer that performance in general would take a hit as a result of this. Time: * Is there direct RTC access? Yes, but not in the way you want. * Could auto wake be achieved by setting the RTC timer alarm for a future point in time, and then running a suspend-to-ram operation? Alarms are settable through sysfs. retu-rtc is what you are after. Look at drivers/cbus/retu-rtc.c in the kernel source if you want additional information, it's rather self explanatory. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Localization.
Hi,I am not really sure if the problems below relates to localization:After successfully installing Maemo, I started the sbox. However on thedisplayed window it shown "home_ap_home_name" instead of "Home" as stated inthe tutorial. I had followed the instructions in the tutorial to setup thelanguage and pager variables in .bash_profile inside scratchbox(/scratchbox/users/edlinoor/targets/SDK_PC/etc/skel/.bash_profile). Is thiscorrect? Anybody have any suggestions / ideas on what is missing / wrongplease?My second problem is that I started the sbox with "af-sb-init.sh start" after I start Xephyrcommand, I try to execute run-standalone.sh memo_hello. It cannot run and itreturn this error message: "/usr/bin/run-standalone.sh: line 16: maemo_hello:command not found". Any ideas please? Ed. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] VNC Viewer maemo port now available
There were a couple of people going for it at the time I wrote this:http://the.taoofmac.com/space/blog/2005-11-27I got some e-mail from them, but despite a few notes on the Maemo Wiki, there wasn't much follow-up (or else I missed it). Still, it's only been a month. :)Rui Carmo(still without a 770 or a way to buy one in Portugal)On Dec 29, 2005, at 19:13, John B. Holmblad wrote: Aaron, that is great news. I am also interested in knowing whether anyone has ported RDesktop to GTK/Maemo. I am interested in having interoperability with Microsoft Windows environments using the Remote Desktop Protocol (RDP). Do you know if anyone is working on this? Best Regards, John Holmblad Televerage International GSEC Gold,GCWN Gold,GGSC-0100,NSA-IAM,NSA-IEM (H) 703 620 0672 (M) 703 407 2278 (F) 703 620 5388 primary email address: [EMAIL PROTECTED] backup email address: [EMAIL PROTECTED] Aaron Levinson wrote: I'm pleased to announce the first version of a VNC Viewer maemo port. Some other developers have announced ports of VNC in the past, but these were strictly builds of the RealVNC vncviewer client and were not GTK/maemo software applications. As such, they lacked certain GTK/maemo amenities, the biggest being no text input methods. This new port is a true GTK/maemo port that basically provides most of the support that one might expect from a maemo-ized VNC viewer. I'm still working on adding some features, and there certainly is room for optimizations, but I'm pretty happy with the way it has turned out so far. It's available at http://www.aracnet.com/~alevinsn/vncviewer_0.1_arm.deb . Here's some brief documentation: -- Press the Select/Confirm button to turn on and off the text input method window (just like in xterm). -- Use the Zoom out (-) button for middle mouse button clicks. -- Use the Zoom in (+) button for right mouse button clicks. -- Use the Cancel/Close button to send an Esc key. -- The other hardware buttons operate similar to how they operate in xterm. -- Turn on/off the toolbar from the View menu. -- It is possible to double-click, but it might require a little practice/multiple attempts. I'm planning on writing one or more e-mails concerning my porting experiences. Hopefully, the information in these e-mails will be useful to some. I'll also be making the source code available once I clean it up a bit more. Aaron Levinson ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___maemo-developers mailing listmaemo-developers@maemo.orghttps://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] strange DNS problem with maemo.org via USB network connection
Hi all, I have just found a strange problem. I tried to update the apt package database on my N770 and get this: nokia770:~# apt-get update Err http://repository.maemo.org maemo1.1rc5/free Packages Could not resolve 'repository.maemo.org' Err http://repository.maemo.org maemo1.1rc5/free Release Could not resolve 'repository.maemo.org' Err http://repository.maemo.org maemo1.1rc5/non-free Packages Could not resolve 'repository.maemo.org' Err http://repository.maemo.org maemo1.1rc5/non-free Release Could not resolve 'repository.maemo.org' Err http://repository.maemo.org maemo1.1rc5/free Sources Could not resolve 'repository.maemo.org' Err http://repository.maemo.org maemo1.1rc5/free Release Could not resolve 'repository.maemo.org' Failed to fetch http://repository.maemo.org/dists/maemo1.1rc5/free/binary-arm/Packages.gz Could not resolve 'repository.maemo.org' Failed to fetch http://repository.maemo.org/dists/maemo1.1rc5/free/binary-arm/Release Could not resolve 'repository.maemo.org' Failed to fetch http://repository.maemo.org/dists/maemo1.1rc5/non-free/binary-arm/Packages.gz Could not resolve 'repository.maemo.org' Failed to fetch http://repository.maemo.org/dists/maemo1.1rc5/non-free/binary-arm/Release Could not resolve 'repository.maemo.org' Failed to fetch http://repository.maemo.org/dists/maemo1.1rc5/free/source/Sources.gz Could not resolve 'repository.maemo.org' Failed to fetch http://repository.maemo.org/dists/maemo1.1rc5/free/source/Release Could not resolve 'repository.maemo.org' Reading Package Lists... Done E: Some index files failed to download, they have been ignored, or old ones used instead. After this I tried to ping the repository: nokia770:~# ping repository.maemo.org ping: repository.maemo.org: No address associated with name an then the homepage itself: nokia770:~# ping www.maemo.org ping: www.maemo.org: No address associated with name the IP of the domain name: nokia770:~# ping 212.187.162.158 PING 212.187.162.158 (212.187.162.158): 56 data bytes 64 bytes from 212.187.162.158: icmp_seq=0 ttl=54 time=266.7 ms 64 bytes from 212.187.162.158: icmp_seq=1 ttl=54 time=53.4 ms --- 212.187.162.158 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 53.4/160.0/266.7 ms nokia770:~# ok the connection is good, but if I try to ping another common domain name like google.de everything works: nokia770:~# ping www.google.de PING www.l.google.com (64.233.183.147): 56 data bytes 64 bytes from 64.233.183.147: icmp_seq=0 ttl=243 time=33.5 ms 64 bytes from 64.233.183.147: icmp_seq=1 ttl=244 time=35.7 ms 64 bytes from 64.233.183.147: icmp_seq=2 ttl=243 time=47.3 ms 64 bytes from 64.233.183.147: icmp_seq=3 ttl=244 time=68.8 ms 64 bytes from 64.233.183.147: icmp_seq=4 ttl=243 time=74.0 ms --- www.l.google.com ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 33.5/51.8/74.0 ms nokia770:~# What can be the source of the problem? Any ideas? I whish all the maemo developers a good start into the new year! :-) Cheers, Timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Huge bundle O' year-end questions
Paul- Thanks for the quick replies, I'll take a look at the relevant bits of kernel source. Thanks also for the explanation on the cache-hit/cache-miss and memory fragmentation issues, definitely food for thought. Would you mind if I bounced the summarized version of your original reply off you for review and possible addition to the Developer FAQ? -JMills From: Paul Mundt [mailto:[EMAIL PROTECTED] Sent: Sat 31-Dec-05 04:04 To: Jason Mills Cc: maemo-developers@maemo.org Subject: Re: [maemo-developers] Huge bundle O' year-end questions On Sat, Dec 31, 2005 at 02:53:19AM -0800, Jason Mills wrote: OMAP1710: * How does one get access to the hardware Random Number Generator? (Is that what /dev/urandom is pinned to?) Via the RNG driver. Look at drivers/char/hw_random.c as well as omap16xx-rng.c if you want to know how it's handled. ... deletia ... ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Localization.
Hi, Happy New Year and thanks for the reply. make sure that LANGUAGE is set to en_GB: % echo $LANGUAGE If not, re-load .bash_profile Done that mate and the screen showed me en_GB but somehow the problem still occurred. Did you run # /scratchbox/sbin/sbox_ctl start in a separate window? I ran it in the same window. The sequence is: xterm 1: sudo /scratchbox/sbin/sbox_ctl start xterm 2: start-xephyr.sh xterm 3: /scratchbox/login xterm 3: af-sb-init.sh start xterm 3: run-standalone.sh my-app I had followed the sequence. Still the run-standalone.sh shown the same error. Is it possible that the maemo_hello application is not install in the machine? Ed. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Localization (the home_ap_home_name problem)
Hi, Thanks for the reply. This one bit me too, perhaps in the same way. Before explicitly setting the LANGUAGE environment variable, what is its value? Does it still occur if you use export LANGUAGE=en_GB after you've launched the Scratchbox shell, but before you start up the environment? -JMills Before, the LANGUAGE was set as en_US. Yes, it still occurred even after I explicitly set the LANGUAGE=en_GB before I start up the environment. You have the same problem right? Have you solved it? Ed. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
