| 00:44.47 | *** join/#openezx johanbr (n=j@blk-7-131-98.eastlink.ca) |
| 02:09.50 | *** join/#openezx WM (n=wyrm@20158135045.user.veloxzone.com.br) |
| 02:10.14 | WM | hi |
| 02:10.33 | WM | sabrod: ping |
| 02:48.41 | johanbr | WM: I'm here. In case you were going to say you had some new gen-blob stuff to test. :) |
| 03:08.06 | tmzt | WM: looks like Q9 is omap, not pxa |
| 03:09.09 | WM | johanbr: yes, can you help me test a new gen-blob version? |
| 03:09.36 | WM | tmzt: what phone is Q9? googling. |
| 03:11.17 | tmzt | WM: just looked at the platform-data patch, it looks like it's against ezx.c |
| 03:11.18 | *** join/#openezx pixel__ (i=nobody@dslc-082-082-072-039.pools.arcor-ip.net) |
| 03:11.46 | tmzt | do I just need to take the pcap parts and put those in motoq.c ? |
| 03:11.52 | WM | tmzt: yes, im lazy to port it to your machine file. |
| 03:12.03 | WM | tmzt: you need everything. |
| 03:12.09 | tmzt | what is all the i2c_board_register for |
| 03:12.29 | WM | all the spi and pcap platform data added by this particular patch. |
| 03:12.45 | WM | tmzt: i2c is not being added by the patch i sent to you. |
| 03:13.11 | WM | look only at the lines that has a + as the first char :) |
| 03:13.52 | WM | but there is spi_register_board_info IIRC, and these are important |
| 03:14.01 | tmzt | oh, those are all per device _init functions, the CONFIG_PXA27x_KEYBOARD was confusing me |
| 03:15.09 | WM | johanbr: please, send me your email address. |
| 03:28.57 | johanbr | WM: I can test a new version now, if you'd like. |
| 03:31.37 | tmzt | WM: git apply didn't work for ezx-pcap.patch, it complained about Makefiles/Kconfig but didn't create driver/mfd/ezx-pcap.c either |
| 03:33.04 | WM | johanbr: sent |
| 03:34.47 | WM | tmzt: edit the patch, and remove the conflicting blocks, and then add manually. |
| 03:35.06 | WM | tmzt: but you should consider basing your work on the latest linus tree. |
| 03:35.29 | WM | in this case, it would not have conflicted :) |
| 03:35.59 | WM | johanbr: please, report the results asap. |
| 03:36.16 | johanbr | WM: Sure, should have something for you in a few minutes... |
| 03:36.21 | WM | Its not expected to work, but the error msgs are much more useful now. |
| 03:37.46 | WM | also, the driver now is much more persistent, it will retry the initializaton commands 100 times instead of the previous 10. |
| 03:38.01 | WM | just in case... ;) |
| 03:42.54 | johanbr | WM: Didn't say much at all. "CMD_APP_CMD Timeout (a12" on the first line and then "Cannot find MMC card" |
| 03:43.03 | johanbr | Tried twice, same result. |
| 04:00.17 | WM | johanbr: sent another one. |
| 04:00.28 | johanbr | Alright, will try again. |
| 04:05.11 | johanbr | WM: That new one doesn't do *anything*. The red screen just remains after the blob is sent. |
| 04:05.26 | WM | hum.. |
| 04:06.11 | johanbr | If I try sending it a second time, boot_usb says "Serching for EZX phone: none." |
| 04:07.36 | WM | have you waited or how much time? |
| 04:07.52 | johanbr | md5sum 3a453e5fef1766cf3548752ee989ef42 on the new file, just to make sure |
| 04:08.14 | johanbr | Waited 30 seconds or so |
| 04:09.04 | WM | match |
| 04:10.07 | johanbr | "match" ? |
| 04:11.39 | johanbr | you found something? |
| 04:12.16 | WM | does this card work on the stock motorola firmware? |
| 04:12.32 | johanbr | yes, works just fine. |
| 04:12.34 | WM | and what a1200 version it is? r? i? e? |
| 04:12.57 | johanbr | Not e. r or i, not sure. |
| 04:17.23 | WM | try 3 sent |
| 04:18.12 | WM | tell me the hex value that will appear now. |
| 04:19.51 | johanbr | WM: CMD_APP_CMD |
| 04:20.02 | johanbr | Timeout (a120f89c) |
| 04:20.09 | johanbr | Cannot find MMC card |
| 04:25.16 | WM | (OUT_OF_RANGE | BLOCK_LEN_ERROR | LOCK_UNLOCK_FAILED | CARD_ECC_FAILED) |
| 04:26.55 | johanbr | If I boot the kernel over usb, gpe starts normally, so I don't think there's anything wrong with the card. |
| 04:37.20 | WM | attempt number 4 |
| 04:39.40 | johanbr | Same thing, but now the hex number is a120f8c0. |
| 04:59.48 | WM | linux recognizes your card as SD or MMC? |
| 05:01.54 | johanbr | In my laptop (with an adapter), the card shows up as /dev/mmcblk0, if that's what you mean. |
| 05:03.11 | *** join/#openezx the_mgt_ (n=ich@dslb-082-083-210-041.pools.arcor-ip.net) |
| 05:03.44 | WM | dmesg shows what when you insert the card? (pastebin) |
| 05:04.21 | WM | on your laptop. |
| 05:06.12 | johanbr | WM: http://pastebin.ca/1236657 |
| 05:09.26 | WM | johanbr: pastebin.ca seems to be down, or my connection to it is firewalled somewhere. |
| 05:09.39 | WM | pastebin.com is working here. |
| 05:10.52 | johanbr | WM: strange. Try http://paste.ubuntu.com/62733/ |
| 05:11.30 | WM | this cant be.\ |
| 05:11.36 | WM | i have this card here. |
| 05:11.42 | WM | and it works :) |
| 05:12.24 | johanbr | Then it must be the phone, I guess. |
| 05:13.01 | WM | but it works on the openezx kernel. |
| 05:13.15 | WM | where there is no change on the configuration. |
| 05:13.42 | johanbr | right |
| 05:13.52 | johanbr | very strange... |
| 05:14.12 | johanbr | But I know the same thing happened for sabrod: his card works with kernels booted over usb, but not with gen-blob |
| 05:15.25 | WM | hum.. |
| 05:15.36 | WM | i will increase the card voltage. |
| 05:15.55 | WM | hope it wont burn people cards. ;) |
| 05:16.26 | johanbr | How does gen-blob work? Is it the same code that's in the kernel? |
| 05:16.55 | johanbr | For driving the card, I mean. |
| 05:17.27 | WM | not really. |
| 05:17.39 | WM | its a subset of the 2.4 kernel driver. |
| 05:17.55 | WM | not the complete thing. |
| 05:18.47 | johanbr | I see. |
| 05:19.13 | johanbr | By the way, now that I think about it, I don't think I've tried this card with the original motorola setup, I put a rootfs on it straight away. |
| 05:19.30 | johanbr | So it's at least possible that it doesn't work with the Motorola 2.4 kernel either. |
| 05:19.46 | WM | the same card (SU02G SD) works here |
| 05:20.53 | johanbr | Sounds like there's some slight variation in the phone hardware that makes it not work for me, then. |
| 05:22.24 | johanbr | Anyway, I really should go to bed. |
| 05:22.27 | WM | sent you another mail, with increased voltage. |
| 05:22.37 | johanbr | Alright, will give that a quick try. |
| 05:22.44 | WM | Thanks! :) |
| 05:22.48 | johanbr | increased by how much? :) |
| 05:23.43 | WM | all o it ;) |
| 05:23.52 | WM | s/o/of/ |
| 05:24.04 | WM | it wont burn my card :) |
| 05:24.43 | johanbr | a120f8b4 |
| 05:25.06 | WM | :/ |
| 05:25.24 | WM | still the same errors. |
| 05:25.47 | WM | better you go sleep. :) |
| 05:26.03 | johanbr | Yes. I will be in the channel at least for a few hours tomorrow. |
| 05:26.06 | johanbr | Good night |
| 05:26.11 | WM | gn. bye |
| 06:39.10 | tmzt | WM: patches kernel boots |
| 06:59.41 | tmzt | WM: there is nothing under /sys/class/spi_master or /sys/class/spidev |
| 07:00.42 | tmzt | WM: and PCAP is not under /proc/interrupts |
| 09:41.21 | *** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1) |
| 10:03.58 | *** join/#openezx yansa (n=yans@89.108.200.2) |
| 11:21.03 | *** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1) |
| 12:25.14 | sabrod | re |
| 12:28.41 | ao2 | hi, now I can capture a full picture with a780, but colors are still off: http://people.openezx.org/ao2/a780-camera-full-frame.jpg |
| 12:32.34 | sabrod | ao2 : cool ! (is it a IR sensor? ;) ) |
| 12:32.42 | ao2 | :P |
| 12:53.56 | *** join/#openezx florian (n=fuchs@f049190195.adsl.alicedsl.de) |
| 12:56.11 | *** join/#openezx neolynx (n=u@32-123-204-62-pool.dsl.fcom.ch) |
| 13:10.10 | *** join/#openezx johanbr (n=j@blk-7-131-98.eastlink.ca) |
| 13:11.29 | *** join/#openezx l403 (n=l@85.132.159.231) |
| 13:32.39 | *** join/#openezx johanbr (n=j@blk-7-131-98.eastlink.ca) |
| 13:44.20 | *** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1) |
| 13:51.49 | *** join/#openezx l403 (n=l@85.132.159.231) |
| 13:52.04 | WyrM | hi. |
| 13:52.30 | gmzhuo | Hi |
| 13:52.35 | WyrM | tmzt: you need pxa2xx_spi and ezx_pcap on .config :) |
| 13:52.53 | sabrod | hello WyrM , gmzhuo |
| 13:53.32 | WyrM | sabrod, hi. |
| 13:53.44 | WyrM | sabrod: want to test a new gen-blob version? |
| 13:54.02 | sabrod | WyrM: sure . |
| 13:55.03 | WyrM | sabrod: ok, will send it on your mail. |
| 13:55.06 | WyrM | just a min |
| 13:55.15 | sabrod | frederi1-gmail.com |
| 13:56.51 | WM | sabrod: sent. |
| 13:57.16 | WM | try it on all your non-working cards and report. |
| 13:57.31 | sabrod | ok |
| 14:07.00 | WyrM | ao2: the camera looks better, congrats :) |
| 14:07.32 | WyrM | the sensor is rgb or yuv? |
| 14:09.03 | ao2 | the sensor can output both formats, now I managed to capture the data coming from the video device, let's see what format is, after that I'll try to spot some configuration error (swapped values, packed vs. planar, etc.) |
| 14:10.44 | ao2 | the sensor can also output a test pattern, it would be useful, it's only that I haven't been able to enable it yet |
| 14:25.55 | WyrM | sabrod: any results? |
| 14:29.22 | sabrod | Tes pastebin.com/m2d310093 |
| 14:29.28 | sabrod | yes |
| 14:30.44 | sabrod | Sd's like johanbr yesterday give no useful results (same as when no sd° |
| 14:30.59 | sabrod | s/°/)/ |
| 14:32.17 | sabrod | i dunno if the others gave usefull results, but at least, they changed ! |
| 14:35.04 | WM | sabrod: lets focus on the cards that gives CMD_SD_OP_COND errors |
| 14:35.14 | WM | and no need to report the partition layout. |
| 14:35.37 | WM | the initialization fails long before any data is read from the card. |
| 14:36.42 | sabrod | Wyrm, i retest the friday's verbose genblob and i have a lot of different lines.I never saw ... |
| 14:40.53 | WM | sabrod: i sent you another version. |
| 14:41.25 | WM | please test on SD3 or SD5 |
| 14:42.11 | sabrod | The last card, I'm sure it's genuine sandisk 2GB... It give me http://pastebin.ca/1236938 |
| 14:42.31 | sabrod | OK, ok, I relax... |
| 14:42.57 | WM | i cant connect to pastebin.ca |
| 14:43.06 | WM | pastebin to another site plz |
| 14:44.15 | sabrod | Ah, I resend to pastebin.com: http://pastebin.com/m780c71b0 |
| 14:45.35 | WM | sabrod: on this last pastebin, the card is initialized. |
| 14:46.14 | WM | but it couldnt detect the fat partition, probably because of data corruption |
| 14:46.25 | sabrod | Ok, but now , it does the old messages |
| 14:46.44 | WM | i think it is some timing issue. |
| 14:47.09 | WM | when you get APP_CMD errors it looks like the card is not even powered on. |
| 14:47.15 | sabrod | Trying to investigate....perhaps timing... |
| 14:48.36 | sabrod | Exact, I tried to flash "blob", and then to power off and fash genblob-sabrod, it gave me the same olds results... |
| 14:49.15 | sabrod | I was wondering if the blob before genblob, made something magic :p |
| 14:49.20 | WM | dont flash these non working blobs. |
| 14:49.50 | sabrod | flash, sorry, put on ram, "boot-usb'ed" |
| 14:50.04 | WM | ahh, ok :) |
| 14:50.26 | WM | but no, no magic from chaining blobs ... lol. |
| 14:50.52 | sabrod | yes :( |
| 14:51.24 | WM | have you tested this last version i sent? |
| 14:51.56 | WM | on SD3 and SD5 only. |
| 14:52.11 | sabrod | Sorry, i will... didn't saw... |
| 14:52.29 | sabrod | (was trying differents batts :p ) |
| 14:53.07 | WM | batts shouldnt make a difference either. |
| 14:54.58 | WM | (blob try 3) sent too, with extra delay after powering up the card. |
| 14:55.22 | WM | please try it on SD6 |
| 14:56.20 | sabrod | yes it tries a long time for sd5 then SD_SEND_OP_COND , timeout 00ff8000 |
| 14:56.34 | sabrod | (test blog2) |
| 14:56.38 | sabrod | blob2 |
| 14:56.45 | WM | looks like there is more than one issue. SD3/SD5 looks like unsupported cards. others look like unpowered cards. |
| 14:58.00 | WM | blob2->SD3, blob3->SD6 |
| 14:58.45 | sabrod | same with blob2-> Sd3, but timeout 00000000 |
| 14:59.18 | WM | btw, i am testing every blob i send you, and all work here :/ |
| 15:00.19 | sabrod | blob3-> SD |
| 15:00.29 | sabrod | 6: |
| 15:01.36 | sabrod | CMD_APP_CMD / Timeout a120f8bc / Cannot find MMC card |
| 15:02.47 | sabrod | was rapid ... |
| 15:03.20 | *** join/#openezx Fosforo (n=Fosforo@20151091229.user.veloxzone.com.br) |
| 15:03.23 | sabrod | blob3 sd4 does exactly the same |
| 15:07.22 | sabrod | sd5 > blob3 : "_OP_COND" / timeout 00ff8000 / cannot find MMC |
| 15:08.33 | sabrod | (same as with blob2 sorry) |
| 15:08.54 | WM | blob4->sd6 |
| 15:09.02 | WM | no need to test on other sds. |
| 15:09.08 | sabrod | Ok, seen ! |
| 15:11.26 | sabrod | I got 3 lines , then screen blank, and timeout.. |
| 15:12.49 | WM | blob5->sd6 blob will freeze so you can read the 3 lines. |
| 15:13.01 | sabrod | 2 Pwr: lines another,... |
| 15:13.28 | sabrod | Ah, ok, I have a web cam, but yes, it's propably easier... |
| 15:14.21 | sabrod | (timeout is a1216dc0) each time, i believe. |
| 15:16.11 | sabrod | Pr: 00025052 Pw: 00025b72 Pr: 0x25bf2 |
| 15:32.43 | WM | blob6->sd6 (only last 3 lines) |
| 15:33.25 | WM | s/3/4/ |
| 15:35.00 | sabrod | CMD55: 0 1 / MMC Status 2140 / C55: / 00000000 00000000 / 00000000 00000000 |
| 15:35.20 | sabrod | each / is a return to line... |
| 15:36.43 | sabrod | but I can easily write the whole message, it's not big, and everything appear on the screen :) |
| 15:37.16 | WM | the others are already known by me. :) |
| 15:37.36 | sabrod | CMD65535: 0 0 ah, ok... |
| 15:38.09 | sabrod | I switch of my webcam immediatly!!! :) |
| 15:38.32 | WM | but C55: should not be all blank. |
| 15:38.59 | WM | try it on SD3 or SD5. |
| 15:40.15 | sabrod | Before these lines there is CMD 55 : 0 1/ MMC status 2142 / MMC_CMD_TIMEOUT / CMD 0 0 / MMC status 2140 ... |
| 15:40.25 | sabrod | just to clarify ...:) |
| 15:41.56 | sabrod | same CMD55: 0 1 / MMC Status 2140 / C55: / 00000000 00000000 / 00000000 00000000 |
| 15:43.36 | sabrod | Ah, no / on SD5 it's C55: 00000120 000000000 / 00000000 00000037 |
| 15:45.03 | WM | ok, good |
| 15:45.18 | sabrod | :) |
| 15:45.42 | WM | lets focus on sd5, as it seems to be at least powered :) |
| 15:46.26 | sabrod | I bought it on amazon :) |
| 15:46.42 | sabrod | PQI 2gb :) |
| 15:49.38 | WM | blob7->sd5 |
| 15:50.55 | sabrod | so much cmd41 and cmd55 !! |
| 15:51.05 | WM | last c41: |
| 15:51.23 | sabrod | ok it stops :) |
| 15:52.03 | sabrod | c41 00ff8000 00000000 / 00000000 0000003f |
| 15:53.41 | sabrod | c55: 00000120 00000000 / 00000000 / 00000037 /cmd 41: ff8000 3 / cmd status 2140 / c41 00ff8000 00000000 / 00000000 0000003f` |
| 15:54.02 | sabrod | to go back a little more on the messages.... |
| 15:56.40 | WM | im looking for a '8' on the first char after C41: |
| 15:56.56 | WM | sending another blob |
| 15:57.40 | WM | blob8->sd5 |
| 15:57.50 | WM | it will be a lot slower now ;) |
| 15:58.43 | sabrod | Ah , i should read the line with a "cmd41: 8..." ? |
| 15:58.48 | WM | yes. |
| 15:59.07 | WM | if you see the 8, we are in the right direction. :) |
| 16:04.03 | sabrod | no, only 00ff8000 .... 00000003f |
| 16:04.52 | sabrod | perhaps i need to test another time |
| 16:12.15 | sabrod | i don't think it gave me a cmd41: 8 or c41: 8*** :( |
| 16:12.47 | WM | after C41: 8 it would freeze, no way you would miss :) |
| 16:13.51 | sabrod | ah, i was near from epilepsia reading all the lines going on the screen :D |
| 16:15.37 | sabrod | no, just kidding, now , it's slow and this console is pretty easy to read : |
| 16:29.25 | sabrod | ao2 : about the colors : www.digitaldog.net/files/Printer_Test_file.jpg.zip |
| 16:30.05 | sabrod | Ok, there is nothing to do with a sensor driver :( , but it may help? People will have the reference for your images ? |
| 16:40.25 | WM | sabrod: blob9->sd6 (your sandisk card) |
| 16:41.12 | WM | increased mmc controller timeout, so it may work on the sds that were giving APP_CMD timeout errors. |
| 16:42.33 | sabrod | ah, (btw my 1gb sandisk goes at full speed even with you slowed blob8, then APP_CMD) |
| 16:42.51 | WM | sabrod, its a diferent loop on the code :) |
| 16:43.15 | sabrod | only: mmc status 24** |
| 16:43.28 | sabrod | testing blob9... |
| 16:44.09 | WM | yeah, there is a chance that blob9 will give you the C41: 8 on all sds except 3 and 5. |
| 16:45.08 | sabrod | well, with sd6, it give c41 000000, for the moment... |
| 16:45.41 | WM | :( |
| 16:46.20 | WM | are you seeing CMD_TIMEOUT lines? |
| 16:46.31 | sabrod | will test the othersnot yet... |
| 16:46.44 | WM | try on sd5. |
| 16:47.02 | sabrod | not yet ( cmd timeout) |
| 16:49.03 | sabrod | blob9 give c41 0000 on sd6 and c41 00ff8000 on sd5 |
| 16:50.30 | sabrod | it swithed bugs :) |
| 16:53.02 | WM | on sd6, all the c41 dump is zeroes? |
| 16:53.16 | sabrod | finally on sd5 it give CMD_SD_SEND_OP_COND / Timeout 00ff8000 |
| 16:53.40 | WM | good. |
| 16:53.42 | sabrod | on sd6 i interrupted but it was 00, yes |
| 16:54.00 | sabrod | should i wait the end with sd6 |
| 16:54.02 | sabrod | ? |
| 16:54.04 | WM | no |
| 16:54.28 | sabrod | 2 cards powered up ? |
| 17:05.08 | sabrod | got blob 10 :) |
| 17:05.10 | WM | sabrod: i need the last MMCs, MMCi and C41 dump |
| 17:05.59 | WM | on sd6 and sd5 too |
| 17:06.25 | sabrod | ok, blob9 with some cards is going fast and timeout, not with sd6 and sd3(000) and sd5 (00ff8000) |
| 17:09.47 | sabrod | on sd6 MMCs : 00002140 / MMCi : 00000004 / C41 : 00...00 / OP_COND / Timeout 00000000 |
| 17:12.20 | sabrod | on sd6 MMCs : 00002140 / MMCi : 00000004 / C41 : / 00FF8000 00000000 / 00000000 0000003F / OP_COND / Timeout 00ff8000 |
| 17:13.02 | sabrod | s/sd6/sd5/ |
| 17:25.08 | *** join/#openezx yansa (n=yans@89.108.255.79) |
| 17:29.27 | sabrod | I had some 2,2,25 that panics with genblob... perhaps it's my phone... |
| 17:30.44 | sabrod | got it! |
| 17:33.51 | *** join/#openezx CIA-28 (n=CIA@208.69.182.149) |
| 17:48.35 | sabrod | WyrM : still no "8" after c41 |
| 17:50.35 | sabrod | 1,2,4 are CMD_APP_CMD |
| 17:51.00 | WyrM | with both blob-l and blob-h? |
| 17:51.05 | sabrod | 3 and 6 gave 00000 |
| 17:52.03 | sabrod | 5 gave 000ff8000 |
| 17:52.03 | sabrod | yes both blobs... |
| 17:52.36 | WyrM | cia filter is working, no commits from upstream on the channel, only via email :) |
| 18:13.41 | CIA-28 | Daniel Ribeiro <drwyrm@gmail.com> ezx/current * b478aeccbb openezx/drivers/mfd/ezx-pcap.c: zero spi_transfer, this was the source of the spi bugs. |
| 18:16.21 | *** join/#openezx johanbr (n=j@JBrannlund2.MathStat.Dal.Ca) |
| 18:28.53 | *** join/#openezx yansa (n=yans@89.108.220.126) |
| 18:59.47 | *** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1) |
| 19:13.36 | tmzt | WyrM: thanks, but it looks like pxa2xx-spi is not in the kernel I am using. |
| 19:13.58 | tmzt | WyrM: I found mailling list messages from June of this year about it, so it's probably in 2.6.27 |
| 19:20.40 | *** join/#openezx yansa (n=yans@89.108.219.33) |
| 19:22.29 | *** join/#openezx sabrod (n=mac@lns-bzn-53-82-65-5-189.adsl.proxad.net) |
| 19:24.07 | *** join/#openezx neolynx (n=u@32-123-204-62-pool.dsl.fcom.ch) |
| 19:36.16 | WyrM | tmzt: which kernel are you using? |
| 19:38.28 | tmzt | 2.6.26-rc9 linuxtogo.org kernel.git master |
| 19:39.23 | WyrM | why don't you use linus tree? is there anything you are currently using on linuxtogo.org tree? |
| 19:39.49 | tmzt | no, how difficult is in to follow upstream? I don't know git very well |
| 19:40.15 | WyrM | its easy. |
| 19:40.37 | tmzt | and you have just the pcap patch for that tree? |
| 19:40.51 | tmzt | just drivers/mfd/ezx-pcap.* |
| 19:40.56 | WyrM | no, all our tree is based on linus tree. |
| 19:41.36 | tmzt | ok, I can pull your tree and bring over my machine then? you are using mach-pxa or mach-ezx? |
| 19:41.46 | WyrM | mach-pxa. |
| 19:41.50 | tmzt | ok |
| 19:42.09 | tmzt | where do I get topgit, not in ubuntu that I can find |
| 19:42.11 | WyrM | yeah, you can use openezx tree too, I update from linux almost every day |
| 19:42.37 | WyrM | git-clone git://repo.or.cz/topgit.git |
| 19:44.19 | WyrM | after installing topgit and cloning from our tree you need to 'tg remote --populate origin && git-checkout ezx/current' |
| 19:45.48 | WyrM | you can get a picture of our tree layout with 'tg summary --graphviz | dot -Tpng -o topgit-layout.png' |
| 19:46.13 | WyrM | and any of our patches with 'tg patch <patch>' |
| 19:48.48 | tmzt | ok, where is your tree manaaged with tg? and what do I do to clone/checkout? |
| 19:56.00 | WyrM | git-clone git://git.openezx.org/openezx.git |
| 19:56.17 | WyrM | tg remote --populate origin |
| 19:56.24 | WyrM | git-checkout ezx/current |
| 19:57.47 | WyrM | also, it may be a good idea to start your work as a topgit branch. |
| 19:58.50 | WyrM | so, before migrating your code, 'tg create <patch_name> ezx/current>' |
| 19:59.06 | WyrM | s/>'/'/ |
| 20:00.29 | *** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 20:00.53 | WyrM | if you want your tree to depend on OpenEZX, or you can 'tg create <patch> master' if you want to base it on linus tree. |
| 20:01.38 | WyrM | topgit is easy, you will get it fast :) |
| 20:01.40 | tmzt | well, for pcap I think I need to base it on openezx |
| 20:02.18 | WyrM | you can base it on pcap only with 'tg create <patch> ezx/pcap' :) |
| 20:02.37 | tmzt | ok, I'll try that |
| 20:02.55 | tmzt | clearing some space on an e2 drive, moving stuff to the fat32 |
| 20:04.16 | tmzt | oh, the mmc doesn't appear to be on pcap, I can mount it with just pxa-mci and a gpio detect |
| 20:04.38 | WyrM | tmzt: not necessarily. |
| 20:04.40 | WyrM | :) |
| 20:05.20 | WyrM | eg, it is probably on PCAP, but wince left the voltage regulator to supply the voltage to the mmc and you used haret. |
| 20:05.30 | tmzt | oh, right |
| 20:05.34 | WyrM | pcap is used to supply power to the card, nothing else. |
| 20:05.56 | tmzt | was just looking at the pcap driver and saw it mentioned mmc |
| 20:06.14 | WyrM | is q9 slot hot-pluggable? |
| 20:06.35 | tmzt | I don't have q9, I have q |
| 20:06.38 | WyrM | s/q9/motoq/ |
| 20:07.02 | tmzt | as in you can remove the card with the machine on? |
| 20:07.07 | WyrM | yes |
| 20:07.09 | tmzt | yes |
| 20:07.37 | tmzt | it should 0 the vdd when the card is ejected? |
| 20:07.54 | WyrM | on ezx it does. |
| 20:08.04 | tmzt | over ssp? |
| 20:08.19 | WyrM | also, you can trace spi with haret to get what voltage regulator is used for mmc. |
| 20:08.29 | WyrM | yes, via ssp/spi to pcap. |
| 20:09.00 | tmzt | ok, I don't think I have gpio1 for pcap, not sure of cs |
| 20:09.15 | WyrM | CS we found the other day. |
| 20:09.25 | WyrM | let me seach the logs. |
| 20:09.38 | tmzt | also, I changed GPIO_IRQ1 to gpio_to_irq(1), is that right? |
| 20:09.58 | WyrM | don't care about irq yet, we can generate some irqs once I/O is working. |
| 20:10.06 | WyrM | yes, it is ok. |
| 20:12.13 | WyrM | 28 is your cs |
| 20:13.38 | WyrM | and probably 26 is your rxd. |
| 20:17.15 | WyrM | http://purl.rikers.org/%23openezx/20081023.html.gz |
| 20:27.24 | *** join/#openezx borman999 (n=quassel@ppp91-78-173-185.pppoe.mtu-net.ru) |
| 20:28.06 | *** join/#openezx yansa (n=yans@89.108.243.227) |
| 20:29.37 | borman999 | can anybody help me to understand the way ezx framebuffer driver works? |
| 20:29.49 | WyrM | sure. |
| 20:29.59 | WyrM | on ezx 2.4 kernel you mean? |
| 20:30.22 | borman999 | in general, but specifically for 2.4 |
| 20:30.38 | WyrM | what do you want to know? |
| 20:30.41 | WyrM | pixel format? |
| 20:30.53 | borman999 | i don't see, at what moment data is writeen to device itsel |
| 20:31.03 | borman999 | yes, pixel format |
| 20:31.30 | WyrM | pixel format is 18bpp packed, rgb666. |
| 20:31.57 | WyrM | data is written to fb memory, the pxafb controller handles writing to the fb device. |
| 20:31.58 | borman999 | i know that and i'd like to change it |
| 20:32.09 | WyrM | there is no way to change it. |
| 20:32.19 | WyrM | it depends on the hardware connection. |
| 20:32.25 | borman999 | that's bad |
| 20:33.05 | WyrM | qtopia is not working with 18bpp? |
| 20:33.17 | borman999 | but it's possible to switch to the format used in 2.6 kernel, isn't it? |
| 20:33.23 | borman999 | it's working |
| 20:33.45 | borman999 | but default scheme 3-bytes-per-pixel is too uncomfortable to read |
| 20:34.00 | WyrM | the format used on the 2.6 kernel is almost the same. what changes is what the kernel reports being the bits_per_pixel. |
| 20:34.10 | borman999 | and it's perhaps too slow |
| 20:34.29 | WyrM | and the fact that on 2.6 we currently use unpacked format. |
| 20:34.34 | borman999 | ok, what should i change to make it like 2.6? |
| 20:34.55 | WyrM | in fact, packed format is more efficient than unpacked. with unpacked a lot of memory is wasted. |
| 20:35.36 | WyrM | let me see the code, I don't remember it. |
| 20:35.38 | borman999 | hmm |
| 20:36.23 | borman999 | and is lcd bus bandwidth the cause of efficiency loss? |
| 20:37.08 | WyrM | generally what causes poor performance with packed mode is converting between pixel formats; |
| 20:37.32 | WyrM | your userspace is probably using 24 or 16 bit color depth, and you have to convert it. |
| 20:37.42 | borman999 | and what causes low performance with unpacked format? |
| 20:37.56 | WyrM | this conversion is more cpu expensive if you use the packed format. |
| 20:38.20 | borman999 | (i don't know the hardware details) |
| 20:38.29 | WyrM | on the other side, unpacked will use more bus and more video memory. |
| 20:39.06 | borman999 | <WyrM> in fact, packed format is more efficient than unpacked. with unpacked a lot of memory is wasted. |
| 20:39.06 | borman999 | <WyrM> let me see the code, I don't remember it. |
| 20:39.06 | borman999 | <borman999> hmm |
| 20:39.06 | borman999 | <borman999> and is lcd bus bandwidth the cause of efficiency loss? |
| 20:39.06 | borman999 | <WyrM> generally what causes poor performance with packed mode is converting between pixel formats; |
| 20:39.07 | borman999 | <WyrM> your userspace is probably using 24 or 16 bit color depth, and you have to convert it. |
| 20:39.09 | borman999 | <borman999> and what causes low performance with unpacked format? |
| 20:39.11 | borman999 | <WyrM> this conversion is more cpu expensive if you use the packed format. |
| 20:39.13 | borman999 | <borman999> (i don't know the hardware details) |
| 20:39.15 | borman999 | <WyrM> on the other side, unpacked will use more bus and more video memory. |
| 20:39.17 | borman999 | oops |
| 20:39.19 | WyrM | ? |
| 20:39.20 | WyrM | :) |
| 20:39.33 | borman999 | missed a key :-[ |
| 20:43.28 | WyrM | about what is needed to change 2.4 kernel to unpacked: LCCR3, instead of LCCR3_18BPP_P(6 << 24) you use LCCR3_18BPP(5 << 24) |
| 20:43.59 | WyrM | but note that the original motorola userspace will not work if you do this change to the kernel code. |
| 20:44.55 | WyrM | it will have wrong colors, and will be squeezed to the superior/left side of the screen. so you may not want to change it :) |
| 20:45.26 | WyrM | or it will not work at all, I never tested this. |
| 20:46.09 | borman999 | thanks, i'll think what to do with it ;-) |
| 20:55.57 | *** join/#openezx yansa (n=yans@89.108.200.4) |
| 21:19.16 | tmzt | WyrM: it checked out? was it supposed to do that before tg? |
| 21:25.19 | WyrM | tmzt: yes, it will automatically checkout master |
| 21:25.31 | WyrM | now tg remote --populate origin |
| 21:25.38 | WyrM | and git checkout ezx/current |
| 21:26.39 | tmzt | ok, for creating a tg patch, I wan ezx/pcap or ezx/pcap_ts or ezx/mach/pcap ? |
| 21:27.23 | WyrM | just ezx/pcap |
| 21:27.37 | WyrM | git checkout ezx/pcap |
| 21:27.46 | WyrM | and tg create <your patch name |
| 21:28.00 | tmzt | tg: Creating motoq base from ezx/pcap... |
| 21:28.00 | tmzt | Switched to a new branch "motoq" |
| 21:28.00 | tmzt | tg: Topic branch motoq set up. Please fill .topmsg now and make initial commit. |
| 21:28.00 | tmzt | tg: To abort: git rm -f .top* && git checkout ezx/pcap && tg delete motoq |
| 21:28.09 | WyrM | good |
| 21:28.10 | tmzt | I want to go back to ezx/pcap |
| 21:28.22 | tmzt | no |
| 21:28.35 | WyrM | its on pcap. |
| 21:28.44 | WyrM | cat .topdeps |
| 21:28.57 | WyrM | it should contain only ezx/pcap if you created it on top of pcap. |
| 21:29.01 | tmzt | yes |
| 21:29.12 | tmzt | I checkout ezx/current, so I wasn't sure |
| 21:29.22 | WyrM | then its ok, tg create <name> <parent> |
| 21:29.37 | tmzt | I did |
| 21:29.53 | tmzt | tg create motoq ezx/pcap |
| 21:30.04 | tmzt | that's when I got to that message |
| 21:30.33 | tmzt | ok, so I put in the machine file (motoq.c) |
| 21:30.40 | tmzt | and change Kconfig/Makefile |
| 21:30.51 | tmzt | then git add arch/arm/mach-pxa/motoq.c |
| 21:30.56 | tmzt | git commit |
| 21:30.57 | tmzt | ? |
| 21:33.15 | ao2 | tmzt, just after you create a new tg brach is sane to do "git add .topdeps .topmms && git commit" |
| 21:34.29 | WyrM | and git add Kconfig Makefile |
| 21:34.36 | WyrM | before commit |
| 21:35.04 | tmzt | those are ignored |
| 21:35.10 | ao2 | s/.topmms/.topmsg/ |
| 22:03.39 | *** join/#openezx neolynx (n=u@32-123-204-62-pool.dsl.fcom.ch) |
| 22:17.15 | tmzt | WyrM: looks like it's building |
| 22:31.47 | tmzt | In file included from arch/arm/mach-pxa/gpio.c:24: |
| 22:31.47 | tmzt | arch/arm/mach-pxa/include/mach/pxa2xx-gpio.h:4:2: warning: #warning Please use mfp-pxa2[57]x.h instead of pxa2xx-gpio.h |
| 22:31.59 | WyrM | ignore |
| 22:32.26 | WyrM | hum.. |
| 22:32.47 | tmzt | I thought it was in my includes, I was really suprised |
| 22:33.04 | tmzt | yesterday I got redifines on most of the gpios/pins |
| 22:33.19 | tmzt | with 2.6.26-rc9 and mfd/ezx-pcap |
| 22:42.22 | tmzt | In file included from arch/arm/mach-pxa/gpio.c:24: |
| 22:42.22 | tmzt | arch/arm/mach-pxa/include/mach/pxa2xx-gpio.h:4:2: warning: #warning Please use mfp-pxa2[57]x.h instead of pxa2xx-gpio.h |
| 22:42.25 | tmzt | no |
| 22:42.38 | tmzt | /opt/arm-2008q1/bin/arm-none-eabi-ld: no machine record defined |
| 22:42.38 | tmzt | make: *** [.tmp_vmlinux1] Error 1 |
| 22:42.54 | tmzt | I added it to arch/arm/tools/mach-types but it still says it |
| 22:43.58 | WyrM | and have you compiled motoq.c? |
| 22:44.09 | WyrM | looks like no, missing on Kconfig or makefile? |
| 22:44.15 | tmzt | dosnn't look like it |
| 22:44.33 | tmzt | I had ARCH not MACH |
| 22:44.44 | WyrM | happens :) |
| 22:45.35 | tmzt | didn't think it could be that easy |
| 22:45.53 | tmzt | motoq.c errors now, as expected |
| 23:17.44 | tmzt | won't boot debian now |
| 23:20.50 | WyrM | ? |
| 23:21.02 | WyrM | your rootfs you mean? |
| 23:21.09 | WyrM | doesn't mount it? |
| 23:21.16 | tmzt | yeah |
| 23:21.27 | WyrM | what error? |
| 23:21.49 | tmzt | I'm using initramfs with a rootdelay option, mounts root= from cmdline, then switches to it |
| 23:22.02 | tmzt | can't execute /init trying defaults |
| 23:22.32 | tmzt | it worked before, I could boot right into root: prompt in debian |
| 23:22.34 | tmzt | armel |
| 23:22.57 | WyrM | review the .config file. |
| 23:23.26 | tmzt | AEABI and OABI_COMPAT are set |
| 23:23.32 | tmzt | mmc is detected p1 p2 |
| 23:23.35 | tmzt | root is mounted |
| 23:23.51 | tmzt | then that /init error, which I think is from a script in the initramfs |
| 23:24.01 | tmzt | it's ezx_defconfig mostly |
| 23:25.08 | tmzt | I might have messed something else when I tried to remove the journal, since I didn't build ext3 |
| 23:25.15 | WyrM | why are you using initramfs if you can use the sd card? |
| 23:25.44 | tmzt | is there a delay before mounting? |
| 23:26.04 | WyrM | no need to delay with initramfs. |
| 23:26.10 | WyrM | there is a kernel commandline for it. |
| 23:26.56 | WyrM | I use: root=/dev/mmcblk0p2 rootfstype=ext2 rootdelay=3 |
| 23:26.58 | tmzt | what is that? |
| 23:27.04 | tmzt | ok |
| 23:30.32 | CIA-28 | Daniel Ribeiro <drwyrm@gmail.com> ezx/current * 06c8074d73 openezx/arch/arm/configs/ezx_defconfig: we need 3 seconds delay at least for a910 mmc |
| 23:36.44 | tmzt | ok, took out the initramfs and now get init v xx booting |
| 23:36.52 | tmzt | which has to be on the debian |
| 23:36.58 | tmzt | but it still freezes |
| 23:37.10 | WyrM | what is the last message? |
| 23:37.16 | WyrM | freeing init memory? |
| 23:37.19 | tmzt | text input doesn't enter either |
| 23:37.36 | tmzt | init version 2.86 booting |
| 23:38.00 | WyrM | check your .config for cpufreq. |
| 23:38.09 | WyrM | and add it in case you haven't. |
| 23:39.08 | WyrM | CONFIG_CPU_IDLE is the important config IIRC. |
| 23:40.14 | WyrM | my rootfs freezes without it. on "freeing init memory". |
| 23:44.13 | tmzt | ok |
| 23:44.15 | tmzt | booting |
| 23:44.22 | tmzt | root: |
| 23:44.31 | WyrM | good. |
| 23:44.41 | WyrM | now check dmesg, for pcap errors :) |
| 23:45.43 | WyrM | and fix it. (check gpio configuration, and pcap_platform_data.config (try CS_INVERTED too)). |
| 23:45.48 | tmzt | well, stuff under /sys/bus/spi/devices/spi1.0/ |
| 23:46.16 | WyrM | add some debug printks on ezx_pcap_read and ezx_pcap_write |
| 23:46.33 | WyrM | to dump the values, it's the only way to assert the driver is working. |
| 23:47.24 | tmzt | don't anything in dmesg about pcap, but I can only see the bottom half of it |
| 23:47.37 | tmzt | need to map some more keys |
| 23:47.52 | tmzt | and fix fb timings with the ones from ce |
| 23:57.17 | WyrM | won't dmesg | less work? :) |
| 23:57.43 | tmzt | I need a second-level keymap on RIGHT_ALT |
