Re: New significant speedups coming to FreeRunner
On Saturday March 06, 2010, Michal Brzozowski wrote: 2010/2/2 Josh Thompson om-c...@joshandbianca.net I just tested this on another computer, and the USB networking worked fine. How do I change it to use the usb_storage gadget instead? Previously, I just rmmoded the g_ether gadget and modprobed the g_file_storage one. Depending on my need, I switch back and forth between these two. Did you figure out how to do this? I need to use my FR with WinXP as a storage device and am stuck to this kernel. Unfortunately, no I didn't. I'm still hoping someone that knows more about usb gadgets will figure it out. Josh ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
2010/3/8 Josh Thompson om-c...@joshandbianca.net Unfortunately, no I didn't. I'm still hoping someone that knows more about usb gadgets will figure it out. Josh It seems that the file storage driver is not even built-in. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
2010/2/2 Josh Thompson om-c...@joshandbianca.net I just tested this on another computer, and the USB networking worked fine. How do I change it to use the usb_storage gadget instead? Previously, I just rmmoded the g_ether gadget and modprobed the g_file_storage one. Depending on my need, I switch back and forth between these two. Did you figure out how to do this? I need to use my FR with WinXP as a storage device and am stuck to this kernel. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
Dnia 13 lutego 2010 12:42 ghislain ghisl...@basetrend.nl napisał(a): Timo Juhani Lindfors wrote: How can kernel modules affect graphics performance? Maybe because some of the necessary modules can't be loaded now. I use this kernel on QtMoko and graphics are very fast, this was the only reason I could think of. Yes, i think this is because of QtMoko v19 nodebug kernel so syslogs are not slowing down all drivers. Thx Radek this kernel kicks ass. Gui is very resonsive, as never before. Best regards. Bartek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: RTC failure in January (was: New significant speedups coming to FreeRunner)
On Sun, Jan 24, 2010 at 06:04:02PM +, Neil Jerram wrote: 2010/1/24 Andy Poling a...@realbig.com: I finally looked into it, and this is the problem (with RTC debugging enabled): [...] Wow, what a fantastic bug! So, IIUC, it will only strike someone who upgraded in January from a kernel without Werner's change, to one with Werner's change - because the old kernel will have left a 0 value in pcf-time[PCF50606_TI_MONTH]. Amazing :-) Great investigation too. I'm really pleased that this is understood now and is going to be fixed. What about the attached patch to ease transition, and to get a working RTC before February? Regards, Neil Hi, what happened with this patch? My FR ran out of power, which resulted in a reset RTC. Now I can't set it back to current time, because of hwclock's read. -- Sebastian signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: RTC failure in January (was: New significant speedups coming to FreeRunner)
On 23 February 2010 18:18, Sebastian Reichel elektra...@gmail.com wrote: Hi, what happened with this patch? My FR ran out of power, which resulted in a reset RTC. Now I can't set it back to current time, because of hwclock's read. I wasn't able to test it myself, because I don't have a cross-compilation setup, and I never heard of anyone else trying it either. For me, the problem was actually solved by trying out SHR-T briefly - while still in January. Then when I switched back to Debian, the RTC was fine again. I remember thinking that I understood this at the time, but right now I can't remember the detailed explanation. In fact, if switching temporarily to another distro/kernel works for you (and for anyone else), that's probably better than having cruft like this patch in your ongoing kernel. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: RTC failure in January (was: New significant speedups coming to FreeRunner)
On Tue, Feb 23, 2010 at 10:40:26PM +, Neil Jerram wrote: On 23 February 2010 18:18, Sebastian Reichel elektra...@gmail.com wrote: Hi, what happened with this patch? My FR ran out of power, which resulted in a reset RTC. Now I can't set it back to current time, because of hwclock's read. I wasn't able to test it myself, because I don't have a cross-compilation setup, and I never heard of anyone else trying it either. For me, the problem was actually solved by trying out SHR-T briefly - while still in January. Then when I switched back to Debian, the RTC was fine again. I remember thinking that I understood this at the time, but right now I can't remember the detailed explanation. In fact, if switching temporarily to another distro/kernel works for you (and for anyone else), that's probably better than having cruft like this patch in your ongoing kernel. I just tried the patch and it seems to work. It will be included in the next Debian kernel. -- Sebastian signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: RTC failure in January (was: New significant speedups coming to FreeRunner)
On 23 February 2010 23:19, Sebastian Reichel elektra...@gmail.com wrote: I just tried the patch and it seems to work. It will be included in the next Debian kernel. OK, cool, thanks. (Wow, my first ever kernel patch!) Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Monday 15 February 2010 19:33:56 Rui Miguel Silva Seabra wrote: A framebuffer device is usually slower than a native driver under X. My Freerunner's UI performance definitely felt a bit faster after moving to the native driver. My point is that X server probably kills the performance here. You can try compile Qtopia on top of X and you will see the difference. The slowness of the graphics is better explained by the brain deadness of the hardware. I think that this is very unfortunate explanation. To me it looks like somebody said that freerunner's graphics sucks and there is no way it will ever be faster and it was taken as a fact. Now i just change a few kernel config options and few line patch (thanks to Thomas White) and the graphics speed is very nice. In QVGA it can probably match iPhone or any Android device. Sorry, i dont like to hear that it sucks. It could be probably good enough as any other phone. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
2010/2/16 Radek Polak pson...@seznam.cz: I think that this is very unfortunate explanation. To me it looks like somebody said that freerunner's graphics sucks and there is no way it will ever be faster and it was taken as a fact. I'm no hardware guru, but if i remember it correctly, it was the fact, that the processor and the graphics chip can't access the RAM at the same time. Both of them lock the channel to the RAM, so they block each other. To make things worse, the uSD card is connected with the same channel. Please correct me, if i'm wrong. Cheers, Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
* Radek Polak wrote, Il 16/02/2010 15:48: Now i just change a few kernel config options and few line patch (thanks to Thomas White) and the graphics speed is very nice. In QVGA it can probably match iPhone or any Android device. I totally agree Radek's words, and in my experience the GUI in QtMoko 19 with the new kernel, it's fast like any other smartphone. _Really_ _fast_, now. So the myth of slowness of the FR, it's now a legend, because QtMoko now has a GUI with a speed absolutely comparable with any other commercial phone. These are facts. -- Andrea ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tuesday 16 February 2010 15:48:49 Radek Polak wrote: On Monday 15 February 2010 19:33:56 Rui Miguel Silva Seabra wrote: I think that this is very unfortunate explanation. To me it looks like somebody said that freerunner's graphics sucks and there is no way it will ever be faster and it was taken as a fact. Graphics performance is better of what it seemed could be archieved at the beggining, but Glamo's bus slowness is not something someone said, it's a fact. Also, qtopia (qtextended, qtmoko) do a lot less effects on graphics than enlightment, that's why it's faster. If you turn off shadows, transparency, etc, you can get shr graphics as fast as qtopia. If you don't believe me, you can try SHR's Neo Theme. You will see it's not X, but eyecandy what makes SHR slower than qtopia. You can search lists archives for several threads about this matter, it was spoken to death. Now i just change a few kernel config options and few line patch (thanks to Thomas White) and the graphics speed is very nice. In QVGA it can probably match iPhone or any Android device. No, it can't, at least until we have an OpenGL driver. But it's true that using VGA resolution is a handicap for such a slow graphics chip, and it would be better QVGA for this hardware. Fact is that glamo is a graphics decelerator. It's known that Neo1973 was faster than FreeRunner on graphics (even on VGA), despite of slower processor. signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tue, 16 Feb 2010 16:19:08 +0100 David Garabana Barro da...@garabana.com wrote: Now i just change a few kernel config options and few line patch (thanks to Thomas White) and the graphics speed is very nice. In QVGA it can probably match iPhone or any Android device. No, it can't, at least until we have an OpenGL driver. But it's true that using VGA resolution is a handicap for such a slow graphics chip, and it would be better QVGA for this hardware. A small point, but there are things we can do along the way to a full GL driver which speed things up, and I don't think we've found them all just yet. For instance, adding proper fencing in the DRM driver unclogs things by a fairly noticable amount: fullscreen (VGA) blits at 100fps with 0% CPU usage, anyone? Fact is that glamo is a graphics decelerator. It's known that Neo1973 was faster than FreeRunner on graphics (even on VGA), despite of slower processor. Yes, the bus speed is a fundamental limitation, and it does suck. But there are other reasons (see below) why the current driver and rendering model is a bad match for the hardware. In fact, it's a bad match for almost all hardware, it's just that normally the overall speed is high enough to get away with it. We haven't yet allowed ourselves to make meaningful use of the acceleration features, and I'm absolutely convinced that if we did so then the GTA02's UI could fly along. It's a fact that to get to this state we're going to have to write a lot of hardware-specific code, and each developer who would potentially work on this stuff has to make their own decision about whether they want to do that for a GPU which won't be found elsewhere. Extract from http://lists.shr-project.org/pipermail/shr-devel/2009-December/001702.html - see the thread for context. --- If you're only talking about the X protocol overhead, then that's true - although I haven't yet seen any numbers... However, it's not the driver's fault. By the time (say) GTK's rendering instructions get to our driver (i.e. xf86-video-glamo), they've been turned into a series of tiny rectangle operations which are almost impossible to accelerate in any useful way. In this sense, the way X requires programs to send their rendering commands, and the way GTK/Cairo sends its commands, and the way the X server core communicates with the driver, are hurting us. Essentially, that's why E is so much faster: it prepares larger chunks of data at a higher level where acceleration can be much more meaningful, then sends them to the server in one big block. The price of this is that the acceleration done by the driver is hardly used in most cases, so we still don't get the best out of our hardware. A more fundamental redesign could potentially allow such pitfalls to be side-stepped, but this also comes at a price: Hardware-dependent code would end up existing at a higher level in the software [1], reducing the reusability of code. [1] In the extreme case, hardware-dependent code can be moved all the way up the the individual client program, abstracted by a library. This is what DRI does, in which case that abstraction library is usually Mesa, providing an OpenGL API. --- My decision about this was simple: Since I enjoy the development work, it doesn't make any difference to me that the hardware will go away in time. Nothing is forever, and this is a perfect opportunity to learn about driver development on a relatively tame piece of hardware. I don't have any immediate plans for world domination [2].. Tom [2] ... or is that just what I want you to believe? Mwahahahaha... -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
It's a fact that to get to this state we're going to have to write a lot of hardware-specific code, and each developer who would potentially work on this stuff has to make their own decision about whether they want to do that for a GPU which won't be found elsewhere. There is another, much more concrete obstacle across this path : AFAIK there are no public release of glamo's datasheet. While I find it conceivable to dedicate some time and effort to code some low level code for a never to be seen again video chip, then to code some apps using this code, I can't stand to have to guess how the chip works. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tuesday 16 February 2010 17:04:28 ri...@happyleptic.org wrote: It's a fact that to get to this state we're going to have to write a lot of hardware-specific code, and each developer who would potentially work on this stuff has to make their own decision about whether they want to do that for a GPU which won't be found elsewhere. There is another, much more concrete obstacle across this path : AFAIK there are no public release of glamo's datasheet. AFAIK, Thomas has access to Glamo's doc under NDA Isn't it, Thomas? signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tue, 16 Feb 2010 16:49:30 +0100 Thomas White t...@bitwiz.org.uk said: On Tue, 16 Feb 2010 16:19:08 +0100 David Garabana Barro da...@garabana.com wrote: Now i just change a few kernel config options and few line patch (thanks to Thomas White) and the graphics speed is very nice. In QVGA it can probably match iPhone or any Android device. No, it can't, at least until we have an OpenGL driver. But it's true that using VGA resolution is a handicap for such a slow graphics chip, and it would be better QVGA for this hardware. A small point, but there are things we can do along the way to a full GL driver which speed things up, and I don't think we've found them all just yet. For instance, adding proper fencing in the DRM driver unclogs things by a fairly noticable amount: fullscreen (VGA) blits at 100fps with 0% CPU usage, anyone? indeed nice.. if there is 100fps of data to blit TO the screen usefully. something has to generate that data... :) technically if you tyried to implement full xrender accel - evas could be partly accelerated by the 2d hw - but.. it's my guess (and still is - but if you ever get that far - prove me wrong :)) that for every win u get from using the 2d hw accel, you will post a loss by falling back to software ops going across the bus from cpu - glamo as the 2d is only partly able to implement xrender and the kind of ops you need. of course.. i'm open to be proven wrong, but.. it's my guess that after all the work and effort, you'll have spent that effort standing still (i.e. gaining on one hand, losing on the other). as for GL.. there is gl-es1.1 - but only minimally useful. can't do vga rendering - so u need to drop to qvga anyway. max texture size of 256x256? not useful for 2d anymore. evas has a full opengl-es2.0 engine - but 2.0 and 1.x in gl-es are completely incompatible api's so you choose one or the other to work on - i chose 2.0 as it's friendly to 2d much more than 1.1. given just the 2 limits above i suspect it will be marginally useful at best. also note - i've working on soc's with full gl-es2.0 gpu's and fast shared buses where cpu and gpu are living in the same memory and there is no system - video ram bottleneck... and software can equal or beat hw gl in a lot of cases. in others gl can beat software - but it's not immensely common. i've pushed things to minimise gl state transitions a lot - minimise re-binds, use texture atlases - and i've pushed shaders to take a lot of the weight of things like enabling and dsabling blending and more. of course u'd need 2.0 to have shaders... but in general gl-es is really good at 3d. ie rotations and perspective transforms. for simpler things like plain alpha blending, blits, fills etc. software can equal or beat even the best gpu's (i'm talking s3c6410, omap3 - sgx 530 and even an sxg540 clocking in at 200mhz and 4 cores). example: http://www.rasterman.com/files/other-vs-gl.html notice gl really works well on the 3d stuff (rotations/perspective), but can lose badly on many other paths. and thats one of the top-of-the-line gpu's in embedded. and for s3c6410 (this is what was once considered for gta03/04 long ago, and by now this SoC is considered old/legacy): http://www.rasterman.com/files/s3c-gl-vs-soft.html the amount of work needed to get it up to snuff was non-trivial with full docs and sample driver code and a few people working on it full time for many months from both ends (kernel driver, xserver, userspace libgl and application sides). you just need to know that - you may get it to work in the end. sure. that may happen. but... your results may be sorely disappointing :( just beware. Fact is that glamo is a graphics decelerator. It's known that Neo1973 was faster than FreeRunner on graphics (even on VGA), despite of slower processor. Yes, the bus speed is a fundamental limitation, and it does suck. But there are other reasons (see below) why the current driver and rendering model is a bad match for the hardware. In fact, it's a bad match for almost all hardware, it's just that normally the overall speed is high enough to get away with it. We haven't yet allowed ourselves to make meaningful use of the acceleration features, and I'm absolutely convinced that if we did so then the GTA02's UI could fly along. It's a fact that to get to this state we're going to have to write a lot of hardware-specific code, and each developer who would potentially work on this stuff has to make their own decision about whether they want to do that for a GPU which won't be found elsewhere. thats one of the saddest things. if glamo had a future.. a glamo2,3,4 that would be found.. it'd be worth effort - but all of this will be for a 1-off gpu that is for a dead platform (freerunner is no longer produced and there is no successor coming that has the glamo or successors as part of it). how much effort do you put into something like that? me - i am a pragmatist here - i'd put as
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tuesday 16 February 2010 17:18:27 Carsten Haitzler wrote: as for GL.. there is gl-es1.1 - but only minimally useful. can't do vga rendering - so u need to drop to qvga anyway. max texture size of 256x256? Wasn't max texture size 512x512? signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tue, 16 Feb 2010 17:33:32 +0100 David Garabana Barro da...@garabana.com said: On Tuesday 16 February 2010 17:18:27 Carsten Haitzler wrote: as for GL.. there is gl-es1.1 - but only minimally useful. can't do vga rendering - so u need to drop to qvga anyway. max texture size of 256x256? Wasn't max texture size 512x512? that was max rendering viewport (max gl buffer). this can't do vga (as vga is 640x... 640 512). maybe u can start rendering by rendering 2 buffers then combining them in 2 output blits. it's not going to be pretty for performance... or for the driver internals. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Saturday 13 February 2010 11:49:14 ghislain wrote: I think the slowness of the graphics can be explained by not having the kernel-modules installed. The slowness is more likely because SHR runs on top of X while QtMoko draws directly to framebuffer. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
Em 15-02-2010 13:03, Radek Polak escreveu: I think the slowness of the graphics can be explained by not having the kernel-modules installed. The slowness is more likely because SHR runs on top of X while QtMoko draws directly to framebuffer. A framebuffer device is usually slower than a native driver under X. My Freerunner's UI performance definitely felt a bit faster after moving to the native driver. I also noticed this in my SmartQ7 after moving from the framebuffer to a native driver. The slowness of the graphics is better explained by the brain deadness of the hardware. Now... Qt from framebuffer devices is very highly optimized, so it may be a bit faster than other Windows managers, but it also does a lot less (like not being exactly a window manager). Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
I think the slowness of the graphics can be explained by not having the kernel-modules installed. The kernel-modules are contained in the rootfs.img as part of the total distribution. Ghislain http://www.basetrend.nl BaseTrend - http://www.openmobile.nl openmobile.nl -- View this message in context: http://n2.nabble.com/qtmoko-New-significant-speedups-coming-to-FreeRunner-tp4284388p4565706.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
ghislain ghisl...@basetrend.nl writes: I think the slowness of the graphics can be explained by not having the kernel-modules installed. The kernel-modules are contained in the rootfs.img as part of the total distribution. How can kernel modules affect graphics performance? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
Timo Juhani Lindfors wrote: How can kernel modules affect graphics performance? Maybe because some of the necessary modules can't be loaded now. I use this kernel on QtMoko and graphics are very fast, this was the only reason I could think of. Ghislain http://www.basetrend.nl BaseTrend - http://www.openmobile.nl openmobile.nl -- View this message in context: http://n2.nabble.com/qtmoko-New-significant-speedups-coming-to-FreeRunner-tp4284388p4565826.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
[cut] This is an installer-image which will flash to nand, but you can flash to nand using dfu-util by flashing the files 'kernel.img' (== uImage) and 'rootfs.img' (== jffs2). Ghislain And which of files is kernel with nodebug? -- Patryk LeadMan Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Fri, 2010-02-12 at 13:39 +0100, Patryk Benderz wrote: [cut] This is an installer-image which will flash to nand, but you can flash to nand using dfu-util by flashing the files 'kernel.img' (== uImage) and 'rootfs.img' (== jffs2). Ghislain And which of files is kernel with nodebug? It's kernel.img ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
Dnia 2010-02-12, pią o godzinie 04:57 -0800, Alishams Hassam pisze: On Fri, 2010-02-12 at 13:39 +0100, Patryk Benderz wrote: [cut] This is an installer-image which will flash to nand, but you can flash to nand using dfu-util by flashing the files 'kernel.img' (== uImage) and 'rootfs.img' (== jffs2). Ghislain And which of files is kernel with nodebug? It's kernel.img Thanks, I made little test. I used this kernel with SHR-T. System loaded fast (~30s) , applications loads fast, but all graphics related activities like screen scrolling are painfully slow and look like a slide show. Would you kindly advise me a better nodebug kernel for tests with SHR-T? -- Patryk LeadMan Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re: [qtmoko] New significant speedups coming to FreeRunner
Thanks, I made little test. I used this kernel with SHR-T. System loaded fast (~30s) , applications loads fast, but all graphics related activities like screen scrolling are painfully slow and look like a slide show. Would you kindly advise me a better nodebug kernel for tests with SHR-T? I used this one for testing on SHR-U http://activationrecord.net/radekp/qtmoko/download/experimental/ However, this kernel reveals problems with fso when trying to register GSM. There are supposed to be solutions for that, but neither worked for me. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: RTC failure in January (was: New significant speedups coming to FreeRunner)
2010/1/24 Andy Poling a...@realbig.com: I finally looked into it, and this is the problem (with RTC debugging enabled): [...] Wow, what a fantastic bug! So, IIUC, it will only strike someone who upgraded in January from a kernel without Werner's change, to one with Werner's change - because the old kernel will have left a 0 value in pcf-time[PCF50606_TI_MONTH]. Amazing :-) Great investigation too. I'm really pleased that this is understood now and is going to be fixed. What about the attached patch to ease transition, and to get a working RTC before February? Regards, Neil From aec6c6be9cadd54f432ffd2b65e8dce37fee78b4 Mon Sep 17 00:00:00 2001 From: Neil Jerram neiljer...@googlemail.com Date: Sun, 24 Jan 2010 15:23:52 + Subject: [PATCH] Fix for failure to read RTC following kernel upgrade in January For explanation see http://lists.openmoko.org/pipermail/community/2010-January/059634.html Thanks to Andy Poling for the investigation. --- drivers/rtc/rtc-pcf50606.c |4 +++- drivers/rtc/rtc-pcf50633.c |4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-pcf50606.c b/drivers/rtc/rtc-pcf50606.c index 6bd93b0..6d4897c 100644 --- a/drivers/rtc/rtc-pcf50606.c +++ b/drivers/rtc/rtc-pcf50606.c @@ -71,7 +71,9 @@ static void pcf2rtc_time(struct rtc_time *rtc, struct pcf50606_time *pcf) rtc-tm_hour = bcd2bin(pcf-time[PCF50606_TI_HOUR]); rtc-tm_wday = bcd2bin(pcf-time[PCF50606_TI_WKDAY]); rtc-tm_mday = bcd2bin(pcf-time[PCF50606_TI_DAY]); - rtc-tm_mon = bcd2bin(pcf-time[PCF50606_TI_MONTH]) - 1; + rtc-tm_mon = bcd2bin(pcf-time[PCF50606_TI_MONTH] + ? pcf-time[PCF50606_TI_MONTH] + : 1) - 1; rtc-tm_year = bcd2bin(pcf-time[PCF50606_TI_YEAR]) + 100; } diff --git a/drivers/rtc/rtc-pcf50633.c b/drivers/rtc/rtc-pcf50633.c index 8669815..637a1d5 100644 --- a/drivers/rtc/rtc-pcf50633.c +++ b/drivers/rtc/rtc-pcf50633.c @@ -71,7 +71,9 @@ static void pcf2rtc_time(struct rtc_time *rtc, struct pcf50633_time *pcf) rtc-tm_hour = bcd2bin(pcf-time[PCF50633_TI_HOUR]); rtc-tm_wday = bcd2bin(pcf-time[PCF50633_TI_WKDAY]); rtc-tm_mday = bcd2bin(pcf-time[PCF50633_TI_DAY]); - rtc-tm_mon = bcd2bin(pcf-time[PCF50633_TI_MONTH]) - 1; + rtc-tm_mon = bcd2bin(pcf-time[PCF50633_TI_MONTH] + ? pcf-time[PCF50633_TI_MONTH] + : 1) - 1; rtc-tm_year = bcd2bin(pcf-time[PCF50633_TI_YEAR]) + 100; } -- 1.5.6.5 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RTC failure in January (was: New significant speedups coming to FreeRunner)
On Mon, 18 Jan 2010, Neil Jerram wrote: One more possible issue with this kernel. The boot messages always say [21474539.53] pcf50633-rtc pcf50633-rtc: hctosys: unable to read the hardware clock I'm seeing this on my build from a recent git pull as well. It also has the unpleasant side effect of also failing to set the time on resume so the clock seems to lose time during any suspend. :-( I finally looked into it, and this is the problem (with RTC debugging enabled): [21474537.86] pcf50606-rtc pcf50606-rtc: PCF_TIME: 24.00.10 06:26:41 [21474537.86] pcf50606-rtc pcf50606-rtc: RTC_TIME: 24.4294967295.110 6:26:41 [21474537.86] pcf50606-rtc pcf50606-rtc: hctosys: unable to read the hardware clock That month fails rtc_valid_tm(), leading to the EINVAL. The commit/fix Werner made last April seems to be not interacting well with the zero-based month count in the pcf50606 RTC (set, in my case, by an old kernel I booted at some point in January): diff --git a/drivers/rtc/rtc-pcf50606.c b/drivers/rtc/rtc-pcf50606.c index e059093..434cfc1 100644 (file) --- a/drivers/rtc/rtc-pcf50606.c +++ b/drivers/rtc/rtc-pcf50606.c @@ -70,7 +70,7 @@ static void pcf2rtc_time(struct rtc_time *rtc, struct pcf50606_time *pcf) rtc-tm_hour = bcd2bin(pcf-time[PCF50606_TI_HOUR]); rtc-tm_wday = bcd2bin(pcf-time[PCF50606_TI_WKDAY]); rtc-tm_mday = bcd2bin(pcf-time[PCF50606_TI_DAY]); - rtc-tm_mon = bcd2bin(pcf-time[PCF50606_TI_MONTH]); + rtc-tm_mon = bcd2bin(pcf-time[PCF50606_TI_MONTH]) - 1; rtc-tm_year = bcd2bin(pcf-time[PCF50606_TI_YEAR]) + 100; } Since hwclock does a read before a write of the RTC, we can't fix this as easily as one might think. I guess in another 7 days it will be working again. :-) I was able to escape the catch-22 by booting an old kernel, setting the RTC to a date in February 2010 with hwclock and then booting the new kernel again. -Andy It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so. - Mark Twain ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Thu, Jan 21, 2010 at 10:26 PM, Timo Juhani Lindfors timo.lindf...@iki.fi wrote: Helge Hafting helge.haft...@hist.no writes: That ticket seems to describe a similiar problem with wifi, it doesn't mention GSM. Or are both handled by a common piece of hardware? No. GSM runs on a separate ARM processor and is accessed over a serial port. As reported by me and others, WIFI is periodically not available after a reboot and there is some suggestion that the faster kernel may be exposing some timing related issues. I'm not yet certain if this issue is also being caused by the timing issues, but on my QtMoko v16b with the nodebug kernel I'm not only experiencing the WIFI problem but more importantly I'm seeing some GSM and SIM related problems. I frequnetly go to make a call and the dialer drops out wihtout errors. If someone can tell me where to look and what to provide to help debug this, then do so. I also sometimes get errors sending SMS and other times get sim card not ready when trying to delete SMS. I just wanted to report these as a data point and if anyone wants more details and logs, please ask. cheers Denis ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Niels Heyvaert wrote: It may be some kind of race condition in the SHR software, that gets trigged much more often with the faster kernel. We found this race condition in Debian, too - even before using a faster kernel by lowering the framework's log_level. So it appears the symptoms have been tracked: http://docs.openmoko.org/trac/ticket/2327 (also see post by Timo). That ticket seems to describe a similiar problem with wifi, it doesn't mention GSM. Or are both handled by a common piece of hardware? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Helge Hafting helge.haft...@hist.no writes: That ticket seems to describe a similiar problem with wifi, it doesn't mention GSM. Or are both handled by a common piece of hardware? No. GSM runs on a separate ARM processor and is accessed over a serial port. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
I experience a very bad suspend battery life after I started using the faster kernel. Even when I make sure gps, gsm, wifi are turned off. Has anyone noticed this? Or maybe something else is causing this? 2010/1/18 David Garabana Barro da...@garabana.com On Monday 18 January 2010 17:13:42 David Garabana Barro wrote: On Monday 18 January 2010 16:52:11 Helge Hafting wrote: Installed the kernel, and the modules. It did not work. Well, X came up and was nice and snappy, but the phone never connected to the GSM network. I tried shr-settings, and GSM could not be turned on! I tried booting several times, I tried restarting various fso daemons that seemed phone-related. Nothing helped. In the end, I flashed the latest shr-unstable kernel, booted, and got a GSM connection just fine. (I use shr-unstable of today.) Too bad this kernel didn't work, it seemed very interesting. I don't know what is causing gsm to not register, but it's not kernel, for sure. Sometimes it registers for me and sometimes it doesn't, with both standard shr kernel and stripped kernel. It seems registration is more frequent with standard kernel. Might it be for worse performance? (some daemon which starts before another one with stripped kernel, for example) For me, it seems if you let FR boot with no iteration, it almost never register. If you do things (f.e. open an applicaiotn) just when illume desktop appears on display, it's more probable to obtain a registration. Just my experience... And sometimes, but only sometimes, when not registered on boot, I can force registration simply by rebooting libphoneui from shr-settings Sometimes it doesn't matter what daemon you reboot. It doesn't register :( ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
I experience a very bad suspend battery life after I started using the faster kernel. Even when I make sure gps, gsm, wifi are turned off. Has anyone noticed this? Or maybe something else is causing this? i got the impression that bluetooth is always on (illume top shelf always shows the bt symbol and a simple hci[tool|config] dev shows the device). no time to dig deeper yet. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
2010/1/20 arne anka openm...@ginguppin.de I experience a very bad suspend battery life after I started using the faster kernel. Even when I make sure gps, gsm, wifi are turned off. Has anyone noticed this? Or maybe something else is causing this? i got the impression that bluetooth is always on (illume top shelf always shows the bt symbol and a simple hci[tool|config] dev shows the device). no time to dig deeper yet. Over here bluetooth is off, so must be something else. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Check for cron or another app using 100% cpu - I had this awhile back and it seemed to affect suspend time, but I think that was because it chewed up so much battery that battery life overall seemed short. I am using shr-t and it seems battery life is better if anything on both the current (no debug/preempt kernel) and a modified version with even more drastic mods (-O2 instead of -Os) Which brings up - how can a user benchmark a kernel in a way thats relevant for user tasks? BillK On Wed, 2010-01-20 at 21:10 -0300, Michal Brzozowski wrote: 2010/1/20 arne anka openm...@ginguppin.de I experience a very bad suspend battery life after I started using the faster kernel. Even when I make sure gps, gsm, wifi are turned off. Has anyone noticed this? Or maybe something else is causing this? i got the impression that bluetooth is always on (illume top shelf always shows the bt symbol and a simple hci[tool|config] dev shows the device). no time to dig deeper yet. Over here bluetooth is off, so must be something else. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- William Kenworthy bi...@iinet.net.au Home in Perth! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
David Garabana Barro wrote: On Monday 18 January 2010 16:52:11 Helge Hafting wrote: [...] Too bad this kernel didn't work, it seemed very interesting. I don't know what is causing gsm to not register, but it's not kernel, for sure. It may be some kind of race condition in the SHR software, that gets trigged much more often with the faster kernel. Still, the solution for now is an old kernel, for I need the phone to work as a phone. Fixing SHR shouldn't be hard, once the race condition is found. If one program depend on another, then start them in sequence instead of simultaneously. Or have the dependant program issue sleep 1 and then retry whenever the other program isn't there. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Tue, Jan 19, 2010 at 09:28:10AM +0100, Helge Hafting wrote: David Garabana Barro wrote: On Monday 18 January 2010 16:52:11 Helge Hafting wrote: [...] Too bad this kernel didn't work, it seemed very interesting. I don't know what is causing gsm to not register, but it's not kernel, for sure. It may be some kind of race condition in the SHR software, that gets trigged much more often with the faster kernel. We found this race condition in Debian, too - even before using a faster kernel by lowering the framework's log_level. -- Sebastian signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: New significant speedups coming to FreeRunner
It may be some kind of race condition in the SHR software, that gets trigged much more often with the faster kernel. We found this race condition in Debian, too - even before using a faster kernel by lowering the framework's log_level. So it appears the symptoms have been tracked: http://docs.openmoko.org/trac/ticket/2327 (also see post by Timo). _ Windows 7: kijk live tv, rechtstreeks vanaf je laptop. Meer informatie. http://windows.microsoft.com/windows-7 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Radek Polak wrote: Radek Polak wrote: Here are mine numbers on QtMoko: kernel size: old: 1 833 952 new: 1 660 364 boot time old: 1min 58s new: 1min 30s Btw if someone wants to try here is new kernel with modules: http://activationrecord.net/radekp/qtmoko/download/experimental/ Installed the kernel, and the modules. It did not work. Well, X came up and was nice and snappy, but the phone never connected to the GSM network. I tried shr-settings, and GSM could not be turned on! I tried booting several times, I tried restarting various fso daemons that seemed phone-related. Nothing helped. In the end, I flashed the latest shr-unstable kernel, booted, and got a GSM connection just fine. (I use shr-unstable of today.) Too bad this kernel didn't work, it seemed very interesting. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Monday 18 January 2010 16:52:11 Helge Hafting wrote: Installed the kernel, and the modules. It did not work. Well, X came up and was nice and snappy, but the phone never connected to the GSM network. I tried shr-settings, and GSM could not be turned on! I tried booting several times, I tried restarting various fso daemons that seemed phone-related. Nothing helped. In the end, I flashed the latest shr-unstable kernel, booted, and got a GSM connection just fine. (I use shr-unstable of today.) Too bad this kernel didn't work, it seemed very interesting. I don't know what is causing gsm to not register, but it's not kernel, for sure. Sometimes it registers for me and sometimes it doesn't, with both standard shr kernel and stripped kernel. It seems registration is more frequent with standard kernel. Might it be for worse performance? (some daemon which starts before another one with stripped kernel, for example) For me, it seems if you let FR boot with no iteration, it almost never register. If you do things (f.e. open an applicaiotn) just when illume desktop appears on display, it's more probable to obtain a registration. Just my experience... signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Monday 18 January 2010 17:13:42 David Garabana Barro wrote: On Monday 18 January 2010 16:52:11 Helge Hafting wrote: Installed the kernel, and the modules. It did not work. Well, X came up and was nice and snappy, but the phone never connected to the GSM network. I tried shr-settings, and GSM could not be turned on! I tried booting several times, I tried restarting various fso daemons that seemed phone-related. Nothing helped. In the end, I flashed the latest shr-unstable kernel, booted, and got a GSM connection just fine. (I use shr-unstable of today.) Too bad this kernel didn't work, it seemed very interesting. I don't know what is causing gsm to not register, but it's not kernel, for sure. Sometimes it registers for me and sometimes it doesn't, with both standard shr kernel and stripped kernel. It seems registration is more frequent with standard kernel. Might it be for worse performance? (some daemon which starts before another one with stripped kernel, for example) For me, it seems if you let FR boot with no iteration, it almost never register. If you do things (f.e. open an applicaiotn) just when illume desktop appears on display, it's more probable to obtain a registration. Just my experience... And sometimes, but only sometimes, when not registered on boot, I can force registration simply by rebooting libphoneui from shr-settings Sometimes it doesn't matter what daemon you reboot. It doesn't register :( signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re: New significant speedups coming to FreeRunner
It did not work. Well, X came up and was nice and snappy, but the phone never connected to the GSM network. I tried shr-settings, and GSM could not be turned on! I tried booting several times, I tried restarting various fso daemons that seemed phone-related. Nothing helped. In the end, I flashed the latest shr-unstable kernel, booted, and got a GSM connection just fine. (I use shr-unstable of today.) Too bad this kernel didn't work, it seemed very interesting. I had the same behaviour with my FR: GSM was only availlable a very few times booting the experimental kernel. No Problems acured with the latest shr-u kernel, however. My last try was to use QI unstead of u-boot, and GSM got connected, I will try another reboot an report if it still works. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re: New significant speedups coming to FreeRunner
And sometimes, but only sometimes, when not registered on boot, I can force registration simply by rebooting libphoneui from shr-settings Sometimes it doesn't matter what daemon you reboot. It doesn't register :( I just managed to force the registering by giving the FR sth. to work and then restart phonefsod. So it seems that there is really a timing problem, which would explain why the problem occurs more often with the faster kernel... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
2010/1/14 Neil Jerram neiljer...@googlemail.com: I've just installed Timo's kernel from http://users.tkk.fi/~tajyrink/moko/kernel_20100108_nodebug_nopreempt/uImage-moredrivers-GTA02_oma-andy-2a04ce8203d7d0f1.bin, One more possible issue with this kernel. The boot messages always say [21474539.53] pcf50633-rtc pcf50633-rtc: hctosys: unable to read the hardware clock and my FR's date and time is always back to 1st Jan 1970 after a reboot. It looks to me as though the RTC device isn't working: debian-gta02:~# hwclock --show RTC_RD_TIME: Invalid argument ioctl() to /dev/rtc0 to read the time failed. debian-gta02:~# hwclock --systohc RTC_RD_TIME: Invalid argument ioctl() to /dev/rtc0 to read the time failed. debian-gta02:~# lsmod Module Size Used by ipv6 268504 14 debian-gta02:~# find /lib/modules/2.6.29-GTA02_oma-andy-mokodev/ -iname *rtc* /lib/modules/2.6.29-GTA02_oma-andy-mokodev/kernel/drivers/rtc /lib/modules/2.6.29-GTA02_oma-andy-mokodev/kernel/drivers/rtc/rtc-s3c.ko debian-gta02:~# modprobe rtc-s3c debian-gta02:~# lsmod Module Size Used by rtc_s3c 8460 0 ipv6 268504 14 debian-gta02:~# hwclock --systohc RTC_RD_TIME: Invalid argument ioctl() to /dev/rtc0 to read the time failed. debian-gta02:~# hwclock --show RTC_RD_TIME: Invalid argument ioctl() to /dev/rtc0 to read the time failed. debian-gta02:~# ls -l /dev/rtc0 crw-rw 1 root root 254, 0 Jan 1 1970 /dev/rtc0 Any ideas? Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Neil Jerram neiljer...@googlemail.com writes: [21474539.53] pcf50633-rtc pcf50633-rtc: hctosys: unable to read the hardware clock Can't find this from logs here. Does cat /sys/class/rtc/rtc0/since_epoch fail also? Can you reboot a few times and see if you see the bug every time or just sometimes? debian-gta02:~# modprobe rtc-s3c This is wrong module anyway. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Tue, Jan 19, 2010 at 7:21 AM, Neil Jerram neiljer...@googlemail.com wrote: and my FR's date and time is always back to 1st Jan 1970 after a reboot. It looks to me as though the RTC device isn't working: debian-gta02:~# hwclock --show RTC_RD_TIME: Invalid argument snip I my case on QtMoko V16B and this kernel I get: hwclock --show Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
2010/1/18 Timo Juhani Lindfors timo.lindf...@iki.fi: Neil Jerram neiljer...@googlemail.com writes: [21474539.53] pcf50633-rtc pcf50633-rtc: hctosys: unable to read the hardware clock Can't find this from logs here. Does cat /sys/class/rtc/rtc0/since_epoch fail also? Yes: debian-gta02:~# cat /sys/class/rtc/rtc0/since_epoch cat: /sys/class/rtc/rtc0/since_epoch: Invalid argument Can you reboot a few times and see if you see the bug every time or just sometimes? I'm certain it's happened every time that I've rebooted (which is 2 or 3 times per day, because of playing with zhone code). It's very noticeable, because it's the first (and in fact only) message when the backlight first comes on. debian-gta02:~# modprobe rtc-s3c This is wrong module anyway. Fair enough, I was just stabbing in the dark there. Thanks for your reply! Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Freerunner can now play Ogg video [was New significant speedups coming to FreeRunner]
Hi, just little notice. Without debug stuff and preempt, Freerunner is now capable of playing ogg videos in 320x240 on framebuffer without frames dropped. This was not possible until now and you had to use non free and patented codecs for videos. Now we have possibility to use open video format. For me it's very good news. Btw mpeg works without glamo acceleration now too. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
2010/1/8 Timo Jyrinki timo.jyri...@gmail.com: If you want to have a quick grab of the new kernel for Debian (or any distro that loads uImage from a file), I put my compilation of kernel and modules to http://users.tkk.fi/~tajyrink/moko/kernel_20100108_nodebug_nopreempt/ I've just installed Timo's kernel from http://users.tkk.fi/~tajyrink/moko/kernel_20100108_nodebug_nopreempt/uImage-moredrivers-GTA02_oma-andy-2a04ce8203d7d0f1.bin, and indeed it does feel a lot snappier. Even more so when I remember to switch frameworkd logging back from DEBUG to WARNING :-). But I noticed two apparent changes/regressions. 1. The openmoko-panel-plugin battery icon doesn't notice changes to the battery charging state. I can force it to notice by clicking on the icon, but it doesn't notice itself. I guess that means that the dbus signals for charging status are not working. 2. My habitual finger presses on the screen don't always register. Is it possible that this new kernel has a less sensitive touchscreen configuration than my previous kernel? My previous kernel was the Debian 2.6.28 one: uImage.bin-2.6.28-20090105.git69b2aa26. Any comments? Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
Denis Johnson wrote: Does this include a normal flashable image I can put straight to nand or is this an SD card install only ? This is an installer-image which will flash to nand, but you can flash to nand using dfu-util by flashing the files 'kernel.img' (== uImage) and 'rootfs.img' (== jffs2). Ghislain -- View this message in context: http://n2.nabble.com/qtmoko-New-significant-speedups-coming-to-FreeRunner-tp4284388p4329047.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Friday 08 January 2010 19:23:00 Timo Jyrinki wrote: Hi, Just FYI to the community list, as slowness has been one of the biggest problems with Neo. Quite nice speedups are coming: http://lists.openmoko.org/pipermail/openmoko-kernel/2010-January/010811.htm l (performance testing by Gennady Kupava) WOW! Its *REALLY* faster. You can feel it from the very first touch: SHR-Today :) signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Le 12/01/2010 12:42, David Garabana Barro a écrit : On Friday 08 January 2010 19:23:00 Timo Jyrinki wrote: Hi, Just FYI to the community list, as slowness has been one of the biggest problems with Neo. Quite nice speedups are coming: http://lists.openmoko.org/pipermail/openmoko-kernel/2010-January/010811.htm l (performance testing by Gennady Kupava) WOW! Its *REALLY* faster. You can feel it from the very first touch: SHR-Today :) I can confirm, but some troubles on the SHRu (Jan 6th) : - Wifi is not available (can't turn on device) - No sound during phonecalls (can't hear nothing on both sides). Someone to confirm those bugs ? (this way I'll trac those points) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Le 12/01/2010 13:51, Thomas HOCEDEZ a écrit : Le 12/01/2010 12:42, David Garabana Barro a écrit : - No sound during phonecalls (can't hear nothing on both sides). Someone to confirm those bugs ? (this way I'll trac those points) Ben moi je pourrais confirmer que j'ai pas de son, mais c'est une autre histoire :) Comment vas-u depuis le temps? Meilleurs voeux au fait! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Le 12/01/2010 14:07, KaZeR a écrit : Le 12/01/2010 13:51, Thomas HOCEDEZ a écrit : Le 12/01/2010 12:42, David Garabana Barro a écrit : - No sound during phonecalls (can't hear nothing on both sides). Someone to confirm those bugs ? (this way I'll trac those points) Apologies for my last mail. It was intendend to be sent off the list.. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Am Dienstag 12 Januar 2010 schrieb Thomas HOCEDEZ: Just FYI to the community list, as slowness has been one of the biggest problems with Neo. Quite nice speedups are coming: Its *REALLY* faster. You can feel it from the very first touch: SHR-Today I can confirm, but some troubles on the SHRu (Jan 6th) : - Wifi is not available (can't turn on device) - No sound during phonecalls (can't hear nothing on both sides). I cannot confirm the wifi problem nor the sound problem you mentioned. I use the latest upgrade as of today (except for the latest e-wm packages). -- Lars Lubarsky's Law of Cybernetic Entomology: There's always one more bug. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Am 10. Januar 2010 18:44 schrieb Fabian Schölzel fabian.schoel...@googlemail.com: Hm... i've done that, but i'm getting the cycles, too. I can't even connect through ssh now. Will there be a v17 release soon, or do i have to revert the kernel? It seems i hadn't v16 installed, so i didn't worked. Now i have it working, and... wow, it's really faster. That's amazing! Thanks to all involved! Cheers, Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
2010/1/12 Thomas HOCEDEZ thomas.hoce...@free.fr I can confirm, but some troubles on the SHRu (Jan 6th) : - Wifi is not available (can't turn on device) - No sound during phonecalls (can't hear nothing on both sides). Someone to confirm those bugs ? (this way I'll trac those points) have you installed the modules? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Tried now on shr-u, simply great! d ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Wed, Jan 13, 2010 at 1:51 AM, Thomas HOCEDEZ thomas.hoce...@free.fr wrote: [snip] I can confirm, but some troubles on the SHRu (Jan 6th) : - Wifi is not available (can't turn on device) - No sound during phonecalls (can't hear nothing on both sides). Someone to confirm those bugs ? (this way I'll trac those points) I had similar problems until I realised I'd untarred the modules into /home/root instead of / Have you extracted the modules tarball? -- Andrew Stephen http://www.evil.geek.nz/ It is absurd to divide people into good and bad. People are either charming or tedious. - Oscar Wilde ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
I think you did not install the modules. it is described earlier in this thread. I had no wifi or even usb networking left though. Solved it by removing sd-card, putting the modules on it from laptop and insert it into the neo again. Wifi works like a charm with nwa, doesn't connect with mokonnect though. Sound during calls is still a mess for the other side though.. Anyways. Big speedup, really nicely done. - Maybe there are even more improvements to the kernel somewhere? On Tue, Jan 12, 2010 at 13:51, Thomas HOCEDEZ thomas.hoce...@free.frwrote: Le 12/01/2010 12:42, David Garabana Barro a écrit : On Friday 08 January 2010 19:23:00 Timo Jyrinki wrote: Hi, Just FYI to the community list, as slowness has been one of the biggest problems with Neo. Quite nice speedups are coming: http://lists.openmoko.org/pipermail/openmoko-kernel/2010-January/010811.htm l (performance testing by Gennady Kupava) WOW! Its *REALLY* faster. You can feel it from the very first touch: SHR-Today :) I can confirm, but some troubles on the SHRu (Jan 6th) : - Wifi is not available (can't turn on device) - No sound during phonecalls (can't hear nothing on both sides). Someone to confirm those bugs ? (this way I'll trac those points) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
В Втр, 12/01/2010 в 20:49 +0100, Richy пишет: Anyways. Big speedup, really nicely done. - Maybe there are even more improvements to the kernel somewhere? I am planning to check various other ideas, don't expect such big difference anymore, but improvements are really possible. have fun. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
В Втр, 12/01/2010 в 13:51 +0100, Thomas HOCEDEZ пишет: Le 12/01/2010 12:42, David Garabana Barro a crit : On Friday 08 January 2010 19:23:00 Timo Jyrinki wrote: Hi, Just FYI to the community list, as slowness has been one of the biggest problems with Neo. Quite nice speedups are coming: http://lists.openmoko.org/pipermail/openmoko-kernel/2010-January/010811.htm l (performance testing by Gennady Kupava) WOW! Its *REALLY* faster. You can feel it from the very first touch: SHR-Today :) I can confirm, but some troubles on the SHRu (Jan 6th) : - Wifi is not available (can't turn on device) - No sound during phonecalls (can't hear nothing on both sides). Someone to confirm those bugs ? (this way I'll trac those points) Please, triple check that you installed kernel and modules in right way and report if you still have issue. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
Excellent thanks, Does this include a normal flashable image I can put straight to nand or is this an SD card install only ? cheers Denis On Mon, Jan 11, 2010 at 6:34 PM, ghislain ghisl...@basetrend.nl wrote: I've created a new installer-image for QtMoko V16B, it can be downloaded here: http://www.openmobile.nl/pages/downloads.php#qtm16b QtMoko V16B . This are the changes: - Kernel without debugging options (overall speedup) - TangoGPS to V0.99.2 - Latest patch from Radek (mmap mmap64) (solves segfault in webviewer / arora) Ghislain http://www.basetrend.nl/ BaseTrend - http://www.openmobile.nl openmobile.nl -- View this message in context: http://n2.nabble.com/qtmoko-New-significant-speedups-coming-to-FreeRunner-tp4284388p4284388.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[qtmoko] New significant speedups coming to FreeRunner
I've created a new installer-image for QtMoko V16B, it can be downloaded here: http://www.openmobile.nl/pages/downloads.php#qtm16b QtMoko V16B . This are the changes: - Kernel without debugging options (overall speedup) - TangoGPS to V0.99.2 - Latest patch from Radek (mmap mmap64) (solves segfault in webviewer / arora) Ghislain http://www.basetrend.nl/ BaseTrend - http://www.openmobile.nl openmobile.nl -- View this message in context: http://n2.nabble.com/qtmoko-New-significant-speedups-coming-to-FreeRunner-tp4284388p4284388.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Michal Brzozowski a écrit : 2010/1/9 Radek Polak pson...@seznam.cz mailto:pson...@seznam.cz Btw if someone wants to try here is new kernel with modules: http://activationrecord.net/radekp/qtmoko/download/experimental/ Is this going to work with SHR or only with Qtmoko? I tested it with hackable:1 rev5, it works out of the box too. David ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
2010/1/8 Timo Jyrinki timo.jyri...@gmail.com Hi, Just FYI to the community list, as slowness has been one of the biggest problems with Neo. Quite nice speedups are coming: Wow, this is big. Literki is like 3x faster ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Fri, Jan 08, 2010 at 08:23:00PM +0200, Timo Jyrinki wrote: Hi, Just FYI to the community list, as slowness has been one of the biggest problems with Neo. Quite nice speedups are coming: This is the single most incredible speedup so far! Big thanks to anyone involved! I'm running shr-testing with neo-theme and at resolution 240x320. Even scrolling the contact list etc. is quite smooth now. And the interface is as responsive as it has never been before. pgpCjstFf5XIT.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Good work, Do I only need the .bin or the config and modules also. I have tried just the .bin using qtMoko v16 image and it boots quite quickly to qt ui then cycles to black screen with blinking cursor then after some time back to qt screen then back to black screen. etc cheers Denis On Sat, Jan 9, 2010 at 4:23 AM, Timo Jyrinki timo.jyri...@gmail.com wrote: Hi, Just FYI to the community list, as slowness has been one of the biggest problems with Neo. Quite nice speedups are coming: http://lists.openmoko.org/pipermail/openmoko-kernel/2010-January/010811.html (performance testing by Gennady Kupava) Apparently, and unfortunately, no-one had really questioned Om Inc:s (who mainly did the kernel work back in the days of the still mostly used 2.6.29) choices of kernel configuration. Disabling kernel debug features and pre-empt has resulted eg. these kind of improvements (from IRC, #openmoko-fi): - boot time 68.5% of original - apt-cache search nano 20s - 14.8s - emacs -f kill-emacs 3.8s - 2.2s These configuration changes are not yet in andy-tracking (the 2.6.29 kernel still being used in most distros), I don't know what's the situation in the new om-2.6.32 branch. Together with the quite recent commit from Thomas White that doubled theoretical glamo speeds (in practice at least 20% in general), I feel that Neo FreeRunner is not anymore terribly slow, but only slow by today's standards, which is quite an improvement. Especially after having been used to the terribly slow general behavior ;) Please tell if some distro happened to have those disabled already, and if someone knew about these speedups via the options already - and please arrange a commit to git.openmoko.org next time! Anyway, this all goes to show that in a project with limited resources like Openmoko, especially now that it's completely in the hands of the community when it comes to Neo FreeRunner development, you have to have the courage to question anything suspicious etc. you are seeing, not trusting that someone has actually optimized something to the extent assumed. If you want to have a quick grab of the new kernel for Debian (or any distro that loads uImage from a file), I put my compilation of kernel and modules to http://users.tkk.fi/~tajyrink/moko/kernel_20100108_nodebug_nopreempt/ -Timo, wishing everyone a speedier new year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Ole Kliemann wrote: On Fri, Jan 08, 2010 at 08:23:00PM +0200, Timo Jyrinki wrote: Hi, Just FYI to the community list, as slowness has been one of the biggest problems with Neo. Quite nice speedups are coming: This is the single most incredible speedup so far! Big thanks to anyone involved! I'm running shr-testing with neo-theme and at resolution 240x320. Even scrolling the contact list etc. is quite smooth now. And the interface is as responsive as it has never been before. Great improvements : I used the same kernel for SHRu (01/06) and H:1rev5, both were dramatically improved ! @/ole : How did you managed to change the resolution ? / ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Sun, Jan 10, 2010 at 02:05:17PM +0100, Thomas Hocedez wrote: @/ole : How did you managed to change the resolution ? I have in /etc/fb.modes: mode 240x320 geometry 240 320 240 320 16 timings 10 8 88 2 2 8 2 endmode Now stop the Xserver. Do: $ echo qvga-normal /sys/bus/spi/devices/spi2.0/state $ fbset 240x320 Then start the Xserver again. This doesn't work with every kernel as some have WSOD-issues with fbset. But it works with the one posted above. You should then make some scaling tweaks. In illume settings under Look-Scaling disable scaling by dpi. You can go to the advanced settings and set a custom scaling factor of 1.2 times or so. I also have in /etc/profile.d/elementary.sh: export ELM_SCALE=1.2 export ELM_FINGER_SIZE=35 Restarting Xserver then might be required. There are a lot of problems still with the lower resolution. The first is that my timings seem to be not 100% correct. There are some horizontal stripes and artifacts. If I have some time, I'll make a post stating a list of problems in scaling and general appearance with 240x320. Maybe someone with more insight into the field of themes, etc. can give some tips then. I'm more the user-type. ;-) pgp6pQzP0uEiF.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Denis Johnson wrote: Do I only need the .bin or the config and modules also. I have tried just the .bin using qtMoko v16 image and it boots quite quickly to qt ui then cycles to black screen with blinking cursor then after some time back to qt screen then back to black screen. etc You need to unpack modules for newer kernel first. ssh r...@neo cd / wget http://activationrecord.net/radekp/qtmoko/download/experimental/modules- v17.tar.gz tar xzvpf modules-v17.tar.gz then you can power off and flash uImage-v17 and it should work. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Sunday 10 January 2010 13:59:01 Denis Johnson wrote: Good work, Do I only need the .bin or the config and modules also. I have tried just the .bin using qtMoko v16 image and it boots quite quickly to qt ui then cycles to black screen with blinking cursor then after some time back to qt screen then back to black screen. etc I guess this is because you are missing the modules and QtE cannot start up its daemons correctly. Try to ssh into your fr and unpack the modules on /. AFAIK you don't need the config. Michael signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Sunday 10. January 2010 15:10:31, Radek Polak Polak wrote: You need to unpack modules for newer kernel first. ssh r...@neo cd / wget http://activationrecord.net/radekp/qtmoko/download/experimental/modules- v17.tar.gz tar xzvpf modules-v17.tar.gz Hm... i've done that, but i'm getting the cycles, too. I can't even connect through ssh now. Will there be a v17 release soon, or do i have to revert the kernel? (Besides, thank you for your work with qtmoko, Radek!) Cheers, Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Thanks to Radek, I indeed also needed to download an untar the modules. All good, great work. On Sun, Jan 10, 2010 at 10:59 PM, Denis Johnson denis.john...@gmail.com wrote: Good work, Do I only need the .bin or the config and modules also. I have tried just the .bin using qtMoko v16 image and it boots quite quickly to qt ui then cycles to black screen with blinking cursor then after some time back to qt screen then back to black screen. etc cheers Denis On Sat, Jan 9, 2010 at 4:23 AM, Timo Jyrinki timo.jyri...@gmail.com wrote: Hi, Just FYI to the community list, as slowness has been one of the biggest problems with Neo. Quite nice speedups are coming: http://lists.openmoko.org/pipermail/openmoko-kernel/2010-January/010811.html (performance testing by Gennady Kupava) Apparently, and unfortunately, no-one had really questioned Om Inc:s (who mainly did the kernel work back in the days of the still mostly used 2.6.29) choices of kernel configuration. Disabling kernel debug features and pre-empt has resulted eg. these kind of improvements (from IRC, #openmoko-fi): - boot time 68.5% of original - apt-cache search nano 20s - 14.8s - emacs -f kill-emacs 3.8s - 2.2s These configuration changes are not yet in andy-tracking (the 2.6.29 kernel still being used in most distros), I don't know what's the situation in the new om-2.6.32 branch. Together with the quite recent commit from Thomas White that doubled theoretical glamo speeds (in practice at least 20% in general), I feel that Neo FreeRunner is not anymore terribly slow, but only slow by today's standards, which is quite an improvement. Especially after having been used to the terribly slow general behavior ;) Please tell if some distro happened to have those disabled already, and if someone knew about these speedups via the options already - and please arrange a commit to git.openmoko.org next time! Anyway, this all goes to show that in a project with limited resources like Openmoko, especially now that it's completely in the hands of the community when it comes to Neo FreeRunner development, you have to have the courage to question anything suspicious etc. you are seeing, not trusting that someone has actually optimized something to the extent assumed. If you want to have a quick grab of the new kernel for Debian (or any distro that loads uImage from a file), I put my compilation of kernel and modules to http://users.tkk.fi/~tajyrink/moko/kernel_20100108_nodebug_nopreempt/ -Timo, wishing everyone a speedier new year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Radek Polak wrote: Here are mine numbers on QtMoko: kernel size: old: 1 833 952 new: 1 660 364 boot time old: 1min 58s new: 1min 30s Btw if someone wants to try here is new kernel with modules: http://activationrecord.net/radekp/qtmoko/download/experimental/ Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
2010/1/9 Radek Polak pson...@seznam.cz Btw if someone wants to try here is new kernel with modules: http://activationrecord.net/radekp/qtmoko/download/experimental/ Is this going to work with SHR or only with Qtmoko? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Am Samstag, 9. Januar 2010 schrieb Michal Brzozowski: 2010/1/9 Radek Polak pson...@seznam.cz Btw if someone wants to try here is new kernel with modules: http://activationrecord.net/radekp/qtmoko/download/experimental/ Is this going to work with SHR or only with Qtmoko? I used the kernel from first post by Timo and just booted successfully my SHR with it :) in less time though ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Radek Polak wrote: Btw if someone wants to try here is new kernel with modules: http://activationrecord.net/radekp/qtmoko/download/experimental/ I see in your supplied config that you still have CONFIG_MTD_NAND_VERIFY_WRITE=y which was found to be a slowdown in write performance. In latest andy-tracking kernel it is disabled. So i'm right now compiling latest andy tracking with your config and nand write verify disabled. I'm curious if this is really faster than my last normal andy-tracking kernel with none of these optimizations. :) Ciao, Rainer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Michal Brzozowski wrote: Is this going to work with SHR or only with Qtmoko? Yes, it should. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
New significant speedups coming to FreeRunner
Hi, Just FYI to the community list, as slowness has been one of the biggest problems with Neo. Quite nice speedups are coming: http://lists.openmoko.org/pipermail/openmoko-kernel/2010-January/010811.html (performance testing by Gennady Kupava) Apparently, and unfortunately, no-one had really questioned Om Inc:s (who mainly did the kernel work back in the days of the still mostly used 2.6.29) choices of kernel configuration. Disabling kernel debug features and pre-empt has resulted eg. these kind of improvements (from IRC, #openmoko-fi): - boot time 68.5% of original - apt-cache search nano 20s - 14.8s - emacs -f kill-emacs 3.8s - 2.2s These configuration changes are not yet in andy-tracking (the 2.6.29 kernel still being used in most distros), I don't know what's the situation in the new om-2.6.32 branch. Together with the quite recent commit from Thomas White that doubled theoretical glamo speeds (in practice at least 20% in general), I feel that Neo FreeRunner is not anymore terribly slow, but only slow by today's standards, which is quite an improvement. Especially after having been used to the terribly slow general behavior ;) Please tell if some distro happened to have those disabled already, and if someone knew about these speedups via the options already - and please arrange a commit to git.openmoko.org next time! Anyway, this all goes to show that in a project with limited resources like Openmoko, especially now that it's completely in the hands of the community when it comes to Neo FreeRunner development, you have to have the courage to question anything suspicious etc. you are seeing, not trusting that someone has actually optimized something to the extent assumed. If you want to have a quick grab of the new kernel for Debian (or any distro that loads uImage from a file), I put my compilation of kernel and modules to http://users.tkk.fi/~tajyrink/moko/kernel_20100108_nodebug_nopreempt/ -Timo, wishing everyone a speedier new year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Fri, Jan 8, 2010 at 7:23 PM, Timo Jyrinki timo.jyri...@gmail.com wrote: Hi, Just FYI to the community list, as slowness has been one of the biggest problems with Neo. Quite nice speedups are coming: http://lists.openmoko.org/pipermail/openmoko-kernel/2010-January/010811.html (performance testing by Gennady Kupava) Apparently, and unfortunately, no-one had really questioned Om Inc:s (who mainly did the kernel work back in the days of the still mostly used 2.6.29) choices of kernel configuration. Disabling kernel debug features and pre-empt has resulted eg. these kind of improvements (from IRC, #openmoko-fi): - boot time 68.5% of original - apt-cache search nano 20s - 14.8s - emacs -f kill-emacs 3.8s - 2.2s These configuration changes are not yet in andy-tracking (the 2.6.29 kernel still being used in most distros), I don't know what's the situation in the new om-2.6.32 branch. Together with the quite recent commit from Thomas White that doubled theoretical glamo speeds (in practice at least 20% in general), I feel that Neo FreeRunner is not anymore terribly slow, but only slow by today's standards, which is quite an improvement. Especially after having been used to the terribly slow general behavior ;) Please tell if some distro happened to have those disabled already, and if someone knew about these speedups via the options already - and please arrange a commit to git.openmoko.org next time! Anyway, this all goes to show that in a project with limited resources like Openmoko, especially now that it's completely in the hands of the community when it comes to Neo FreeRunner development, you have to have the courage to question anything suspicious etc. you are seeing, not trusting that someone has actually optimized something to the extent assumed. If you want to have a quick grab of the new kernel for Debian (or any distro that loads uImage from a file), I put my compilation of kernel and modules to http://users.tkk.fi/~tajyrink/moko/kernel_20100108_nodebug_nopreempt/ -Timo, wishing everyone a speedier new year ha ha, great work man! I'll try it soon! d ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Timo Jyrinki wrote: Disabling kernel debug features and pre-empt has resulted eg. these kind of improvements (from IRC, #openmoko-fi): - boot time 68.5% of original - apt-cache search nano 20s - 14.8s - emacs -f kill-emacs 3.8s - 2.2s Here are mine numbers on QtMoko: kernel size: old: 1 833 952 new: 1 660 364 boot time old: 1min 58s new: 1min 30s + wihout debug stuff there is also some more RAM and it seems it will be possible to compile moredrivers config 2MB and subjectively everything is faster. So for me this optimazations are definitely useful. Maybe we could remove all the stuff from gta configs and put them in another small file (gta02_debug_config?) so that if anybody wants to compile with debug options he can just copy paste this file into moredrives/packaging config and he will easily end up with the same debug options as we have now in configs. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Fri, Jan 8, 2010 at 2:28 PM, Radek Polak pson...@seznam.cz wrote: Here are mine numbers on QtMoko: kernel size: old: 1 833 952 new: 1 660 364 boot time old: 1min 58s new: 1min 30s huzzah! lets get this piped in asap. would this help with application load time? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Hi, I get similar boot speed improvements on my FR with both qtmoko v16 in NAND and Hackable1 rev5 on SD. The kernel also fixes an issue with both distro's where BT would fail to wake after suspend. Well done! -Dave On Sat, Jan 9, 2010 at 8:49 AM, jeremy jozwik jerjoz.for...@gmail.comwrote: On Fri, Jan 8, 2010 at 2:28 PM, Radek Polak pson...@seznam.cz wrote: Here are mine numbers on QtMoko: kernel size: old: 1 833 952 new: 1 660 364 boot time old: 1min 58s new: 1min 30s huzzah! lets get this piped in asap. would this help with application load time? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
