Re: python2.5 - unnecessary multiple processes forked
ext Frantisek Dufka [EMAIL PROTECTED] writes: I can't imagine any valid reason for gtk/hildon to fork more processes just to show a GUI dialog. Does anyone know? I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. I think you are correct. I heard that some gnome-vfs plugins, for example UPnP, start their own thread (or something like that). But I'm a network guy, I know jack about our UI. So I might be wrong here. -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: busybox applet selection (again)
ext Damien Moore [EMAIL PROTECTED] writes: https://bugs.maemo.org/show_bug.cgi?id=989 the bug was marked WONTFIX Eero Tamminen's resolution was to not add any additional applets to BusyBox because in his opinion those needs can best be met by creating full versions of the tools in separate packages. I don't think this is a good idea because it creates a proliferation of unnecessarily bloated packages with the attendant problems of maintaining multiple packages (keeping in mind that the target hardware is a capacity constrained tablet). The benefit of busybox is that most appplets add just a few kb to the binary size and all of them sit inside a single binary. I have to agree with Eero here. It's much more useful to have the original tools available instead of (too) simple busybox variants. For example, you need to be root to run busybox ping and it does not support flood ping. Having iputils-ping would fix both of these problems. -- Kalle Valo ___ 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: Dbus call to launch Image-Viewer?
Hi, ext Marius Gedminas wrote: On Fri, Dec 28, 2007 at 04:52:14PM +0200, Tuomas Kulve wrote: Is there a Dbus call to launch the Image-Viewer app with a parameter image file? Not sure about dbus call, but check hildon_mime_open_file() in /usr/include/hildon-mime.h. At least it's trivial to make a simple executable opening a file with that. I think that basically just sends a dbus call, so using dbus directly should be possible too. I would be nice if future version of the OS came with a small hildon-open program, similar to gnome-open on desktop systems. $ hildon-open /path/to/file $ hildon-open http://some/url Even better would be to provide the standard xdg-utils package: http://portland.freedesktop.org/wiki/ The binary could be named as hildon-open, but it should be at least symlinked to xdg-open, and the package containing this should state that it Provides xdg-utils. Could you make a bug about this and put me on CC? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
Hi, ext Jayesh Salvi wrote: I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes. They are not processes, but gnome-vfs worker threads (you don't want the UI to freeze e.g. until network timeouts). So this behavior seems valid for FileChooserDialog. But then I should be able to cleanup those extra processes when I am done with the FileChooserDialog. I called destroy() on the dialog object, but that doesn't help. They remain in the gnome-vfs thread pool even after the UI component is destroyed. The memory usage issue is elsewhere. You could look into your program Private_Dirty memory usage in /proc/PID/smaps file. Or run the same program on your PC under Valgrind Massif plugin: http://maemo.org/development/tools/doc/valgrind http://valgrind.org/docs/manual/ms-manual.html I'm not sure how well that tells about issues in Python code. Is there any memory profiler for Python applications? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
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? 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). 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. 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) 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. 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? Or is it more complex procedure not posible to do with tools available to public. What is DSP synchronizer? Tried google but found nothing tha made sense in this context. 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. But maybe that's just my feeling caused by my general inexperience and lack of other documentation. In such case any hints in the code helps. As for OMAP2 it is bad there is no documentation at TI site. Having same set of manuals like they have for 5910 and 5912 boards would be nice. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SQLite bindings for Python2.5 in Chinook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 HI. On Wed, 2 Jan 2008 14:55:58 +1100 Devraj Mukherjee [EMAIL PROTECTED] wrote: Hi everyone, I am trying to find out if Python 2.5 has bindings for SQLite under Chinook. apt-cache search reveals libsqlite3 but no python bindings. Do they exists, if so please tell me where I should be looking. Thanks. Sqlite3 bindings are in the python2.5 package. So if you do import sqlite3 you will have it. Cheers. - -- Daniel Martin Yerga http://yerga.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHe5hDcnvB1T3xmfMRAluVAJ4uXxLYxWRRWb6K6VVWCo4HG10uuACeNBD2 ApitmoT1eXeZX+pEyN1u0QU= =5SK1 -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: busybox applet selection (again)
Hi, I think it's good you raised this issue as it needs some discussion. Busybox is a base part of maemo, but we don't yet list it as an official SDK API although most packages need/use it when they are installed. ext Damien Moore wrote: I'd like to bring up the busybox applet selection issue again. This was previously discussed here: http://lists.maemo.org/pipermail//maemo-developers/2007-April/009738.html with associated bug here: https://bugs.maemo.org/show_bug.cgi?id=989 the bug was marked WONTFIX Eero Tamminen's resolution was to not add any additional applets to BusyBox because in his opinion those needs can best be met by creating full versions of the tools in separate packages. I don't think this is a good idea because it creates a proliferation of unnecessarily bloated packages with the attendant problems of maintaining multiple packages (keeping in mind that the target hardware is a capacity constrained tablet). The maintenance wouldn't be a problem. Then those packages can come directly from Debian. Also, then trying to install a properly working replacement for a buggy/incomplete Busybox functionality doesn't mean that one would need to remove first Busybox and half the device software depending on what else Busybox provides. As to bloatedness, there's an apt-hook installed on the device that removes the extra docs when a package is installed (at least man info pages). Developer could also run something like Debian's localepurge. Most of the package sizes can come from documentation and localization (which Busybox tools are lacking), sometimes also from extra binaries. IMHO the actual binary size is significant only in fairly rare cases. The benefit of busybox is that most appplets add just a few kb to the binary size and all of them sit inside a single binary. If they are not on the device, but separately installable packages in a tools repository, they take even less space on most users' devices. :-) N8x0 devices have more Flash available than 770, so the disk usage isn't anymore as severe issue as it was. This differs from package to package, so the decision about this needs to be done case by case. My proposal is to create an alternative essential busybox package that optionally replaces the default busybox, say busybox-max. busybox-max would be built with many more applets (more of the archive tools, more shell support (e.g. longer command histories and color coded ls), I think improving the already configured Busybox functionality is a good idea. We're providing an xterm with the device, so it makes sense to have what's already installed as usable as possible. It would be nice to have a bug about that with details about what Busybox options should/could be enabled/disabled and what will be their effect to Busybox size RAM usage. What are your propositions for enhancing the currently configured Busybox tools? more networking tools etc. This package would not be installed by default, it would just be an optional package for developers/hackers. I don't know how well dpkg would handle the package replacement but it is worth exploring. However, I don't think it's a good idea to add more tools to Busybox. Busybox is an essential package, so having incompatible versions of it or trying to replace some of the binaries with the real versions will end up with packaging conflicts. IMHO only good reasons for adding a tool to Busybox would be compatibility to Debian (derived distributions) from which most of the other maemo tools come from. I.e. if Busybox claims to provide a certain Debian package, it should try to provide as many binaries from that package as possible. And even this only if: - The real package (without docs and localization) is significantly larger than the corresponding Busybox binaries size - The package in question is an essential in Debian and at least some of its binaries are used by the preinstalled device software What's the problem of using the real packages / functionality instead (specific example, please)? E.g. if you want a good interactive shell, why not add that as a separate package (Busybox POSIX shell would then be used only by the shell scripts)? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: busybox applet selection (again)
On 1/1/08, sebastian maemo [EMAIL PROTECTED] wrote: What would happen with an order like this?... # apt-get -o APT::Force-LoopBreak=1 install busybox replacement Maybe a broken system? I would think almost certainly a broken system. I think dpkg scripts depend on busybox tools being there, so they can't be removed (even briefly) just replaced. There must be a way to do it. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: busybox applet selection (again)
On 1/2/08, Kalle Valo [EMAIL PROTECTED] wrote: I have to agree with Eero here. It's much more useful to have the original tools available instead of (too) simple busybox variants. what I'm suggesting would be an optional package that, if set up correctly, won't break anything (but will block the installation of overlapping tools in other packages). Users who want original tool sets could take the standard busybox package and install separate tools packages. If having the original tools is always better perhaps busybox shouldn't be used at all? Yet another alternative: a package that replaces busybox with original tools For example, you need to be root to run busybox ping and it does not support flood ping. for good or bad the root problem is overcome with # chmod 4777 /bin/busybox Having iputils-ping would fix both of these problems. why not take all of iputils? On 1/2/08, Kalle Valo [EMAIL PROTECTED] wrote: ext Damien Moore [EMAIL PROTECTED] writes: https://bugs.maemo.org/show_bug.cgi?id=989 the bug was marked WONTFIX Eero Tamminen's resolution was to not add any additional applets to BusyBox because in his opinion those needs can best be met by creating full versions of the tools in separate packages. I don't think this is a good idea because it creates a proliferation of unnecessarily bloated packages with the attendant problems of maintaining multiple packages (keeping in mind that the target hardware is a capacity constrained tablet). The benefit of busybox is that most appplets add just a few kb to the binary size and all of them sit inside a single binary. I have to agree with Eero here. It's much more useful to have the original tools available instead of (too) simple busybox variants. For example, you need to be root to run busybox ping and it does not support flood ping. Having iputils-ping would fix both of these problems. -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: correct kernel source for RX-34_2008SE_2.2007.50-2 ?
On Jan 2, 2008 1:06 AM, Terje Bergström [EMAIL PROTECTED] wrote: Frantisek Dufka wrote: some time ago I noticed there is osso63.1 version of kernel source here http://repository.maemo.org/pool/chinook/free/source/k/kernel-source-rx-34/ and thought it is source of kernel for latest 2008 firmware. But it is not! First I noticed my N800's external mmc slot doesn't work with this kernel. Cover switch works but when any card is inserted I see only Hi, Unfortunately due to holiday season and vacations of members in my team it will take still a while before we can release the source code for the latest N800/N810 firmware. Sorry for the delay. That's a pretty cavalier attitude to a clear legal obligation, IMO. Dave ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: busybox applet selection (again)
ext Damien Moore [EMAIL PROTECTED] writes: On 1/2/08, Kalle Valo [EMAIL PROTECTED] wrote: I have to agree with Eero here. It's much more useful to have the original tools available instead of (too) simple busybox variants. what I'm suggesting would be an optional package that, if set up correctly, won't break anything (but will block the installation of overlapping tools in other packages). Users who want original tool sets could take the standard busybox package and install separate tools packages. If having the original tools is always better perhaps busybox shouldn't be used at all? That's what Eero is proposing here: disable certain tools, for example ping, from busybox and install the full versions, for example iputils-ping. example, you need to be root to run busybox ping and it does not support flood ping. for good or bad the root problem is overcome with # chmod 4777 /bin/busybox I'm not even going to comment on that. Having iputils-ping would fix both of these problems. why not take all of iputils? Sure, if there is a need. ping was just an example. -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: correct kernel source for RX-34_2008SE_2.2007.50-2 ?
On Jan 2, 2008 9:33 AM, Dave Neuer [EMAIL PROTECTED] wrote: On Jan 2, 2008 1:06 AM, Terje Bergström [EMAIL PROTECTED] wrote: Frantisek Dufka wrote: some time ago I noticed there is osso63.1 version of kernel source here http://repository.maemo.org/pool/chinook/free/source/k/kernel-source-rx-34/ and thought it is source of kernel for latest 2008 firmware. But it is not! First I noticed my N800's external mmc slot doesn't work with this kernel. Cover switch works but when any card is inserted I see only Hi, Unfortunately due to holiday season and vacations of members in my team it will take still a while before we can release the source code for the latest N800/N810 firmware. Sorry for the delay. That's a pretty cavalier attitude to a clear legal obligation, IMO. If the alternative is to not get new firmware released until later when source is ready to go at the same time I think getting firmware as soon as possible and showing some patience while waiting for the source is the preferable arrangement for most users. I suppose not everyone sees it that way though. John ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: busybox applet selection (again)
On 1/2/08, Eero Tamminen [EMAIL PROTECTED] wrote: The maintenance wouldn't be a problem. Then those packages can come directly from Debian. Also, then trying to install a properly working replacement for a buggy/incomplete Busybox functionality doesn't mean that one would need to remove first Busybox and half the device software depending on what else Busybox provides. Shouldn't need to remove any device software if REPLACES is used and if any dependencies in the system respect treat the replacement as equivalent to the original. The only dangerous thing is that dpkg scripts presumably rely on busybox being there: at some point during install the old busybox is replaced by the new one, old symlinks are replaced by new and we have make sure that this won't create problems. As to bloatedness, there's an apt-hook installed on the device that removes the extra docs when a package is installed (at least man info pages). good to know. although sometimes I find the absence of docs an obstacle (would be nice if they could be saved to one of the mmcs) Developer could also run something like Debian's localepurge. Most of the package sizes can come from documentation and localization (which Busybox tools are lacking), sometimes also from extra binaries. IMHO the actual binary size is significant only in fairly rare cases. N8x0 devices have more Flash available than 770, so the disk usage isn't anymore as severe issue as it was. This differs from package to package, so the decision about this needs to be done case by case. I'll think about this. If it is really true that binary size doesn't matter, then that's a strong case for not using busybox at all (or at least offering a full versioned drop in toolset replacement for busybox) However, I don't think it's a good idea to add more tools to Busybox. Busybox is an essential package, so having incompatible versions of it or trying to replace some of the binaries with the real versions will end up with packaging conflicts. that's why I advocated making it optional. to resolve the conflict, reinstall the slimmed down one. Can busybox be configured to use shared libraries for classes of toolsets? that way, optional packages could be provide distinct functionality in a shared object with accompanying symlinks without the need to overwrite the busybox binary. IMHO only good reasons for adding a tool to Busybox would be compatibility to Debian (derived distributions) from which most of the other maemo tools come from. I.e. if Busybox claims to provide a certain Debian package, it should try to provide as many binaries from that package as possible. And even this only if: - The real package (without docs and localization) is significantly larger than the corresponding Busybox binaries size - The package in question is an essential in Debian and at least some of its binaries are used by the preinstalled device software It would be nice to have a bug about that with details about what Busybox options should/could be enabled/disabled and what will be their effect to Busybox size RAM usage. What are your propositions for enhancing the currently configured Busybox tools? ok, at the very least I think all of the coreutils should be available with more options switched on (personal favorites: diff, patch, color coded ls etc). I'd also like to have all of the archive tools available but maybe I'm in the minority. Even a busybox with virtually everything switched on is only 740kb binary. I can't imagine RAM usage would be an issue. I'll add more later, when I file the bug What's the problem of using the real packages / functionality instead (specific example, please)? E.g. if you want a good interactive shell, why not add that as a separate package (Busybox POSIX shell would then be used only by the shell scripts)? the problem isn't a specific one, it's a general one. 1. it requires a package hunt to create a working system (perhaps this is resolved by the creation of a super package that installs all of the others). 2. I can't help but think there will inevitably be small patches to the debian packages that makes maintenance of many sets of packages a nightmare. Maybe I'm wrong about that. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: correct kernel source for RX-34_2008SE_2.2007.50-2 ?
inode0 wrote: If the alternative is to not get new firmware released until later when source is ready to go at the same time I think getting firmware as soon as possible and showing some patience while waiting for the source is the preferable arrangement for most users. I suppose not everyone sees it that way though. Yes, not everyone sees it that way :-) Last time it was discussed here http://lists.maemo.org/pipermail/maemo-developers/2006-November/thread.html#6032 Only this time it is not only too late but we also have two phoney kernel sources in repository for last two OS2008 releases :-) Yes it is in some way better than nothing, but still far below standards I would expect from Nokia. For me it also means I should better pull off custom OS2008 kernels I was providing in good faith since it looks like N800 users will lose functionality of external card slot. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: busybox applet selection (again)
Hi, ext Damien Moore wrote: On 1/2/08, Eero Tamminen [EMAIL PROTECTED] wrote: The maintenance wouldn't be a problem. Then those packages can come directly from Debian. Also, then trying to install a properly working replacement for a buggy/incomplete Busybox functionality doesn't mean that one would need to remove first Busybox and half the device software depending on what else Busybox provides. Shouldn't need to remove any device software if REPLACES is used and if any dependencies in the system respect treat the replacement as equivalent to the original. The only dangerous thing is that dpkg scripts presumably rely on busybox being there: at some point during install the old busybox is replaced by the new one, old symlinks are replaced by new and we have make sure that this won't create problems. The problematic use-case would be trying to install a new package that works with the default busybox but depends/requires something that is in a Debian package from which only some binaries were included into busybox-max, but not that required one. With default Busybox the co. package would be automatically installed (as its contents don't conflict with busybox) and everything is fine. With busybox-max developer would need to replace busybox-max with the default busybox to be able to install the new package and its deps. This is fairly unlikely case, but IMHO reason enough not to have two busybox versions with different set of tools. Main thing is that the developer can get the required tool, not whether it's in Busybox I think. As to bloatedness, there's an apt-hook installed on the device that removes the extra docs when a package is installed (at least man info pages). good to know. although sometimes I find the absence of docs an obstacle (would be nice if they could be saved to one of the mmcs) I think you can just do apt-get remove docpurge if you don't like this. Unfortunately it doesn't restore the docs that were removed before this. :-) Developer could also run something like Debian's localepurge. Most of the package sizes can come from documentation and localization (which Busybox tools are lacking), sometimes also from extra binaries. IMHO the actual binary size is significant only in fairly rare cases. N8x0 devices have more Flash available than 770, so the disk usage isn't anymore as severe issue as it was. This differs from package to package, so the decision about this needs to be done case by case. I'll think about this. If it is really true that binary size doesn't matter, It matters, but less. And it depends on whether that functionality needs to be pre-installed. If it doesn't need to be pre-installed size is not really a concern with most packages. Developers can install only the tools they care about and e.g. keep rest on an MMC card. then that's a strong case for not using busybox at all (or at least offering a full versioned drop in toolset replacement for busybox) Busybox is pre-installed. However, I don't think it's a good idea to add more tools to Busybox. Busybox is an essential package, so having incompatible versions of it or trying to replace some of the binaries with the real versions will end up with packaging conflicts. that's why I advocated making it optional. to resolve the conflict, reinstall the slimmed down one. Can busybox be configured to use shared libraries for classes of toolsets? that way, optional packages could be provide distinct functionality in a shared object with accompanying symlinks without the need to overwrite the busybox binary. They would be pretty small libraries and not shared by any other binaries. Shared libraries include both startup (symbol resolving), and RAM cost (please read Depper's dsohowto), and don't really solve the problem of different busybox versions having different conflicts. Do all Busybox target platforms even support shared libraries (I doubt the chances of this patch getting to upstream Busybox)? IMHO only good reasons for adding a tool to Busybox would be compatibility to Debian (derived distributions) from which most of the other maemo tools come from. I.e. if Busybox claims to provide a certain Debian package, it should try to provide as many binaries from that package as possible. And even this only if: - The real package (without docs and localization) is significantly larger than the corresponding Busybox binaries size - The package in question is an essential in Debian and at least some of its binaries are used by the preinstalled device software It would be nice to have a bug about that with details about what Busybox options should/could be enabled/disabled and what will be their effect to Busybox size RAM usage. What are your propositions for enhancing the currently configured Busybox tools? ok, at the very least I think all of the coreutils should be available with more options switched on (personal favorites: diff,
Re: correct kernel source for RX-34_2008SE_2.2007.50-2 ?
Frantisek Dufka [EMAIL PROTECTED] writes: inode0 wrote: If the alternative is to not get new firmware released until later when source is ready to go at the same time I think getting firmware as soon as possible and showing some patience while waiting for the source is the preferable arrangement for most users. I suppose not everyone sees it that way though. Yes, not everyone sees it that way :-) It also reveals a cultural or management failing at Nokia. Such steps (making correct source available) should be properly planned into the development process. Once you do that, you'll find that they don't actually take any significant time. We hear endless talk of lawyers when it's a matter of why Nokia can't make their media player (file manager, application manager, etc.) open source. Why are the same lawyers not so hot on making sure that legal obligations are met w.r.t. the kernel code? Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: busybox applet selection (again)
On Jan 2, 2008 7:04 AM, Eero Tamminen [EMAIL PROTECTED] wrote: As to bloatedness, there's an apt-hook installed on the device that removes the extra docs when a package is installed (at least man info pages). Developer could also run something like Debian's localepurge. Most of the package sizes can come from documentation and localization (which Busybox tools are lacking), sometimes also from extra binaries. IMHO the actual binary size is significant only in fairly rare cases. Just my two cents... I have a guide for setting up localepurge on the 770 at http://sparrsstuff.com/localepurge It saves enough space to be worthwhile. (sorry to Eero about the double reply) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: correct kernel source for RX-34_2008SE_2.2007.50-2 ?
Neil Jerram wrote: It also reveals a cultural or management failing at Nokia. Such steps (making correct source available) should be properly planned into the development process. Once you do that, you'll find that they don't actually take any significant time. Yes it may be cultural difference. Can you imagine Red Hat or Novell or any other Linux distributor releasing their next big version, giving you binary ISOs and informing you with straight face that ISOs with srpm packages will be available sometime in future when people get back from vacation? How it could be that what is inconceivable with linux distributions on PCs is possible with linux distribution on Nokia tablets? Looks like since this thread http://lists.maemo.org/pipermail/maemo-developers/2005-October/thread.html#1355 more that 2 years ago nothing really changed in this matter. Also one correction, the old thread I mentioned before was not last time it was discussed. Here is at least another one http://lists.maemo.org/pipermail/maemo-developers/2007-March/009250.html Well, enough from me in this topic. Let's move on. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: correct kernel source for RX-34_2008SE_2.2007.50-2 ?
On Jan 2, 2008 10:45 AM, inode0 [EMAIL PROTECTED] wrote: On Jan 2, 2008 9:33 AM, Dave Neuer [EMAIL PROTECTED] wrote: That's a pretty cavalier attitude to a clear legal obligation, IMO. If the alternative is to not get new firmware released until later when source is ready to go at the same time I think getting firmware as soon as possible and showing some patience while waiting for the source is the preferable arrangement for most users. I suppose not everyone sees it that way though. Sorry, I don't see how what's preferable for users matters in this case at all. Nokia is under legal obligation to distribute source w/ it's products which contain GPL software or not distribute the software at all. Besides, there really is no excuse not to have them ready at the same time. Nokia clearly has the source, since they used it to build the binaries. And at this point they have built so many IT firmware images that they simply _have_ to know which of that software requires source distribution. It can't be any harder to publish the source than it is to publish the binaries. Dave ___ 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: correct kernel source for RX-34_2008SE_2.2007.50-2 ?
Dave Neuer wrote: Sorry, I don't see how what's preferable for users matters in this case at all. Nokia is under legal obligation to distribute source w/ it's products which contain GPL software or not distribute the software at all. Besides, there really is no excuse not to have them ready at the same time. Nokia clearly has the source, since they used it to build the binaries. And at this point they have built so many IT firmware images that they simply _have_ to know which of that software requires source distribution. It can't be any harder to publish the source than it is to publish the binaries. Dave No source code. No change log. No process. It's been this way from the beginning. Eventually the correct source code will be cobbled together, as might a change log. As has been pointed out, if these two items were part of the *process* then publishing the source code and a change log simultaneously with the binary wouldn't take any appreciable time whatsoever. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
