Re: [FSO] GSM Radar/AT Commands
Arigead wrote: I'm not using the FR as a daily phone as yet but thought I could simply use an AT command to do a quick check on the various signal strengths. I tried AT+WS46=? but it has not come back to me and just hangs there. Does anybody, with better knowledge of AT commands then me, know of a likely command or if this is even possible. If I remember correctly AT+CSQ gives signal strength. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] man pages??? killing events/0
Matthias Apitz wrote: $ man proc By the way, if you don't have them locally: http://www.google.com/search?q=proc+manpage Don't you think that this answer is too simple? I thought it was dead easy. Why, what sort of hoops do you prefer to jump through to find a man page? ;-) Second Google result: http://linux.die.net/man/5/proc I have a lot of Unix systems sitting around me, I'm just typing these lines into one, a FreeBSD 7.0. I was asking for the man pages matching exactly the Linux derivate which is installed in the FR; Well of course it's going to be different on FreeBSD -- different kernel -- but the location of the CPU time in /proc is going to be the same as any other system running the Linux kernel (well at least any that's not completely ancient anyway). So the simplest option, as I was suggesting is just to consult the proc manpage on any random Linux PC and if you don't have a Linux box handy then Google it, as people have put most of the man pages online. for example where is the man page of 'dropbear'? http://www.google.com/search?q=dropbear+manpage First result: http://downloads.openwrt.org/people/nico/man/man8/dropbear.8.html ;-) Seriously though, if you must have the absolute exact same version for some reason and don't have a Linux box, just grab the source tarball: wget http://downloads.openmoko.org/sources/dropbear-0.51.tar.bz2 tar -jxvf dropbear-0.51.tar.bz2 cd dropbear-0.51 man ./dropbear.8 Usually manpages aren't installed on embedded systems in the interests of saving space. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] man pages??? killing events/0
Matthias Apitz wrote: I thing Linux/UNIX goes the wrong way if we depend on Google to lookup man pages; We don't. Well, at least anyone actually running Linux doesn't. Just typing man proc worked for me. ;-) I added the Google link as an after-thought in case you were running something else. Now we're getting closer; thanks for the hint; maybe it would be a good idea if we have *all* man pages installed at http://downloads.openmoko.org/ or even as a fetch-able tar ball; Sure, that sounds handy! Maybe you could contribute one? :-) in KDE you can just put 'man:ssh' into the KDE's browser Konqueror and you get what you want; That'd work too, just install dropbear on your PC and I bet you could view its manpage with Konqueror as well. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] man pages??? killing events/0
Matthias Apitz wrote: how can I ask for the actual CPU time of a proc? I was thinking in something like 'cat /proc/5/...' but have no man pages about the /proc layout :-( $ man proc [...] /proc/[number]/stat Status information about the process. This is used by ps(1). It is defined in /usr/src/linux/fs/proc/array.c. [...] utime %lu The number of jiffies that this process has been scheduled in user mode. stime %lu The number of jiffies that this process has been scheduled in kernel mode. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] man pages??? killing events/0
Alex Osborne wrote: Matthias Apitz wrote: how can I ask for the actual CPU time of a proc? I was thinking in something like 'cat /proc/5/...' but have no man pages about the /proc layout :-( $ man proc By the way, if you don't have them locally: http://www.google.com/search?q=proc+manpage ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Using the neo as a Bluetooth external gps...
Nicola Mfb wrote: It may be interesting to serve raw nmea gps output over bluetooth to have it used by some other phones/pda with routing/navigation software. This will permit to test gps accuracy against usual bt gps antennas, and to eliminate another device, cable and battery from my car :))) Any idea about this? http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS#Bluetooth_GPS_relay ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: A Call for community action
Hi Steve, Steve Mosher wrote: My idea. throw these out to community and see if folks would pick a bug and try to fix it, actually sign up to try to fix it, so we get a coordinated effort. Sean liked the idea and I thought it was worth a try. I'm afraid I'm not using any of the Qtopia apps at the moment, which most of these issues are about. It's also not clear (at least to me) whether we can even make Qtopia contributions, which may be part of the reason you're not getting many takers. As far as I'm aware there's no public source code tracker and I guess Trolltech having a seperate proprietary version might make accepting patches somewhat complicated for them. (I'd be pleased to be corrected though.) 5. 1493 : [system software] when press power button makes some noise during suspend time(https://docs.openmoko.org/trac/ticket/1493) I had a look at this (see my comments in the ticket) and managed to stop it, but it's not much of a solution. This probably needs somone who is more of a hardware person than me. Cheers, Alex ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The Lost Openmoko Community: Official newsletter?
Steve Mosher wrote: Question: what functions do you see a community manager performing. Write his job spec. As I see it there's two main points that Risto and others have usually brought up on this topic, communication and leadership. Communication This is the big point that everyone always mentions. You can't have leadership without first a way to communicate effectively. In my opinion, the wiki is being covered pretty well now and is becoming a really good _reference_. So what is missing? News! News! News! The engineering updates are excellent once you've discovered them. The community updates by Steve leading up to the release of the FreeRunner were also good. The planet, as several people have mentioned is a mixed bag, now and then there's good blog posts by various people but there's too much off topic or personal stuff that shouldn't be there and it's in desperate need of a way to filter by language. Sadsammy also pointed out in a reply to Risto's Lost Openmoko Community blog post that these guys are doing fantastic job: http://onlinedev.blogspot.com/search/label/openmoko But they're not even in the planet! (I just filed a bug to admin-trac). There's also not enough stuff from within Openmoko itself in the planet, it should be a central place to look for news. How is news handled elsewhere? For small specialised projects a mailing list and the lead developer's blog is fine. But the Openmoko community is extremely diverse covering lots and lots of different bases and is rapidly growing in size. It's not just a single software package, heck it's not even a single distro! So lets look to the big diverse communities. For general Linux stuff there is the absolutely fantastic Linux Weekly News [1]. In addition to that, virtually all the large community-style projects have their own newsletters, either weekly, bi-weekly or monthly: Debian [2], Gentoo [3], Ubuntu [4], Fedora [5], Mozilla [6] and so on. GNOME [7] and KDE [8] have a continuous planet-style news rather than a newsletter, but they are edited by real humans and serve much the same purpose and have recurring feature articles. Lets look at what they have in common: * Visibility: If not directly on the front page, then a big fat link at the start of the navbar News. Not hidden away in some mailing list (although usually mirrored or announced on lists). * Well edited: Typically they have one *human* editor who puts everything together in a consistent easy to read way and filters out the rubbish. * Sections: The details vary a bit between the projects but in some form they usually have the following. Theses don't have to be particularly long. A paragraph or two on each section would do. - Table of contents with highlights of the most important stuff from the other sections. - Corporate news: What's happening in the core company (Mozilla), council (Gentoo) or core developers (Linux kernel). These decisions have been taken. This is the new policy for X. We're opening a new t-shirt store. We're looking to hire a community manager and two kernel hackers. We will be having an IRC or real-life meeting to discuss issue X at this time and place. John Smith has moved to the Foobar team will now be working on X. This should help a little to give a voice to the company, what are its interests and where it is going. - Special features: Two or three more in-depth articles on a particular topic. This could be a review of a new program, discussion on a debate about a particularly tricky technical problem or a round-up from a recent conference or event with a few photos. It would be good to have maybe one or two by the newsletter's editor and then some good-quality articles by guest authors. If there's a good article on some random person's blog, ask them whether you can include it. Offering some incentives (merchandise, gear or even a small sum of money like LWN) could help encourage people to submit good articles. - Development news: Digest of the more interesting commits to the repositories of core projects. Bug tracker statistics (list of fixed bugs, how many news ones etc). LWN has the mailing list quote of the week, which often mixes a few funnies (whatever creative way Linus has told someone their code stinks this week) with rather interesting mailing list threads worth reading. - Software release notices: Generally submitted from the community, but edited, or at least with a policy of how they should look to be accepted. Kept short and to the point. One sentence description of what the project is (maybe a little longer if its a new project), list of big changes, link to the project's website or install instructions. - Community events/announcements: OpenMoko community get-together in Sydney. Upcoming mobile computing conference in Denmark. New users group in Italy looking for members. - Tips and tricks: This is not so general, but something I noticed in Gentoo's
Re: is fr usb host mode prone to damage from regular usb charging
Robin Paulson wrote: similarly, if i turn on host mode while it's plugged in, what can happen? i can't see anything in the kernel archives, but i'm not sure i'm looking in the right place Andy replied: http://lists.openmoko.org/pipermail/openmoko-kernel/2008-October/005450.html So I guess that means something like: we can't be sure but it probably won't. I've also briefly (by accident) enabled host mode while on charger or plugged into the PC and it didn't seem to damage anything. Cheers, Alex ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alasal's blog
Minh Ha Duong wrote: Please make sure that the feed is not syndicated without discussing it with Alasal (the author's blog) again. Two weeks ago we decided against including it because he had mixed feelings about the planet: http://lists.openmoko.org/nabble.html#nabble-tt796556%7Ca1087886 Sorry, I hadn't seen that. I should have asked, but I didn't see an obvious way to contact the author and I didn't realise anyone would actually not want to be included. :-( Of course, nothing prevents us to ask him again *** with hearts of it and lots of sugar, pretty please *** Alasal, please, is there any chance? It does look so much better with your posts in there. In the mail Minh linked, you said you want to draw visitors directly to your blog for adsense. Blogger has an option under Site Feed settings that gives out a short feed that only has the first paragraph of each of your posts and you have to click through to see the rest. Perhaps you could set that on your blog and that way the planet could actually be a source to increase your visitors? In fact I only found out about your blog through someone else mentioning it in the planet. If not I will ask to have it removed again. Of course that is not going to make the planet suddenly less a mixed bag. The signal drowns out the noise if we have enough people who tag their posts properly? ;-) It's actually pretty good at the moment, there seems to be only 2 off-topic posts in there. I would volunteer to edit it, but I don't think I'm reliable enough to do it constantly. :/ I love the idea of being language inclusive by default. Down-to-earth convenience also suggest that we need I can read this language checkboxes and cookies somewhere... Right. Anyone know any libraries that do language detection? Heck, I wouldn't mind if it fed everything through an automatic translator. It's a pity Google's language AJAX API has such restrictive terms of service. Cheers, Alex ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: microSD single ext2 or ext3 partition boot?
On 06/10/2008, at 11:49 AM, feywulf wrote:
setenv menu_9 Boot from microSD (ext2): setenv bootargs \$
{bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \$
{mtdparts} ro\; mmcinit\; ext2load mmc 1 0x3200 \$
{sd_image_name}\; bootm 0x3200
I think it would. For me $bootargs_base also contained root= and
rootfstype= pointing at the flash which was giving the kernel some
confusion having them specified twice, so if you have problems with
it check that.
I'm thinking that the 0x3200 might indicate an offset to where
the partition starts when you have an 8mb vfat partition first.
Should it be changed to 0x0?
No. 0x3200 is the memory address the kernel will be loaded to.
So ext2load reads the file $sd_image_name into memory starting at
address 0x3200. Then bootm 0x320 jumps there to start the
kernel running.
Cheers,
Alex___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.9]Debugging the FreeRunner Kernel?
Helo Arigead, Arigead wrote: Does anybody have an opinion that it might not be the kernel? As it happens all the time for various apps I'm assuming that it's something core. When it locks up, does the device stop responding to ping over USB? That would indicate the whole kernel is getting messed up by the lock ups. Would the debug board enable me to get to the bottom of this? It would probably help to some extent. You could see the kernel messages over the serial console and potentially even inspect what the CPU is doing when it hangs over JTAG. Although if it's a hardware fault, which seems likely if nobody else seems to be experiencing random lockups, I guess it could be really hard to diagnose even with the debug board. Will somebody please reply so that I can tell it's got to the list Your mails are getting to the list. See for example: http://kerneltrap.org/mailarchive/openmoko-community/2008/10/1/3465464 Cheers, Alex ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO] losetup trouble
Hello, On 04/10/2008, at 2:51 AM, rhn wrote: [EMAIL PROTECTED]:/media/card# touch /dev/loop0 [EMAIL PROTECTED]:/media/card# losetup /dev/loop0 bigfile losetup: /dev/loop0 [EMAIL PROTECTED]:/media/card# ls -l /dev/loop0 -rw-r--r--1 root root0 Oct 3 16:31 /dev/loop0 I'm surprised losetup didn't complain. There's not much point in making loop0 a regular file. I have not tried usb storage but: pico:~# ls -la /dev/loop0 brw--- 1 root root 7, 0 Oct 4 12:08 /dev/loop0 pico:~# dd if=/dev/zero of=foo bs=1k count=1k 1024+0 records in 1024+0 records out 1048576 bytes (1.0 MB) copied, 0.208113 s, 5.0 MB/s pico:~# mke2fs foo mke2fs 1.41.1 (01-Sep-2008) [...] pico:~# mkdir /mnt/tmp pico:~# mount -o loop foo /mnt/tmp/ pico:~# ls -la /mnt/tmp/ total 17 drwxr-xr-x 3 root root 1024 Oct 4 12:12 . drwxr-xr-x 5 root root 4096 Oct 4 12:12 .. drwx-- 2 root root 12288 Oct 4 12:12 lost+found pico:~# mount | grep foo /root/foo on /mnt/tmp type ext2 (rw,loop=/dev/loop0) I imagine normally /dev/loop* should be created by udev. The fact that it doesn't exist might indicate that you don't have loopback device support in your kernel. Check this: pico:~# grep loop /proc/devices 7 loop If it's not there try modprobe loop. If it is there, delete your bogus /dev/loop0 and recreate it like this: mknod /dev/loop0 b 7 0 Cheers, Alex ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: duke3d on debian ?
On 04/10/2008, at 12:25 PM, Charles-Henri Gros wrote: I tried once but it wouldn't resize or rotate (I believe the framebuffer version of X doesn't allow that) Install the xserver-xglamo package to get the version that can be resized and rotated with xrandr. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] xterm larger fonts
On 01/10/2008, at 2:07 AM, Matthias Apitz wrote: Any hint about the name of a larger font that could be used with 'xterm -fn ...'? I'm as well missing 'xlsfonts' in FR :-( xterm -fn -*-fixed-medium-*-*-*-20-*-*-*-*-*-*-* ? Here's the xlsfonts binary from Debian. It's probably binary compatible enough to work on Om2008.9 as well. http://meshy.org/~ato/tmp/xlsfonts ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] Sephora 0.2 pre alpha 1 - Impressions and suggestions needed
Hi Michele, Michele Renda wrote: About the sources: I will start to work in a decent deb-src, but for now you can download the sources from the bazaar repository of the project Have you committed the latest version to bazaar? I couldn't see anything about --preload in there, so I extracted sephora.py from the deb instead. Adding more tabs I saw that the program start to become a bit slower. I worked on the code, and now I have to take some design decision. The program can be launched from console with the parameter --preload : With this parameters the start will become slower but the first panel switch will be very fast. Without --preload the program start will be faster, but the first switch will be a bit slower. Is it slow because of all the DBUS calls done on startup? Maybe you could use asynchronous DBUS calls instead: http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html#making-asynchronous-method-calls That way you could fire off the calls to fetch all the information on startup but since they're asynchronous it won't block the program and the user can start doing stuff. When the information is returned from DBUS you can then update the widgets. Cheers, Alex ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FDOM and WiFi
Vince M. Clark wrote: If I open a terminal and run ifconfig all I have is eth0, lo, and usb0. The wifi is eth0. Is there an address associated with it there? Also check the output of iwconfig. If it has associated the AP then it should say Access Point: and then give the MAC address of the AP. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.9] Wifi very unreliable
Matthias Apitz wrote:
I'm trying to bring up the eth0 with
# ifup eth0
this works very unreliable; in (let's say) 8 of 10 cases it can't
associate to the AP, even not after fresh re-boots and independently if
the AP at my home works with WEP or in my office with WPA;
I found that with wpa_supplicant there was a problem with disconnecting
from an AP. The essid would apparantly not get cleared properly on the
card (although iwconfig would show it as cleared) and until you manually
cleared it, wpa_supplicant would just sit in a loop trying to connect
and getting authentication timeouts. You can see these message if you
run wpa_cli. I worked around it by adding a pre-up that clears the essid:
allow-hotplug eth0
iface eth0 inet manual
wpa-driver wext
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
pre-up iwconfig eth0 essid off
iface default inet dhcp
iface home inet dhcp
This seems to work reliably for me except that I still have to ifdown
and ifup when I move to a different AP. So if manually connecting with
iwconfig works for you, you could try same workaround. Here's what my
wpa_supplicant.conf looks like:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
network={
ssid=XXX
key_mgmt=NONE
wep_key0=XX
wep_tx_keyidx=0
id_str=home
}
network={
key_mgmt=NONE
}
Note that this is with Debian, not 2008.9 -- I'm not sure whether
Om2008.9 supports exactly the same /etc/network/interfaces syntax as Debian.
Cheers,
Alex
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: email
On 30/09/2008, at 3:36 PM, W.Kenworthy wrote: Tried it - at the small screen setting and smallest I could set font the email got only 2 -3 words per line! Almost useless. I guess you're not using Debian then. Here's what it looks like out of the box on Debian, which I suppose has a different default GTK theme. I haven't changed any settings except filling in my account details and switching to small screen view and collapse quotes: http://meshy.org/~ato/tmp/claws-gta02-deb.png I'd actually much prefer a larger font. While I can read that it's not all that comfortable and is particularly difficult somewhere with a lot of ambient light. It's also easy to miss tap on the wrong email in the list as the rows are so small. It also often drags instead of clicks due to touchscreen jitter. My IMAP folder with this mailing list has 6317 messages, it took about 5 minutes to download them the first time I opened the folder. Claws was sitting at about 20% CPU, so it's likely bound by the network speed. Scrolling is a little slow, but no slower than any other app on the FreeRunner that has to redraw a large potion of the screen (due to the glamo bus speed I guess). I'd prefer a really lightweight mail viewer that you can drive with a finger. Probably this would be a good use of Edje (from Enlightenment, what Zhone uses) as it seems a bit leaner than GTK and seems like it'd be easier to come up with something that works nicely with pen input. Perhaps similar scrolling as Aza Raskin's Mobile Firefox concept video [1], but maybe scrolling out the right side of the screen goes to the next unread message, while out the left goes back. Fullscreen scrolling is slow on the FreeRunner, but after testing a bit with Edje, I still find it quite usable, it just looks jerky. Actually one option might be to just scroll part of the screen (say a quarter) as a preview and then update the rest when you release. That should allow for smoother control. The reason I said *viewer* is I'd probably just go with a button to pop open a buffer in Emacs for composing/replying and use a bluetooth keyboard, I don't think I have the patience to compose email with fingers or a stylus. ;-) Cheers, Alex [1] http://labs.mozilla.com/2008/06/firefox-mobile-concept-video/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
On 30/09/2008, at 9:41 PM, Nishit Dave wrote: How about experience? I don't know about programming or system specifics, but as a user, Please don't take this the wrong way. There's a common misconception amongst non-programmers and even some less experienced programmers than anything except compiled code is going to feel slow. This is what Mickey means by prejudice, you're judging that a poor user experience is Python's fault without really understanding how things work. I'll try to explain below. You can test that on the FR - just try Mofi, switch to say the home screen, and switch back. You will be able to see how long it takes before text appears. You mean start Mofi, then switch to a different app and back to the still running Mofi? The window renders virtually instantly for me, there's a little flash of it redrawing but you really have to watch for it and it's not noticeably worse than any other app. I'm switching between xterm and Mofi on Debian on the FreeRunner. The fact I can't see it could be due to Debian using a different GTK theme, I notice the font (and hence all the widets) are much smaller on Debian than on OM 2007/8, so it might render faster. The fact that Python is used for the application logic should have zero effect on the redraw speed. This is because the code that does the drawing (GTK), is actually written in C. The Python code tells GTK once when the window is created, hey I want five buttons and a textbox with this text, in this arrangement, you figure out the rest, it's then GTK's responsibility to redraw them and tell python when a button gets clicked or a menu item is selected. In a normal application that's just using standard widgets and not doing any custom drawing, redraws (like switching between applications) shouldn't execute any Python code at all. When you click scan the interfaces freezes, but that's because it's waiting for the hardware to do the wifi scan. This is poor practice, it should really do the scan asynchronously so the interface doesn't freeze and display a spinner, or at least say Please wait, scanning At least the freeze is not very long. But again, that has nothing to do with the programming language used, it's just as easy to make the same mistake with C. Just from an efficiency point of view, don't you think a compiled program may run better than an interpreted one on a system with limited hardware capabilities. For doing math intensive stuff like drawing, compression, encryption, etc -- sure definitely -- you're trying to do hundreds of millions of operations per second. For app logic, when this button is pressed, turn on the wifi, configure it with these settings and such there's really no difference between a few thousand CPU cycles of tightly optimized C code and a tens to hundreds of thousands of cycles of Python per button click, they're both imperceptible and are both not a bottleneck. Can you tell the difference between 1 microsecond and 1 millisecond? I certainly can't. I guess one might be able to form an argument that Python has a lower barrier of entry for programmers than C so you would be more likely in general to get programs written by less experienced people, but I personally might actually call that a point in favour of Python. ;-) It also by no means implies that Python programs are *only* written by inexperienced people. I hope that makes things a bit clearer. Analysing software performance is actually a very complex process and more often than not it's not just raw computation speed that wins the day. Often your intuitions like that compiled code should be better than interpreted byte-code often do not hold, as good code can often be exponentially better than bad code, while compiling might get you at the very most only a 5 to 10 times speed boost. Also, how caching and memory is used plays a very large role in the performance of programs running on modern hardware. But for typical GUI programs processor speed is usually largely irrelevant as long as the underlying toolkit is not completely broken. If a GUI is not responding it's a problem with how the program is structured, it should be doing something asynchronously instead of blocking the event loop. Cheers, Alex ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.9] Wifi very unreliable
On 30/09/2008, at 10:37 PM, Matthias Apitz wrote: Wireless event: cmd=0x8b1a len=18 Authentication with 00:04:e2:a1:76:0b timed out. Added BSSID 00:04:e2:a1:76:0b into blacklist Yeah. That's exactly the same sort of thing I was seeing, which clearing the essid seems to help with most of the time. I occasionally find the wifi just stops working completely for no apparent reason, ping and all other traffic fails but it otherwise seems normal from the iwconfig and ifconfig output. Other times I get pages and pages of this rapidly flooded in dmesg: AR6000 disconnected from XX:XX:XX:XX:XX:XX AR6000 disconnected from XX:XX:XX:XX:XX:XX AR6000 disconnected from XX:XX:XX:XX:XX:XX AR6000 disconnected from XX:XX:XX:XX:XX:XX AR6000 disconnected from XX:XX:XX:XX:XX:XX AR6000 disconnected from XX:XX:XX:XX:XX:XX AR6000 disconnected from XX:XX:XX:XX:XX:XX AR6000 disconnected from XX:XX:XX:XX:XX:XX AR6000 disconnected from XX:XX:XX:XX:XX:XX AR6000 disconnected from XX:XX:XX:XX:XX:XX AR6000 disconnected from XX:XX:XX:XX:XX:XX AR6000 disconnected from XX:XX:XX:XX:XX:XX AR6000 disconnected from XX:XX:XX:XX:XX:XX without any line breaks and where the XX is the access point address. The only thing that seems to fix it when it does that is to reboot. Cheers, Alex ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialer UI Design
On 30/09/2008, at 11:34 PM, Nishit Dave wrote: If a GUI is not responding it's a problem with how the program is structured, it should be doing something asynchronously instead of blocking the event loop. I just hope everybody follows best practices. At the end of the day, all I need is something that is responsive. Yep. I guess one thing that makes it difficult is that the author of a program usually knows what the program is doing in detail. They'll be thinking something like oh, the program is just enumerating the doodad configuration, that's why the interface has frozen. So they won't really notice the problem because they have a good idea what's happening internally. While a user is thinking, hey I just clicked the settings button and the program has locked up for no good reason, what the heck?!? You can try submitting a bug report about it, but unfortunately, particularly for projects with small communities, the developer is likely to think, hmm, good point, but it'd be more fun to work on adding a new whiz-bang instead, besides it doesn't really bother me, can't they just be patient and wait for it to finish loading? At least in a project with a larger community these sort of small tweaks to how the interface looks and behaves can serve as a fairly safe entry point for developers new to the project to learn the code base. To a developer these sorts of things can really seem like trivial details not worth bothering over, but often they're really quick to fix and can dramatically improve the user experience-- they're just not very exciting to work on.___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Windows CE on freerunner
On 22/08/2008, at 1:19 PM, Vikas Saurabh wrote: I would definitely give it a try. Not intereseted in font blitting, so would stick to the morse code idea :). Would send out the details (and wiki them). Here you go, I wrote an extremely simple example program: http://wiki.openmoko.org/wiki/Bare_metal I don't have a physical device yet, so I've only tested this in qemu, but I can't see any obvious reason why it shouldn't work on the real thing. You should be able to upload it with u-boot in USB console mode using kermit. There should also be a way to flash it on in place of a kernel image or put it on a SD card, but I'm not familiar enough with u-boot to know how to do it. Anyway, for testing it's probably much easier just to send it via USB each time, rather than mucking around reflashing or putting SD cards in and out. You might need to adjust the for loop, as I set it based on the speed of qemu on my PC, it'll probably be completely different speed running on the device. You might like to extend it to flash hello world in morse code, or use an LED or the vibrator instead. You could get really fancy and have it read morse code from someone tapping the AUX button and make simple morse-code shell or some such. ;-) If you try it on a real device, please add instructions on how you did it to the wiki page. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Windows CE on freerunner
On 22/08/2008, at 11:41 AM, Vikas Saurabh wrote: Why can't I fool the bootloader to think that I am a kernel. I always thought boot loaders just load the kernel image, pass it some parameters and start executing them. Indeed, that's exactly what it does. It loads the kernel image into RAM, puts some parameters and a pointer to the ATAGS (which include stuff the kernel command-line) into registers and jumps to the start of the image. See here for details: http://www.arm.linux.org.uk/developer/booting.php I had done this helloworld kind of thing with grub during college...but then maybe grub is advanced. What puzzles me is how exactly? Note that the Freerunner doesn't have a BIOS. When you did it on x86 you probably used the BIOS' printing routines. If you want to do it on the FR you'll have to do your own font blitting etc. If you have a debug board you could print it to a serial port. You can then also use JTAG to debug your code and figure out what is going on. If you don't have the debug board, I guess you could easily enough blink out hello world in morse code through an LED or by turning on and off the backlight or something. It might also be useful to play with it in qemu, just pass in your binary with the -kernel option, you can connect gdb to it and step through line by line (see the qemu documentation for how to do this). As to how to actually do it, it's a bit of a pain. You'll probably need to write a little ARM assembler stub entry point to setup a stack and call your C code. Although you might be able to just reuse u-boots stack, I guess. Then you'll need to compile your code with - nostdlib and link it in a way that ensures your assembler code is at the start of the image, you might need to investigate custom linker scripts for this, I can't remember. You can then use something like objcopy -O binary mycode.elf mycode.bin to pull the raw code out of the elf file the linker generated, so that you can give it to u-boot. Remember also that you won't have any standard library, so you'll have to write every function you want to use yourself (or use something like the OSKit C library) and if you code has a bug it's just going to hang or reset the CPU, unless you define your own error handling code. So yes, certainly doable and a good learning experience but it's not exactly straightforward. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
