**** BEGIN LOGGING AT Wed Jun 16 02:59:56 2010 Jun 16 06:55:34 moin Jun 16 06:56:34 zub: I locally applied your last patch... still have to build and test and push though Jun 16 06:56:41 zub: just for you to know something is happening :) Jun 16 07:28:43 <[Rui]> moin Jun 16 07:31:55 moin Jun 16 07:48:53 <[Rui]> JaMa: hi! hope json-c can be included... Jun 16 07:49:25 sure... I'll check it later Jun 16 07:51:32 <[Rui]> JaMa: replacing libxml in elmdentica with it is being relatively quick (although last night while I was testing the timeline loading I found a bug but were too tired to fix) Jun 16 07:52:13 <[Rui]> oops, gtg to work, see ya Jun 16 08:01:28 freesmartphone.org: 03Frederik.Sdun 07utilities * r0fc89972717c 10/palmpre/preboot/src/main.vala: preboot: fix boot timeout Jun 16 08:01:29 freesmartphone.org: 03Frederik.Sdun 07utilities * reb254eda48d4 10/palmpre/preboot/src/main.vala: preboot: fix shutdown timeout Jun 16 09:48:55 JaMa: any idea why I get this: http://shr.pastebin.com/0RJktSkh ? Jun 16 09:50:18 mrmoku: no, haven't seen this (I'm now on bitbake master) Jun 16 09:51:13 JaMa: I got this after interrupting bitbake while parsing... Jun 16 09:51:38 * mrmoku switches to master Jun 16 09:56:24 mrmoku: master won't probably help, but you can try to move bb_cache.dat somewhere and rerun Jun 16 10:03:31 JaMa: at least it gave me a different error :) pointing me to BBFILES being wrong in my config Jun 16 10:03:41 * mrmoku tries to build without Makefile for the first time :P Jun 16 11:04:33 <[Rui]> JaMa: could you update the rev for elmdentica to r49653 so people can get 0.9.9 (with 2 crasher bugs fixed)? It still isn't a jsonified version, but I'm not sure how quickly it'll take converting and I'd rather those bugs got fixed in the repo.... Jun 16 11:11:18 [Rui]: now we have "49660" Jun 16 11:11:37 <[Rui]> JaMa: you're pushing it all along with e, then? Jun 16 11:12:02 yes Jun 16 11:12:09 <[Rui]> ah cool :) Jun 16 11:12:31 <[Rui]> since I usually have a bigger release number when I build locally I don't usually upgrade elmdentica from the repo so I didn't notice it Jun 16 11:12:49 <[Rui]> just done an upgrade, let's see how it looks Jun 16 11:17:02 larsc, hi. By using a dedicated workqueue and flushing the queue instead of calling do_pio_read in the IRQ handler, we can reduce a bit the code duplication Jun 16 11:17:39 I wonder if we can drop the error handling in the worker the same way Jun 16 11:18:11 (it should be handled by the IRQ handler, we shouldn't have to check the status reg) Jun 16 11:18:48 <[Rui]> hms... I just did an upgrade and it seems to have stuck on boot Jun 16 11:22:05 <[Rui]> oh shit, my card reader is not here so I can't fsck the card :( Jun 16 11:25:29 [Rui]: fsck on target device ? Jun 16 11:28:53 <[Rui]> found a colleague with a card reader Jun 16 11:29:05 <[Rui]> dcordes: right, when it stucks on boot requiring a fsck you do that how? :) Jun 16 11:29:38 always keep initramfs with interactive shell Jun 16 11:31:05 or have 2 OS: one on nand and one on sd Jun 16 11:32:51 <[Rui]> dcordes: on openmoko? :) Jun 16 11:33:11 <[Rui]> anyway, fsck done, booted just fine now. Jun 16 11:34:06 [Rui]: yes Jun 16 11:34:45 <[Rui]> dcordes: how do you propose I type 'y' to questions I don't even see as the boot splash is there? :) Jun 16 11:34:45 another thught configture fsck to run frequently enough to avoid errors Jun 16 11:35:04 [Rui]: rm /etc/init.d/psplash Jun 16 11:35:39 <[Rui]> dcordes: right... Jun 16 12:46:14 hi Jun 16 12:47:08 i try to run navits qml gui an i found that a package with qtxmlpatters is needed, is it anywhere? Jun 16 12:49:13 no Jun 16 12:50:00 * JaMa rebuilding qt to check why Jun 16 12:50:35 maybe only missing QT_LIB_NAMES but libgui_qml is not linked against it.. Jun 16 12:51:33 what does that mean: " * JaMa rebuilding qt to check why" ? Jun 16 12:52:24 I'm rebuilding it to see if it's not built or not packaged Jun 16 12:52:33 JaMa: ok Jun 16 12:53:15 but I should finish some work first.. so I'll check result later (hopefully today) Jun 16 13:17:05 mickey|wm, hi Jun 16 13:31:06 GNUtoo|laptop: lol Jun 16 13:31:08 found the error Jun 16 13:31:17 this NAND driver is somewhat of crap Jun 16 13:31:26 I should shoot some qualcomm people ... -.- Jun 16 13:31:33 it doesnt only allow subpage size Jun 16 13:31:40 it also doesnt allow multi page size Jun 16 13:31:54 you can only read 2048 bytes at once Jun 16 13:31:57 not more, not less Jun 16 13:32:13 so now, I'll also implement multipage size reading Jun 16 13:32:15 xD Jun 16 13:32:55 thats somewhat to barf Jun 16 13:33:03 anyway, I'll go to electronics store now Jun 16 13:33:24 need some parts, wanna look if they have it in theire sortiment Jun 16 13:33:43 when multipage reading also works Jun 16 13:33:50 ok Jun 16 13:34:02 we finally have something which is callable a working driver Jun 16 13:34:16 because that stuff android produced is unusable Jun 16 13:34:27 if you're not using this raped android linux Jun 16 13:34:28 ... Jun 16 13:34:58 did you see mickey arround? Jun 16 13:35:06 ~seen mickeyl Jun 16 13:35:40 GNUtoo|laptop: it seems thats hes watching this evil game today Jun 16 13:35:43 called football Jun 16 13:35:56 ahh ok Jun 16 13:36:03 I thought he abandoned the community Jun 16 13:36:12 no Jun 16 13:36:16 ok nice Jun 16 13:36:19 he's just tooo social Jun 16 13:36:22 :-) Jun 16 13:36:30 and watches tv, even football Jun 16 13:36:37 lol ok Jun 16 13:37:05 I consider football such interesting like watching colored amoebias crowling around in a petri shell Jun 16 13:37:12 when does footbal finishes? Jun 16 13:37:18 dunno Jun 16 13:37:22 like I said Jun 16 13:37:24 BORING Jun 16 13:37:31 I do not care about the match Jun 16 13:41:04 GNUtoo|laptop: you can be sure, its duration doesnt take longer, if you consider the requested physical conditions and circumstances Jun 16 13:41:16 will mean: I consider them not to be doped Jun 16 13:41:27 so it wont take longer then 1h or so ;-) Jun 16 13:41:33 ? Jun 16 13:41:49 mickey will be back soon Jun 16 13:41:54 or you can higlight him Jun 16 13:42:02 his nick atm is mickey|wm Jun 16 13:42:04 :-) Jun 16 13:42:11 ok bug he doesn't seem on irc Jun 16 13:42:25 mickey|wm, don't repond Jun 16 13:42:35 wtf? Jun 16 13:42:46 anyways Jun 16 13:42:51 need to go now Jun 16 13:43:12 I need some parts for my new project Jun 16 13:43:13 ^^ Jun 16 13:43:19 hmm, but first Jun 16 13:43:21 I've an idea Jun 16 13:43:23 what project? Jun 16 13:43:31 serial port for htcdream? Jun 16 13:43:35 to conquer the world Jun 16 13:44:16 been there, done that... not worth doing again. Jun 16 13:44:41 (world domination is over-rated.) Jun 16 13:47:40 no I wont conquer the world Jun 16 13:48:10 this project possibility died when the humans reached more then the half of the actual population Jun 16 13:48:27 more something like escape plan number Jun 16 13:48:31 ... i stoped counting Jun 16 13:48:35 >_< Jun 16 13:48:56 its a MEG Jun 16 13:49:06 motionless electromagnetic generator Jun 16 13:49:14 I'll tune it to bring full capacity Jun 16 13:49:24 so Jun 16 13:49:37 farnell doesnt have the needed parts either Jun 16 13:49:48 lets watch pusterla Jun 16 13:49:57 they have even the good old vacuum tubes Jun 16 13:49:58 ^^ Jun 16 13:51:09 so Jun 16 13:51:11 Transistors were a conspiracy. Long live the vacuum tube! Jun 16 13:51:24 mwester: its only the next step Jun 16 13:51:39 the last step is using quantum mechanics for programming Jun 16 13:51:48 imagine a recursive function Jun 16 13:52:09 coded into the spin of the valenc electrons and its bindings of the cristal network Jun 16 13:52:25 so you can calculate with volumina holograms Jun 16 13:52:32 anyways Jun 16 13:52:40 too complex Jun 16 13:52:42 yet Jun 16 13:52:46 I need to go Jun 16 13:52:51 need this c-cores Jun 16 13:52:58 cu l8er Jun 16 13:53:00 :-D Jun 16 15:35:45 PaulFertser, if you still remember the issue: I got my sd card working with up to 833kHz of glamo max sd clock Jun 16 15:52:19 cz_jc: i do. Jun 16 15:52:41 cz_jc: strange, 833kHz is very low Jun 16 15:52:50 PaulFertser, its a class 4 card though and I got way better transfer rates outside FR. any idea how could this be ? Jun 16 15:53:22 PaulFertser, but I tried at least 20 boots with normal clockrate, it didn't work. With 833kHz, it always works for 5 boots. So I think this is no fluke Jun 16 15:53:32 cz_jc: not really. I have one in fact but it never really was confirmed, so just a guess. Jun 16 15:53:44 PaulFertser, at 1MHz, I get segfaults in random programs and sometimes it doesn't boot Jun 16 15:54:18 PaulFertser, oh ! also, I have to set sd_post_power_clock to: 100000 Jun 16 15:54:42 cz_jc: i think usb cardreaders use fixed voltage for powering cards. And pci sd cardreader (SDHCI driver) uses voltage range where the lowest voltage is higher than that allowed on FR. Jun 16 15:55:09 cz_jc: so if the card advertises unreasonably low voltage, it can still work ok on other devices (because they can't provide it anyway) but fail on FR. Jun 16 15:55:17 cz_jc: should be easy to check with a little kernel hack. Jun 16 15:55:20 PaulFertser, the card works in an mp3 player, camera, internal laptop reader and nintendo ds Jun 16 15:55:47 PaulFertser, sure.. :) Jun 16 15:56:24 PaulFertser, oh ! also size is incorrectly advertised, but blockdev is fine: Jun 16 15:56:30 PaulFertser, Jan 01 03:29:05 [kernel] mmcblk0: mmc0:e726 SU08G 3.40 GiB Jun 16 15:57:06 PaulFertser, could you please confirm this source is where every glamo dirty work with sd cards is done? http://git.openmoko.org/?p=kernel.git;a=blob;f=drivers/mfd/glamo/glamo-mci.c;h=acf16360cfd3d6dd0d99a11098d640194f3cef99;hb=andy-tracking Jun 16 15:57:08 cz_jc: it might be interesting to compare traces of access between glamo-mci and sdhci. Jun 16 15:57:35 cz_jc: indeed :) Jun 16 15:58:13 PaulFertser, also I noticed a fluke: the first half of the card is faster than the second half... I discovered this by polling dd during block transfer Jun 16 15:58:49 cz_jc: is it reproducible with sdhci? Jun 16 15:59:20 PaulFertser, this was on the usb mp3 reader.. so it was over usb to scsi layer I think Jun 16 15:59:57 PaulFertser, in sdhci, you mean native sd reader as in the laptop for example ? Jun 16 16:00:16 cz_jc: yes, it's basically the most common low-level access device you can find. Jun 16 16:00:29 cz_jc: but some laptops have an integrated usb cardreader. Jun 16 16:00:33 PaulFertser, ok I'll test it throrougly and report what it does :) Jun 16 16:00:39 PaulFertser, mine exposes the cards as mmcblkx Jun 16 16:00:50 cz_jc: then it is sdhci, i guess. Jun 16 16:01:28 cz_jc: i mean to try to trace the issue/difference it might make sense to add some instrumentation (or at least enable full debug) to mmc layer, and then compare the differences. Jun 16 16:01:53 cz_jc: i'm not sure if spending time on that particular card worth the effort though. Jun 16 16:02:10 PaulFertser, well.. I'm pretty broke and too lazy to work Jun 16 16:02:18 PaulFertser, I have time to waste :D Jun 16 16:03:21 cz_jc: also kernel-level hacking is kinda fun as it is :) Jun 16 16:04:15 * ThibG reads the conversation, he is pretty interested in anything that have to do with glamo-mci Jun 16 16:05:50 ThibG: the original question is why the hell some particular card cz_jc's got works everywhere but FR (though he found extremely lowering the clock makes it work somehow). Jun 16 16:06:04 cz_jc: have you tried any sd_drive tweaking? Jun 16 16:08:03 hm ok Jun 16 16:09:51 PaulFertser, good idea Jun 16 16:09:59 PaulFertser, I think I'll try different drive Jun 16 16:16:03 PaulFertser, does the change in drive come to effect on runtime ? Jun 16 16:16:23 I can't see anything in glamo-mci itself that would play (note that I'm new to this, and don't know much about the SD stack or the way glamo itself works) Jun 16 16:16:56 cz_jc: it does Jun 16 16:17:20 PaulFertser, ok my drive was 0, so I set 2, touched a fnew ile in /tmp, done sync and it wrote ok.. Jun 16 16:17:25 ThibG: as already stated, neither me, except for the different voltage range. Jun 16 16:17:43 that said, there is a piece of code that should improve (read) performance while allowing to lower the clock (although 833kHz is still extremly slow) Jun 16 16:17:47 PaulFertser, is there a way to tell what voltage it is currently on ? Jun 16 16:17:59 ThibG: it's not glamo-mci specific, it's FR-specific. Jun 16 16:18:16 cz_jc: i'm not sure, i'd need to seriously dig the code to answer. Jun 16 16:18:18 PaulFertser, is really glamo anywhere else ? Jun 16 16:18:31 cz_jc: to the best of my knowledge, no. Jun 16 16:18:41 PaulFertser, lucky suckers :D Jun 16 16:18:49 now did they found glamo?? Jun 16 16:18:58 cz_jc: but my remark meant that voltage constraints are not set in glamo-mci.c which is what ThibG knows well now :) Jun 16 16:19:07 ok Jun 16 16:19:16 gena2x: i guess raster might know the story. Jun 16 16:20:57 PaulFertser, ok so now with a higher drive, I try overclocking it slowly at runtime and testing io ? Jun 16 16:21:09 cz_jc: sounds like a plan :) Jun 16 16:21:13 ok Jun 16 16:21:17 cz_jc: clocking has immediate effect as well. Jun 16 16:21:47 1MHz seems ok now.. Jun 16 16:21:51 weird Jun 16 16:21:55 thats where it failed before Jun 16 16:22:18 PaulFertser, could it be possible with drive=0, it works up to 800kHz and drive=2 works higher ? Jun 16 16:22:58 cz_jc: sure Jun 16 16:23:12 cz_jc: i even voted for using drive=1 by default Jun 16 16:23:25 Because it doesn't seem to affect GPS but is necessary for some cards. Jun 16 16:23:26 (drive?) Jun 16 16:23:39 ThibG: yes, that's line drive strength, with 0 being so lowest. Jun 16 16:23:48 ok Jun 16 16:23:49 ThibG: sd_drive module parameter Jun 16 16:24:04 PaulFertser, what is it good for btw ? Jun 16 16:24:29 PaulFertser, it lowers the voltage on glamo side of data/clock output ? Jun 16 16:24:32 cz_jc: making the signal edges less sharp, thus producing less interference for the GPS receiver. Jun 16 16:24:37 cz_jc: not voltage Jun 16 16:24:50 PaulFertser, so like spread spectrum ? Jun 16 16:25:00 cz_jc: it's "value of the pull-up/down resistors" used to drive the line. Jun 16 16:25:04 ~ Jun 16 16:25:47 PaulFertser, ok.. Jun 16 16:25:56 PaulFertser, should I try 1 or 2 ? Jun 16 16:26:07 cz_jc: 2 is the strongest, so i'd try 2 first. Jun 16 16:26:17 PaulFertser, ok Jun 16 16:27:24 PaulFertser: btw, what is 'normal' sd speed in Mb/s? hdparm -t? Jun 16 16:28:00 gena2x: no real idea, but i know it's higher than glamo bus constraints. Jun 16 16:29:04 PaulFertser: higher than bus speed? i have 2.34. is it ok? Jun 16 16:29:43 PaulFertser, maybe that was it.. now I'm wgetting a large file with 2MHz glamo sd clock and it didn't blow up yet.. Jun 16 16:30:09 but the ultimate test will be to set the drive strength, higher clock speed and try to boot with it. That's where it always failed reliably Jun 16 16:30:22 cz_jc: sorry for not mentioning that earlier, somehow i've forgotten about that particular gotcha. Jun 16 16:30:37 gena2x: that's glamo limit afaik Jun 16 16:30:47 mine is: Linux version 2.6.29-rc3-hackmobile (jc@hackbox) (gcc version 4.4.2 (Gentoo 4.4.2 p1.0) ) #1 PREEMPT Tue Apr 27 16:41:30 CEST 2010 Jun 16 16:31:07 PaulFertser, has this parameter (sd_drive) been dropped...? Jun 16 16:31:10 gena2x: iirc you can get a 30% better speed on recent kernels with the display blanked. Jun 16 16:31:19 if you want me to dig, I'd give you the commit hash Jun 16 16:31:20 ThibG: shouldn't have been. Jun 16 16:31:31 :) sound funny, but useful Jun 16 16:31:42 ThibG, its in latest git Jun 16 16:31:55 i noticed io is somehow much faster on .34 btw (than .32 and .29-nodebug) Jun 16 16:32:13 ThibG, http://git.openmoko.org/?p=kernel.git;a=blob;f=drivers/mfd/glamo/glamo-mci.c;h=acf16360cfd3d6dd0d99a11098d640194f3cef99;hb=andy-tracking#l105 Jun 16 16:32:17 but didn't do any measurements Jun 16 16:32:21 module_param(sd_drive, int, 0644); Jun 16 16:32:37 btw. it doesn't get boundary checked: Jun 16 16:32:45 556 writew((readw(host->base + GLAMO_REG_MMC_BASIC) & 0x3e) | Jun 16 16:32:45 557 0x0800 | GLAMO_BASIC_MMC_NO_CLK_RD_WAIT | Jun 16 16:32:45 558 GLAMO_BASIC_MMC_EN_COMPL_INT | (sd_drive << 6), Jun 16 16:32:45 559 host->base + GLAMO_REG_MMC_BASIC); Jun 16 16:32:51 that's just some bad coding practice :) Jun 16 16:33:01 it doesnt get preprocessed in any way Jun 16 16:33:24 someone could mangle his GLAMO_REG_MMC_BASIC Jun 16 16:33:34 cz_jc, huh, it isn't there, in the 2.6.34 branch Jun 16 16:33:53 ThibG, really ? are there the others ? Jun 16 16:34:15 instead, it is computed Jun 16 16:34:29 ThibG, based on what? :) Jun 16 16:34:40 sd_drive = (rate * 4) / host->clk_rate; Jun 16 16:34:40 if (sd_drive > 3) Jun 16 16:34:40 sd_drive = 3; Jun 16 16:34:58 ThibG, so its done based on clock rate Jun 16 16:35:00 ThibG: who invented that? Jun 16 16:35:04 ok let's see, the default is 16MHz Jun 16 16:35:05 me Jun 16 16:35:10 larsc: i knew that ;) Jun 16 16:35:32 larsc: can you please elaborate a bit, it's interesting to know the reasoning behind it. Jun 16 16:36:36 experimentation showed that higher sd_driver proved more stable results at higher clock rates Jun 16 16:36:53 larsc, I can confirm that now :D Jun 16 16:37:34 larsc: well... I'd use the highest strength always, but what about GPS, doesn't it affect it badly, have you done any tests? Jun 16 16:37:43 nope Jun 16 16:38:17 ok I set my sd_max_clk to 16666667 now (alleged default) Jun 16 16:38:21 wish me a lot lot of luck :) Jun 16 16:39:17 larsc: it was assumed that it was exactly using a lower drive strength that helped to solve GPS reliability problems. Jun 16 16:39:39 seems to work. OK officially, I'm an extremely happy camper now :) Jun 16 16:39:41 PaulFertser, thaaaanks :) Jun 16 16:40:49 PaulFertser: but without it sd card access doesn't work at all at higher speeds Jun 16 16:42:08 larsc: higher than 16MHz? Are you sure sd_drive=1 is not enough? Because here most folks were running with sd_drive=0 and default clock without any problems. Jun 16 16:42:35 PaulFertser, no I don't think so Jun 16 16:42:49 PaulFertser, because my card 'mysteriously' worked in SHR and kernel still couldn't boot from it Jun 16 16:42:51 PaulFertser: not sure. it's been a while Jun 16 16:42:55 PaulFertser, I think SHR resets it runtime Jun 16 16:44:17 # cat sd_drive sd_max_clk Jun 16 16:44:18 0 Jun 16 16:44:18 16666666 Jun 16 16:44:36 That's on my Debian. I use only root on SD, and that's for more than a year now. Jun 16 16:45:00 PaulFertser, yeah.. but the most used distrubition is SHR and they definitely reset it.. I could check to make sure if you want Jun 16 16:45:44 cz_jc: if they do reset it, then they should fix the distro to not mess with users' preferences, imho. Jun 16 16:46:30 PaulFertser, probably Jun 16 16:46:50 PaulFertser, maybe they only reset it when they detect i/o errors. Thats what came up in my dmesg. Jun 16 16:47:11 PaulFertser, don't take me for my word, I just speculate. But my card did only work in shr Jun 16 16:48:54 larsc, hi Jun 16 16:49:10 quite a few patches for you :p Jun 16 16:52:26 I set glamo_mci.sd_drive to 2 but my phone still doesn't boot with it.. strange Jun 16 16:52:35 maybe the card needs to be slow for a while or something Jun 16 16:52:42 and again, what about submitting the drivers upstream? :) Jun 16 16:52:52 ThibG: i saw them. will look at them later or tomorrow Jun 16 16:52:57 PaulFertser, but setting it to 800kHz and then resetting it to 16MHz in an init script is fine for me :) Jun 16 16:53:11 ThibG: if you want to take care of it go ahead. Jun 16 16:55:23 btw, the read_worker works fine with me (but I've only built glamo-mci, not even glamo-fb, so, maybe there were side effects...?) Jun 16 16:57:09 PaulFertser, cz_jc: root@om-gta02 /sys/module/glamo_mci/parameters # cat sd_drive sd_max_clk Jun 16 16:57:12 0 Jun 16 16:57:15 16666666 Jun 16 16:57:19 on stock SHR Jun 16 16:57:48 mrmoku: ok, good to hear :) Jun 16 16:58:40 mrmoku, that's strange then.. maybe it just doesn't work when mounting it as root. But I tried rootdelay of upto 60 Jun 16 16:59:22 mrmoku, anyway thanks for clearing that up Jun 16 17:09:41 hm, i wonder why don't we see any crc errors although coorupted data has been transfered? Jun 16 17:10:31 cause if we would, we could increase sd_drive in case of an error Jun 16 17:10:41 so it only gets set for cards where needed Jun 16 17:11:49 PaulFertser: and yes, also wanted one other interesting thing. about sdram speed. we have 100mhz memory bus, 4byte wide, so burst read should be 400Mb/s. yes? why we have 100Mb/s read? Jun 16 17:12:36 PaulFertser: i read specs on s3c (and rechecked sd timings btw), and noticed strange thing in controller description Jun 16 17:13:15 PaulFertser: (now openining to citate) Jun 16 17:14:13 PaulFertser: 1. nothing is written about bursts in memory controller section Jun 16 17:15:08 PaulFertser: 2. in dma section some bursts mentioned Jun 16 17:16:48 PaulFertser: 3. where is register bits to change 'burst lenght' in SDRAM mode register, but it has 1 fixed value Jun 16 17:17:52 PaulFertser: i am quite new to sdram, so i am misunderstand something. Jun 16 17:18:23 PaulFertser: so question is - did anyone measure DMA memory-to-memory speed (is it possible at all btw?) Jun 16 17:18:35 PaulFertser: and is our 100Mb/s ok? Jun 16 17:19:36 gena2x: i honestly have zero idea, but i hope larsc knows more. Jun 16 17:20:08 larsc: may my questions be interesting? Jun 16 17:22:36 gena2x: i think the original openmoko folks tested mem to mem dma an came to the conclusion that it was even more slower, because of the overhead of setting up the dma transactions Jun 16 17:24:59 larsc: hm... it would be interesting to see code and retest on nodebug kernel. Jun 16 17:25:54 larsc: any thoughts about bus speed? Jun 16 17:26:38 gena2x: http://www.mail-archive.com/openmoko-kernel@lists.openmoko.org/msg03657.html Jun 16 17:26:45 gena2x: nope Jun 16 17:34:49 gena2x: btw. the bus is only 2bytes wide Jun 16 17:36:59 am??? Jun 16 17:37:05 2? Jun 16 17:37:20 memory bus? Jun 16 17:39:05 the bus between the glamo and the soc Jun 16 17:39:14 forget glame Jun 16 17:39:27 glamo :) Jun 16 17:39:35 i'm about direct sdram read. Jun 16 17:40:11 which, i hope, 4byte wide Jun 16 17:40:39 did i told glamo? :) Jun 16 17:40:47 i told 'memory to memory' Jun 16 17:40:53 yes Jun 16 17:41:08 but what else do you need it for then copying from the glamo? Jun 16 17:41:33 i am about CPU->sdram Jun 16 17:41:46 read speed is 100Mb/s. Jun 16 17:41:48 why? Jun 16 17:41:54 bus is 4byte wide. Jun 16 17:42:00 clock is 100mhz Jun 16 17:42:31 oh, sdram->cpu Jun 16 17:43:45 and i am not expert on topic. sorry is my question look stupid :( Jun 16 17:44:14 where did you read that it was only 100Mb/s Jun 16 17:44:26 or did you test it? Jun 16 17:44:32 lmbench. Jun 16 17:44:36 checked code Jun 16 17:47:13 http://www.bsdmn.com/openmoko/summary1.txt Jun 16 17:47:22 mem read Jun 16 17:47:34 mem write Jun 16 17:47:59 testing tool have clean c code and may be run separately Jun 16 17:48:08 from command line Jun 16 17:49:17 hm. mem write is twice as fast as mem read Jun 16 17:50:33 in fact my questing is: for given timings (we have sdram module timings), we have bus speed, know all setup, how much it should be theoretically. Jun 16 17:51:12 yes, it's strange to have 100mb/s read and 190 write Jun 16 17:52:46 rd measures the bandwidth for reading data into the processor. It computes the sum of an every fourth element of an integer array. Jun 16 17:52:46 for (i = 0; i < N; i += 4) sum += array[i]; Jun 16 17:53:18 ops Jun 16 17:53:57 my miss. seem i misread this last time Jun 16 17:57:21 how many instructions per clock cycle can the cpu do? Jun 16 17:57:46 i checked this Jun 16 17:57:50 all as expected Jun 16 17:57:57 400mhz Jun 16 17:58:04 you may see also bogomips Jun 16 17:58:22 [21474536.520000] Calibrating delay loop... 199.47 BogoMIPS (lpj=498688) Jun 16 17:58:31 200 - 2 instructions Jun 16 17:58:39 add and jump Jun 16 17:58:53 i rechecked. true 400mhz Jun 16 17:59:19 debian-gta02:/home/gena/lmbench_o/lmbench-2.5/bin/armv4tl-linux-gnu# ./bw_mem 10240000 frd Jun 16 17:59:19 10.24 100.16 Jun 16 17:59:49 no. frd is frd measures the bandwidth for reading data into the processor. It computes the sum of an array of integer values. Jun 16 17:59:49 for (i = 0; i < N; i++) sum += array[i]; Jun 16 18:00:04 OUTPUT Jun 16 18:00:04 Output format is "%0.2f %.2f\n", megabytes, megabytes_per_second, i.e., Jun 16 18:00:04 8.00 25.33 Jun 16 18:00:17 so yes, 100Mb/s Jun 16 18:00:34 180 for fwr Jun 16 18:01:19 frd(register TYPE *p, register TYPE *lastone) Jun 16 18:01:19 { Jun 16 18:01:19 register int sum = 0; Jun 16 18:01:19 while (p <= lastone) { Jun 16 18:01:19 sum += Jun 16 18:01:20 #define DOIT(i) p[i]+ Jun 16 18:01:22 DOIT(0) DOIT(1) DOIT(2) DOIT(3) DOIT(4) DOIT(5) DOIT(6) Jun 16 18:01:24 DOIT(7) DOIT(8) DOIT(9) DOIT(10) DOIT(11) DOIT(12) Jun 16 18:01:26 and so on Jun 16 18:02:12 so fwr is unrolled an the other is not Jun 16 18:02:13 ? Jun 16 18:02:41 i didn't check assembler for this... Jun 16 18:03:01 well the read loop should be at least 4 instructions Jun 16 18:03:02 both unrolled Jun 16 18:03:05 ah ok Jun 16 18:03:36 (according to c code) Jun 16 18:04:04 why 2? Jun 16 18:04:13 tfu Jun 16 18:04:19 why 4 instructions? Jun 16 18:04:43 i see sum+=p[0]+p[1]+p[2]... Jun 16 18:05:25 i'll check assembler now... Jun 16 18:05:42 but anyway, why 100mb/s?? Jun 16 18:05:53 why write is faster? Jun 16 18:07:44 if 4 instructions, speed still have to be 400mb/s Jun 16 18:08:05 because of prefetch? or not? Jun 16 18:11:39 fwr: Jun 16 18:11:39 @ Function supports interworking. Jun 16 18:11:40 ... Jun 16 18:11:44 str r2, [r3, #508] Jun 16 18:11:45 str r2, [r3, #504] Jun 16 18:11:45 str r2, [r3, #500] Jun 16 18:11:45 str r2, [r3, #496] Jun 16 18:11:45 str r2, [r3, #492] Jun 16 18:11:47 ... Jun 16 18:11:51 1 instruction Jun 16 18:12:25 frd: Jun 16 18:12:31 .L25: Jun 16 18:12:31 ldmia r3, {r2, r4, lr} @ phole ldm Jun 16 18:12:31 ldr ip, [r3, #12] Jun 16 18:12:31 add r2, r4, r2 Jun 16 18:12:33 add r2, r2, lr Jun 16 18:12:35 ldr lr, [r3, #16] Jun 16 18:12:37 add r2, r2, ip Jun 16 18:12:39 ldr ip, [r3, #20] Jun 16 18:12:41 add r2, r2, lr Jun 16 18:12:45 ldr lr, [r3, #24] Jun 16 18:12:47 add r2, r2, ip Jun 16 18:12:49 ok, 2 instructions Jun 16 18:13:05 but second one not related to memory access Jun 16 18:13:18 so and with 2 clock cycles per instruction you get 100Mhz Jun 16 18:13:31 well 100Mb/s Jun 16 18:13:33