Re: [maemo-developers] Ideal way to develop a long-running app?
Hi, you want to write a power savvy application, then. Few basic advices, which are also useful from a performance point of view (sorry if i'm stating the obvious but there's really no trick involved): -avoid polling: polling is generally bad, it's useful only for very tight loops that usually are not involved when writing apps -avoid busy looping (see polling): a significant amount of power is saved only when the processor is really idle, therefore ever call to sleep functions is fine, when you need to wait for something. If it's an asynchronous event that you are waiting for, then you can probably execute some sort of blocking call that will effectively prevent execution of your app until the data it's waiting for is really available -don't perform unnecessary activity: if the screen is blank, there is no need to update it, if you can manage to quickly redraw it when it's unblanked; however you can surely stops animations effects, such as glowing blinking and similar -don't abuse of connectivity resources like bt or wlan I hope this few points will help you br, igor On Tue, 2005-12-20 at 00:28 -0500, ext Peter Kahle wrote: Hi, I'm new to Maemo, and to developing for small/embedded devices in general. I'm trying to wrap my head around the whole concept, especially the 'killable' apps that Maemo enables. I'm trying to figure how long-running but mostly ignored apps like IM clients fit into the whole picture. Sure, you can just mark them killable=false, but that seems inefficient. So I'd like someone to tell me what's wrong with the following scenario: Instant Messaging Application, designed from the ground up for Maemo, architected in 3 or 4 parts: Backend: No GUI but uses libosso, handles all the connection details, buddy list, etc. Stores incoming IMs and uses auto-save to persist them until they're seen. Auto-started on if-up if so configured, or launched by dbus from the front end. killable=false. Frontend: Only GUI, receives dbus messages from backend and displays them to user. Also handles management and configuration of the accounts and buddy lists. killable=true. Launched by maemo-launcher, if that saves memory/time. Statusbar and/or home applet: Displays some sign that there are (not) new IM's that haven't been shown. launches frontend on click/ doubleclick/whatever. So what am I missing? The most likely is that process overhead overshadows the memory saved by only running the GUI portions when needed. And the obvious complexity of the system. What else? Thanks, Peter ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Maemo Alarm/Notifier Interface
On Wed, 2006-01-11 at 11:35 -0800, ext Jason Mills wrote: A few items: 0) The RTC subsystem is served off a chip known as Retu. Most of the ASICs on the Nokia 770 board seem to have nice nordic names to them. :-) 1) The RTC subsystem only supports one future alarm event, and that event may not be more than 24h59m from now. Maximum alarm granularity is +/-1 minute or so. 23h59m if memory serves me well Only Retu can wake up the device from poweroff state at a preset time; unfortunately this is the time resolution that it canprovide. In order to extend alarms and events scheduling one could have the daemon scheduling periodic wakeups (every 24h) till the real alarm is closer than 24h. The granularity problem could be overcome using either a sw timer or an internal HW timer, with better resolution than 1m. It would be programmed by the daemon, after the last wakeup and before reaching the scheduled time for the event. 2) The actual definition of now is a bit arbitrary, because of how the RTC synchronization works. 3) There is a functional, albeit spartan CLI utility already available to talk to the RTC subsystem, -and- to set/check the alarm. /mnt/initfs/usr/bin/retutime 4) The osso_alarm and osso_notifier daemons are missing at least from the 2005.51 Nokia build. No bug is currently filed against this, and I haven't had a chance to file one yet. I think, though am not 100% sure, that these two daemons are required in order to fetch the actual alarm signal from the RTC subsystem. -JMills ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
) Unfortunately these require the device to be running and waste battery. A much more desirable feature for a battery powered system would be having the alarm/timer/event/whatever daemon providing interfaces compatible with these programs so that no change would be requiured in applications using them. I think it would be good idea to have a wiki page? My objective is quite achieved that there is community participation, and people inside nokia need to look into what the community had wanted and what was delivered :) even when I know product schedules and requirements are highest priority [read as , you wont get always what you wanted ;)]. cheers Devesh ext Igor Stoppa wrote: On Wed, 2006-01-11 at 11:35 -0800, ext Jason Mills wrote: A few items: 0) The RTC subsystem is served off a chip known as Retu. Most of the ASICs on the Nokia 770 board seem to have nice nordic names to them. :-) 1) The RTC subsystem only supports one future alarm event, and that event may not be more than 24h59m from now. Maximum alarm granularity is +/-1 minute or so. 23h59m if memory serves me well Only Retu can wake up the device from poweroff state at a preset time; unfortunately this is the time resolution that it canprovide. In order to extend alarms and events scheduling one could have the daemon scheduling periodic wakeups (every 24h) till the real alarm is closer than 24h. The granularity problem could be overcome using either a sw timer or an internal HW timer, with better resolution than 1m. It would be programmed by the daemon, after the last wakeup and before reaching the scheduled time for the event. 2) The actual definition of now is a bit arbitrary, because of how the RTC synchronization works. 3) There is a functional, albeit spartan CLI utility already available to talk to the RTC subsystem, -and- to set/check the alarm. /mnt/initfs/usr/bin/retutime 4) The osso_alarm and osso_notifier daemons are missing at least from the 2005.51 Nokia build. No bug is currently filed against this, and I haven't had a chance to file one yet. I think, though am not 100% sure, that these two daemons are required in order to fetch the actual alarm signal from the RTC subsystem. -JMills ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On Thu, 2006-01-12 at 15:55 +0100, ext Florian Boor wrote: Hello, Igor Stoppa wrote: Only Retu can wake up the device from poweroff state at a preset time; unfortunately this is the time resolution that it canprovide. In order to extend alarms and events scheduling one could have the daemon scheduling periodic wakeups (every 24h) till the real alarm is closer than 24h. i'm not that familiar with the power states of the 770. Does it actually reach poweroff during normal use without turning it off with the power switch? Nope. Omap has basically idling states: -arm idle -big sleep -deep sleep and which one is reached at a certain time depends on which peripherals/clocks are active. Obviously they have different wakeup latencies but all of them are insignificant, when compared to the delay that would be introduced by a traditional suspend-to-disk, which is the closer state to the poweroff that youu are mentioning. The granularity problem could be overcome using either a sw timer or an internal HW timer, with better resolution than 1m. It would be programmed by the daemon, after the last wakeup and before reaching the scheduled time for the event. As long as there is such a timer which can be used that would be fine. Sounds a little bit similar to what we do on the iPAQ. I used generic terms, but the Omap RTC is what I had in my mind. However this fine-grained resolution would be lost when the device is _really_ off and the usual trick to wake up and wait would be required. And the RTC has to be added to the list of wakeup sources that can trigger the transition from any sleep state to running. Greetings Florian -- Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: 770 Power Management and power states --- WAS: Re: [maemo-developers] Maemo Alarm/Notifier Interface
On Fri, 2006-01-20 at 16:17 +0200, Riku Voipio wrote: On Wednesday 18 January 2006 15:07, Igor Stoppa wrote: The price for it is that we had to fix drivers and applications so that they would behave decently, without keeping resources (clocks) constantly allocated and without generating unnecessary activity. The problem is 3rd party developers who are not aware of such situation. for example, a periodically updating statusbar plugin will eat your battery away. STOP DOING STUFF WHEN YOU GET system_inactivity_ind should be in big red letters in the first part of api documentation. They will be, when next version of maemo will be relesed. Those requirements are already However almost everything that optimises cpu performance is good for power consumption too (on a fixed frequency system). If I had to summarise, well it would go like: -1)Thou shan't busy-loop -2)Thou shan't poll poll -3)Thou shan't use libraries that will do 1) and 2) in your place. Then we move to a grayer area, like don't do unnecessary stuff. Screen updates with unlit screen are a good example, but only when the effect of the update is not going to be needed later on. Typical case: blinking, glowing and such eyecandies. But that is GOOD anyway because it means having better code, better algorithms. With this argument, multitasking of windows 3.11 is better since it forces developers to write code so that they give time to others. I disagree: this case is just making obvious to people how to leverage hw that they are already using. Quite different. So the 770 can save power even when you have the device in your hand with the screen lit and a wireless connection open, as long as it's not actually doing something, like rendering a web page. Which is a *very* good thing, I don't think anyone suggested removing current dyntick and PM setup, but rather added suspend as well. Many users have grown accustomed in manual suspending, so perhaps adding no-op suspend button to the powerkey menu would make them happy =) bad habits should be discontinued, not supported. Don't tell me that you would like to have a crank on the front of your car so that you can start the engine =) hmm.. maybe just sending SIGSTOP to all user apps is enough to make them release clocks? I doubt: apps are not directly involved in clocks handling: it would be a possible approach for a suspend-based system, but what is really desirable here is that apps just make sure to avoid keeping the processor busy. The system can take care of itself as long as it's idle. -- Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Automatic Startup of Device with no reason
On Tue, 2006-02-14 at 16:38 +0200, ext Tomi Ollila wrote: [clip] I don't either (have a clue)... but before my first flashing my 770 used to boot exactly 12:41 every day. That's kinda strange because, even if there was an alarm expiring, it should be ACK'ed to allow another one to expire :-/ Now it doesn't. I have that -51-ending version. BTW: I'm keeping my 770 running all the time so the autostart-feature I used to have would not have mattered much lately... [clip] -- Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] How to keep app running indefinitely
On Sun, 2006-03-05 at 16:37 -0800, ext Steven Hill wrote: Hello all: I have written an application for the Nokia 770 that I want to keep running indefinitely - i.e. I want to stop the automatic process that runs in the background and stops applications when there is nothing going on for a long time, or to conserve power - The 770 can still save power even if the backlighting is on, as long as the application doesn't do unnecessury stuff, like busy looping / polling. And that will also enhance the duration of indefinitely when running on batteries :-D can anyone tell me how to go about doing this? Thanks in advance for your help... ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Measuring power consumption of 770
On Tue, 2006-03-14 at 14:53 +0100, ext Claudio Scordino wrote: Hi all. We have a Nokia 770, and we want to study the effectiveness of some algorithms that reduce the number of transferred data in order to reduce the overall energy consumption of the device. To make this study, we need a way to measure the energy consumption of the device or, at least, an accurate measure of the battery charge. Our idea was to remove completely the battery, and measure the energy consumption through a cable connected to an electric socket with a multimeter. However, we noticed that the 770 does not work when the battery is not inserted, even if the device is connected to the electric plug with a cable. Does anybody have an idea about how to make the Nokia 770 work without the battery (just with the electric cable) or how to make such a measurement ? :-O Why don't you just wire a battery to the battery pins and connect your meters to these wires? BTW, is there any pubblic reference to these algorithms? Many thanks. The best, Claudio Scordino _ Claudio Scordino Computer Science Department Ph.D. student University of Pisa, Italy Office: 341 Phone: +39 050 221 3137 e-mail: [EMAIL PROTECTED] home-page: http://www.di.unipi.it/~scordino/ _ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Measuring power consumption of 770
On Tue, 2006-03-14 at 21:42 +0100, ext Claudio Scordino wrote: Does anybody have an idea about how to make the Nokia 770 work without the battery (just with the electric cable) or how to make such a measurement ? Why don't you just wire a battery to the battery pins and connect your meters to these wires? The voltage and the current provided by the battery is much different from the values provided by an electric cable connected to a socket (220V and 50Hz here in Italy). I know that, been there for 28 years :-D That's why our measurement tools wouldn't work with such a small current... Then I would recommend you to fix the design of you measurement setup if you want to get anything useful out of it. You know the battery capacitance, the promised standby time and browsing time, you can figure out the current value that you are going to measure. Many thanks, Claudio Cheers, Igor -- Igor Stoppa, Nokia M / Tampere Finland ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Measuring power consumption of 770
hi, On Fri, 2006-03-17 at 15:44 +0100, ext Claudio Scordino wrote: On Thursday 16 March 2006 00:22, Larry Battraw wrote: I concur; measuring the voltage and current simultaneously (And rapidly) is critical. If I can make the 770 work with only the battery charger (using a kind of bypass instead of the battery), I could use my multimeter for electrical sockets to measure the power consumption of the device... A multimeter for the electrical socket is cheap, and does not require to play with resistors and the Ohm law. As I told you, the problem is that when the battery charger is plugged in but the battery is not, the 770 does not work (and it makes sense, since it is a *battery* charger, and not a power supply for the 770). So, my question is: any idea about how to bypass the battery, making the 770 work with just the battery charger ? I repeat this only because you might have missed my previous advice. You DO want to use the battery, _without_ the charger. igor Many thanks for your help. Best, Claudio -- Igor Stoppa, Nokia M / Tampere Finland ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Measuring power consumption of 770
Hi, On Tue, 2006-03-21 at 09:33 +0100, ext Frantisek Dufka wrote: Hello Igor, can you comment on idea mentioned in this thread about charging the battery fully and then measuring DC current from charger? Is this nonsense or not? Is the battery used when already charged and device is still connected to the charger? I thought most laptops and PDAs work this way i.e. disconnect battery and use only power from AC adapter. How 770 works? Or is there other issues except those already mentioned? One potential issue is that power saving features may be turned off when charger is connected so the device requirements may be higher than when using battery. let's say that if I were to do this measurement, with a production device, I would do it without the charger. About other devices, I'm sorry but I don't think I'm the right person to give detailed comments. You might want to try on the linux-pm mailing list where there are many people dealing in linux on laptops. Anyway I think that to avoid flaws in the comparison between vanilla 770 and 770 with extra power saving algorithms, the measurement should be done in the typical condition that the device is intended to be used mostly: disconnected from the power socket. This test should be done anyway, before claiming that the algorithm is effective. And disabling native power saving features is reasonable only when developing an algorithm that is intended to be a replacement, but the one mentioned at the beginning of the thread was only for data transfer. Maybe a laptop would benefit more from this stuff than an embedded device. igor Frantisek Igor Stoppa wrote: Hi Dave, On Mon, 2006-03-20 at 11:00 -0700, ext david feldman wrote: Will the 770 run with the recharger (or other external DC power source) attached, with the battery REMOVED? This could be same as the case of an expired battery that will no longer accept a charge. In this case, the only power consumed by the 770 would be by the machine itself, not by the battery recharge, nor assited by battery discharge. Unfortunately I cannot comment on this issue because it has _strong_ liability implications: when dealing with the battery there might be potential safety issues, in case of abuse, overcharging and so on, therefore it's one of the few subjects that cannot be discussed openly. I have not tried this idea, and it could cause unit damage or malfunction, so I do not recommend the procedure - Exactly, that's the point. And that's why there are safety mechanisms that will get in the way when trying to counterfait the battery. The original conversation was about validating power saving algorithms and I was trying to help doing it without safety features becoming an obstacle. The simplest solution is to use an original battery and wire it to the connector pins. igor ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] 770 display failure workaround
On Mon, 2006-03-27 at 16:05 +0100, ext [EMAIL PROTECTED] wrote: -- original message -- Subject: Re: [maemo-developers] 770 display failure workaround From: Ed Okerson [EMAIL PROTECTED] Date: 27th March 2006 3:37:59 pm Hi, Does anyone have a patch for the 770 display failure? How about a kernel image? :-) Software cannot fix a hardware failure. --- i heard from a good source that it's a software failure, and of a workaround. White vertical lines, no nokia splash... Then maybe you could let us know and help us save a few bucks in servicing defective units ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Measuring power consumption of 770
Hi, On Tue, 2006-03-21 at 11:31 -0500, ext Larry Battraw wrote: I would advocate building a dummy battery out of a piece of wood/plastic with a small piece of copper clad board (split into three pads) to act as the contacts of the battery. You can then run wires from those to the real battery, passing it through whatever resistor/sensing equipment you want. As soon as you try measuring what goes into the DC jack you're then including whatever losses incurred by the DC-DC conversion from 5V to whatever used internally, as well as issues around having it potentially trying to charge the battery at the same time you're measuring. That, and Igor as much as said that things could behave differently based on whether it detects wall/DC power vs. battery power alone. Honestly, at this point you probably could have built a couple rigs for measuring power from the battery in all the time that has been spent discussing it. :-) Larry On 3/21/06, Frantisek Dufka [EMAIL PROTECTED] wrote: Well I was not thinking about measuring at the mains plug. I was thinking about measuring at the n770 side (5V?) because it is a bit easier then opening the device and messing with battery pins. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers did anybody produce anything? I was hoping that the discussion would bring some interest to the fabulous world of power management also amongst other developers ... -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Measuring power consumption of 770
Interesting ... frankly nothing new to me, but it is a good start point that proves how it is possible to have good performances even with low power devices. Next week i probably won't be able to reply to anything, however soonish Maemo designing/coding guidelines will be available, and i hope we'll have some discussion about battery-friendly drivers/applications. igor On Wed, 2006-03-29 at 19:40 -0500, ext Larry Battraw wrote: Ok Igor, you finally motivated me to do some measurements :-) All measurements were done with a .1 ohm resistor (measured as .0924 ohms using the 4-wire method) and a HP 3456A 6.5 digit voltmeter. The meter was set to the slowest (most accurate) sampling rate, performing the calculations on-the-fly for the Ohm's law derived current. I did _not_ measure battery voltage, so wattage calculations are not possible. This shouldn't be a big deal as the current will give a good indication of what the device is doing at the time. I've attached a CSV file of the spreadsheet for results. I tried to hit most of the use cases people might be interested in, and everything is pretty impressive except for leaving MP3 files paused in the media player, which consumes over 10 times the normal current while sleeping. Larry On 3/29/06, Igor Stoppa [EMAIL PROTECTED] wrote: Hi, On Tue, 2006-03-21 at 11:31 -0500, ext Larry Battraw wrote: I would advocate building a dummy battery out of a piece of wood/plastic with a small piece of copper clad board (split into three pads) to act as the contacts of the battery. You can then run wires from those to the real battery, passing it through whatever resistor/sensing equipment you want. As soon as you try measuring what goes into the DC jack you're then including whatever losses incurred by the DC-DC conversion from 5V to whatever used internally, as well as issues around having it potentially trying to charge the battery at the same time you're measuring. That, and Igor as much as said that things could behave differently based on whether it detects wall/DC power vs. battery power alone. Honestly, at this point you probably could have built a couple rigs for measuring power from the battery in all the time that has been spent discussing it. :-) Larry On 3/21/06, Frantisek Dufka [EMAIL PROTECTED] wrote: Well I was not thinking about measuring at the mains plug. I was thinking about measuring at the n770 side (5V?) because it is a bit easier then opening the device and messing with battery pins. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers did anybody produce anything? I was hoping that the discussion would bring some interest to the fabulous world of power management also amongst other developers ... -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Frustrating power downs...
Hi, On Tue, 2006-05-02 at 10:49 -0400, ext Chris Bare wrote: I am wondering if this is a hardware or software fault? Does anybody else see this happening? Are there any hints on what might be tha cause? And especially if this can be fixed? I too have seen mysterious power downs. So far I haven't been able to detect a pattern. Sometimes I've plugged it in to recharge and when I came back and opened the cover it had powered down. I wonder if a surge or static shock might cause it in this case, high unlikely, whatever would be able have such an effect would probably fry it for good. but other times I've just found it in the off state when I know I left it on, and the batter still had a charge. It would help to know which sw you are running: is it vanilla or are you using a custom set of packages? -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: [maemo-users] Constantly rebooting
Hi, On Wed, 2006-05-03 at 09:31 -0400, ext Jeremy Mcnicoll wrote: Is there a way to restore my 770 if after scp'n a big file to my 770 I now have it constantly restarting? Can I use the flasher to restore it? Yes, flasher should be enough. Is there a magical key sequence that will allow me to blank out the flash? help? ___ maemo-users mailing list maemo-users@maemo.org https://maemo.org/mailman/listinfo/maemo-users -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
On Wed, 2006-05-10 at 14:45 -0500, ext Larry Battraw wrote: On 5/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext Dave Neuer Sent: 04 May, 2006 23:39 To: Kothari Devesh (Nokia-M/Tampere) Cc: maemo-developers@maemo.org Subject: Re: [maemo-developers] Too busy to accept help? I'm not complaining I can remove all software for which I cannot access and re-publish the source code and all of the hardware capabilities (power management, DSP and whatever other little doodads Nokia packed in there) are still accessible; I can compile a kernel and a corresponding initfs and root fs from source. Etc. Those are the goals but i have to admit we have not yet reached there. We are working on most parts e.g you can compile your own kernel, create your custom rootfs, remove stuff etc with package management. There are still certain piecies which are either not in our direct control (e.g TI/DSP related stuff), and some which we just cant give out (e.g battery related software). I'm curious-- when you say you can't give out the battery-related software are you referring to the power management system as it stands OR any of the details about how to talk to the battery control interface? I can understand either one, as the power management is difficult/proprietary, and the battery interface might allow someone to overcharge or destroy the battery. That being said, it would be nice to have an entry in /proc of the raw battery voltage and any additional available power info. Larry Hi, please note that the the vast majority of 770 power management stuff is opened already, since it lives in kernelspace. -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] device powers on at 8am every day?
On Fri, 2006-07-07 at 13:41 +0300, ext Weinehall David (Nokia-M/Tampere) wrote: On tor, 2006-07-06 at 11:10 -0700, ext George Farris wrote: On Thu, 2006-06-07 at 10:49 -0700, Collin R. Mulliner wrote: Hi, I have a very strange bug/feature. My device (running IT2006 final) powers on every day at 8am. I don't have an alarm set in the clock application, so what could this be? To be clear, this happens while the device is shutdown and the cover is over the display. Any ideas, may be I miss a new feature? Interesting. I also experience auto power on. For example: Every evening I turn my 770 off before going to bed. I know it was off as I checked this morning before I left the house. When I got to work I pulled the 770 out of my pocket and there it was on. This isn't the first time this has happened. No it was not turned on in my pocket. I have turned it off at night and come back in the morning and it has been on, very weird. I have set an alarm before but don't have one set now unless once you set it the 770 never ever goes off again:-( Try removing the battery for an hour or so, to let the backup battery lose the time (you'll have to set your clock again after this), then insert the battery again and see if you have the same problem. If this solution works, it's probably a bug in the alarm software that does not reset the RTC-alarm after the alarm has been acknowledged. For the internal RTC, 15-20 minutes is the expected life support time, so a little bit more than that should be enough. -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] initfs hacking questions
On Fri, 2006-07-14 at 09:01 +0200, ext Frantisek Dufka wrote: Hello, Hi, I'll reply only to those points I'm 100% sure of, sorry for the incomplete answer. Probabaly Devesh can provide some info on the legal side. recently I tried to modify initfs to allow dual booting and got some questions: Is there a way to get code of pressed HW key in /linuxrc script? There is command that waits for keypress. There is also something is sysfs for detecting battery door, shell, headphone jack state but nothing simple for keys. Anything I missed or do I need to compile my own executable? Which scratchbox uclibc toolchain should I use? There are two ones here http://scratchbox.org/download/files/sbox-releases/0.9.8/tarball/ sf (softfloats) and non-sf. What exactly is testserver? initfs is full in IT2006 so I need to delete something. I deleted testserver and its shared libraries and device seems to boot. Is this needed for device operation or it is really for factory testing or something like that so it never gets executed automatically on boot. Only for test mode and factory. And you are right: it's a good target to free space =) How do I run those test anyway? Can I distribute hacked initfs? If not, is binary patch OK? Which functionality I loose when dsme is not executed from /linuxrc (battery charging?) WDs kicking, sw watchdog for processes, battery charging, device mode control and backlighting(almost certainly). Is is a good idea to use cal-tool frequently (i.e on each boot) to set various flags (root device,..)? This get stored to flash, how it is with wear leveling of config partition? Thanks for any answers. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia does not switch on [IT2005]
On Mon, 2006-07-31 at 16:03 +0200, ext Benjamin Zeller wrote: Hi @ all, i have a problem with some Nokia 770. My Company bought about 70 Nokias for a customer. The Nokias are with IT2005. After testing every device there are about 20 that don?t work. You can not switch them on if they are not plugged in ( yes they are all fully charged ;-) ). The screen leaves blank and it seems that nothing happens. But connected to the socket they somtimes switch on. Is there something known about a Hardware/ Software /manufactoring issue ?? regards benjamin Hi, have you tried swapping batteries, i.e. taking a battery from a working one and using it to boot one of those who are not behaving properly? -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo alarms == retutime
On Mon, 2006-07-31 at 10:34 -0400, ext Michael P. Lococo wrote: I think what Chris, me and others are really looking for is the alarm framework for application notification, not the mere RTC alarm. There is no alarm framework I would have expected such framework after the longish discussions on the mailinglist some time ago (effectively more than half a year ago). Since there isn't any calendar application in the 2006 software edition, management didn't really prioritise a sane alarm interface. There is is substantial user demand, though, and there are three different community-based or third-party calendaring applications that are all hamstrung by the lack of an alarm facility. It seems fairly clear at this point that: 1) The need for an alarm framework is not a passing fancy. 2) In order to be done sanely, it must be centralized... either as a single community project or as a Nokia supported part of the product. Applications cannot reasonably be expected to handle it without tripping over each other and killing battery life with polling. Mike I think Devesh is the proper interface for this sort of discussion, since he takes care of harmonizing this sort of internal/external needs/demands/activities. And he's your best chance to get any statement ;-) -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Re: 770 stopped booting
On Wed, 2006-08-09 at 10:13 +0200, ext Fionn Behrens wrote: On Tue, 08.08.2006, 16:54 -0400 Larry Battraw wrote: Silly question, but have you tried leaving it on the charger for an hour or so? I've seen quite a few questions with similar problems and unless you've loaded some new packages recently (And it doesn't sound like you have) this is probably due to a low battery. Unfortunately it doesnt seem to be so easy. Because once you hook the unit up to the PSU it also boots into some kind of charging display. With my unit, this fails, too. So it keeps doing endless reboot cycles once I apply external power. I am afraid if I did that for extended amounts of time, it would do no good to the backlight which goes on an off all the time. Hi, the backlight is provided by LEDs so it shouldn't suffer much from being switched continuously. About the cycling: hard to say anything without logs, but if reflashing doesn't work (meaning that you cannot even reflash a full image), chances are that the bootloader got corrupted and probably only cold-flashing will do. That's something the service points can do, or you can do it yourself with one of the unofficial cables that you can find on the net (either schematics or seller). Of course it is very likely to void your warranty, so i strongly advice to check with customer service about it. -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-users] Re: [maemo-developers] Future features for Maemo Desktop (Task Navigator, Home, Status bar)?
On Fri, 2006-08-18 at 18:09 +0100, ext Peter Robinson wrote: snip - Expanded power management. This is more kernel than actual UI but some of the things that I've seen around for projects like OLPC where if the sound driver isn't used for a couple of seconds its shut down etc. Things like the USB port, in the general scheme of things, aren't used very often so could (not sure if they are all ready) be shut down most of the time to save battery (saw a blog entry somewhere where someone played with the shutdown of usb when not in use and saved a couple of watts). Done already, check the power management and drivers code. Next? Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: [maemo-announce] New Nokia 770 software image available
On Fri, 2006-11-03 at 11:09 -0500, ext Michael Wiktowy wrote: On 11/3/06, Frantisek Dufka [EMAIL PROTECTED] wrote: Daniel Stone wrote: you can't do the bootloader, kernel, and initfs from userspace. Well, you can, but it really isn't a good idea. It has no chance to be completely safe, something may go wrong pretty easily (like random device reboot). There is no safe order in which you can make the upgrade of those specific parts (bootloader,kernel,initfs,rootfs) and still have device bootable if the process is interrupted. That is also something that could be said for the flashing through the USB method too. If that is interrupted then you are likely equally unable to boot your 770. No: only the bootloader is the critical part, since it takes care of flashing anything else. As long as the bootloader replacement succedes, you can always refrash the rest. If not, well, you have just become the happy owner of a brick. Service point can help. However, you can always try again ... just like you could always fall back to the USB method if the updating internally fails. What might really complicate this a great deal is if the N770 kernel uses those run in place features I recall reading about that was introduced for embedded systems that causes the kernel to just run apps directly from flash memory rather than copying them to RAM and then running from there. Writing directly to a program space that you are currently running is the road to nastiness. No, 770 doesn't and anyway NAND flash is not very xip friendly :) -- Cheers Igor Stoppa [EMAIL PROTECTED] (Nokia M - OSSO / Tampere Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] kernel source for 2.2006.39-14?
On Wed, 2006-11-08 at 14:31 -0500, ext Dave Neuer wrote: On 11/3/06, Kimmo Hämäläinen [EMAIL PROTECTED] wrote: On Fri, 2006-11-03 at 12:58 +0100, ext Frantisek Dufka wrote: ... I understand it may be hard to make everything ready at once but still I don't like it and think you should make the sources available at the same time as binaries. After all this firmware is 5 weeks old, there should be plenty of time to prepare the sources while lawyers or QA do its job. So, next time we'll release the binaries only when the sources are available ;) When will Nokia release the source code to the time machine they are apparently using to build binaries from source which isn't even available yet? I definitely want that! Dave It's very easy, just get yourself a legal department, any will do, it will provide instantaneous time warping =) -- Cheers Igor Stoppa [EMAIL PROTECTED] (Nokia M - OSSO / Tampere Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] RE: brightness Re: [maemo-users] Re: Storage/Sleep Issues..
On Thu, 2007-01-25 at 14:54 +0200, Salminen Karoliina.T (Nokia-M/Helsinki) wrote: Hi, Nothinig prevents you from creating a sysfs entry wich returns tahvo_get_backlight_level() or even a proc one, if you really are into that sort of thing. There is such entry - /sys/devices/platform/omapfb/panel/backlight_level One related thing would interest me: - would it be possible to crank the level up further than the 127 the number in /sys/devices/platform/omapfb/panel/backlight_level states when the display plugin has the maximum setting? i'm no hw guru, but afaik, no, we should already be providinig the maximum brightness possible. As I am part of the engine monitor and EFIS project, I would be interested if there would be some way to increase the daylight readability in challenging environment with direct sunlight hitting the screen on airplane panel through a clear canopy above the clouds where there is nothing blocking the sunlight coming with full power directly to the display where you are supposed to see some gauges. The N800 display already is somewhat better than the N770 for that, but more would be of course always better than less taking in addition that panel mounted airplane EFIS displays commercially available use ultra high brightness displays. In this environment the battery consumption is non-issue because the device is plugged all the time to charger. Ok, it might be also so that the 127 is the maximum the physical display panel can output and no more can be achieved, but I was just wondering if it wasn't. This may be fruitless speculation, but I would be glad if anybody of the hw gurus could enlighten me some? Thx. Best Regards, karoliina -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia M - OSSO /Helsinki Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: RFC: n800 suspend to ram
Hi! On Wed, 2007-03-07 at 05:01 -0600, ext Mike Baker wrote: Hi; I've been doing some experiments with powersave on the n800. Good, that's really good news. It seems you can't just put the n800 into suspend mode simply by doing a echo mem /sys/power/state, the retu watchdog kicks in if you leave it in that state too long. There is a flasher command to disable the retu watchdog, although through some horrible mistranslation it only stops the system from refreshing the watchdog -- it still goes off and brings down the system. Luckily there's an alternative, messy as it is - The wd in retu is a deadman's button. It comes from phones legacy, where a rebooting device can disrupt communications for others as well. In the tablet it still makes sense to have it for avoiding that if the devices becomes stuck, it also drains your battery. Refresh the retu watchdog, this will give you 64 seconds until it needs to be refreshed again. Next, set the retu rtc alarm; you only get one minute resolution, but that's jsut enough. Once the alarm is set, suspend; the alarm will wake the device out of suspend mode and the cycle repeats. Theoretically it's good; practically, i'm not so sure. The reason being that with runtime power management we get away quite cleanly with drivers not having to save/restore their state (we only ask them to use the clock fw). You probably would use suspend as an alternative to long idle periods, such as overnight, maybe using an idle timer to detect it. However, because of the 64s constraint, the energy price is not little when doing the wd kicking from userspace. A more power efficient solution (at the expense of stability) would be to do it from kernelspace, _whitout_ triggering the whole system thaw and re-enabling only those drivers required to talk with retu (since it contains both the rtc and the wd). But that's a very custom hack. Attached is a script to suspend the n800, the script is designed to run in the background and take advantage of the softoff state. (If you haven't done so already, I'd suggest editing /etc/mce/mce.ini and setting the power button to softoff). Once the softoff state is detected, the script will attempt to force the device into suspend. The script will spit out debug messages as it's run - wait the script is waiting for a softoff (backlight off, touch disabled) it will poll the system in 10 second intervals refresh updating the retu watchdog sleep XX suspending until rtc alarm in XX seconds awake (asleep X:XX:XX) device came back from sleep state before the alarm; likely the result of user interaction. X:XX:XX represents the total amount of time the script -attempted- to sleep for. Caveats - - the script must be run as root and should be run locally (not via ssh) - the device doesn't always suspend; particularly when the charger is attached - loadavg after exiting suspend is extremely high; probably miscalculated - the dsp REALLY hates it when you suspend with dsp activity yeah, that too There doesn't seem to be a good way of suspending dsp activity; I've read through the dsp documentation (http://dspgateway.sf.net) which seems to suggest the 'dspctl suspend' and 'dspctl resume' commands, which don't work. Once the dsp has crashed I can't find a reliable way to even restart it without rebooting. Requested - - completely disabling the watchdogs I'm not sure that will ever be an option, with the device having radios. - help with dspctl/dsp_dld system The latest version of the script can always be found at http://mbm.openwrt.org/n800/suspend.sh Never the less, congratulations for the effort. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia M - OSSO /Helsinki Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: How to install Xepphyr deb file on Redhat which uses rpms?
On Wed, 2007-03-21 at 09:33 -0600, ext Paul F. Sehorne wrote: Thanks to advice from Kimmo Hämäläinen, I now have my first Hildon program (the sample) compiled and ready to run. Next is to get Xephyr running. I'm running Redhat which uses RPMs. How do I install the Xephyr DEB file? Thanks, what about alien? -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: 0xFFFF: GPL-licensed flasher for n770 and n800
On Fri, 2007-04-13 at 09:23 +0300, ext Daniel Stone wrote: On Thu, Apr 12, 2007 at 06:59:55PM -0700, ext Carl Worth wrote: On Sat, 7 Apr 2007 12:07:33 +0200, pancake wrote: The past week I released a gpl-licensed flasher for both Nokia Internet Tablets. Fantastic! I've been very much looking forward to the time where there would be instructions for downloading an entirely Free flasher and Free image to flash to bring the unit into a bootable state from scratch. So this addresses an essential missing piece in that. What else might be missing? Depends on what you mean by 'from scratch'. If the unit does not have a bootloader _at all_, then you need to flash a bootloader via JTAG. But that's mildly convoluted. Serial console is the usual way to go. There is rom code that provides this facility. Of course a serial programmer (aka flasher) is needed. What elements go into the Nokia fiasco image that cannot be built from Free source? The bootloaders (xloader, 2nd, secondary). Of those, which must not be left out in order to have a bootable device? If your device already has bootloaders, you don't need to flash them again, but you do need to execute this piece of non-free code every time you boot, or flash. The alternative would be for us to publish the required mux settings and so on. Which i think is pretty silly that we haven't done so far. Disabling muxing in kernel as we are doing now, certainly doesn't prevent one from usinig the kernel to write directly to the supposedly inaccessible registers. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: 0xFFFF: GPL-licensed flasher for n770 and n800
On Sat, 2007-04-14 at 19:39 +0200, ext Visti Andresen wrote: On Fri, 13 Apr 2007 21:47:47 +0200 Visti Andresen [EMAIL PROTECTED] wrote: On Fri, 13 Apr 2007 09:47:01 +0300 Igor Stoppa [EMAIL PROTECTED] wrote: Depends on what you mean by 'from scratch'. If the unit does not have a bootloader _at all_, then you need to flash a bootloader via JTAG. But that's mildly convoluted. Serial console is the usual way to go. There is rom code that provides this facility. Of course a serial programmer (aka flasher) is needed. Are you telling me that the N770 has a ROM (not EEPROM or FLASH) that allows one to rewrite the Flash no matter how badly you screwed any part of the programmable memory? I'm asking as I have until now been quite cautious in my experiments with the Nokia, knowing that there is a way to recover the device (by my self) would put my mind at ease :) If it has such a marvellous ROM bootloader, is it by any chance one with any documentation regarding the protocol? Something like UBoot would really nice :) I have been digging around and it actually seems that a omap1710 has a boot rom? It's a feature common to many SoC. I don't know how detailed the information available in the public TRM is, but i would recommend googling for web sites devoted to phone hacking. Note that it's up to you to figure out if tampering with the device at such level is legal in your country. I really have no clue. The outcome could be at worst a dead device (not bricked, you can really kill the processor if you get the connection wrong or exceed the voltage levels) or anyway a device bricked in such a way that will probably void the warranty and make it necessary to get it re-flashed by the service point. On some development boards one has to move a jumper for the bootloader to be run (changes the memory map), and it isn't uboot but an iboot/ihost bootloader, capable of flashing over usb? Do we have to hold down some button in order for the boot loader to start(at powerup)? No, i wish it was so simple. Unfortunately the internet tablets have inherited some legacy features from the phones, features that are purposefully intended to prevent or at least make it difficult to do a cold-flash. Incidentally this detail comes in the way of disclosing informations since they would be useful also for hacking phones (which has significant legal implications). An omap1710 could be seen as an OMAP5912 according to http://focus.ti.com/general/docs/wtbu/wtbusplashcontent.tsp?templateId=6123contentId=4753 http://focus.ti.com/docs/prod/folders/print/omap5912.html contains data sheets for this processor http://tree.celinuxforum.org/CelfPubWiki/FlashRecoveryUtility seems to be an open source iboot a like program to be able to flash an omap cpu over USB. The protocol seems quite straight forward iirc usb flashing requires a different hw configurations (done by connecting resistors of a certain value to the proper pads) we should have OMAP configured for serial port so i don't think that option is viable. So maybe we have here something to add to the wishlist for maemo, albeit i'm not sure that it includes hw features. I think the opinion from the internet tablet hackers would be valuable. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: watchDog
Hi, On Tue, 2007-06-26 at 19:47 +0200, ext Visti Andresen wrote: On Mon, 25 Jun 2007 11:46:46 +0200 Massimo Pace [EMAIL PROTECTED] wrote: Hi, Is it possible to disable the watchdog? Thanks. Massimo The flasher should be capable of disabling the watchdog Here's the output from the Linux flasher utility, read up on the flags no-omap-wd and no-retu-wd the retu wd cannot be disabled, it's a powerdown wd and is controlled only by hw means (resistance on a specific pin) which are not available in standard devices. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Internet Tablet Power Management presentation from linux-pm summit 2007
Hi, this is the presentation we gave last week in Ottawa at the pm summit. It is the first step in improving our communication process with the community and give a preview of what we are working on. http://maemo.org/midcom-permalink-0c828d202f2011dc9945e502835830f130f1 It contains a brief overview of what is already shipping in the 770 and the n800, but the main focus is about our work in progress. Comments and questions are welcomed. However, please understand that intentionally there is no reference to dates or future products: being wip it is under development and evaluation, therefore we cannot make any commitment till the job is completed. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Wed, 2007-07-11 at 10:08 +0200, ext Frantisek Dufka wrote: Thanks Igor, it is quite interesting. Maybe there is a bug on page 15 with DSP frequency for OP 0, shouldn't the 133 be 233 or 333 (unless you need to slow it down because of speeding up the arm core to meet some power requirement)? No, no bug unfortunately, simply TI doesn't support the combination with DSP @ 266 MHz (that would be the proper value). Of course ymmw and some chips probably can cope with it (actually there are also thermal issues so i bet that most OMAPs can do it at room temperature) but in order to provide a certain yield value, the constraints on the operating range are stricter. I certainly will run my tablet at higher speed and/or lower voltage; finland makes it unlikely to incur in heating problems ;-) Does it mean the arm core in current N800 can run at 400Mhz? Yes, the data is for stock N800 (we have this SpeedSorted OMAP2 that can run with ARM @ 400MHz). As for dynamic voltage and frequency scaling did I understood it correctly that even if lower voltage means considerable saving (even if task runs longer) it is almost not worth the hassle due to other issues (latency of voltage/frequency change, static power consumption of other parts, hard prediction of future)? It just means that the whole system must be considered, not only the processor. But we do have significant benefits at using the lower OP in many cases. It could be that there are benefits at using OP3 simply because of problems in the current implementation of the sw stack, so fixing them would make DVFS less attractive. But while we get all the issues fixed, DVFS seems to help, for example in reducing boot time and applications load time. Or how big savings do you expect overall from voltage/frequency scaling when the device is mostly idle (i.e being mostly waken up by inefficient system or apps waiting for something and not hogging the CPU). Or maybe the question is how efficient is the system currently, is there something like http://www.linuxpowertop.org/ for omap to see what can be improved or what cannot and could benefit from lower frequency/voltage? Yes, eventually our goal would also be to provide users with means to evaluate themselves 3rd party applications. I remember several times somebody complaining about battery life after installing some 3rd party application that had not gone through our validation process. Not that I'm really blaming the developers: one can do code review up to a certain point, but without proper tools it's hard to evaluate how pm friendly a caertain application is. Do you plan to have user selectable power/speed profiles to let people choose whether they want slower system or shorter battery life? My personal belief is that the user should not have to care about this: something is broken if the user has to be involved. The system should have all the info (and means) to run at good enough speed when needed. It's a similar case to sleep while idle vs user-controlled suspend: just because old devices were doing suspend that doesn't make it desirable. Or do you suppose there will be good enough cpufreq governor so it is not needed. On demand should fit the bill, with some fixes. Conservative is useles sfor every practical application, in our case. Or do you consider some API so apps can suggest how fast system they want (i.e. media players, games, emulators vs book readers)? You mean QoS. Yes, that seems to be the general understanding. Intel too is going in that direction and they have very serious problems when comparing their hw against OMAP, which is designed from ground up to be pm friendly. OMAP2 has retention mode and the transition to/from retention is much faster than any OP change, so race-to-idle is more important on OMAP than on x86 devices. I would expect Intel to get QoS usable before us because of a more urgent need. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Wed, 2007-07-11 at 13:28 +0100, ext Andrew Flegg wrote: On 7/11/07, Igor Stoppa [EMAIL PROTECTED] wrote: [snip lots of interesting stuff] It's a similar case to sleep while idle vs user-controlled suspend: just because old devices were doing suspend that doesn't make it desirable. This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. Why not just put it in offline mode and lock the screen and keys? That's what i do and it simply works. The only drawback is that with sane applications you would get only 12 days with a full battery. I do admit that in some extreme case it might not be enough, but on OMAP2 it doesn't justify the hassle. I'd rather spend time and resources in fixing kernel and applications to make sleep while idle as close as possible to suspend to ram. Plain suspend to ram (or disk), imho, sucks, because it produces a useless brick till it is forcibly resumed. I think it would be much better to simply let wakeup events happen, but make sure that only the _useful_ ones happen. The user should be able to configure wakeup sources, certainly, even up to the point of saying: wake up only for power button, but the system should manage itself automatically. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Wed, 2007-07-11 at 16:01 +0300, David Weinehall wrote: On ons, 2007-07-11 at 13:53 +0100, ext Andrew Flegg wrote: On 7/11/07, David Weinehall [EMAIL PROTECTED] wrote: On ons, 2007-07-11 at 13:28 +0100, ext Andrew Flegg wrote: This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. So what you want is basically the Soft Poweroff option that's available [...] but with some minor tweaks? Yes, exactly :-) I guess that can be arranged =) Cool. Is it anything I could do straight off (I can also imagine a control panel applet to allow users to customise[1] this suspended state as Igor describes), or does it still dependent on some relatively closed/unhookable infrastructure? systemui.xml (sorry, not conf as I wrote in my previous e-mail) file supports callbacks, to get customised behaviour. [1] Sound on/off, network on/off being the obvious ones I can make that configurable through /etc/mce/mce.ini Sorry to ruin the party, but as Mike Baker wrote some time ago (RFC: n800 suspend to ram) the suspend wouldn't be forever anyway: Mike's script or something similar should be used. So there _would_ be anyway some activity. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Wed, 2007-07-11 at 14:29 +0200, ext Frantisek Dufka wrote: Igor Stoppa wrote: I certainly will run my tablet at higher speed and/or lower voltage; finland makes it unlikely to incur in heating problems ;-) CPU temperature sensor might be useful to guess the limit and cut the speed down in case one is not in Finland :-) Is there one? There is one between omap and the combo chip memory, but it is quite sucky. Not that we haven't thought about it. If there is some spare time (yeah, right) we could try to use it, but TI is unlikely to support it and therefore i'm quite confident it will ever ship (albeit it would be quite interesting since it would allow much more aggressive trimming down of the voltage). Well, I'm not sure but maybe when being conservative with power saving and when some hints are applied (i.e some API) it could work. I'm mainly thinking about CPU spikes when applications are starting. I fear the system will not react quickly enough with 'overclocking' when application starts since otherwise the device does nothing before and after. But this specific problem could be solved with some hints done from application launcher or maybe kernel or libc (exec/fork call) itself. Ondemand starts by cranking up to the max the frequency. It cannot be beaten. I'm not sure how linux currently does it on x86 (shame on me, using XP on laptop and linux only in vmware) but my experience with RMClock on XP (http://cpu.rightmark.org/products/rmclock.shtml) is that it is hard/impossible to tune it in such way that application startup is not slower and you still save some power. OMAP has retention so it's not that critical to fine tune. x86 otoh doesn't, afaik, so it would require more aggressive tuning [snip] You mean QoS. Yes, that seems to be the general understanding. Yes that's it. Didn't know this term is used also in power management, though. I use it :-P others are more shy about it, but when asked they admit that it is what they have on their mind. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Wed, 2007-07-11 at 16:26 +0300, ext David Weinehall wrote: On ons, 2007-07-11 at 15:16 +0200, ext Visti Andresen wrote: [snip] I could suggest using a double click on the power button First click opens the Device mode dialogue. Second click suspends the device. The idea is great, IMHO, but I doubt that Nokia's UI-team would agree; on a Nokia phone, pressing the power button when the device menu is open acts as cursor down. On our device it just ignores the press completely, which was an acceptable behaviour too. Adding a totally different behaviour would probably be regarded as too complicated for the user, or something =) We are doing open software, right? So let's provide a good mechanism that supports more advanced interactions and even if we have to officially ship with a lame set of choices for the average user, others can implement more advanced features. From the discussion so far, I'm getting the impression that what people are actually asking for is a way to create very customised extra profiles. Example: Create Night mode and associate it with the shortcut (double press on the power button): -disable chat/presence -leave only VOIP with a subset of users actually able to generate rings -kill all the led signalling - All these actions should be (are they already?) commands to be sent to the interested application/daemon through DBUS, so a simple script, paired with a command line dbus interface would be sufficient. It's just a matter of having available the list of commands/requests supported by every application over DBUS. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Thu, 2007-07-12 at 08:48 -0400, ext Brian Waite wrote: [snip] So I have another request, Can we possibly have different profiles for battery/powered? I think it is really important to be able to say if I am plugged in do not go offline because I want to get my VOIP calls, but if I am on battery do something more miserly. Again, we have the profiles already, I would just like to be able to use different profies for different power conditions. We are shipting in the metaphisical field of centralised vs. distributed control. What you are asking for is certainly doable for a device meant to run few well known applications, like a phone. On a tablet it seems cleaner to just broadcast the plugged/unplugged event and let the apps deal with it by themselves. You are proposing something similar to screen timeout on a laptop, that can be set separately depending on presence of external power. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
Hi, On Wed, 2007-07-11 at 05:35 -0700, ext Andy Mulhearn wrote: Apart from shutting off the sound thing thsi looks like a N770 cover on mode. Is that about right? Even if it's not, it's one I would like to have as well - as a put away for a while mode, I understand the need, but there are so many different (and rightful) opinions that rather than changing the standard interface, I'd like to have a cusomisation interface for system-level features plus let applications have their own local settings for certain standard dbus events. Then everyone can configure things to his heart content and we don't impose our opinion on anybody. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On Thu, 2007-07-12 at 10:21 -0400, ext Brian Waite wrote: [snip] What I am asking for is a setup like my laptop where I have a complete power profile for the system. [snip] I see no technical problem in maemo providing the means to implement it. AFAIK there might be legal and IP related isses on us just shipping the feature, as Nokia has a patent on phone profiles and it seems that it's one of the family jewels :-/ It beats me why there isn't any issue with laptops doing basically the same thing. I leave it to someone more versed in legal/IP issues. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Java acceleration/Jazelle
On Wed, 2007-07-18 at 11:01 +0100, ext Simon Pickering wrote: Yes, in an ideal world this would be nice, but I'm doing okay with ssh/sftp over wifi for the time being. Out of interest, does the N800 actually have solder points for a serial port at some known location? There are websites, such as mobilchips that distribute schematics and assembly instructions for phones and other devices. They haven't managed to get an N800 manual, but they have the 770 one. I don't know how legal it is for them to distribute such documents and for people to download them, so this is _not_ a written permission or anything similar, just a comment. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
On Tue, 2007-07-31 at 13:11 +0300, ext Lauri Leukkunen wrote: You could take the current emulate mode as a template and start adding to that your exceptions. Maybe it's a matter of sb developer's vs sb user's point of view, but I would rather consider sb to be the exception ... -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
Hi, On Wed, 2007-10-24 at 15:14 +0300, ext Kimmo Hämäläinen wrote: On Wed, 2007-10-24 at 14:56 +0300, Marius Vollmer wrote: Kimmo Hämäläinen [EMAIL PROTECTED] writes: Wrong. It would depend on the context and language. Yes, it COULD, fer-crying-out-loudly. :) We have the data now to figure out whether it actually DOES for the set of our supported languages. 'For the set of our supported languages' -- quoting you -- 'that way lies madness'. You would need to do this verification every time you add a new language, or change the context a bit. And what happens when you add a new, more 'context-sensitive' language? We change the code. Simple. Providing unneeded context is bad in my opinion, and the way we do it with the logical ids is excessivly ugly. You also need to retranslate and test all the supported languages for the new strings (some of that you could maybe automate). Changing the code is the easy part. Why not make the engineering English unique, and use it instead of the logical ids (OK 1, OK 2 ;)), hey, we do it with variable names in code already... FWIW, here's my 2cents: I don't use localised images simply because i find revolting what is the commonly understood right way of translating english terms to italian and therefore i wouldn't really be of any help. Hence my contribution in that direction is nil. Then enters the logical_ids: I get 8cm long strings on a button that is designed to accept 6-8 characters (btw, that also would be affected by certain localizations, but let's ignore it for the moment). So even where i _could_ be of some help in providing feedback, I cannot because i have no clue of what the logical id means. And i am not going to read the UI specs just for that. I suppose this applies to many others, here. So logical IDs semm to be a nice way to hide away logical errors. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hi, please find my (very biased) comment below. On Mon, 2007-10-29 at 07:42 +0200, ext Quim Gil wrote: Hi, On Sat, 2007-10-27 at 22:41 +0200, ext Tim Teulings wrote: Hmm, you never would get my applications ;-) I'm pretty sure that I won't fulfill all the requirements. Maybe then rephrasing the sentence? This is not an official certification process, it is just a tool to get developers aware about the level of quality expected in extras. But. For example being good at battery time is a tricky thing to test If this is true then we need to provide better documentation and tools to test/debug. At least the big issues should be not difficult to detect (you app is draining the battery in 24h even if running just in the background). I guess any developer can get some help by getting the packages in extras-testing and expressing the will to push them to extras. If a developer is not concerned at all about power management and hasn't got a clue about how his app is treating the battery, then his software shouldn't get so fast in extras. Indeed. We have got already real cases of a popular app getting all kinds of positive comments in one side, and then 'this battery sucks'-like threads here and there. Until someone is able to connect one app A with battery problems B. Developer A is then aware, gets feedback and implement fixes. Doing this before hitting extras instead of after makes a whole difference. I'd like to distinguish between 3 major areas: -kernel this _is_ painful as everybody here can testify, but we ship a SoC, therefore there is only this much of drivers to be developed and there is already a very active OMAP community, so I wouldn't consider maemo as the best place where to discuss OMAP related issues. There is also a linux-pm mailing list for generic power management related discussions. Also the cpufreq ml is a good place where to follow power-related discussions, although we are not very active there. -userspace - infrastructure with this i refer to all the stuff that provides the ecosystem to applications (and probably it is the core of what maemo is at the moment): we are talking about sw that is supposed to run (almost) all the time and can significantly affect the performance of the device. At the moment this sw is only about the ARM core in omap, so the usual 2 rules strictly apply: * make your code have low average CPU usage * try to hit 0% CPU usage as often as you can To elaborate it a bit, it's much better to have high activity bursts than spread the activity over longer time (yes, this seems to clash against our DVFS implementation, but it's better to let the system spread the load, than trying to be smart in every single application). What i have described above is indirect power management through CPU load profiling and is simpler to accomplish (no need to instrument your device with a current meter) and Eero has already provided on these lists eccelent examples of how to monitor the CPU activity. -userspace - applications this case is probably both the more common and at the same time the simpler, if we assume that the application will run for a limited amount of time, possibly as main application on the screen and should be easily associated to the battery running flat. The same techniques described at the previous point are effective in this case as well. I think that having developers clearly stating to which class their code belongs to would significantly improve the perception that the user has of the sw he is installing. I don't want to single out Canola, but it is just the first example that comes to my mind of something that is perceived as plain application, while it also has infrastructure components. To conclude, it shouldn't be too difficult to get power management working, as long as we are talking of developing applications. Unfortunately it is not perceived as a _required_ aspect of a quality application. As much as having a usable UI. OMAP3 will make the requirement even stronger; this is the right time to start changing mindset about power management. Doing CPU profiling is a good step down that road. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Pascal on armel Was: [Re: About the upcoming maemo user karma]
Hi, On Tue, 2007-11-06 at 12:56 +0100, ext Luca Olivetti wrote: En/na vicente garcia ha escrit: Finally after 4 hours of fiddeling I want the old days with my old TurboPascal back. ;-) Are you crazy? I must develop some applications with pascal + mysql + gtk 2 then I felt in the Hell. I hate pascal but I learn so many gtk tricks :) It's not my intention to start a language flame war :-) but evidently you never heard of delphi and lazarus. It's sad that the pascal word is automatically associated to a clumsy, outdated language by most developers, since, while lazarus is not 100% mature, being modelled after delphi it blows away anything else for database and gui development (at least under linux, where there's no other comparable product). In fact, having started (real time) pascal development a long time ago, followed through to delphi and now using freepascal and lazarus when I can, I find the various C/C++/Java/whatever development environments really primitive (unsurprisingly, since they're only now trying to do what borland already did almost 15 years ago). ok, so maybe you can help me: I'm trying to get the NBC compiler http://bricxcc.sourceforge.net/nbc/ working on the tablet. Currently i'm stuck with having source code for Delphi/FreePascal and not being able to compile it since (to the best of my knowledge) FreePascal only supports ABI, not EABI. GPC would be a much better alternative since it basically can generate executables for whatever is supported by the backend of gcc. So, is this attempt reasonable? Do you use gpc on the tablet? BTW, Kdevelop is not that bad an IDE, albeit Konsolle + VIM + cscope is the way to go imho ;-) -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pascal on armel Was: [Re: About the upcoming maemo user karma]
Hi, On Tue, 2007-11-06 at 17:47 +0100, ext Luca Olivetti wrote: En/na Igor Stoppa ha escrit: Currently i'm stuck with having source code for Delphi/FreePascal and not being able to compile it since (to the best of my knowledge) FreePascal only supports ABI, not EABI. Yes, that's the problem. OTOH, if it's a relatively simple console program, with no external libraries dependencies, the static binary it generates should run on the tablet (at least a simple hello world worked, as well as a static C program compiled with an old ABI toolchain). I hope one day freepascal for arm will be able to generate eabi calls, but I don't think that's one of freepascal developers top priorities :-( And something like KOL-CE (but for maemo) would be very interesting: http://wiki.freepascal.org/KOL-CE thanks for the answer (also to Riku and peter and klaus here that provided live verbal feedback). I got it working this morning and being a compiler, it doesn't interact much with the system, apart from some file I/O. As a reference for others with similar issues, here's the WORKSFORME procedure: - install qemu - create a barebone debian arm image following the instructions from [1] - download the tarball from the emulated arm system the free pascal from [2], by using any of the available mirrors _but_ sourceforge (it doesn't have the arm version) - untar and install as root with the shell script no debian package available :-( Then i proceded by installing make (it was missing from the basic installation) and finally managed to compile the NBC compiler for Lego NXT by following its instructions. Later I'll make the binary available on garage. It seems to work on n810 and there is no difference between bytecode generated with the x86 version of nbc and the ARM one. [1] http://www.aurel32.net/info/debian_arm_qemu.php [2] http://www.freepascal.org/down/arm/linux.var -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New developer - lots of questions
On Fri, 2007-11-16 at 15:11 -0500, ext [EMAIL PROTECTED] wrote: On Fri, 16 Nov 2007, Igor Stoppa wrote: If disk space is not an issue for you Nope, it isn't... , maybe you can do like me and use a chrooted environment for each sdk (i use it because I have a full 64bit system, but scratchbox is only 32 bit). I prefer this solution since it makes it quite easy to experiment: install your chrooted system, make a copy of it and feel free to trash it after experimenting. My development is also pure 64bit :-) So, do you install a 32bit distro + scratchbox inside the chroot or just scratchbox? I already have a 32bit chroot installed already (mainly to run 32bit plugins and codecs). The gotcha is that I have to do all the bindmounting that scratchbox would do from the outside. Apparently doing a double bindmount from chroot to sbox of a /dev or /proc directory doesn't work and at the second step you end up with an empty directory. Could you explain this a bit more? ok, *I have the chroot environment in /var/chroot/maemo : you can follow the instructions from the official debian howto; i use sid *I have inside the main directory of my user, a directory for the same user to be bindmounted in the chrooted environment: /home/igor/maemo_home_igor *Inside that I have also a directory that is used as home for the scratchbox user: /home/igor/maemo_home_igor/sbox_home here is the relevant part of my fstab: # maemo chroot /sys/var/chroot/maemo/sys none bind 0 0 /tmp/var/chroot/maemo/tmp none bind 0 0 /dev/var/chroot/maemo/dev none bind 0 0 0 0 /dev/pts/var/chroot/maemo/dev/pts none bind 0 0 /dev/shm/var/chroot/maemo/dev/shm none bind 0 0 /proc /var/chroot/maemo/proc none bind 0 0 /proc/sys/fs/binfmt_misc /var/chroot/maemo/proc/sys/fs/binfmt_misc none bind 0 0 /home/igor/maemo_home_igor /var/chroot/maemo/home/igor none bind 0 0 /home/igor/maemo_home_igor/sbox_home /var/chroot/maemo/scratchbox/users/igor/home/igor none bind00 /var/chroot/maemo/scratchbox /var/chroot/maemo/scratchbox/users/igor/scratchbox none bind00 /tmp /var/chroot/maemo/scratchbox/users/igor/tmp none bind00 /proc /var/chroot/maemo/scratchbox/users/igor/proc none bind00 /proc/sys/fs/binfmt_misc /var/chroot/maemo/scratchbox/users/igor/proc/sys/fs/binfmt_misc none bind 0 0 /dev /var/chroot/maemo/scratchbox/users/igor/dev none bind00 /dev/pts /var/chroot/maemo/scratchbox/users/igor/dev/pts none bind0 0 /dev/shm /var/chroot/maemo/scratchbox/users/igor/dev/shm none bind0 0 /sys /var/chroot/maemo/scratchbox/users/igor/sys none bind00 I use this script to start everything: #!/bin/bash mount /var/chroot/maemo/sys mount /var/chroot/maemo/tmp mount /var/chroot/maemo/dev mount /var/chroot/maemo/dev/pts mount /var/chroot/maemo/dev/shm mount /var/chroot/maemo/proc mount /var/chroot/maemo/proc/sys/fs/binfmt_misc mount /var/chroot/maemo/home/igor mount /var/chroot/maemo/scratchbox/users/igor/home/igor mount /var/chroot/maemo/scratchbox/users/igor/scratchbox mount /var/chroot/maemo/scratchbox/users/igor/tmp mount /var/chroot/maemo/scratchbox/users/igor/proc mount /var/chroot/maemo/scratchbox/users/igor/proc/sys/fs/binfmt_misc mount /var/chroot/maemo/scratchbox/users/igor/dev mount /var/chroot/maemo/scratchbox/users/igor/dev/pts mount /var/chroot/maemo/scratchbox/users/igor/dev/shm mount /var/chroot/maemo/scratchbox/users/igor/sys chroot /var/chroot/maemo /sb_run umount /var/chroot/maemo/scratchbox/users/igor/sys umount /var/chroot/maemo/scratchbox/users/igor/dev/shm umount /var/chroot/maemo/scratchbox/users/igor/dev/pts umount /var/chroot/maemo/scratchbox/users/igor/dev umount /var/chroot/maemo/scratchbox/users/igor/proc/sys/fs/binfmt_misc umount /var/chroot/maemo/scratchbox/users/igor/proc umount /var/chroot/maemo/scratchbox/users/igor/tmp umount /var/chroot/maemo/scratchbox/users/igor/scratchbox umount /var/chroot/maemo/scratchbox/users/igor/home/igor umount /var/chroot/maemo/home/igor umount /var/chroot/maemo/proc/sys/fs/binfmt_misc umount /var/chroot/maemo/proc umount /var/chroot/maemo/dev/shm umount /var/chroot/maemo/dev/pts umount /var/chroot/maemo/dev umount /var/chroot/maemo/tmp umount /var/chroot/maemo/sys *the sb_run script that is executed in the previous script lives in /var/chroot/maemo and is the following: #!/bin/bash /scratchbox/sbin/register_misc_runner sux - igor scratchbox /scratchbox/sbin/register_misc_runner -d Not exactly straightforward, but as I said I had some problem with cascaded bindmounting and this in the end works for me; furthermore it keeps the user data safe by removing all the bindomounts as soon as you log out from scratchbox. As a nice sideeffect, the sbox daemon gets killed as soon as you log out from the chroot. The combined effect of these 2 features makes it safe to discard your
Re: Representing libraries, applications by Finite State Machine or block diagrams (don't delete
Hi, On Mon, 2007-11-26 at 00:46 +, ext Darius Jack wrote: Hi, if there any chance to have applications written for Nokia tablet represented by block diagrams or by Finite State Machine like that http://www.tcpipguide.com/free/t_DHCPGeneralOperationandClientFiniteStateMachine.htm To speed up development time of third party open source applications I would welcome an option of block diagram or Finite State Machine included or attached. Any chance for implementation of such approach to open source development ? Have you tried Forum Nokia? They now support officially the maemo platform. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
Hi, On Mon, 2007-11-26 at 13:11 -0500, ext Jesse Guardiani wrote: [snip] This would mean that the Kagu backend process would be a daemon (aka a service, depending on your education environment). If possible, please no, not another daemon. We are already plagued by a large number of (mostly unnecessary!) daemons (i don't remember on top of my head how many exactly, but it's a 2 digits figure) that have trickled over the years in the standard stack. The metacrawler is a good example of why you don't want to write a daemon. To write a daemon is to ask for trouble since your sw will use memory, cpu time and power all the time. Also bugs will be more critical. What's wrong with something that runs on-demand? Unless you rely on having dbus to start and stop the service ... that would probably be ok. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
On Mon, 2007-11-26 at 15:31 -0500, ext Jesse Guardiani wrote: Let's please try to avoid stop energy in this thread. http://www.userland.com/whatIsStopEnergy Nice link. But I don't think it applies here. I _did_ propose an alternative. Of course you are free to ignore it, but your energy would be better spent if directed toward something useful. I'm just trying to help you avoid ending up in a Canola-like situation where, after you have delivered your nice application, somebody complains that the battery lasts nothing, we check what could be and then we find out that it's Canola sucking current all the time. On demand sounds great in theory, but let's think about it for a second: How do you start on-demand a web app? (HTTPD daemon) How do you play the next track when the current track finishes playing? (Kagu daemon, or FastCGI Kagu daemon + HTTPD daemon) Yes, that's the intrinsic problem of using an http-based approach. You rely on the http daemon being nice. Kagu is used very similar to a daemon. It runs as long as you're playing music. And if that's all you use an n800 for then it's always running. It might even be in the background if you're taking notes or browsing the web. The difference is that it has a GUI right now. I'd like to make that portion optional to save some memory/CPU when you aren't using it. I'd also like to make startup time faster, and I'd like to make a web frontend for it. Then you have to make sure that it will have 0% CPU residency, otherwise you'll be stealing playback time from your use-case. And you'll be taking memory no matter what, but hopefully not too much. Also, if you choose this approach, it is worth mentioning it in the release notes of your application, so that users don't get the false impression that your sw is harmless to battery life. No, I don't mean an always on daemon. I mean an on-demand daemon. A background process that runs when you need it and doesn't when you don't. I'm not a userland guy, but for what i remember, dbus should be able to start for you services that are not running, and dbus is _already_ running all the time. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OS2008 on n800 - Nice Job
Hi, On Sun, 2007-12-09 at 13:09 -0500, ext Acadia Secure Networks wrote: Mike, I expect that Nokia has filed lots of patents regarding its battery and power management intellectual property. not a single one for what concerns power management (battery charging is a Nokia legacy component and i'm not well informed about its potential patents). We _did_ check to not being infringing any patent, yes, but all the power management stuff (the one that matters and is hard to achieve) is open and is available in the kernel sourcecode. Unfortunately our dear legal department wants to keep dsme and mce closed, but apart from waiting some time and blanking the screen and changing the wireless timeout, they don't do anything that is power-saving related. I hope the maemo community can leverage what is available from ohm [1] and the intel less watts [2] websites. It would be great if some developer in the maemo community (sorry for the cross posting), somebody who does not have to obtain approval from the Nokia legal department, could replace the closed components. I think at that point there would be no more excuses to prevent us (as OSSO - Nokia) from moving to such open solution. Many in the past have asked for the source of dsme and we have never been able to provide it (even if, ironically, it became public by mistake and lived in the google cache for a while). Hopefully the community can provide its own answer to this deficiency. [1] http://ohm.freedesktop.org/wiki/ [2] http://www.lesswatts.org/ -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to port SDIO stack to N800/ N810 OSs ? (Quim, don't delete it)
Hi, On Sun, 2007-12-16 at 21:30 +, ext Darius Jack wrote: I remember well having not got your approval to develop 2 gps units enabled navigation for Nokia tablet project at maemo.org (requested you 3 times). So be a honest man and tell me frankly what you mean, to not waste my time. Just out of curiosity: why do you need approval? I thought we at Nokia were making open source sw ... what is preventing you from just doing whatever you want, as long as you comply with the licensing? I haven't seen any other developer here asking for permission :-/ -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Hi, On Sun, 2007-12-30 at 17:16 +0100, ext Krischan Keitsch wrote: Hi, I read an interesting thread about overclocking the n800 [1]. Based on that I started experimenting with the n800 running OS2008. The OS scales the cpu frequency nicely from 165MHz up to 400MHz. The current cpu scaling can be checked with cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq So far so good. I noticed that during playback of mp3 files the cpu is scaled to 330MHz. Stressing the cpu during mp3 playback will not change the scaling - the cpu will not scale up to 400MHz. According to a presentation Nokia Internet Tablet Power Managemen [2] the dsp runs at 220MHz when the cpu is set to 330MHz. (This is the default setting in OS2007, by the way.) I was wondering if the device really needs to run at 300MHz (220MHz dsp) for mp3 playback? Is the max dsp power needed for such a task? Or would 220MHz (177MHz dsp) or 165MHz (85MHz dsp) be sufficient? Would a lower dsp scaling save even more battery? The issues are: - doing dvfs while ther is audio playback will generate audible ticks because of problems with the dsp dma - the dsp is always set to support even the weirdest cases, therefore there is a lot of spare DSP horsepower that could be cut off if you knew that your mpu load is not going to change too much and it will be low Practically speaking: if you remove the constraint of fixed [EMAIL PROTECTED] [EMAIL PROTECTED] when there is a dsp task active, you might end up in a situation where you are listening to MP3 @ low OMAP clock, then start the browser, therefore causing the OMAP clock to change rapidly and get lots of garbage on the audio out. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On Mon, 2007-12-31 at 12:40 +0200, ext Siarhei Siamashka wrote: On 30 December 2007, Frantisek Dufka wrote: Krischan Keitsch wrote: I was wondering if the device really needs to run at 300MHz (220MHz dsp) for mp3 playback? Is the max dsp power needed for such a task? Or would 220MHz (177MHz dsp) or 165MHz (85MHz dsp) be sufficient? Would a lower dsp scaling save even more battery? Well, yes it looks a bit simplistic now. Even if you play audio decoded by ARM cpu (ogg, real audio) it seems to lock ARM core to 330 and dsp to 220Mhz. I suppose it is because you need pcm dsp task running for audio output and any active dsp task locks it to 220Mhz (and thus cpu to 330). I wonder if it is just simple implementation that can be tuned in next firmwares or there is some fundamental problem (like changing dsp clock of already running dsp task may break it so it is hardcoded to 220). ARM cpu frequency is apparently not locked at 330MHz when using pcm dsp task. That's why it is faster to do MP3 decoding on ARM core with the current OS2008 firmware. Extra 70MHz of ARM core frequency are more than enough to handle MP3 and there are even some resources left to speed up video decoding. It is interesting if it is possible to lock ARM/DSP frequency at 400/166 instead of 330/220 when playing video. That would probably improve built-in player performance on some heavy bitrate/resolution videos. Also it is interesting to know what is the difference in power consumption between 400/166 and 330/220 modes? Sadly, because of DSP sw issues, little power saving is possible when the DSP is running (ARM can still go to idle and most of the processor can have its clock gated, but it's not possible to reach OMAP retention). It would be nice to have the DSP able to sleep between frames; the time taken to decode an mp3 frame is significantly shorter than the related playback. However the voltage used @330MHz is the same used @400MHz and the associated DSP clock is actually lower, therefore it _might_ be that the power consumption is the same or lower. If anybody has time and the means to measure it (*), it would certainly be interesting to do a comparison. * a clock is enough if one is sufficiently patient: fully charge the battery and measure how many hours of playback can be achieved in each mode before the battery goes flat this requires _exclusive_ utilization of the system by the player, therefore one has to give up doing anything while the test is ongoing Also, note that for the test to be reliable, it should be executed on a freshly flashed unit with stock sw (apart from the modified kernel) and no extras whatsoever -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On Mon, 2007-12-31 at 12:52 +, ext Simon Pickering wrote: It is interesting if it is possible to lock ARM/DSP frequency at 400/166 instead of 330/220 when playing video. That would probably improve built-in player performance on some heavy bitrate/resolution videos. Would this be possible then? What knocks the CPU speed down when the DSP is used (or rather when a music file is played)? A dsp task loaded changes the cpufreq policy, so that the only allowed frequency for ARM is 330 Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. The media player presumably? Assuming it is the media player that makes the change, I presume that mplayer should run at 400MHz all the time? If mplayer is not using any dsp codec, it should already be in such case. Sadly, because of DSP sw issues, little power saving is possible when the DSP is running (ARM can still go to idle and most of the processor can have its clock gated, but it's not possible to reach OMAP retention). It would be nice to have the DSP able to sleep between frames; the time taken to decode an mp3 frame is significantly shorter than the related playback. Presumably the background IDL thread implements power saving functions and is present in the dsp kernel? What actually prevents the DSP from sleeping between frames? Far from optimal design. In other word there has not been enough commitment to push the sw envelope so that it could actually leverage what the hw can do. The current architecture met the (relatively relaxed) time requirement that were set and therefore it didn't receive any further improvement. If the mp3 task is written using semaphores around the data transfer/notification functions, shouldn't the task yield to the background thread after it has decoded a frame and DMA'd it to the audio codec hardware? The mixer is still running and it has a significant timeout, iirc. Also, 'm not so sure that the tasks are actually behaving so nicely. I'm not really into audio, but if you try to decode some mp3 that requires a lot of dsp time vs one that requires very little (silence?), I'm almost certain that there will be no sigificant difference in terms of power consumption. It should be easy to verify with a large enough SD and some mp3 handcrafting skills (several copy paste of the right type of data should be enough). -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On Mon, 2007-12-31 at 17:37 +0100, ext Frantisek Dufka wrote: Igor Stoppa wrote: Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. Interesting, so, umm, there is way to play audio from ARM side directly? Mixing is still happening on DSP. What I tried is to play BBC radio in home screen applet which activated only pcm2 task and arm clock dropped from 400 to 330. That lead me to conclusion that there is no way to output audio with arm clock at 400Mhz. Why there are pcm tasks (used when streaming internet radio) if we could output audio from arm side without limiting ARM clock? Siarhei apparently used a way to output audio without activating DSP from mplayer, how? flash-based audio is decoded on arm (last.fm, ...) Indeed there is something in arch/arm/mach-omap2/board-n800-audio.c arch/arm/mach-omap2/board-n800-dsp.c that looks like there is a way to (partly?) power up dsp, do not run any task and send audio from arm side? As for the policy I had a look at arch/arm/mach-omap2/board-n800-dvfs.c and there are four states defined OP_0 to OP_3 and two additional ones OP_DSP_H (H=high?) and OP_CPU_H as aliases to OP_1 (330/220) and OP_0 (400/133). So one could probably redefine OP_DSP_H to different OP_X to try running dsp at different clock and see which dsp tasks are not fast enough. The multimedia requirements are very strict and comprise some almost-unrealistic cases of multiple streams being decoded and mixed. That's where the extra horsepower is needed. Being apparently impossible to have a continuous dma from the dsp sram to the hw codec practically prevents doing DVFS while the DSP is doing anything. Therefore the only OP which somehow catches all the possible cases over time (i'm talking about a user who is doing more than just mp3 playuback, but might start browsing and so on) is 330/220. Also I wonder what happens when I set DSP_CLK_KHZ in OP_0 state to 266000, can I damage the hardware or will the DSP just crash (leaving rest of the system relatively OK)? Depending on many conditions, it might or might not work, however as long as you don't crank up the voltage, there is no risk of damaging the silicon. HOWEVER (!) corruption in the DSP execution path might lead to unpredictable results, including bricking the unit (to that point that cold flashing is required). Overclocking the DSP only should not so easily cause damage but it's not really a black and white situation. Also you might have to play with the synchronizer. Some comments would be nice there like e.g. which clocks in the table are tied together or which combinations (dsp vs mpu vs other) are allowed. You can refer to the omap2 specific clock framework: it has all the dependencies, basically it replicates the clock tree. BTW, are you forbidden to put any meaningful comments about the hardware there? If yes then how come you are allowed to publish the code itself? The comment i got from TI when i asked is that we are not allowed ot do copy paste of the TRM into the code. Anything else is ok since it is our interpretation of what the TRM says. But having worked on these things for a while it's hard ot tell the difference between what is obvious and what is not. What exactly would is missing? I see no point in replicating the clock dependencies. Is there something else that you think should be added? -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On Wed, 2008-01-02 at 13:30 +0100, ext Frantisek Dufka wrote: Igor Stoppa wrote: On Mon, 2007-12-31 at 17:37 +0100, ext Frantisek Dufka wrote: Igor Stoppa wrote: Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. Interesting, so, umm, there is way to play audio from ARM side directly? Mixing is still happening on DSP. I see so DSP is running fully but there is no dynamic task loaded so the multimedia requirements are low and it can run at 400/133, right? So whan playing audio like this (using SDL and esd) and starting internet radio later I should hear som pops and clicks when freauecny changes to 330/220? If you have a ARM based sound that is being played when the (first) DSP task is loaded, yes, you should hear a click - one - but it's a fairly uncommon case. The typical case is that the interaction sound is played, then the system is for a while @400 MHz but the loading of the task brings it down to 330 MHz Why there are pcm tasks (used when streaming internet radio) if we could output audio from arm side without limiting ARM clock? Siarhei apparently used a way to output audio without activating DSP from mplayer, how? flash-based audio is decoded on arm (last.fm, ...) So is (or should be) Real audio but still CPU drops to 330 (OP_DSP_H). If there are no dsp tasks loaded, then the constraint on the fixed OP is not active. So it is perhaps more about different frameworks used, gstreamer uses pcm dsp tasks (and thus lowers arm core to 330) but things not implemented via dynamic dsp tasks (SDL, esd, flash plugin) use the OP_CPU_H state. Right. And the OP is not changed while the sound is played. You can refer to board-n800-dvfs.c The multimedia requirements are very strict and comprise some almost-unrealistic cases of multiple streams being decoded and mixed. That's where the extra horsepower is needed. So perhaps we can introduce another state or swith between OP_DSP_H and OP_CPU_H depending of which exact dynamic tasks are started on DSP. And only when almost unrealistic thin happens (like decoding mp3 and starting decoder and encoder tasks for VOIP/Skype) switch to OP_DSP_H. This would solve use case of listen to mp3 music while surfing the web (and wanting microb to rut at 400Mhz) Yes, but never the less you have the constraint of keeping low (0) the number of op changes wile audio is active, since they will be perceived as clicks. Also I wonder what happens when I set DSP_CLK_KHZ in OP_0 state to 266000, can I damage the hardware or will the DSP just crash (leaving rest of the system relatively OK)? HOWEVER (!) corruption in the DSP execution path might lead to unpredictable results, including bricking the unit (to that point that cold flashing is required). Overclocking the DSP only should not so easily cause damage but it's not really a black and white situation. Also you might have to play with the synchronizer. Cold flashing because of unstable DSP? Hmm that's bad. Whatever uncontroled code is executed, it can nuke the data/controls written on the onenand bus and there is no _phisical_ protection for the bootloader, meaning that the whole chip content can be randomly trashed. That reminds me that there is no guide for cold flashing. It this supposed to work via the released linux flasher binary and firmware and perhaps serial pins next to battery? That is the connector, yes, you need level shifters, but i think there is on the net some instruction on how to build one. Or is it more complex procedure not posible to do with tools available to public. I don't remember if the public flasher tool provides support for cold flashing but it shouldn't be much different from USB flashing, from the flasher point of view. What is DSP synchronizer? Tried google but found nothing tha made sense in this context. It takes care of the possible difference between DSP_IF and L3 clock, iirc, anyway it's already included in the parameters that describe one OP, check the already mentioned board-n800-dvfs.c and dvfs.c The comment i got from TI when i asked is that we are not allowed ot do copy paste of the TRM into the code. Anything else is ok since it is our interpretation of what the TRM says. Sounds good :-) What exactly would is missing? I see no point in replicating the clock dependencies. Is there something else that you think should be added? Perhaps not if it is somewhere in the clock architecture code. I only had a feeling that the kernel code which originated from Nokia has less or no comments when compared to other linux code and was thinking about reasons why it is so. Examples are/were retu/tahvo drivers and video driver for the epson chip. Retu tahvo are nokia asics and the security through obscurity is intentional, albeit i agree that it is ridiculous since somebody with enough motivation can
Re: n810: Light Sensor (?)
On Mon, 2008-01-14 at 13:59 +0200, ext Marius Gedminas wrote: On Sun, Jan 13, 2008 at 01:32:26AM +, Neil MacLeod wrote: Deleting or renaming /usr/lib/mce/modules/libfilter-brightness-als.so (and rebooting) is an effective way to stop the light sensor from randomly and inappropriately changing the display brightness[1] even in a well lit environment. It might be worth perusing the source code for the aforementioned library in order to glean any useful tidbits (assuming it hasn't been retained as closed source). I tend to assume that anything developed by Nokia is closed-source, unless they started from an existing GPL project to save money and therefore can't close it. iirc this was taken from some phone product, to save time (yes, that's arguable but it's not the point here) and therefore it's considered not viable for opening. I strongly suspect that if you just check the website of some manufacturer of ALS devices, you'll probably get some demo algorythm to do the filtering, likely similar to the one we are using. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: n810: Light Sensor (?)
On Mon, 2008-01-14 at 20:05 +, ext Neil MacLeod wrote: Igor Stoppa wrote: iirc this was taken from some phone product, to save time (yes, that's arguable but it's not the point here) and therefore it's considered not viable for opening. I strongly suspect that if you just check the website of some manufacturer of ALS devices, you'll probably get some demo algorythm to do the filtering, likely similar to the one we are using. If Nokia open sourced the code taken from the phone I'm sure we could fix it for you![1] heh, if it was for me i couldn't ask for more :) As it stands, the light sensor is more irritating than it is useful, as it constantly alters the backlight brightness between bright and dim even when the room lighting level is consistently bright. yup, i noticed that too, it would be nice (even for the average user) if there were more UI options to tweak the behaviour, up to disable it. Of course, i agree that open is better. Hopefully we can do better in the future. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Best format for SD ?
On Wed, 2008-04-02 at 18:47 +0200, ext pHilipp Zabel wrote: On Wed, Apr 2, 2008 at 8:45 AM, Igor Stoppa [EMAIL PROTECTED] wrote: On Tue, 2008-04-01 at 20:27 +0300, ext Marius Vollmer wrote: ext Klaus Rotter [EMAIL PROTECTED] writes: Charles Werbick wrote: [...] ARM simply cannot compete with a Pentium III CPU at 1.5 GHz and 12 watts total dissipation. I predict that the n900 series, should it reach production, will run Intel and not TI silicon. The N8xxs have a 1,5Ah x 3,7V = 5,5 Wh accu. A 12 W design will run out of power in less than half an hour. Charles is missing a dot: The chips have a thermal design power (TDP) specification in 0.6-2.5 watt range and scale to 1.8GHz [...] http://www.intel.com/pressroom/archive/releases/20080302comp.htm Anyway that's still insanely high: 0.6-2.5 watt is for a pocket stove, not an handheld device. According to Wikipedia it can idle in the 0.01 W to 0.1 W range. But this is still just for the processor core, chipset peripherals not included... Are there similar estimations for power consumption of OMAP35x processors produced in 45nm? Sure, but i don't know how many are those that are also public. You should check the TI website. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DVFS module guide for n810
Hi, On Sat, 2008-04-12 at 11:32 +0300, ext Vinod Hegde wrote: Hi , How can I the details of the operations of DVFS (Dynamic Voltage Frequency Scaling) Module which is present on n810. In the sire, I could not find much details. Thanks for any guidance.. What exactly would you like to know? -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: code for altering the voltage/ frequency..
On Sat, 2008-04-12 at 18:37 +0300, ext Vinod Hegde wrote: Hi, I was wondering how to write a piece of code to alter the voltage/frequency of the n810 device. Are there any standard libraries available in the OS. Thanks... Heh, apparently you are so eager to have an answer that you cannot wait few hours after i answered your previous request, but not eager enough to search the archives. http://www.mail-archive.com/maemo-developers@maemo.org/msg13322.html -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Reboot with charger plugged in
On Mon, 2008-04-28 at 14:16 +0300, ext Marius Vollmer wrote: ext [EMAIL PROTECTED] [EMAIL PROTECTED] writes: The fact is that the charger screen is actually managed by X, so if you turn off your device, the system essentially switches to the special run level (ignore the detail in case it isn't a true run level) where X is running w/ the charging screen, and when you turn on your device, the system essentially switches to the normal run level (*). As a user, this is usually fine. What annoys me is that the device boots into the charging screen when you switch it on with the charger connected. That's according to spec and for once I agree with it. But I suppose that it would be possible to modify the behaviour by introducing yet another RD flag in the bootloader and flasher. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
On Sat, 2008-05-03 at 10:00 -0400, ext Ian Lawrence wrote: It is like that game of 'pass the parcel' you play as kids when you unwrap a layer of a present when the music stops. It does not matter how interesting each layer is (Hildon Input Framework etc) if the final layer has a padlock around it. It would have been better to have played 'Hide and Seek' instead, you get no prize but at least you know whats gonna happen and its free. Maybe a clever solution to this would be for Nokia to take some dead product that everyone has forgotten about and completely open it. Hell, even make some marketing splash like: 'In response to community feedback we are releasing 'X' under the GPL. In its time 'X' had the most innovative power management on the market but we think that this can be improved by a 'lots of eyeballs' approach. Prove us right, do your bit for the planet and join us on maemo.org' I'd hack on it anyway Sadly the padlock (and i'm not denying that there is one) is around some of the most boring or crufty stuff, not really on the family jewels. To hack on the hardware you would need: -serial console: that can be obtained with some hacking by attaching a level shifter and a serial connector to the serial pads exposed, it would be enough to release schematic and layout (although i think there are already unofficial howtos) -undocumented HW: TI has opened some of the latest and greatest HW but afaik nothing is going on regarding older products. We have been asking them to release it since we shipped 770. So much for the Nokia can exert more pressure than a single developer mantra. One could argue that we should not have used closed HW and I respect the argument, but containing cost was one of our goals and Nokia buys gazillions of OMAPs. Guess which chip was cheaper ... Then we have some legacy Nokia ASIC that AFAIK is still in use in phones, where many more features are used than what we have in the tablet. Namely Retu/Tahvo and following variants. Again a HW design decision that had pros and cons. We have already enjoyed the pros, now it's time for the cons. Personally I doubt that we would have any real problem in releasing the specs, but when the chip is inside so many devices already on the market, lots of people get nervous (to understate it) when there might be some lawsuit on the horizon for safety threats - the chips are involved in battery charging. Or SIM handling - another hot topic with operators. -closed SW: There are some bits that are quite trivial. I don't think anybody with some programming experience would have problem at stitching together a replacement for dsme mce, given the functional specifications. The state machines implemented are not so straightforward, but a simple start to get going is probably not too difficult to obtain. Then comes bme: charging the battery is something that nowadays is described quite well in the application notes of many battery charging chips, so google would be able to provide all the needed information for some primitive charging sw, but again this is a lawsuit waiting to happen. If common sense was more diffuse and companies didn't have to be paranoid, probably more opening could be done, but i'm skeptic about anything happening on that front at the moment. Finally we have the WLAN module and FW, which are again developed under NDA and it's quite unlikely that the manufacturer is willing to release the source. In the end I think what would be realistically possible - and i'm already completely sure that many won't be satisfied and will complain - is that Nokia provides one person whose sole task is to support the community by mantaining the closed code and providing new binaries that link against recent libraries. The community would still be able to set the direction for the development and ask for updates, so that these closed areas would not hold back work done in the open part. Which is the majority. And I think it would be only fair that, having Nokia enjoyed the benefits of taking these shortcuts (mostly can be summarized in not using better/more open HW), now it will take also the pain of providing continued support for the closed components. This is my personal opinion - not to be taken as a promise or plan - but as an advice in what the community could do/demand to keep the old devices alive. Anyway note that in order to do proper low level kernel development, one needs also measuring tool and special boards that allow for precise measuring of what the sw is doing. Nobody in the community has such setup, so some help from Nokia for validation would still be required. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Hi, On Sat, 2008-05-03 at 19:58 +0200, ext Hans J. Koch wrote: Am Sat, 03 May 2008 17:47:08 +0300 schrieb Igor Stoppa [EMAIL PROTECTED]: Hi Igor, In the end I think what would be realistically possible - and i'm already completely sure that many won't be satisfied and will complain - is that Nokia provides one person whose sole task is to support the community by mantaining the closed code and providing new binaries that link against recent libraries. You're right, I'm not satisfied. The acid test for a Linux device based on OpenSource software is that I can compile my own kernel. I want to be able to download 2.6.25 from kernel.org now, apply some hardware specific patches (GPL, of course) and compile that. With this kernel, all hardware of the device should be functional. Whenever a company designs such a device, hardware should be chosen that makes this possible. Note that I'm not talking about firmware. IMHO firmware belongs to the hardware, and there might be valid reasons to keep it closed, e.g. to fulfill legal requirements for the WLAN chip or for the battery charger you mentioned. In userspace, closed source applications are OK as long as I have all information required to write my own replacement. No help from Nokia is required, except giving us information. I accept it if I have to fix the kernel patches for a new kernel version myself. And of course I accept that it's my own problem if something doesn't work. The community would still be able to set the direction for the development and ask for updates, so that these closed areas would not hold back work done in the open part. Which is the majority. I disagree. Any closed part in a Linux system forces developers to implement stupid wrappers and workarounds somewhere. If I'm forced to use a certain kernel or glibc version, it's not an open system. Probably i was not clear: i'm just saying that if a new kernel comes out and the only impediment in using it is that the proprietary module is not compliant, a new module compiuled against the new kernel should be made available. And I think it would be only fair that, having Nokia enjoyed the benefits of taking these shortcuts (mostly can be summarized in not using better/more open HW), now it will take also the pain of providing continued support for the closed components. That is just additional cost caused by the closed components. Use open components and use the money for something more useful. And I thought that I was writing in good english. Poor me. I'm talking about the past and you want open components. Is Nokia supposed to go around and replace all the sold devices with open hw? This is my personal opinion - not to be taken as a promise or plan - but as an advice in what the community could do/demand to keep the old devices alive. I'll continue demanding open hardware. I'm really fed up with so-called Linux devices where I can't make the hardware work with free software. I've a similar problem ATM with the Eee PC's unsupported WLAN and its buggy BIOS... And that is good, but once certain things have happened, there is no way back. An I think I have explained what I think are the obstacles in opening specs of existing hw. Not that i wouldn't be happy to be proven wrong. Anyway note that in order to do proper low level kernel development, one needs also measuring tool and special boards that allow for precise measuring of what the sw is doing. Oh, please, leave that to the people who want to do kernel development. Yeah, I happen to be one of them, sorry for the personal point of view. OTOH the fact that you don't care doesn't mean others are not interested. If you talk about an open device, it's the whole stack that should be targeted, no? Nobody in the community has such setup, How do you know that? I compile kernels for ARM devices almost every day and also build the bootloaders for them. But not our own boards, i guess. If you do it would be interesting to know how you have obtained one. Compiling for your custom or eval board means very little. To give you an example, every pad must be checked so that it has the right idle configuration depending on what is connected to it, or high currents can be seen. Hard to do without schematics. so some help from Nokia for validation would still be required. What do you want to validate? I agree if my warranty is void if I use my own kernel, just let me do it. Maybe i'm too idealistic, but my idea of open source is a working model where if one has an interesting piece of code, the code can be committed back to the community. Code compile tested or boot tested should not be good enough for being included in repositories that are meant to be used for rolling kernels that will be provided to less experienced users. I don't care if you void your warranty and blow up your device, but i get interested if you start distributing
Re: Corporate ownership of open source projects [LWN]
Hi Ed, good to see you still around here! On Sun, 2008-05-04 at 11:20 -0500, ext [EMAIL PROTECTED] wrote: Hi, On Sun, May 4, 2008 at 3:30 PM, Hans J. Koch [EMAIL PROTECTED] wrote: Am Sat, 03 May 2008 20:53:53 +0300 schrieb Igor Stoppa [EMAIL PROTECTED]: I disagree. Any closed part in a Linux system forces developers to implement stupid wrappers and workarounds somewhere. If I'm forced to use a certain kernel or glibc version, it's not an open system. Probably i was not clear: i'm just saying that if a new kernel comes out and the only impediment in using it is that the proprietary module is not compliant, a new module compiuled against the new kernel should be made available. Proprietary modules are a GPL violation (though this is sometimes tolerated) and taint the kernel. You loose the kernel community's support if you use them. That support is more important than Nokia's support. And I doubt you can supply modules for all the kernel flavors out there. Today, I might want to use 2.6.26-rc1 (came yesterday), Linus' git tree (changes every few hours), or linux-next (changes daily). Thats pretty much the key point for me in this discussion. If you really want to be able to foster an independent linux distro (or more than one), then you need/want to be able to control and upgrade your kernel. Most of the kernel and system components are open or enough is known to provide basic usage, but an 'internet tablet' with proprietary wifi firmware that is not accessible in newer kernel version is a killer. At the moment i am happy with usb networking for my experiments with newer kernels, but the basic function of the device is crippled. Not complaining, and I do not know if it is feasible to supply builds of umac.ko for later kernel versions, but I think this is a barrier to really fostering a 'community distro'. A possible interim solution is to use one like nVidia has used for years for their closed video card drivers. Provide a binary object that implements all the core functionality of the chip, with a public API. Then have an open source kernel module wrapper that calls the funcions in the public API of the binary module. Then the open source part can be compiled for any kernel version and simply link in the closed object. Not an ideal model, but one that solves the problem of legacy hardware that vendors will not allow releasing info on. Indeed; I also think it would not be a big deal to setup daily/nightly builds of this module, once the source trees have been identified - I don't expect them to be too many. That's something much more practical and easier to achieve than release all the code, including what is not under your direct control. If the solution to ease the pain of development is one script away, i guess it shouldn't be too hard to implement and too unreasonable to demand that Nokia provides it as proof of goodwill. Of course those who are interested in wifi development would still have reasons to complain, but the majority of developers would see the obstacle removed. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
On Mon, 2008-05-05 at 22:30 +0200, ext Marcin Juszkiewicz wrote: Dnia Saturday 03 of May 2008, Igor Stoppa (Nokia) napisał: Sadly the padlock (and i'm not denying that there is one) is around some of the most boring or crufty stuff, not really on the family jewels. The padlock is on many things which got limited just because no one took a moment to discuss things with community (guess). -closed SW: Then comes bme: charging the battery is something that nowadays is described quite well in the application notes of many battery charging chips, so google would be able to provide all the needed information for some primitive charging sw, but again this is a lawsuit waiting to happen. If common sense was more diffuse and companies didn't have to be paranoid, probably more opening could be done, but i'm skeptic about anything happening on that front at the moment. At least ability to *read* battery status without Nokia *closed* binaries should be possible. There is battery class now in kernel... Finally we have the WLAN module and FW, which are again developed under NDA and it's quite unlikely that the manufacturer is willing to release the source. Wlan situation was wrong from beginning - when 770 was released. N8x0 just use newer version of 770 driver. Too bad that no one was working on it to make it work with standard linux wlan components like WPA supplicant. This also blocks Nokia tablets from being usable with non-maemo systems. In the end I think what would be realistically possible - and i'm already completely sure that many won't be satisfied and will complain - is that Nokia provides one person whose sole task is to support the community by mantaining the closed code and providing new binaries that link against recent libraries. The community would still be able to set the direction for the development and ask for updates, so that these closed areas would not hold back work done in the open part. Which is the majority. This is not a solution. There are many closed components (some of them were open in older releases) and one person will never get request queue cleaned in acceptable time. I will not mention that many of those closed components looks like closed just because Nokia was able to close it -- other ideas do not came to my brain now. And I think it would be only fair that, having Nokia enjoyed the benefits of taking these shortcuts (mostly can be summarized in not using better/more open HW), now it will take also the pain of providing continued support for the closed components. I hope that one day (during this year not 2012) few Nokia developers/managers will take a list of maemo components and triple check which one should be closed and which not. Then releasing sources for second ones and reasons of closing for others. Till here you are not really providing much of a proposal for getting things done, just generic complaints that historically are proven to not work. This is my personal opinion - not to be taken as a promise or plan - but as an advice in what the community could do/demand to keep the old devices alive. Can community also demand informations how to make non-maemo systems working on tablets? What if I would like to run XFCE on 770 or Qtopia? Ask Quim, he is the Maemo man. Anyway note that in order to do proper low level kernel development, one needs also measuring tool and special boards that allow for precise measuring of what the sw is doing. Nobody in the community has such setup, so some help from Nokia for validation would still be required. People are doing lot of low kernel development on misc palmtops with only serial cables (some try even without them). Having measuring tools, special boards is handy but such setups not always are the same as final devices. Even our developers have problems at producing proper code without these tools. It's relatively easy to get some functionality to apparently work, but getting it to work right and properly leverage the HW is a different case. And we take care that our hw boards are in sync. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Open Source Software New Global Alliance - proposal
On Thu, 2008-05-08 at 10:07 +, ext Darius Jack wrote: Developers of GNU open source software have been working hard for years, working for the community and today, their job and work is made commercial software product by others and offered for more than 1 US$ on a market. So there is a need a new global alliance to solve the problem of financing of open source software developers as money for sold Linux based open source software products in hardware embedded devices (TomTom and others) goes in millions per day. Darius f.IT forensic expert There are far different issues with companies using FOSS than suing them because their sw works only on their hw. From your description it looks like you don't even have well clear the difference between source and binary. Why would i bother with the binary if i can recompile/modify the source code? Want to help? There are companies doing modifications of GPL code and not providing the cource. That's a violation. You are focused on the plain monetary exchange but fail to notice that the real price companies have to pay for using FOSS is that they have to give back whatever innovation has been created on top of free code. In _source_ format, please. Also if you are involved in legal stuff, you should know that for certain regulations the manufacturer of a device can be considered responsible of damage done by 3rd party sw, unless it has taken care to make reasonably hard for the user to install any non authorized sw. This covers crypto signed binaries and hw locks. -- Cheers, Igor --- Igor Stoppa NGSW - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hello Maemo - CFSONID 2008
On Fri, 2008-06-06 at 11:44 +, ext Darius Jack wrote: Nokia's corporate business is not exactly the business of developers working for free to let Nokia make business and generate profit. You have been adviced some time ago to check what's the reality around you. Looks like you didn't do your homework ... -- Cheers, Igor --- Igor Stoppa Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community council is a representative body - not community leadership
On Mon, 2008-06-16 at 20:04 +, ext Darius Jack wrote: speaking in the name of the Nokia Corporation, be so kind to set the sdame rules for your kind ffriends, financed by Nokia to avopid any discrimination policy at the website, financed, donated by Nokia. Just read the European Union standards and rules on non-discrimination policy. *plonk* -- Cheers, Igor --- Igor Stoppa Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: implementation of 2-dimensional array in bash - kind request
On Sat, 2008-07-05 at 17:54 +, ext Darius Jack wrote: I need such 2D array to save gps data and more. Hmm ... why not switching to C? It might make far less painfull your effort, and probably would be more efficient. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Battery drain with Diablo 4.2008.23-14
On Mon, 2008-08-11 at 12:17 +0100, ext Andrew Flegg wrote: On Mon, Aug 11, 2008 at 12:13 PM, Kimmo Hämäläinen [EMAIL PROTECTED] wrote: Do you have the RD mode enabled? It can drain the battery in a day. It can? Previous information has been that RD mode on its own (i.e. without enabling the serial console etc.) has no effect on battery life; and solely enables `sudo gainroot'. And that should still hold true, afaik What does plain RD mode do which affects battery so greatly? Nothing unless somebody had the bright idea to hook something to the plain RD mode flag. Which i really hope is not the case. Kimmo: can you please detail? -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: On the problem of Nokia bugs substituting changelogs
On Sun, 2008-08-24 at 14:15 -0400, ext Ryan Abel wrote: While this is great for Nokia employees and contractors, this is not an OK thing to hoist upon the community. Even for internals it's not so nice to constantly refer to bugzilla and certainly very few bugs are known by heart by developers - and even then not _that_many_ developers. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
vpn on the tablet vs Nokia intranet
Hi, I spent some time trying to locate in the wiki nokia pages a vpn package that still runs on Diablo and can provide access to the intranet, but I only found a bunch of outdated and binary only stuff. Does anybody know of an up to date version? thank you -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Nokia - lost second chance - another multitouch by Apple patented
On Thu, 2008-09-04 at 06:48 -0700, ext Sarah Newman wrote: I am 99.99% certain the internet tablets use resistive touch screens, which means this underlying technology cannot do multitouch. Yes, it's resistive and resisitive ts have (had) higher resolution than capacitive ones. The iphone doesn't have 800x400 pixels and it is not meant to be used with a stylus. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is there a roadmap for opening of binary blobs of N8x0 hardware ?
On Thu, 2008-09-25 at 13:56 +0300, ext David Weinehall wrote: On tor, 2008-09-25 at 10:28 +0530, ext Kevin Verma wrote: I cannot make predictions about other components, but for the battery software a well-educated guess is Never, and the reasons are manifold: possible liability issues, patents, and the fact that it's software developed by another branch of Nokia rather than internally within Maemo. In that sense it would be probably simpler to get rid entirely of it than to open it. But still no predictions, sorry. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Does anyone know the mechanism in Nokia's LCD driver?
Hi, On Tue, 2009-01-13 at 17:21 +0800, ext Huang Gao (Gmail) wrote: But I am still wondering why the screen will not flicker if the DMA only refreshes when the data changed. Does Nokia uses something like smart panel? There is an external HW framebuffer between omap and the lcd -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Does anyone know the mechanism in Nokia's LCD driver?
Hi, On Tue, 2009-01-13 at 18:06 +0800, ext Huang Gao (Gmail) wrote: Hi, Igor Stoppa: Thank you for your reply! So can I understand that this hardware FB is not contained in SDRAM or SRAM, and LCD will refresh itself from this hardware FB by its controller automatically, without the help of OMAP DMA channel? I'm in no way a display guy but iirc there are 2 modes for refresh: -auto: whatever is written to the framebuffer goes through straight to the LCD -manual: the image needs to be flushed to the LCD If you are interested, you can check it from the kernel source files. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does anyone know the mechanism in Nokia's LCD driver?
On Tue, 2009-01-13 at 12:23 +0200, ext Felipe Contreras wrote: On Tue, Jan 13, 2009 at 12:05 PM, Igor Stoppa igor.sto...@nokia.com wrote: Hi, On Tue, 2009-01-13 at 18:06 +0800, ext Huang Gao (Gmail) wrote: Hi, Igor Stoppa: Thank you for your reply! So can I understand that this hardware FB is not contained in SDRAM or SRAM, and LCD will refresh itself from this hardware FB by its controller automatically, without the help of OMAP DMA channel? I'm in no way a display guy but iirc there are 2 modes for refresh: -auto: whatever is written to the framebuffer goes through straight to the LCD -manual: the image needs to be flushed to the LCD If you are interested, you can check it from the kernel source files. Would the manual mode help to avoid tearing? but afaik it is already used by default -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo on Google Summer of Code 09 - Help needed
On Tue, 2009-02-17 at 18:31 +0100, ext Dave Neary wrote: * Hardware hacks: Maemo is one of the few projects where it's possible to hack hardware to do cool stuff. There must be some interesting way to use a tablet + some software that would be worth doing just to prove it can be done... The n810 has USB OTG, meaning that it allows for hacks that can be accessible to other users _withouth_ really starting drilling and sawing the device. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 usb host + power charge
On Sun, 2009-09-20 at 20:44 +0200, Gil Quim (Nokia-D/Helsinki) wrote: Hi, I plan to create a proposal for the push n900[1] and I plan to use the usb port. I have the following question. When the device is in usb-host mode it should of course provide power does it? Is it possible to charge the device while it's in usb-host mode? The N900 comes without USB host mode. When I asked I was told that the limitation comes at hardware level. I can confirm this. The most reasonable setup would have been to provide the A connector, but only gadget mode working forthe sales release, then in a SW update to provide full spectrum support. Then enters the USB certification with all its mass of quite often bizantine, obsolete and plain braindead requirements. One of them being that the certification with A connector can be passed only if full functionality is provided by the SW. In this case I propose that complaints are directed to the USB consortium. I have really come to doubt that it's actually protecting the consumers' interests in nowadays scenario. The reason for this decision was the complexity of providing support for charging, PC connectivity and USB OTG efficiently through the same Micro USB port within the project deadlines. Add to that several HW bugs that were discovered during the development and needed workarounds. We needed to make choices and the decision was to sacrify USB OTG and concentrate on the essential use cases of charging and connecting to the PC, bringing the N900 to the market in its due time. Although noone really liked the choice we had to make. We do use our products and as consumers we are aware of the limitations sometimes we have to apply. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 usb host + power charge
On Sun, 2009-09-20 at 22:56 +0200, ext Kees Jongenburger wrote: On Sun, Sep 20, 2009 at 9:02 PM, Igor Stoppa igor.sto...@nokia.com wrote: Add to that several HW bugs that were discovered during the development and needed workarounds. Does this simply mean it's not possible at all? not even for example booting in HOST only mode? AFAIK no. Not even that. Note that i'm no USB expert, but if i have understood correctly, part of the configuration is done automatically by the transceiver and that cannot be done because of the missing line from the connector that would identify the port as A type. -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras-devel - extras-testing auto-promotion not working?
ext Mikko Vartiainen wrote: You can promote PyMaemo packages to extras-testing but it's not the solution, because it doesn't help getting them to Extras (you can't promote them there). Even if newer versions of non user/ packages were promoted to Extras it doesn't help much getting them to end users devices if they had earlier version of them installed because of how Application Manager works. Currently getting something to updated requires that update is somehow visible through user/ package both in Application Manager and packages interface autopromotion algorithm. Promotion system could probably be changed that it always promotes newer version of non user/ package. One option would be that package maintainer can promote updates of non user/ package to extras manually, but that circumvents the whole qa process. But if here there is a clear bug (not using /opt) which gets fixed by the newer version, what more is needed? And why? igor ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
ext Jeremiah Foster wrote: 4) Project decisions should be made in closed-door meetings. 5) Employ large amounts of legalese. 7) Keep the decision-making powers unclear Unfortunately a bit of this is true. But this is part of maemo's dual nature, the half-closed, half-open beastie. To be honest, in a project like debian the entire infrastructure is open to debian developers so there is no closed-door, no cabal. Maemo could do better here. In the end Nokia is expecting to create - and sell! - Maemo based products. So some choices are product driven and unfortunately cannot be communicated / discussed publicly. However some community members have already been involved in testing the recent upgrades before the release, so maybe what could happen in the future is that there could be a larger involvement of people who are not Nokia employees but agree to sign NDAs for being part of early discussions. A similar example comes from the kernel community, where a pool of kernel developers is willing to sing NDAs with industrial players to have access to device documentations and create/improve kernel drivers. igor ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
Hi, ext Graham Cobb wrote: We have to live with that and try to come up with a solution that is best for the users. In my view, that means having as many apps as possible available to people who are still running the initial release. That would not be very wise: you are assuming that all the units will be manufactured with the same SW onboard. But what gets flashed in production gets updated every now and then, when a new SW build is available. This is a typical procedure and is aimed at: - reducing failure rate in production caused by sw bugs - reducing return rate and customer care costs in the field when users do not update the sw and complain about bugs already fixed So I recommend a different approach. For example, what about actively supporting (at any point in time) the current and previous official build? That should cover the vast majority of the users and ensure that you do not deal constantly with bugs that have already been fixed. igor ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
ext Graham Cobb wrote: It is still my view that, if at all possible, applications should install on the initial release. Otherwise we lose those applications for a large part of our user base (those who got a device with an earlier version of the software and have not upgraded). this is the point where we disagree: _at_the_moment_ your user base might be using the earlier version of the sw, but even if none of them was to update, the proportion are going to change in the future, hence my proposal below For example, what about actively supporting (at any point in time) the current and previous official build? That should cover the vast majority of the users and ensure that you do not deal constantly with bugs that have already been fixed. I don't object to applications rejecting bugs (and even a Maemo policy which says that bug reports will be rejected) if the device is not running the latest or previous firmware. But that is different from building them such that they will not install on previous versions. I didn't mean that, just what you said, actively support only recent sw. This really isn't hard! For the vast majority of applications there is no reason at all why they cannot be built against the first software release and install on all later releases, taking advantage of the bug fixes made since. I have been doing that for GPE since the first Maemo release. That is what the autobuilder should be doing by default -- no need to make life hard for users **by default**! Building is not so much my concern, but rather testing: what is going to be the accepted environment for approving and releasing a new version of your sw? Hopefully not the first sales release. All we need is an exception process for the very, very few apps which want to make use of the few new features introduced in the new releases. I think the impact of new features varies greatly depending on the POV. Graphics is a very good example: if an application doesn't rely on OpenGL or QT, then it's no problem. But for a vast class of applications there will be a significant difference. That is why I proposed the alternate builder queues which will cause the builder to use a later SDK. Any application built using one of the alternate queues will not install on all versions of Fremantle so using it is discouraged unless it is necessary. Yes, I think we mostly agree, it's just the expectations/forecast about future applications development that are different. igor ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo code in Linux kernel?
Hi, ext Christopher Intemann wrote: Hello, I came across this blog-entry [1] which is describing why the Android kernel extensions were removed from the current kernel version. I'm just curious: Where does Nokia/ Maemo stand? Are there Maemo sources in the official Linux kernel tree at all? http://opensource.nokia.com/contributions.html igor ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Building Maemo OS from Source.
ext Marcin Juszkiewicz wrote: Dnia czwartek, 18 marca 2010 o 19:59:25 Samir Faci (Dev) napisał(a): Hmm.. any one know if meego will be completely open source?. Or is it too early to know for sure at this point. It was already said that Nokia devices running MeeGo will contain closed source components. So answer to your question is no, it won't be. Incorrect. A Nokia device running MeeGo is not the same as a Nokia device running _exclusively_ MeeGo. iow the total sw stack will be a superset of a configuration of MeeGo So MeeGo can still be fully open. igor ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Building Maemo OS from Source.
ext Ryan Abel wrote: Well, except for the part where Nokia ends up marketing it as MeeGo. Oh, and Harmattan's, apparently, MeeGo, too, and it definitely has closed stuff at the platform level. Yeah . . . not confusing at all. ;) No at all: it's about standardization. The device must support a certain set of features and provide well defined APIs. So if a device is MeeGo compliant, it will be advertised as such. What's confusing about it? If you write an application which relies on MeeGo features only and can be run across multiple MeeGo compliant devices, what matters to you that in one of them there might be a closed component which doesn't belong to the MeeGo stack? igor ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Building Maemo OS from Source.
ext Marcin Juszkiewicz wrote: It was already said that Nokia devices running Nokia provided MeeGo based system will contain closed source components. So far no one told what base meego system contains and how useful it is. It depends on your intent and goals. I cannot comment on what MeeGo will contain simply because: - I am not involved in defining the content - I have no official communication role (yes, i'm using my job email address but I will not make statements) Judging from current situation I assume that it will be nearly not usable without having N900 connected to charger due to lack of open BME alternative == no charging. Well, if for you it is good enough to have binary packages added, it probably would be possible. Ask Quim. Even now the userspace driver for the 3D accelerator is closed source (even in Nokia it takes a business reason to see the code: I was the proj manager for it and still i didn't have access to the repo). Would a mesa implementation be good enough for you? Probably not: it would be better to have text console only than an extremely cpu-intensive and slow sw-renderer. There are build systems already which provides alternative root filesystems for nokia N900 and all of them suffer more or less due to that. Again, your problem might be solved by MeeGo or not, based on the content. However battery charging is very platform specific, while MeeGo deals mostly with parts that aren't. Worksplit between HW and SW in future products (not only Nokia) will also play a major role. igor ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
