Re: N810 discount code frustration
Vivia Nikolaidou wrote: > Anyway, here is the story: All this is very unfortunate and it is too late now but you could have done some things better to minimize those issues. I'm not sure about N810 program but with N800 there was a FAQ page http://maemo.org/community/wiki/n800developerdeviceprogram/ (see "Nokia shops don't cover my country, do I still have a chance?") and implications were discussed in this list many times. Maybe with future developer device programs (if any) this should be stressed again to prevent or minimize such frustration. Here are the facts: - devices are sold only in some countries - you need to use online store of those countries - you need to use credit card with shipping and billing address from that country So the best way is to have friend from that country who will buy the device for you, use his/her own credit card, gets the device, then preferably also tests the device (and handles possible replacement) and then ships it to you. Unfortunately you can't ship device directly to you and you can't use your own credit card. And most probably you can't easily claim warranty in your country if device arrives broken or gets broken later. This is the reality you either accept or not. The other choice Maemo team had (and I think they really considered it) was to limit the program only for developers from those selected countries to prevent similar unhappy stories. Fortunately they decided against such 'unfair' setup and some developers (including me) are very happy with this :-) The first (770) device program was done differently and maemo team shipped device directly which was of course better for developer outside of those countries but I can perfectly understand this was not easy and most possibly such experiment was possible only in the beginning of such project. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sqlite3 CLI?
Marius Gedminas wrote: > Do you know the reason for that? No. I also wondered why someone took the time to edit debian files to remove it from the build, it does not look like the most productive thing to do :-) Maybe it saves some trees? > > Is there a bug filed on bugs.maemo.org for restoring the command-line > tool? I did not file any since removing it was intentional and nobody missed it (except me). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sqlite3 CLI?
[EMAIL PROTECTED] wrote: > Which package do I need to install to have the sqlite3 command-line tool > available ? > There is no such package in SDK repository, you should install sqlite3 but this one is disabled in maemo patch for sqlite3 so you need to rebuild it from source and revert part of sqlite3_3.4.1-1osso3.diff.gz patch which disables it. http://repository.maemo.org/pool/chinook/free/s/sqlite3/ I had same problem some time ago, my build for chinook is here http://fanoush.wz.cz/maemo/sqlite3_3.4.1-1osso3_armel.deb Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: developing xkb mappings
Frantisek Dufka wrote: > xev is (or was?) in package x-debug-tools in maemo repository (chinook, > bora, ...) > > However it is not mentioned here > http://maemo.org/development/tools/ Correction, it is hidden under 'x-debug-tools' with link to separate page http://maemo.org/development/tools/doc/chinook/x-debug-tools Package is available in SDK repository http://repository.maemo.org/pool/chinook/free/x/x-debug-tools/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: developing xkb mappings
Tim Tisdall wrote: > Neither "showkey" nor "xev" are > already in Maemo and there doesn't seem to be anything in the package > handler containing these. xev is (or was?) in package x-debug-tools in maemo repository (chinook, bora, ...) However it is not mentioned here http://maemo.org/development/tools/ and searching maemo.org for xev brings xev manpage but also stale link to http://maemo.org/development/tools/doc/x-debug-tools Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Let's do something together in LinuxTag
Jose Manrique Lopez de la Fuente wrote: > Is the irc meeting log available somewhere? > Something is here http://maemo.org/maemo-meeting/maemo-meeting-2008-05-13.html but it appears to be cut at midnight. I couldn't attend so actually I'm not sure if there was anything interesting past midnight. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: dsme, Re: Would like to know the status of (was RE: Corporate ownership of open source projects [LWN])
nick loeve wrote: > Yep, I have been reading the archives and have compiled a shortlist of > info based on past discussions (mainly that you have started! ). I > guess I might start documenting what is known already and try and get > it all in one place. Yes, please do if you can. I am guilty of not doing it myself over years. I'm sure people on this list can fill some gaps. Apart from examining dsme, its modules and dsmetest in initfs (and its runtime behaviour using strace), check also powerlaunch http://powerlaunch.garage.maemo.org/ It is replacement of mce (also closed). mce talks to dsme too and is done in similar modular way so it can help with some understanding. Powerlaunch imitates some mce<->dsme communication, see dsme.c,h at https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/powered/?root=powerlaunch As for bme and figuring out how battery charging works, one could strace it and see what tahvo/retu register it uses, some bits are mentioned in kernel headers (not sure about name now, something like tahvo_retu_user.h) and there is also this info http://marc.info/?l=linux-omap&m=120752529631862&w=2 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
dsme, Re: Would like to know the status of (was RE: Corporate ownership of open source projects [LWN])
nick loeve wrote: > 2. Is it possible to at least get some basic documentation of what bme > and dsme are doing (beyond obvious basics)? There is a lot of info. Search list archives for dsme (or bme) http://www.gossamer-threads.com/lists/maemo/ If you still have some specific question not answered, ask again, maybe someone knows, maybe not. I'm not sure what 'obvious basics' means to you. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Gecko version? Re: Diablo, do we need a separate repository?
[EMAIL PROTECTED] wrote: > The only major changes are feature updates to the browser (not actually > a new browser, it's still based on the same old gecko as 2008) Sorry for hijacking thread, this is certainly not central to this discussion. Does the "it's still based on the same old gecko as 2008" really mean "same old and slow gecko as 2008 just with updated browser UI" or does it mean "same old gecko but synced to upstream mozilla code with multiple speed and memory optimizations done in last year or so"? Sorry for being a bit thick, I guess the latter is true and most probable but I am no longer sure due to the way you wrote the sentence above and you general description of Diablo in other mails ( About half of the packages have not changed version numbers at all ...). Thanks. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
[EMAIL PROTECTED] wrote: > 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. It is almost like this but not exactly. There is cx3110x open source glue part cx3110x.ko (see http://cx3110x.garage.maemo.org/), so far so good, but unfortunately the closed part (umac.ko) is full kernel module not linkable object file so it too depends on kernel version and sadly even specific kernel configuration, see https://garage.maemo.org/pipermail/cx3110x-devel/2007-December/07.html I don't understand where the line in GPL vs binary only code in kernel lies. I'd say that using struct sk_buff should make it derived work of linux kernel and subject to GPL but of course IANAL. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Igor Stoppa wrote: > -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) For 770 those pin are known, there is a schematics with pin descriptions. For N800 it is harder, there is also schematics on the net but those pins are sadly not documneted there. For N810 we even don't have schematics. Personaly I have tried it with clone of CA-42 cable http://www.dealextreme.com/details.dx/sku.446, there is PL-2302 usb to serial converter in the blue connector so in theory one could just cut nokia plug, attach rx,tx and gnd to 770 pads and connect it over USB. When I tried I had no output in terminal when booting (with r&d and serial console flags) so most probably I did something wrong or my plug made from pins and rubber had bad contact or the cable was faulty or whatever. I guess I'll try some soldering next time. > 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. brightness, watchdog kicking, ... all relatively easy, the hardest part is IMO /usr/lib/dsme/libcalmodule or /usr/lib/libcal.so, these modules implement access to config partition /dev/mtd1. There is some sort of filesystem which stores quite interesting and vital information. It can be reverse-engineered but I fear that trying to write there can be fatal if done wrong. Hopefully current work on qemu N800 emulation will allow us to play with it safely. > 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. Yes, that's what I sugested here (end of mail, point 2) http://lists.maemo.org/pipermail/maemo-users/2008-April/010183.html for those who missed it (in maemo-users) whole thread relevant to this discussion is here http://www.gossamer-threads.com/lists/maemo/users/36150 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
kernel patches, Re: DSP framebuffer access on N8x0
Simon Pickering wrote: > This requires two things, a kernel patch, and adding a FRAMEBUFFER section > to the /lib/dsp/avs_kernelcfg.cmd file. See > https://bugs.maemo.org/show_bug.cgi?id=3123 for the patch. Nice. I've been thinking about garage project named kernel-hacks or something, that would accumulate interesting kernel patches and even have some pre-built kernels with those patches applied. The reason is that there are already quite a few interesting kernel patches and it is hard to keep track of them. Of course it would make sense only if people doing some kernel hacking would actually join such project and submit patches and optionally build kernel images with some subset or all the patches. Opinions? Is it needed? Would you (actively) participate? Any better solutions (git tree)? Or we can still keep them scattered across bugzilla and internet. So far I know about following additional patches (feel free to add other stuff I missed, as I said it is hard to track all of them): - framebuffer rotation http://sse2.net/rotate/ http://labs.vivi.eng.br/blog/?p=39 - japanese FM bands for N800 tuner https://bugs.maemo.org/show_bug.cgi?id=2249 - high speed (48MHZ) SD/MMC http://intr.overt.org/blog/ - patches that run N8x0 DSP/CPU at 133/400 when playing audio - my (mostly 770) stuff - extended brightness control, mmcplus, sdhc, tearsync, yuv420 mode http://fanoush.wz.cz/maemo/ Some of them could be merged to mainline or Nokia kernel but many of them are just quick hacks of debatable value and correctness with little chance of merging to some official tree. Maybe some public GIT tree would be better but I'm not familiar with GIT. And also I don't have 24/7 online server for this anyway. I also thought about starting someting similar directly on http://fanoush.wz.cz/maemo/ but I don't want to hijack other people's stuff and it is free hosting so it is not safe, it can vanish anytime. Also recently I have become a bit slow due to busy real life so having more people for maintenance would be nice :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia SDL color format for pixels
Michael Stepanov wrote: > int bpp = surface->format->BytesPerPixel; You can check also other fields of SDL_PixelFormat structure to get R,G,B color components. Interesting field names are Uint8 Rloss; Uint8 Gloss; Uint8 Bloss; Uint8 Rshift; Uint8 Gshift; Uint8 Bshift; Uint32 Rmask; Uint32 Gmask; Uint32 Bmask; Or you can use SDL_GetRGB(Uint32 pixel, SDL_PixelFormat *fmt, Uint8 *r, Uint8 *g, Uint8 *b) function which will probably do the dirty bit shifting and masking work for you. http://www.google.com/search?q=SDL_GetRGB ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia SDL color format for pixels
Michael Stepanov wrote: > So, how in that situation I can get correct color? It is already correct. The color format is RGB565. What 'correct' means to you in this context? If you need the value in different format you need to convert it. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia SDL color format for pixels
Michael Stepanov wrote: > In case of Nokia that method returns *(Uint16 *)p. But instead of 6 > hexadecimals it returns only 4. For example, for white color it returns > instead of F. The same, for the rest of colors. > > Any idea why? > Some typo in your mail? Uint16 is 16 bit value, you really can't fit more than there :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: radare 0.9.4 for maemo
Andrew Flegg wrote: > On Tue, Mar 18, 2008 at 2:49 AM, pancake <[EMAIL PROTECTED]> wrote: >> I have managed to build vala 0.1.8 (svn) in scratchbox and updated >> the radare package. > > Are your vala packages in extras(-devel)? I know jott compiled some > for 0.1.6 at: > > http://sse2.net/vala/ > > More up-to-date, and centrally available versions for Scratchbox would > be handy, though. Even not just for scratchbox but for N810 directly too. We have keyboard so using gcc directly on N810 is not as insane as it looks first. One can quite easily apt-get gcc and developer packages and compile C stuff directly on device (tried X, SDL and glib stuff, not gtk or hildon). Vala would be nice addition too. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
usb networking with N810, Re: Nokia flasher parameters/boot sequence repair
Tuomas Kulve wrote: > "It also allows you to start ssh and telnet server in the device and > login over usb before even root filesystem is mounted so you can fix > system which is not booting properly." By the way, can anyone confirm it is working with current N810 firmware for linux (CDC) or XP (RNDIS) connection? Yesterday tried this for the first time with N810 with two XP based computers and it doesn't work for me. Network connection shows up in Network Connections but it is marked as disabled and when trying to enable it, it fails and stays disabled. Nothing strange in kernel log on N810 side. With same computer plugging 770 or OS2007-based N800 works fine with usb networking. N810 doesn't work for me either with current bootmenu or when precisely folowing http://maemo.org/development/documentation/how-tos/4-x/setting_up_usb_networking.html BTW, doing the insmod twice really works. Magic? So anyone is using it with success with Linux or Windows? Thanks for any report. I'm not using this feature much as booting from mmc is easier for recovery but yesterday I wanted to play with inserting framebuffer console modules early on boot and see if I can spawn shell on it. For N810 it finally makes sense having real (framebuffer) console with shell for recovery :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Launch image to increase feeling of responsiveness (a la iPhone)
Andrew Flegg wrote: > and it opened very quickly in less > than 2 seconds. Yes, expectations differ widely :-) For me anything above 1 second is slow and needs improvement. Anything above .5 second is bearable but not ideal. This is bad habit from PalmOS and old days when computers were fast :-) There is some old paper on the net about KDE performance by Waldo Bastian, see also [1]. Here is the relevant part: "Slow is a very subjective term, but when it comes to a graphical user interface, things are typically perceived as slow when there is a latency of more than 0.3 secs. between action and reaction. So if I click on a button, it should bring up a window on my screen within 0.3 secs. If it takes longer, users tend to perceive the system as slow." Frantisek 1. http://www.linuxtoday.com/developer/2001050801020OSDTKE ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Launch image to increase feeling of responsiveness (a la iPhone)
Michael Wiktowy wrote: > Well, I have news for you ... that <3s standard for showing a basic UI > has already been met (with the N800 and N810 running OS2008 at least). Actually OS2007 is faster here with my N800 in this regard. When launched repeatedly, both Application Manager and File Mananger show something below 0.5 seconds and look complete in <=1 second (except scanning cards and directories in FM). Startup of other apps is slower though. In OS2008 File manager is below 1 sec too, AM is slow like others. > So all your smoke and mirrors will likely impact the user perception > negatively Well, while the fake UI is non-functional it may still help you to do the thing faster. Imagine Calculator application. It takes time before one thinks about what to type and finds specific number button, but until you see the layout, you can only wait. With correct screenshot your mind can start thinking about what buttons to press in which order earlier. True that at the time you manage to hit first button with stylus, it must already be functional or at least buffer the events or you are confused. So IMO it is not just smoke and mirrors. With banner your mind is occupied with watching spinning circle and you don't/can't think about what exact actions you are going to do next. But still, focusing on improving actual startup speed is of course much better than doing such dirty tricks :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Launch image to increase feeling of responsiveness (a la iPhone)
[EMAIL PROTECTED] wrote: > When I and tired of waiting it is usually when launching gmail. > the think I do in between is to start a second web-browser. How would that > look > with the "startup"picks? Well the idea (not sure how real it is) was that doing the snapshot would be part of application initialization so the appliation itself could figure out pointer to bitmap of its own window and do a snapshow no matter if it is currently on the top or not. Also most applications do not take any input parameters so they look same on startup. Those that take parameters (like browser) either look same before they go to URL or maybe the snapshot should be done only if application is launched in some 'normal' way without using special parameters. As for fancy launcher with thumbnails, maybe this could be part of such launcher even now if the bitmap of specific window can be read via X API somehow. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Launch image to increase feeling of responsiveness (a la iPhone)
Mika Yrjölä wrote: > Then there is also the question of theming; even if the application > would have separate skeleton startup images for several themes (eating > the precious storage space), consistency still goes out of the window > if user installs a new, probably different-looking theme. One could perhaps do a snapshot on application startup before main loop is entered so next startup has updated banner screenshot. This would of course slow down startup even more but is one time penalty after each theme change. Still, maybe the effort should be better spent on improving actual startup speed ;-) Even current banner is sign of giving up. And it can be done. One such example is Application manager. Even on 770 with hacker edition it starts below half second, and N800/OS2007 is good too. Too bad I need quick startup with Calculator more than with AM :-) OS2008 is slower (even with higher cpu clock) but let's hope it can be improved in next firmware versions, first ones for previous system were not exactly fast too. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: devloping/using bitmap fonts on osso_xterm
Tomi Ollila wrote: > Hi > > Does osso_xterm support a bitmap font wrapped in a sfnt (TrueType or > OpenType wrapper)? > > I tried the following command: > > fonttosfnt -v -o fatFixedBitmap.ttf fat7x16-iso10646-1.bdf > fat8x16-iso10646-1.bdf > > ( above files available at http://www.iki.fi/too/sw/fatXfonts/ ) > > then moved fatFixedBitmap.ttf to /home/user/.fonts (on both 770 and N800) > and rebooted the tablets (somewhat different xterms on OS2006 and OS2008). > > Now both allows me to choose 'fatFixed' font on osso_xterm configuration > window but all I get is blank characters on xterm window when this font > is chosen (any point size). > Maybe you did not hit the correct size. I got this one (google for Terminus font, you may need to use cache if page with links is not available) http://chlamydia.fs.ei.tum.de/~corecode/unsorted/Terminus.ttf http://chlamydia.fs.ei.tum.de/~corecode/unsorted/TerminusBold.ttf and it shows blank characters except one specific size (use zoom keys to find it). See also http://www.internettablettalk.com/forums/showthread.php?t=17002 for screenshots. This made my xterm very pleasant to my eyes (finally). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: error while configuring kernel
Vinod Hegde wrote: > hi everyone, > I am getting the following error when i tried apt-get update in > MaemoKernel.. Just in case you missed it in the tutorial - "It is not mandatory to set up a separate target for kernel compilation, but this example does it in case the default armel target has been modified in some special way." So maybe you don't need to do such excercise. Also in case you want to change kernel configuration, check this http://www.internettablettalk.com/forums/showthread.php?p=124726#post124726 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
Kalle Valo wrote: > "ext Siarhei Siamashka" <[EMAIL PROTECTED]> writes: > >> A while ago I looked for various kernel docs to see what's happening in the >> wlan driver and what can be done to reduce cpu load. My impression was that >> tasklet can be only preempted by hardware interrupts, so it is impossible to Thanks for enlightement to both of you, that was the part I was missing. >> sleep in it and give cpu resources to userland applications. If that is true, >> no matter if n800 driver looks nicer, it must end up busylooping too. > > Nope, on N800 cx3110x and omap2_mcspi do not busyloop during the DMA > transfer. They use workqueues to allow sleeping, and completions for > signalling. > How is it so when you cannot sleep inside cx3110x_spi_dma_read and cx3110x_spi_dma_write? There appears to be same code for N800 too just the body of those functions does not use McBSP but SPI API: spi_message_add_tail(&t[1], &m); spi_sync(lp->spi_device, &m); Does it mean we can wrap McBSP usage into similar api and leave cx3110x otherwise alone without restructuring it? But still I don't get it, either spi_sync bysyloops or the semantics of cx3110x_spi_dma_write changed and it can return when the transfer is not yet done (??). Frantisek BTW, let's remove maemo-developers@maemo.org and move just to [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
Kalle Valo wrote:
>> Also CPU usage is very high because of busyloop when waiting till
>> DMA transfer is done. Tasklet, which executes the code can't be
>> easily preempted, as far as I understand kernel documentation. Maybe
>> it is possible to split tasklet into several parts, one of them
>> could be responsible for initiating DMA transfer, the other could be
>> activated on DMA transfer completion? This all is important for
>> video streaming as any excessive CPU resources consumption by WLAN
>> driver negatively impacts video playback performance.
>
> Sorry, I'm not familiar with OMAP 1710 McBSP, so I can't comment.
>
I think you don't have to. From the code (sm_drv_spi_io.c) it looks like
McBSP is setup to use dma transfer with callback when it finishes
omap_request_dma(OMAP_DMA_MCBSP2_TX, "McBSP TX", dma_tx_callback, ...
omap_request_dma(OMAP_DMA_MCBSP2_RX, "McBSP RX", dma_rx_callback,
and the dma_tx/rx_callback() code just sets variable
spi_dma.dma__tx/rx_done to 1.
But the code that sends/receives the frame busyloops for it like this
omap_start_dma(spi_dma.dma_rx_ch);
omap_start_dma(spi_dma.dma_tx_ch);
while(!spi_dma.dma_rx_done) {
udelay(5);
}
while(!spi_dma.dma_tx_done) {
udelay(5);
}
spi_dma.dma_rx_done = 0;
spi_dma.dma_tx_done = 0;
So there is this nice dma architecture with callback used but the code
still spins up the cpu waiting for the done flag instead of sleeping.
So you need to be familiar with the driver and tell us if it is possible
to sleep inside cx3110x_spi_dma_read and cx3110x_spi_dma_write. And one
also needs to be familiar with kernel programming and waiting primitives
to suggest how to sleep and wait for the callback (if possible in this
context) and how to wake up the sleeping code from the dma callback.
Frantisek
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [Maemo App Dev]How to make my app UI different
Ross Burton wrote: > Why would you want to make your application look and feel different from > every other application? An integrated system where all of the > applications for a coherent whole is far easier to use than one where > every application has buttons with different colours and fonts. Exactly. Also think about themes, user can choose from more default themes or have even custom theme (like black one) and your buttons or whatever will look completely wrong and may be not even readable. Will you test your application with every theme available? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using the scrollbar on the N810
Neil MacLeod wrote: > Richard Booth wrote: > >> How do others find it? >> >> Rich > > Exactly the same as you - when I grab the scrollbar thumbtrack, instead of > the events being processed by the scrollbar widget the events appear to be > processed by the main page of the application At least on my device this is due to erratic touchscreen. Try to install maemopadplus, turn off toolbar so there is no scrollbar and try to 'drag scrollbar'. At least on my device I always have beginning of the line moved to the left so it looks like T or 1. This means the first tap is interpreted inside main page. Please report it in bugzilla if you have time. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Horrible Roaming Performance (N800, OS2008), Software or Hardware Problem ?
Siarhei Siamashka wrote: > I'm sorry. For some unknown reason, I thought that I notified you > about this problem long ago, but appears that we only discussed this > issue privately with Frantisek Dufka :( I think it was discussed also in the "Memory corruption during WLAN use" bug too - http://bugs.maemo.org/show_bug.cgi?id=2006 > [50622.038146] We haven't got a READY interrupt from WAKEUP. (firmware > crashed?) > [50622.038269] Try again... > [50622.038330] succeeded!!! > > I'm attaching the same patch here. It is not very clean, but it does > the job (for Nokia 770). Not seeing whole code now but I wondered before - isn't it possible just to increase timeout inside 'if (time_after(jiffies, timeout))' instead of two passes in loop? > Also CPU usage is very high because of > busyloop when waiting till DMA transfer is done. Tasklet, which > executes the code can't be easily preempted, as far as I understand > kernel documentation. Maybe it is possible to split tasklet into > several parts, one of them could be responsible for initiating DMA > transfer, the other could be activated on DMA transfer completion? > This all is important for video streaming as any excessive CPU > resources consumption by WLAN driver negatively impacts video playback > performance. I wonder about this too. Sadly I am not so skilled in kernel and don't know rules for interrupts, sleeping in kernel, bottom halves etc. so splitting the code at least in 770 version (bit banging over McBSP and ugly udelay() busylooping for DMA transfer) is too much for my abilities. The N800 code looks nicer, where the CPU is burnt there? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
Siarhei Siamashka wrote: > N800 hardware definitely supports tearsync. And 770 should too according to the schematics floating on the net. Only the code never made to official 770 kernel but is/was part of released N800 kernel. Sadly last time I tried and ported this code back to 770 kernel it just hanged the device and the interrupt on TE pin never arrived. I'm suspecting the sossi TE pin needs to be enabled somehow via some platform specific (omap1) initialization code that was not part of N800 kernel. The failed attempt is here http://fanoush.wz.cz/maemo/2.6.16.yuv420+tearsync-not-working.diff Got no reply here http://lists.maemo.org/pipermail/maemo-developers/2007-May/010156.html but something here http://www.gossamer-threads.com/lists/maemo/developers/22701#22701 Also on the similar 'banging my head against the wall' kernel topic - some weeks ago I downgraded my N800 back to OS2007 (as I have N810 with it, the N800 touchscreen is much worse in OS2008 and I like speed of Opera and the system i general). Also since I boot from mmc I flashed only initfs and kernel (i.e. not bootloader). Then I noticed my external mmc slot does not work. Flashed to OS2008 back - it worked again, flashed back to OS2007 - no luck even with original Nokia kernel. I spent some time digging in kernel source and even backporting changes in mmc stack from 2.6.21 to 2.6.18 with no luck. Finally I had an idea to flash bootloader too (over USB, kernel and initfs can be done on the fly from the device so one could sort of dual boot between OS2007 and 8). After doing this my external mmc slot magically works again in OS2007 (NOLO is downgraded from 1.1.7 to 1.1.6). This was a bit discouraging and tells me something about chances of getting tearsync code working without proper HW initialization and bootloader sources :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
Siarhei Siamashka wrote: those interested in the topic, documentation for the Epson LCD > controller used in N8x0 (S1D13745) is available here: > http://vdc.epson.com/index.php?option=com_docman&task=cat_view&gid=38&Itemid=40 And for 770 (S1D13742) here http://vdc.epson.com/index.php?option=com_docman&task=cat_view&gid=36&Itemid=99 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
Tapani Pälli wrote: > Hello; > > ext Tobias Oberstein wrote: >> Hello tableteers, >> >> I've done some initial experiments hacking my N800/OS2008 and ran into a >> couple of issues: >> >> When using the supplied SDL library for doing timer-based frame >> rendering, there seems to be >> >> - heavy tearing >> > > Tearing unfortunately happens because there is no vsync available for > framebuffer driver to use. > with direct fb access there is ioctl flag OMAPFB_FORMAT_FLAG_TEARSYNC that should take care of it and schedule the update at right time. But still I think there is not enough time to do full screen 800x480x16bit update even if it starts at right time. In the example Tobias posted it is this part // wait for fb->lcd video ram transfer complete ioctl (fbfd, OMAPFB_SYNC_GFX); // "render" whole frame in single color memset (fbp, n, ssize); // wait for vsync ioctl (fbfd, OMAPFB_VSYNC); // request transfer of fb-> lcd video ram for whole screen ioctl (fbfd, OMAPFB_UPDATE_WINDOW, &update); and basically it looks correct to me except maybe 'ioctl (fbfd, OMAPFB_VSYNC);' may do nothing but won't hurt. >> Q: Is this expected behaviour? What could I do about the tearing? What >> about the Xomap overhead? This was discussed here in the list and there are timing results posted by Siarhei Siamashka. I think you can only solve it by updating smaller region and/or use 12 bit YUV format. There was also discussion about 'accelerated' SDL with direct fb access. I think it would be a nice hack to use direct fb access when SDL X window is on the top or full screen and fall back to using X in other cases. But due to hackish nature and HW dependency on features of Epson chips in 770 and N8x0 it won't be accepted to nokia version of SDL. I think the hint was that that future generation of devices will not use similar chip so there is no future for this code. But true that there are present and past devices so it may make sense to make hacked community version of SDL for current game ports. Also such version could safely take advantage of pixel doubling which is impossible to use safely with Xsp extension. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, tearing, X overhead and direct framebuffer gfx
Michael Flaig wrote: > Hi, > > sorry can't say much about the other things... > >> Q: btw - how can I shutdown Maemo Launcher/Hildon/Matchbox/Xomap? >> Whenever I do one of >> >> /etc/init.d/maemo-launcher stop >> /etc/init.d/x-server stop >> >> the device will automatically reboot. > > There is a watchdog in place. I believe you can disable it with the > flasher utility... Never tried but I think it should be possible to stop (almost) everything in reverse order without triggering reboot. In this case reboot may mean x-server was stopped before stopping other services that depend on it. Try to go over /etc/rc2.d/ and stop stuff in reverse order. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: RE : Re: Fullscreen and flash, new question
Hi, you forgot to cc the list Frédéric Charrier wrote: >> Instead of workarounds you mentioned it could be done via custom >> application that just embeds browser engine and flash plugin like the >> getting started tutorial present on the device. Or even custom >> (browser) >> engine with enough hooks to just embed the flash plugin without full >> html rendering widget would be nice for saving free memory. > > It seems a good idea. > Where can I find information about how to embed a flash plugin into my > own app ? (I didn't knew there is a flash plugin available for custom > apps on Maemo). Search the mailing list, few days ago someone tried this http://lists.maemo.org/pipermail/maemo-developers/2008-February/014564.html but you may find even older attempts an pointers http://www.gossamer-threads.com/lists/engine?list=maemo&do=search_results&search_forum=all&search_string=embed+browser+engine&search_type=AND > > And how can I see the "getting started tutorial" on my N810 ? It is an applet called "Get started" on home screen. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fullscreen and flash, new question
Frédéric Charrier wrote: > Hi everyone, > > as Carlos Pinto, I want to display my Flash application in fullscreen > mode. > Instead of workarounds you mentioned it could be done via custom application that just embeds browser engine and flash plugin like the getting started tutorial present on the device. Or even custom (browser) engine with enough hooks to just embed the flash plugin without full html rendering widget would be nice for saving free memory. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810: shift+fn+N or M generate two keycodes each
Santtu Lakkala wrote: > Shift-fn-n and -m both produce $€, so same b0rkedness can be observed > here too. Ok, thanks. Reported as http://bugs.maemo.org/show_bug.cgi?id=2933 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
N810: shift+fn+N or M generate two keycodes each
Hi,
I have device with german keys. I've been playing with changing
/usr/share/11/xkb/symbols/nokia_vndr/rx-44 and adding my custom
keymappings. Mapped 'Tab' '`' '|' to Fn + 'space' ',' '.' with no
problem. Also found that there is third and fourth column duplicated and
one could in fact press left shift + fn quite easily with thumb (shift
first) to access fourth column. Succesfully mapped 'K','L' which gives
with fn only '(' ')' to give me '[' ']' with shift+fn. Then tried same
trick with 'N','M' giving '<' '>' to give me '{' '}' but each of them
print "{}" instead of just '{' or '}'.
Switched to unmodified English layout to disable my changes but pressing
N also print two characters instead of one - dollar and euro sign.
Verified also with xev and when I press shift+fn+N I see two key press
and release events generated for N.
KeyPress event, serial 20, synthetic NO, window 0x181,
root 0x3e, subw 0x0, time 237914792, (32,305), root:(112,365),
state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 characters: ""
KeyPress event, serial 23, synthetic NO, window 0x181,
root 0x3e, subw 0x0, time 237916134, (32,305), root:(112,365),
state 0x1, keycode 216 (keysym 0xfe03, ISO_Level3_Shift),
same_screen YES,
XLookupString gives 0 characters: ""
KeyPress event, serial 23, synthetic NO, window 0x181,
root 0x3e, subw 0x0, time 237918277, (32,305), root:(112,365),
state 0x81, keycode 57 (keysym 0x7b, braceleft), same_screen YES,
XLookupString gives 1 characters: "{"
KeyPress event, serial 23, synthetic NO, window 0x181,
root 0x3e, subw 0x0, time 237918277, (32,305), root:(112,365),
state 0x81, keycode 58 (keysym 0x7d, braceright), same_screen YES,
XLookupString gives 1 characters: "}"
KeyRelease event, serial 23, synthetic NO, window 0x181,
root 0x3e, subw 0x0, time 237918430, (32,305), root:(112,365),
state 0x81, keycode 57 (keysym 0x7b, braceleft), same_screen YES,
XLookupString gives 1 characters: "{"
KeyRelease event, serial 23, synthetic NO, window 0x181,
root 0x3e, subw 0x0, time 237918430, (32,305), root:(112,365),
state 0x81, keycode 58 (keysym 0x7d, braceright), same_screen YES,
XLookupString gives 1 characters: "}"
KeyRelease event, serial 23, synthetic NO, window 0x181,
root 0x3e, subw 0x0, time 237918625, (32,305), root:(112,365),
state 0x81, keycode 216 (keysym 0xfe03, ISO_Level3_Shift),
same_screen YES,
XLookupString gives 0 characters: ""
I tried all other keys on keyboard and no other keys do it when shift
and fn are pressed, just 'N' and 'M'. Can anyone with no modifications
done on your device press left shift+fn+n and see if two keys are
generated too?
Is this bug in mapping somewhere deeper than xkb or can this phantom key
be some HW limitation when those 3 keys are pressed?
Frantisek
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New release of Python2.5 for Maemo
Luciano Miguel Wolf wrote: > What's planned? > --- > Next release is planned to have a beta version of Python-Launcher. It is > a daemon that loads heavy modules, like pygtk, and just fork every time > python is called. This reduces the startup time of applications using > pygtk. Just curious, any more details on this? I did a quick look at pymaemo-developers archive and browsed pymaemo SVN tree but failed to find any details or code in progress. I wonder how configurable it will be (i.e list of modules preloaded in the launcher, could and should I still launch separate python for simple non-gui python stuff?) and how it will play with memory - will each (forked) python instance with gtk and everything take additional memory (like now) or will be most/all of it shared. But I guess we'll see when the beta arrives in next release (any ETA?). Thanks for the release BTW, I hope we'll see quick and lean python runtime preinstalled (or in some repository enabled by default) in the tablets in future. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Compiling new kernel for N810
David Hautbois wrote: > The kernel-source-rx-34-2.6.21.0 package >Is it the N810 kernel source ? Yes but providing a link or telling us what version you used could help with troubleshooting your issue :-) The osso63.1 one is known to have this problem at least with N800. Kernel for latest firmware is here http://repository.maemo.org/pool/os2008/free/source/k/kernel-source-rx-34/ Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Klaus.K Pedersen (Nokia-M/Helsinki) wrote: > 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 what you are seeing is that the "DSP task policy" is active even > though there are no dynamic dsp task loaded? > Just an update/explanation. I was not fuly aware of how it works. The most important difference here that I missed previously is the term 'dynamic dsp task'. I was not aware that there are also 'static' dsp tasks. They look same from userspace but are linked statically to dsp bios (?) and the clock policy ignores them (on purpose). So the pcm0/pcm1 dsp tasks are static but pcm2 is dynamic. Therefore uncompressed audio output via pcm0/1 leaves the clock at 400 but same output via pcm2 drops clock to 330. So maybe this is a bug and I should report it in bugzilla? Maybe Real audio should use pcm0 or 1 or pcm2 should not be dynamic task? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Announcement: OS2008 2.2007.50-2 source repository
Murray Cumming wrote: >> Thank you. So Chinook and os2008 is different thing now. > > That makes no sense to me - it's contradictory to everything we've heard > before. I don't understand why a new repository has been created. > To me it makes sense to have it separated. os2008 is repository with sources for released firmware (IMO best would be to have os2008-2.2007.50-2 and os2008 being symlink to latest and keep few older ones too). You don't need repository for this but why not, you need to dump those files somewhere anyway (to satisfy GPL). It is better than one big tar archive as it was before. chinook is the SDK - it contains extra stuff for development, some stuff missing (provided by scratchbox), some stuff different that breaks the tablet but is needed in SDK etc So for me it makes sense. Also you can (and should) release os2008 repository at the time of firmware release. With SDK you can wait few days or weeks to make all tools ready. That was one 'excuse' we heard before (firmware is ready, SDK not, should we delay firmware because of this?). Also you can provide system updates via os200x repository. With the SDK one it is harder to not to break anything. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Announcement: OS2008 2.2007.50-2 source repository
[EMAIL PROTECTED] wrote: > Hi, > > The source code for open source components of OS2008 version 2.2007.50-2 > have been uploaded to a new repository. To be able to find the sources, > please point your browser to > > _http://repository.maemo.org/pool/os2008/free_ > Thank you. So Chinook and os2008 is different thing now. Chinook is the SDK and os2008 has sources to (latest only?) firmware image. That's nice and makes sense. Perhaps os2008 repository is there also to provide those planned non-monolithic OS updates in future? So, umm, any plans to make os200x repository updated together with firmware release in future? Frantisek P.S. I am very happy about the kernel source, thanks http://repository.maemo.org/pool/os2008/free/source/k/kernel-source-rx-34/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Klaus.K Pedersen (Nokia-M/Helsinki) wrote: > So what you are seeing is that the "DSP task policy" is active even > though there are no dynamic dsp task loaded? No, not exactly. First thing - I did not know there is a way to output audio without loading dynamic dsp tasks (named pcm and possibly also pcm2 and 3). I guess this is new feature in OS2008 and with the frequency scaling complictions it looks like this feature is a solution to many performance problems (like videos in flash player) and is generally useful. Also it makes the pcm dsp tasks (i.e. tasks playing just uncompressed audio) obsolete and worse choice because of lowered arm clock when they start. So what I see instead is that gstreamer framework probably uses those pcm dsp tasks (instead of the new way) so when you are playing music in Real audio format (like the BBC radio preinstalled in the firmware) the audio is decompressed on CPU but pcm2 task is started and frequency drops to 330. And so in fact when listening to internet radio you are penalized twice with real audio - frequency drops and audio is decoded on cpu so user experince with microb is degraded. It is slightly better with MP3 audio but still it is unexpected penalty which did not happen with N800/OS2007 and 770 too. On those systems playing mp3 on background came virtually for free. Also that is why I asked why there are pcm dsp tasks at all in OS2008? Or if they are there for better mixing than the logic which reduces clock from 400/133 to 330/220 should be more clever and kick in only when it is really needed. The switch (and audio click) is there anyway if you are first playing music in something SDL based (ScummVM) and then start audio via gstreamer (internet radio). 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 ?
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 ?
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: 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: Frequencies scaling with OS2008
Simon Pickering wrote: > It would be interesting to see whether the mp3 task (for example) can > decode in real time when the DSP is run at 133MHz or are your > audio/video sync problems because it's running too slowly? This would > remove some load from the CPU and allow us to use the DSP for something. As I mentioned in some previous mail, it is quite easy, just redefine O_DSP_H on line 44 of arch/arm/mach-omap2/board-n800-dvfs.c Here is testing kernel with this state defined as 400/133. http://fanoush.wz.cz/maemo/zImage-2.6.21.0-osso63-dsp133.tar.gz Tried few mp3 songs and radios and didn't hear any problems, 128kbps is absoulutely fine and I didn't notice any problem also with VBR with average rate ~160kbps (some frames even 224 or 320 kbps). I don't have any music in AAC or very high constant mp3 bitrate. 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 ?
Another update. I checked also kernel from first OS2008 beta kernel version in firmware is SW version in image: RX-34_2008SE_1.2007.44-4_PR_MR0 Image 'kernel', size 1529984 bytes Version 2.6.21.0-200744osso2 debian/changelog: kernel-source-rx-34 (2.6.21.0-osso55) unstable; urgency=low * week200741-2 release * Fixes: NB#72086, NB#72075 * Revert "JFFS2: Reduce time for which erase_free_sem is held during erase." * USB: OTG: Disable autosuspend for whitelisted nokia devices * USB: MUSB: Add missing otg_set_error when device draws too much current * Reduce dirty ratio granularity to 0.1%. * MMC: OMAP: Cleanups and fixes for mmc clock management. -- Yauheni Kaliuta <[EMAIL PROTECTED]> Tue, 9 Oct 2007 19:01:56 +0300 kernel-source-rx-34 (2.6.21.0-osso54) unstable; urgency=low * Updated bugfixes. Fixes: NB#71677, NB#72396 -- Yauheni Kaliuta <[EMAIL PROTECTED]> Mon, 8 Oct 2007 18:33:31 +0300 ... ... Looks like even osso55 is not exactly same as 200744osso2 from firmware image. Changelog in kernel source has week200741-2 release on the top (!? 41 vs 44). And what is also interesting - with both older kernels (from 1.2007.44-4 firmware and self compiled osso55) external mmc slot doesn't work on my N800. It only starts to work once I flash kernel extracted from RX-34_2008SE_2.2007.50-2_PR_MR0. I tried 3 different SD cards (256MB SD, 1GB SD, 4GB SDHC) with same result. Internal slot works fine with these cards. Another interesting thing is that kernel images from both firmwares are shorter (even if they are padded in firmware image) than self compiled ones (no patches, nokia_2420_defconfig). RX-34_2008SE_1.2007.44-4: 2.6.21.0-200744osso2 - file size 1529984, kernel size inside 1529876 self compiled 2.6.21.0-osso55 - file and kernel size 1532176 RX-34_2008SE_2.2007.50-2: 2.6.21.0-200749osso2 - file size 1529984, kernel inside 1529864 2.6.21.0-osso63.1 - file and kernel size 1530288 bytes In all cases /proc/version reports same compiler - gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2), the one from scratchbox arm targets for all recent SDK (snice 2.2?). I have used the one from SDK40. So either the published kernel sources for both recent OS2008 releases are different or Nokia uses different build procedure (patched compiler, different compiler flags) or even both. That's unfortunate. How can we trust such kernels when the result compiled from published sources differs both in size and functionality? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
correct kernel source for RX-34_2008SE_2.2007.50-2 ?
Hello, 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 mmci-omap mmci-omap.1: command timeout (CMD8) mmci-omap mmci-omap.1: command timeout (CMD8) I thought this is because of some of my patches but even build from clean source like this tar zxvf kernel-source-rx-34_2.6.21.0.orig.tar.gz cd kernel-source-rx-34-2.6.21.0 zcat ../kernel-source-rx-34_2.6.21.0-osso63.1.diff.gz | patch -p1 make nokia_2420_defconfig make has same problem. Also when extracting firmware, kernel version is reported as SW version in image: RX-34_2008SE_2.2007.50-2_PR_MR0 Image 'kernel', size 1529984 bytes Version 2.6.21.0-200749osso2 and not osso63. Also debian/changelog inside kernel source has no week release on the top, here is beginning: kernel-source-rx-34 (2.6.21.0-osso63.1) unstable; urgency=low * Fix cache coherency issue on ARM -- Yauheni Kaliuta <[EMAIL PROTECTED]> Fri, 16 Nov 2007 16:00:52 +0200 kernel-source-rx-34 (2.6.21.0-osso63) unstable; urgency=low * week200743-1 release. Fixes: NB#73077 * mmc mounts messed up and load of other weirdness -- Yauheni Kaliuta <[EMAIL PROTECTED]> Tue, 23 Oct 2007 17:47:25 +0300 So, umm, can we have real kernel source for RX-34_2008SE_2.2007.50-2 please? Thanks. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
Jayesh Salvi wrote: > I guess there isn't much to do - for an app programmer at least. I found > the same behavior with osso_pdfviewer. It also uses hildon's > FileChooserDialog. But even before that dialog is invoked, multiple > processes are forked. ... and they do not disappear until their parent > exits. I think once they are initialized they don't go away since you may actually need them if user clicks some file in the dialog which is 'provided' by them. > They keep occupying the same amount of memory as their parent. > This is really taxing on my n770. > > If this is the default behavior of gnome-vfs based GTK apps, then I hope > it gets improved for embedded devices. > BTW, are you sure the memory situation is really worse because of this? If yes then maybe this is specific to python. In C forked process does not add much memory overhead because memory pages in childs are shared with the parent until they are modified. So I guess when programming in C this is not a big issue so nobody cared so far. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
Jayesh Salvi wrote: > 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. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
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? 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? 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. 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)? 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. 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? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
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). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bluez utilities - where get it
Arkady Glazov wrote: > Hi, > > Can I get same bluez utils from standart repositories? I need in > hcitool and rfcomm for binding console to my TomTom Go 910. Or, I > should compile them from source itself? What the version BlueZ i > should compile then? > If all you need is 'hcitool scan' and rfcomm bind and release functionality then you may also check how it is done in kbdd for OS2008 [1][2]. There is dbus-bluez-rfcomm shell script as a replacement for rfcomm binary and dbus-bluez-scan binary made out of Vala bluez example [3]. Additional advantage is that you don't need root privileges and rfcomm port is allocated automatically so you don't need to hardcode it. Frantisek 1. http://fanoush.wz.cz/maemo/#kbdd 2. http://fanoush.wz.cz/maemo/kbdd.tar.gz 3. http://live.gnome.org/Vala/BlueZSample ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: point ou9t, [please, the way to go ...
Well, if Chinook SDK page [1] with installer script (which should download correct versions of everything) doesn't work for you for some reason, you can try Maemo VMWare appliance [2] with SDK already preinstalled. 1. http://maemo.org/development/sdks/maemo_4_0_chinook_sdk.html 2. https://garage.maemo.org/projects/maemovmware/ ___ 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 ?
Darius Jack wrote: > It would be nice to have that solution incorporated into N800s one day. Well, even if you get SDIO stack working, most or even all SDIO cards are longer than memory cards so they are not very practical with N800 due to location of the slot. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ogg Vorbis / Theora Language Removed From HTML5 Spec
Raphaël Jacquot wrote: (But I'd guess that a fair number of maemo-developers are LWN subscribers, so hopefully my post is useful for them.) >>> http://lwn.net/SubscriberLink/261694/.../ >> Do NOT spread the word ... > > don't worry, it won't escape the internet ;-) Well actually this lwn.net feature is meant exactly for this. It should give you a peek so you realize LWN is great (and it really is :-) and subscribe. For starving hackers there is even cheap starving hacker level. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: USB Host mode and OS2008
Juuso Räsänen wrote: > I also tried with a recompiled kernel with CONFIG_USB_OTG_WHITELIST disabled. > It "removed" some of the above "warnings" but otherwise I didn't notice any > difference in the behaviour. What does this whitelist actually mean?? I'm puzzled by this too. In OS2007 this had some effect and I think USB devices did not work but people are reporting success even without this option. So far I was too lazy to switch this back on and see what works and what not. Maybe this still have some effect but most devices are enabled in the whitelist (like hubs, usb storage or HID devices) so with most devices there is not difference. As for meaning - this whitelist should allow manufacturer to provide a list of tested and supported devices to kernel and disallow any other random device you may otherwise connect. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810: 2GB internal flash and boot from MMC ?
Igor Stoppa wrote: > > It's a GBA chip. > Oh, so it is similar/same solution like those eMMC chips mentioned at http://www.mmca.org/home after all. I was afraid of that but still was secretly hoping for inaccessible simplified mmc slot with glued real card or something, this could still save some space (but not $$). So looks we're stuck with 2GB size. I guess it it impossible to remove soldered BGA chip. Let's hope it is at least fast and durable one (i.e. SLC flash, 8bits mmc bus width or capable of 48MHz) not similar in quality to cards Nokia bundles with phones or tablets. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810: 2GB internal flash and boot from MMC ?
Uwe Koch wrote: > ...and supposed this method (the initfs of that method) will adopted to the > N810 firmware. Oh and it is already adopted since the day we had N810 firmware booting on N800. Not sure if someone tried with N810 but the initfs flasher should work with both N810 and OS2008 based N800 (real beta for N800 or firmware intended for N810). Maybe with N810 you need to backup data (maps?) before re-partitioning internal 'card' if you want to boot from it. Or maybe you can reformat it and later just download maps you need to fresh FAT partition. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810: 2GB internal flash and boot from MMC ?
N810 internal 2GB storage looks to linux kernel like normal MMC card. You just can't remove it :-) It is similar/same like having 2gb card in N800 internal slot. Still I wonder how it looks on the board. I hope it can be replaced somehow. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
770 mmc hardware question - sdhc bugfix needed for high capacity cards?
Hi, this is question mainly to @nokia.com kernel people familiar with 770 and N800 MMC code and/or OMAP1 vs OMAP2 power management (like those ones who fixed bug http://bugs.maemo.org/show_bug.cgi?id=1204#c120) Is the MMC_POWER_STANDBY feature implemented in OMAP MMC driver for latest N800 2.6.18 kernel relevant to 770 hardware? Does omap1710 lower MMC slot power in sleep (when all clocks are off) too so this is needed for high capacity cards? Recently I have backported MMC code from N800 2.6.18 kernel to allow SDHC cards to be used in 770 but I don't know whether I should let the code which waits for the card before turning off MMC clock in or not. And while we are are at it, here is second question that bugs me for long time. Does 770 hardware allow to give MMCmobile cards 1.8 volts? From the schematics floating on the net it looks like OMAP uses 1.8 volts but there is LP3928TLX voltage converter [1] [2] between omap and mmc slot which cannot be bypassed in software, is this correct or did I miss something? And third bonus question, is it stupid idea to search for OMAP pins for second MMC interface and connect them directly to dual voltage MMCmobile card capable of running at 1.8 volts and have some chance for this to actually work? Frantisek 1. http://www.national.com/opf/LP/LP3928.html 2. http://www.alldatasheet.com/view.jsp?Searchword=LP3928TLX ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bugfix in cx3110
Steven Walter wrote: > While reading through the wireless card driver (what source is > available), I noticed what is almost certainly a bug: Great. There better place for this - http://garage.maemo.org/mailman/listinfo/cx3110x-devel Or maybe even bugzilla? Regards, Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Static and dynamic linkage
[EMAIL PROTECTED] wrote: > > Which would mean having to deal with SQLite as a dependency of this > package... > I have similar problem with ScummVM. I really do not want to deal with all the dependencies and maintain them in Maemo extras repository so I am linking libmad, Tremor, FLAC, libmpeg etc. statically. I don't know how to easily solve static vs dynamic linking flags too so my solution was to compile and install all those libraries inside scratchbox only statically (i.e. no .so, just .a) and point scummvm to them so linker does not find their dynamic libraries at all. Then you don't need to mess with linking flags and package builds fine. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Static and dynamic linkage
[EMAIL PROTECTED] wrote: > Is there a standard way to ask for a specific library to be linked in > statically and the rest to be dynamic? > > Specifically, I want to statically link in the SQLite library but leave > the rest of the linkage as is. > It may work in your case but in general there may be unexpected issues when mixing this especially when using c++ check http://www.trilithium.com/johan/2005/06/static-libstdc/ Also in plain C linking some library foo statically while linking other library bar dynamically that is already linked dynamically to foo (and similar variations of this when using multiple dependent libraries) may give you unexpected issues both at link time and also later at run time. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: TI frees its DSP toolchain for open source apps (?) - linuxdevices
Nils Faerber wrote: > I had a quite longish discussion with TI DSP OSS support about a year > ago. And after some weeks of back an forth the guy said, that they (TI) > would have no problem with open source code being developed with this > toolchain and even binary versions of the code being redistributed - as > long as noone makes money from using the toolchain, I guess. Good news overall, thanks. Still it would be nice to have the agreement text cleaned up. TI's opinion may change without warning and the text as it is now is not so friendly. But it is good to know that chances of unhappy calls from TI's lawyers are low :-) One more reason to take DSP development seriously. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Confused about Application Catalog
Graham Cobb wrote: > Do I create a new page (even though the "unix name" > will be the same)? Yes. Not sure about unix name but it seems to work. > > This seems a retrograde step as it is useful to just have one page for > comments, one page to update if the app moves, etc. Exactly. I feel you pain too, see http://bugs.maemo.org/show_bug.cgi?id=2121 I my case I even have exactly the same binary for all systems so making 3 pages for it is just pure annoyance. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: installable deb package, Re: Data corruption on N770
Rainer Dorsch wrote: > thanks for providing the package for OS2006, that is great news. I installed > it and it did not break anything as far as I can tell. Thanks for the report. > The only thing I am > surprised is that the module is reported as cx3110x by lsmod: Yes, it is just renamed on disk to not to conflict with the original one in case someone has modules in rootfs in /lib/modules/2.6.16.27-omap1 too. Internal module name set at compile time is still cx3110x. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: TI frees its DSP toolchain for open source apps (?) - linuxdevices
Simon Pickering wrote: > I'm not all together sure how this (the Google SoC project) differs > from the dspgateway, except perhaps for the choice of DSP. Why have yet > another way of bridging between ARM and DSP? Either C54x architecture is more limited (no MMU? no space for multitasking core like DSP BIOS?) or this is really quick student hack for G-SoC without deep research for existing alternatives. > We do already have a Linux Ti toolchain ( > https://www-a.ti.com/downloads/sds_support/targetcontent/LinuxDspTools/index.html) > which is for the C55x only (i.e. is useful to us). I'm not sure the release > of another (similar afaict) toolchain for the C54x will make any odds to us > (except perhaps that Ti are embracing open source developers > :). Well the EULA says that it should be used only with TI development board (without exact definition what it is) so I am not sure that open source code can be compiled with it and result published for usage with 770 or N8x0 even if our tablets contain silicon made by TI and it is non-profit. Perhaps more friendly licencing terms similar to this C54x toolchain would be nice to have for our C55x toolchain too. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
installable deb package, Re: Data corruption on N770
Frantisek Dufka wrote: > I am also working now on packaging this module as installable deb for > OS2006 users. > Hello, I have created installable deb package for OS2006 and older hacker editions. If possible please test and report problems here. There is one more fix for omap_mcbsp_spi_master_recv_word_poll function writing one word past the end of data buffer. Alignment issues remain unfixed since it seems they do not cause any problems as the buffer seems to be properly aligned. For details see https://bugs.maemo.org/show_bug.cgi?id=2006 Link to deb package - http://bugs.maemo.org/attachment.cgi?id=613 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: new hacker edition Re: Data corruption on N770
Joni Valtanen wrote: > Propably best to copy wlan driver > from https://bugs.maemo.org/show_bug.cgi?id=2006 and path your initfs > yourself. I'm not sure whether you compiled driver yourself from sources and patches attached or just took the preliminary one uploaded by me and copied it to HE initfs. If you took the attached binary and pal to do it again then please wait I will upload different one today. I'll bump up the version string so it can be easily identified in kernel log and also add waiting for both dma transfers in cx3110x_spi_dma_write which is more correct (even if it may not make any difference in reality since both DMA transfers are started and should finish at the same time). We definitely do not want DMA to hit stack variable after exiting function. I am also working now on packaging this module as installable deb for OS2006 users. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
new hacker edition Re: Data corruption on N770
Hi Joni, thanks for fixing this in latest hacker edition. Is there any reason why older initfs was used again? There is latest -49 OS2006 firmware with changelog telling something about wi-fi certification (so there were some further fixes?) but this and previous hacker edition used older -38 initfs from older 2006 firmware. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL App runs for some seconds and then dies
Eero Tamminen wrote: > Easiest is to fix your .desktop file. Which in other words means that you should remove D-BUS service declaration in the .desktop file if you don't implement it in your application. See also http://maemo.org/community/wiki/gamedevelopment/#7179b7084dd3339e008879a088142aae ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OS2008 download?
Ferenc Szekely wrote: > Yep, Marius is right. Nokia will release an image for N800 soon. The > image for N810 (or parts of it) is (are) not meant for N800. > Still it seems to work with no major issues and is very useful for developers with N800 for testing and polishing chinook stuff right now. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Data corruption on N770 in OS2007 HE
Alex DAMIAN wrote: > Any idea about what I'm doing wrong ? Hard to guess without any details posted but you might try to make it directly on the device if you already got the initfs flashing script with mtd-utils. sudo gainroot #copy initfs mkdir -p mnt mount -t jffs2 -o ro /dev/mtdblock3 mnt cp -a mnt initfs umount mnt rmdir mnt #make image cp ../cx3110x-on-stack.ko initfs/lib/modules/current/cx3110x.ko mkfs.jffs2 -r initfs -o initfs.jffs2 -e 128 -l -n rm -rf initfs now copy initfs.jffs2 to PC and flash with Nokia flasher or flash it directly from device like this ../initfs_flash initfs.jffs But maybe the easiest is to modify /etc/init.d/rcS to remove broken module and reinsert fixed one like mentioned in previous mail. As for easy to install (.deb) package I'm still not sure which one to make - initfs reflash or rootfs modification, first (initfs modification) is a bit more unsafe to install but can be done only once when booting multiple systems, second is safe to install and a bit easier to make but needs install into each rootfs. Perhaps I should make both to make it even more confusing :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Data corruption on N770
Levi Bard wrote: > Fantastic. I've been having to reflash roughly once a week due to > spontaneously occurring reboot loops. Has this bug always been there, > or will reverting to an earlier 2007HE help avoid it? Well maybe you can't blame this bug for every crash but yes it is there for long time, possibly since day one of Nokia 770. It was reproduced more than year ago by several people see http://bugs.maemo.org/show_bug.cgi?id=677#c4 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Data corruption on N770
Neil MacLeod wrote: > Until this bug is eliminated any device instability while WiFi is enabled can > be attributed to it. > Well it is slightly worse. Also some device instability even when wifi is off can be attributed to it if wi-fi was enabled at least once on this device. Like this example shows, it most probably corrupted memory of application manager before it saved updated status file with package info. Any file modified when wi-fi is on can become corrupted. One random example - whole gconf system configuration is saved as a set of xml files and contain sensitive data that could bring device to reboot loop or random reboot when some (system) application reads its settings from it and becomes confused due to bad data. This configuration is saved when some device setting changes (like changing brightness or sound volume level) which happens relatively often. Also installation of any package over network can corrupt some random bytes when extracting it so future execution can run faulty code or read bad data even when wi-fi is not enabled. Yes, it would be nice to have it fixed in latest downloadable 2006 firmware or at least in some re-release of current 2007 based hacker edition version before it moves to 2008. And it is worth fixing even if we lived with this bug in our tablets for 2 years and were mostly happy :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Data corruption on N770 in OS2007 HE
Alex DAMIAN wrote: > I hoped for an error in dpkg > routines which handle the status file; now you made my day, I need a > better tablet :) Or just replace cx3110x.ko in /mnt/initfs/lib/modules/current/ with quick fix attached to the bug https://bugs.maemo.org/attachment.cgi?id=594 Or if you don't want to mess with initfs you can put in somewhere in rootfs and remove and reinsert it in some boot script (like /etc/init.d/rcS), something like rmmod cx3110x insmod /path/to/your/cx3110x-on-stack.ko chroot /mnt/initfs wlan-cal should fix further data corruption caused by this bug. Doing a dry run in xterm would be wise before modifying /etc/init.d/rcS I am writing it from my memory (with some data corruption issues too :-). Please note that the final version of bugfixed cx3110x.ko may be a bit different, it may use different solution and further bugfixes. Just watch the bug. There are also other issues with the open sourced glue cx3110x.ko driver code (data alingment issues, busywaits everywhere). And thanks must go to Tilman Vogel and Siarhei Siamashka who traced down root of the bug and found a fix (after more than year, see also http://bugs.maemo.org/show_bug.cgi?id=677). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Data corruption on N770 in OS2007 HE
Alex DAMIAN wrote: > Does anyone else experience these issues ? Ahything random can happen with wi-fi connected 770 due to this https://bugs.maemo.org/show_bug.cgi?id=2006 It doesn't matter which system (2006 or 200HE) you use. BTW this problem can be caused by any other bug too, but since ^@ looks like interpretation of zero, [EMAIL PROTECTED]@ may be really caused by this bug since it overwrites random memory with two zeroes. Congratulations, looks like you have won a lottery :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: About the upcoming maemo user karma
Frantisek Dufka wrote: > Having same e-mail account everywhere is not very nice. Please consider > allowing more of them. Reported now as http://bugs.maemo.org/show_bug.cgi?id=2212 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: About the upcoming maemo user karma
Henri Bergius wrote: > There will be recount every night, so once you have linked your > garage, bugzilla, maemo.org and mailing list accounts together (mostly > by using a consistent email address everywhere), your stats will start > to show up nicely. Few days ago I changed my email in maemo profile and garage account to be the same as the one I use for mailing list and still have 0 in discussion column (related to maemo mailing lists?). Bug? > > Comments welcome, as always :-) Having same e-mail account everywhere is not very nice. Please consider allowing more of them. At least mailing list vs rest (maemo profile, garage). Mailing list has relatively high volume so people may want to handle it differently. Currently I changed it to be the same (mainly to test it and see how much points it will give me) but I don't plan to keep it that way. Also more addresses would be useful to allow future changes. I suppose if one changes e-mail for sending messages to the list, his karma for list will start from scratch, right? Overall this karma thing may be useful to push people to be more active so this looks like good thing. It may also result in worse quality vs quantity ratio in blogs, mailing list etc. Let's see how much of cheap karma hunting we'll get. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ARM MMU questions
Simon Pickering wrote: > Of course, I'd just not realised that the name of the memory section > was used to perform the framebuffer sharing. I had expected to have to > make an explicit call to the DSP memory ioctl to do this. I don't know for sure, it was just a guess that could explain why it behaves differently. >>> Another thing I need to look at is whether I can share some large shared >>> memory regions on the 770 at higher addresses in the DSP memory map (to >>> be used by mplayer to avoid memcpy operations on frames). >> Well that would be nice but most probably you need continuous physical >> (not virtual) memory for this so the frame can be used as real video >> memory = transferable via DMA to external video chip. > > This is probably not such a big issue - the idea here is to share some > memory buffers between mplayer and the DSP so mplayer can fill them > (and then use them to calculate the next frames, etc.) and the DSP can > be told to display the data in one of these buffers (after it performs > colourspace conversion and scaling). There will be some memcpys on the > DSP side (from shared memory to framebuffer), but hopefully this will > be fast enough as the DSP does not have to do anything else. Oh, I see. I was thinking about zero copy mechanism, this makes it one copy on DSP side which may be almost free and nicely kills one or more birds with one stone. Now I think I understand the idea :-) - mplayer produces more frames in advance to some dynamic memory, dsp does colourspace conversion and copy to real video ram one frame at a time. So there is no need to have continuous physical memory and still mplayer can decode frames in advantage with zero copy on arm side. Looks like win for 770 :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ARM MMU questions
Simon Pickering wrote: > If I try to name my memory section FRAMEBUFFER (same code, just changing > the name in the command file), I'm back to the original problematic sort > of output: > > dsp_dld output: > > dsp_dld: event detected. > dsp_dld: event detected. > device sharedmem is requesting for TADD. > starting TADD process for device sharedmem. > loading /lib/dsp/modules/sharedmem.o. > exporting framebuffer to 0x30 > FBEXPORT failed > adding _task_sharedmem(@145120) into system. Well it makes sense this is really a special case since (at least on 770) you don't want to map just any random memory, you want to map _framebuffer_ memory (i.e. specific memory preallocated in bootloader and used by omapfb driver). It doesn't explain why the mapping should be done differently on DSP side but it is definitely handled as a special case in kernel so it needs special keyword. With different name you get some random memory not related to video (thus you need to do additional copy to real video memory on ARM side). > Another thing I need to look at is whether I can share some large shared > memory regions on the 770 at higher addresses in the DSP memory map (to > be used by mplayer to avoid memcpy operations on frames). Well that would be nice but most probably you need continuous physical (not virtual) memory for this so the frame can be used as real video memory = transferable via DMA to external video chip. Such regions have to be preallocated when kernel boots since at later time physical memory becomes fragmented. Not sure how good is 2.6.21 (used future N8XX firmwares) but in older kernels such fragmentation is not easy thing to solve. In recent kernels there is some ongoing work related to defragmenting or preventing physcal memory fragmentation. Also in N800 (and up?) some video RAM is in SRAM so there is definitely not space for more frames there. Even if using main SDRAM would be possible (i.e. there is no specific SRAM related setting somewhere in various pieces of omap framebuffer driver - disp.c omapfb_main.c blizzard.c rfbi.c - each hadling different piece of video hardware puzzle) we may suffer some performance hit for such frames. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
WPA? Re: WLAN connectivity using only wireless-tools
Kalle Valo wrote:
>> I don't see any PSM lines for example, while with the ITOS I do.
>
> Yeah, you have to enable PSM with the power iwconfig parameter.
> Otherwise PSM is disabled.
>
Interestingly this parameter need values less than 1 for sensible
timeout, something like "iwconfig wlan0 power timeout 0.0002" gives me 200ms
Yesterday I tried to bring up wireless via wireless-tools too but it
looks like it doesn't support WPA-PSK at all. It this correct? How the
system does it anyway?
Then I tried to compile latest (v0.5.8) wpa_supplicant with just
CONFIG_DRIVER_WEXT=y
CONFIG_WIRELESS_EXTENSION=y
but when run on 770 with simple
network={
ssid="myssid"
scan_ssid=1
key_mgmt=WPA-PSK
psk="very secret passphrase"
}
it prints two pages of scanning output but then segfaults and causes
kernel to crash inside wlan driver.
[45362.203674] CX3110x: MAC address
[45366.735626] Scan complete, scanned 13 channels
[45371.795043] Unable to handle kernel paging request at virtual address
ffbc
[45371.795166] pgd = c3ed4000
[45371.795196] [ffbc] *pgd=10002031, *pte=, *ppte=
[45371.795318] Internal error: Oops: 17 [#1]
[45371.795379] Modules linked in: bnep cx3110x umac ext3 jbd mbcache
[45371.795501] CPU: 0
[45371.795562] PC is at wireless_process_ioctl+0x3bc/0x7bc
[45371.795654] LR is at __init_begin+0x3fff8000/0x2c
[45371.795745] pc : []lr : [<>]Tainted: P
[45371.795776] sp : c1107e00 ip : c02afc20 fp :
[45371.795898] r10: c3f8a800 r9 : c1107ec8 r8 : c0218f80
[45371.795959] r7 : r6 : r5 : r4 :
[45371.796051] r3 : r2 : 0001 r1 : c02afc00 r0 :
[45371.796142] Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user
[45371.796234] Control: 5317F Table: 13ED4000 DAC: 0015
[45371.796295] Process wpa_supplicant (pid: 2307, stack limit = 0xc11061a0)
[45371.796386] Stack: (0xc1107e00 to 0xc1108000)
...
Is there any way how to make WPA running from command line?
I was actually trying to do it early on boot from initfs
as per comment #7, http://bugs.maemo.org/show_bug.cgi?id=2006
so I have whole memory free. Looks like I really need to downgrade
security on my router to attach to it from command line?
Frantisek
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re :Re: Regarding Enabling of USB on restart of NokiaN800
priyank kumar chourasia wrote: > Hi Kimmo, > Thanks for replying, I tried by modifying /etc/init.d/ke-recv by adding > OSSO_KE_RECV_IGNORE_CABLE=1 but the problem still persist. Did you really add "export OSSO_KE_RECV_IGNORE_CABLE=1" as suggested by Kimmo and not just "OSSO_KE_RECV_IGNORE_CABLE=1" as you wrote above? The 'export' word is important. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developing for all IT platforms
Frantisek Dufka wrote: > can I make one single click install file for IT2006, 7 and 8? > Will old AMs ignore extra sections for IT2008? Umm, sorry, there was example provided by Santtu earlier in this thread so it seems to be possible. But still, it would be nice to have some real examples in the documentation. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developing for all IT platforms
Marius Vollmer wrote: > "ext Santtu Lakkala" <[EMAIL PROTECTED]> writes: > >> I didn't find documentation for chinook .install files, [...] > > Here: > > http://hildon-app-mgr.garage.maemo.org/install.html > Thanks for the link. I'm not sure from the syntax in last compatibility chapter - can I make one single click install file for IT2006, 7 and 8? Will old AMs ignore extra sections for IT2008? Currently there is no way to provide more .install files in downloads.maemo.org so it would be handy now. However, it will be fixed soon [1] so this feature won't be strictly needed in future. But still, one install file could be easier for end users. Also could you provide some example with real Maemo extras repositories gregale, bora and chinook? Maybe even section 'Examples' with such real examples would be nice in the documentation linked above. it could save a bit of time for clueless packagers like me :-) Thanks, Frantisek 1. https://bugs.maemo.org/show_bug.cgi?id=2121 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ARM MMU questions
Simon Pickering wrote: > (i.e. see my shared memory example code I sent to the list > a few weeks ago, which runs on both 770 and N800). Yes, I've seen it. Please don't stop with such examples :-) > Yes, that's why it's not mapped, but there shouldn't necessarily be any > reason why it can't be remapped and used (e.g. for colourspace > conversion), which is my goal. I wonder what is real goal? Some test or benchmark? Or some image processing without displaying it (as graphics chip can display both RGB and YUV directly so there is no need to convert)? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ARM MMU questions
Simon Pickering wrote: > Hello all, > > I'm looking to share the framebuffer between the ARM CPU and DSP and > therefore would like to ask a few questions about the ARM MMU and in > particular TLBs. Most probably it is related to DSP MMU not ARM MMU but I am not sure. Until now I thought TLB (translation look-aside buffer) is dynamic thing you mostly don't care about just like L2 or L1 CPU cache (Well unless you read LWN of course :-) see http://lwn.net/SubscriberLink/255364/65f972b0422f379b/ ). Since the message "TLB full" did not make sense to me at all I did a google check and got this http://focus.ti.com/lit/an/swpa038/swpa038.pdf "When table walking is enabled, TLB entries are automatically written by the table walking logic. Alternatively, entries can also be manually written by the user. This is done to ensure that the time-critical data accesses execute as fast as possible. Such user-defined entries are typically locked to prevent them from being overwritten subsequently. " Page 16 "Programming the DSP MMU The DSP MMU can be programmed in two ways: by building translation tables or by writing all required entries directly into the TLB. A mix of these two ways is also possible. In that case, translation tables are used but some of the most time-critical translations are preloaded into the TLB." So it looks like DSP TLB is set up manually for fast access and indeed it may be full. > So it appears that I'm running out of TLBs in the ARM MMU. I think TLB on main (ARM) cpu is too precious to be locked in this way since it is needed for every access to memory by every process. I guess it really may be DSP MMU where it make more sense. > It's interesting that the 770 has a mapped framebuffer. I wonder how it > gets away with doing this while the N800 can't (if it's not by using a > larger page size)? 770 has framebuffer mapped for DSP because there are video codecs implemented as DSP tasks. This is no longer true with N800 so mapping for DSP makes little sense. With N800 some (or all? video one at least) planes are even mapped to SRAM not normal SDRAM like with 770 so maybe it is even not accessible by DSP (not sure about this limitation at all). I hope all this is not completely wrong and can help you but I don't know how to solve this. Maybe the set of DSP tasks on N800 are coded to use TLB fully since framebuffer acces is not needed. Still the rest free TLB entries may be enough if it is possible to use them in dynamic way but it will be slower. That's how I understand it. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo Downloads, Re: N810 maemo device program open for submissions
[EMAIL PROTECTED] wrote: > That was not the point. Please read my initial problem description. The > problem is, that if your application catalog entry states that you have > packages for multiple OS version (my current packages support OS2006 and > OS2007) and you search for packages for OS 2007, you will not see most of my > packages. At least that is the way it is for my packages. Then perhaps you may fill it as bug in bugzilla? I didn't know abut the garage tracker Quim mentioned but I did file two bugs for Maemo Downloads recently http://bugs.maemo.org/show_bug.cgi?id=2120 http://bugs.maemo.org/show_bug.cgi?id=2121 and both got handled and will be fixed in new version. So maybe bugzilla is better fo real bugs (not Midgard feature enhancements). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 maemo device program open for submissions
Danilo Cesar wrote: > Or, is there other options to developers who lives outside the countries > that maemo program covers? Yes, I believe the terms are worded in such way that you can apply if you have someone in one of those countries who will buy the device for you. See point 2 in http://maemo.org/device/terms/ , the part "or you have a valid address in that country where the purchased device can be sent" i.e. you have address of your friend or relative. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: chinook
Jonathan Greene wrote: > does anyone have anything built to test? love to try some apps on the > N810 ... Umm, if you are bored, could you try ScummVM? Click http://fanoush.wz.cz/maemo/scummvm_0.10.0-4_armel.deb or see http://maemo.org/community/wiki/scummvm http://fanoush.wz.cz/maemo/#scummvm for more help. Since it is not GTK based it may run out of box. When trying in Chinook scratchbox target I see --- dsp_protocol_open_node(): Could not open pcm device file /dev/dsptask/pcm3 qemu: Unsupported syscall: 298 --- so it is a bit mystery if it runs on actual device or not. Also many of us would be interested in hardware details so it would be nice to see output of commands like: dmesg (run ASAP after boot) df cat /proc/mtd cat /proc/cpuinfo find /sys find /mnt/initfs Question is - is there osso xterm or dropbear or openssh for Chinook to run those commands? Could you try to install http://maemo-hackers.org/apt/pool/main/d/dropbear/dropbear-server_0.49-1mh3_armel.deb and ssh in and run them? Thanks. Best regards, Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 maemo device program open for submissions
Hello Quim, maybe wiki page with questions&answers would be good again. Q: Is the code really tied to specific country or only to region (US/Europe) like before? Can I change the country in future? The form needs to fill specific country in field "Nokia shop to get the device from". Can I select some country now but change it later to some other (European) country if something goes wrong with the "you have a valid address in that country where the purchased device can be sent" condition in future? (see 2. NOKIA ONLINE SHOPS https://maemo.org/device/terms/) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Nokia N810 Q
David Weinehall wrote: >> Is the internal 2GB card slot still user accessible next to the battery? > > No. > Is it SD/MMC compatible i.e. similar/same to those eMMC mentioned here http://www.mmca.org/home ? Or to put it differently - which kernel driver is used for this? MMC or mtd or something else? Thanks. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 experimental host mode patches updated
Juuso Räsänen wrote: > What is the role of this latter file? kernel modules (i.e. drivers), you need to extract it somewhere and use insmod (as root) to add some of them to kernel at runtime (depends on device you want to use). For usb storage you need to insert those in drivers/scsi/ and drivers/usb/storage/. For keyboard you need drivers/usb/input/usbhid.ko > > Currently I just flashed the kernel with following command: > ./flasher-3.0 -f -k zImage-usbhost --enable-usb-host-mode --enable-rd-mode -R You don't need "--enable-usb-host-mode --enable-rd-mode" for this. > So, what could be of help there?? Google for 'linux kernel modules' to get familiar with the concept. BTW there is some issue with mounting cards (related to ke-recv service). Once you switch to host mode with ke-recv running, cards get unmounted (and swap turned off). You can prevent this by stopping ke-recv before switching and starting it after switch. /etc/init.d/ke-recv stop /etc/init.d/ke-recv start Similar for switching back - usb icon will go away after setting mode back to 'peripheral' and restarting ke-recv. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 experimental host mode patches updated
Tony Lindgren wrote: > It needs a gadget loaded to be active because it runs in OTG mode. > For some reason g_file_storage is not loaded automatically, do things > work if you run /usr/sbin/osso-usb-mass-storage-enable.sh after booting? > > If I run that, peripheral and host modes work. > Yes, that was the trick, thank you. The script above takes storage devices as a parameter so it should be run like /usr/sbin/osso-usb-mass-storage-enable.sh /dev/mmcblk0 /dev/mmcblk1 Tried, hub, mouse and flash disk and they get detected. Will do more tests this evening (it is morning here now). I have re-uploaded the kernel with CONFIG_USB_OTG_WHITELIST disabled. BTW, when after host mode I did echo otg > /sys/devices/platform/musb_hdrc/mode N800 was not properly dedected by PC (with Windows XP), it said 'device malfunctioned' and prompted for driver install. I had to run echo peripheral > /sys/devices/platform/musb_hdrc/mode To see my cards mounted on PC. Regards, Frantisek Oh, and thanks for your work on N800 host mode patches :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 experimental host mode patches updated
[EMAIL PROTECTED] wrote: > I didn't test this particular kernel but I did use host mode a few days > ago. I had to disable CONFIG_USB_OTG_WHITELIST to make it work. > Thanks, just tried and it didn't help. Still the same. Also found later that this kernel with host mode patches kills also normal client mode. After boot when attached to PC it does nothing too. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 experimental host mode patches updated
OK, my attempt is here http://fanoush.wz.cz/maemo/4.2007-usbhost-kernel.tar.gz http://fanoush.wz.cz/maemo/4.2007-usbhost-modules.tar.gz It boots, has 48Mhz MMC mode enabled but without the mmc clock debug patch since it is printed very often (at least when one boots from MMC). I have actually never tried host mode with N800, just 770 and when doing echo host > /sys/devices/platform/musb_hdrc/mode with this kernel nothing happens in log and it still contains "b_idle". Tried to connect powered hub, mmc card reader and mouse and it does nothing. I dont have proper cable for autoswitching, just regular mini-USB with female to female adapter on the end. kernel contains .config so please check if anything is wrong. Since I already had custom config I tried to enable same options by hand. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 experimental host mode patches updated
Tony Lindgren wrote: > Anybody else here willing to provide the compiled kernels? Maybe throw > in also the MMC patches from http://intr.overt.org/blog/?p=63 :) Just finished the crypto API enabled kernel http://www.internettablettalk.com/forums/showthread.php?p=81758#post81758 so I guess I'll just add this and rebuild the kernel once again :-) Will take few minutes. F ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: General bugs being assigned to ITOS2007HE in Garage, not Bugzilla
Noticed that too for bugs reported by me. Bugs are generic and apply to N800 too. Definititely a bit strange, some explanation would be appreciated. The original bug remains open in Bugzilla so I hope it is not the end. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
N800 shuts down after 364 seconds in initfs
Hello, as already mentioned here I have implemented USB networking recovery mode in bootmenu. It works fine with 770 but unfortunately N800 doesn't like staying in initfs too long. After few tests it looks like the device shuts down exactly 6 minutes and 4 seconds after linux kernel is booted. Possibly this is exactly 6 minutes after dsme or bme is started. Here is kernel log. I tried it few times and the timing is always the same. <4>[3.872497] VFS: Mounted root (jffs2 filesystem). <6>[3.872833] Freeing init memory: 92K <4>[8.175262] ether gadget: using random self ethernet address <4>[8.175384] ether gadget: using random host ethernet address <6>[8.192687] usb0: Ethernet Gadget, version: May Day 2005 <6>[8.192779] usb0: using musb_hdrc, OUT ep1out IN ep1in STATUS ep2in <6>[8.192840] usb0: MAC c2:5c:98:eb:81:21 <6>[8.192901] usb0: HOST MAC 66:33:7e:ee:63:da <6>[8.192932] usb0: RNDIS ready <4>[8.195648] drivers/usb/musb/tusb6010.c musb_platform_enable: dma not reactivated <7>[ 16.637207] musb_stage2_irq 628: SUSPEND, devctl 99 <7>[ 17.777954] musb_stage0_irq 530: BUS RESET <7>[ 17.782806] musb_stage0_irq 530: BUS RESET <7>[ 18.019683] musb_hdrc periph: enabled ep2in for int IN, dma, maxpacket 16 <7>[ 18.019744] musb_hdrc periph: enabled ep1in for bulk IN, dma, maxpacket 512 <7>[ 18.019775] musb_hdrc periph: enabled ep1out for bulk OUT, dma, maxpacket 512 <6>[ 18.019989] usb0: high speed config #2: 100 mA, Ethernet Gadget, using RNDIS <6>[ 364.809326] tahvo: Registering interrupt 7 for device <6>[ 364.809844] retu: Registering interrupt 8 for device <6>[ 364.810760] retu: Registering interrupt 1 for device <6>[ 364.811157] tahvo: Registering interrupt 1 for device Connection to 192.168.11.1 closed by remote host. Connection to 192.168.11.1 closed. Anyone can explain what (dsme? bme?) does it and why? Can I suppress this somehow? My idea is that it is some safety mechanism detecting that device did not boot properly. Please note tahvo and retu interrupts right before shutdown. Can I somehow let the device know that everything is OK? Thanks. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
