| 00:00.11 | tmzt | yes, same url |
| 00:00.17 | tmzt | I checked, channel names are there |
| 00:01.50 | tmzt | ok, I will have to upload the htc-hw |
| 00:02.50 | tmzt | gsm commands should be standard, any linux gsm howto should have them |
| 00:03.00 | cr2 | i can't check right now, because i need to dismantle the nc10 and loose the inet link |
| 00:03.15 | cr2 | i have them from nc10 |
| 00:03.55 | tmzt | that should work |
| 00:03.55 | cr2 | but since it's cdc_acm there, it uses only 1 channel for cmd/data |
| 00:03.58 | tmzt | should be the same commands |
| 00:04.00 | cr2 | nc10 runs debian |
| 00:04.15 | cr2 | yeds, but still not exactly the same script. |
| 00:04.22 | tmzt | pon? |
| 00:04.41 | cr2 | pon is more or less direct pppd call |
| 00:04.46 | tmzt | why not? |
| 00:05.02 | tmzt | check the chat line in peers |
| 00:05.50 | tmzt | the only difference seems to be the AT commands are on one channel, ppp is on another |
| 00:06.07 | tmzt | but the same commands |
| 00:06.59 | cr2 | yes, i hope pppd would have been smart enough to support split channels |
| 00:08.19 | tmzt | I'm not getting it |
| 00:09.01 | tmzt | ppp isn't really involved in AT, it just allows to connect script to use the same tty |
| 00:09.29 | cr2 | pon calls 'pppd call $foobar_provider |
| 00:09.56 | tmzt | yes, so look in /etc/ppp/peers/ |
| 00:10.03 | cr2 | and in /etc/ppp/peers/$foobar_provider you can specify only 1 serial port |
| 00:10.05 | cr2 | afaik. |
| 00:10.35 | tmzt | after AT echoes I do: |
| 00:10.54 | tmzt | pppd /dev/smd1 noauth local |
| 00:11.02 | tmzt | that's all |
| 00:11.04 | cr2 | ok. |
| 00:11.26 | cr2 | i'll try it tomorrow. it's 2:10 here. |
| 00:11.30 | cr2 | good night |
| 00:13.59 | *** join/#htc-linux StarLite (n=nnscript@swaneng.xs4all.nl) |
| 00:21.24 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 00:25.51 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 00:29.02 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 00:35.03 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 00:39.43 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 00:42.54 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 00:46.35 | *** join/#htc-linux StarLite` (n=nnscript@swaneng.xs4all.nl) |
| 00:50.46 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 00:54.20 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 00:57.38 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 01:10.48 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 01:20.05 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 01:23.16 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 01:24.06 | *** join/#htc-linux StarLite (n=nnscript@swaneng.xs4all.nl) |
| 01:28.17 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 01:34.22 | *** join/#htc-linux onlysoaa (n=onlysoaa@dsl-142-148.aei.ca) |
| 01:36.45 | onlysoaa | Hello guys... Any progress reports on Diamond and Raphael? The last commit on git was on April 26th... |
| 01:37.39 | tmzt | weel, cr2 is busy on it doing research |
| 01:37.56 | tmzt | madCoder-: |
| 01:38.21 | tmzt | maejrep I mean has been busy with other stuff |
| 01:38.31 | tmzt | which raph/diam? |
| 01:40.37 | onlysoaa | Well I have a DIAM500 specifically, and I suppose the DIAM100 has a higher priority. |
| 01:40.57 | onlysoaa | Although, DIAM100 progress might help with the DIAM500 port as well. |
| 01:41.13 | tmzt | diam500 is cdma? |
| 01:42.16 | onlysoaa | Yup it is. I'm guessing CDMA support would take a while, but it'd still be nice to hear about DIAM100 updates. |
| 01:42.23 | tmzt | maejrep has raph800 |
| 01:42.37 | tmzt | I have raph500 |
| 01:42.42 | tmzt | both cdma |
| 01:42.53 | onlysoaa | Ah, that's cool. :D |
| 01:43.01 | tmzt | not sure about updates |
| 01:43.12 | tmzt | mostly research right now |
| 01:43.18 | onlysoaa | Hmm... What's the current roadmap, if any? |
| 01:43.28 | tmzt | I do have something to test if you want |
| 01:43.34 | onlysoaa | Sure! :D |
| 01:43.41 | onlysoaa | Anything to get this done faster. |
| 01:43.51 | tmzt | should enable calling with no audio |
| 01:44.14 | tmzt | tinderbox.dev.gentoo.org |
| 01:44.15 | onlysoaa | Oh, on the CDMA network? |
| 01:44.29 | tmzt | tinderbox.dev.gentoo.org/embedded/linwizard |
| 01:44.35 | tmzt | latest msm- |
| 01:44.38 | tmzt | yes |
| 01:44.45 | tmzt | maybe sms as well |
| 01:45.01 | onlysoaa | Is it source or binary? |
| 01:45.11 | tmzt | binary |
| 01:45.16 | tmzt | stage3 |
| 01:45.43 | tmzt | extract to sd card under root on ext2/3 |
| 01:45.51 | tmzt | partition |
| 01:46.03 | onlysoaa | Oh, it's not Android? |
| 01:46.11 | onlysoaa | And there's no SD card in the DIAM500. |
| 01:46.18 | tmzt | I'm going to try to put this in wiki |
| 01:46.34 | tmzt | internal sd, but yeah, won't work |
| 01:46.42 | tmzt | needs loop |
| 01:47.14 | onlysoaa | Loop... Sorry, I'm a bit new to this. I did manage to compile my own kernel and boot Android though. |
| 01:48.48 | tmzt | cool |
| 01:48.55 | tmzt | loop is loopback fs |
| 01:49.12 | tmzt | not really an fs, it's a block device |
| 01:49.43 | tmzt | that's how android works actually |
| 01:51.27 | onlysoaa | Ahh. So your build won't work? |
| 01:52.03 | tmzt | not on diam |
| 01:52.26 | tmzt | since you can't partition the internal sd |
| 01:53.18 | onlysoaa | I see... Thanks for informing me though! |
| 01:53.28 | onlysoaa | Do calls and sms work on your phone? |
| 01:54.26 | tmzt | I've only tried making calls |
| 01:54.41 | tmzt | there's something else, hold on |
| 01:54.59 | onlysoaa | Kk. |
| 01:57.34 | *** join/#htc-linux StarLite` (n=nnscript@swaneng.xs4all.nl) |
| 01:57.36 | *** join/#htc-linux fnord_ (n=fnord@24-151-90-116.static.nwtn.ct.charter.com) |
| 01:57.37 | tmzt | root=/dev/loop |
| 01:58.25 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 02:02.44 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 02:04.42 | tmzt | looproot=/dev/mmcblk0:giz.img |
| 02:04.57 | tmzt | ok, this should work |
| 02:05.29 | tmzt | people.openezx.org/tmzt/initfs.img |
| 02:05.58 | tmzt | did you put android in tmp on internal sd? |
| 02:09.09 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 02:11.27 | tmzt | onlysoaa: get that? |
| 02:13.10 | tmzt | copy zImage haret and default.txt to a folder giz on internal card |
| 02:13.21 | tmzt | from android |
| 02:13.47 | tmzt | put that initfs.img in that folder |
| 02:14.03 | tmzt | change default.txt |
| 02:14.20 | tmzt | set INITRD initfs.img |
| 02:15.30 | tmzt | set CMDLINE "root=/dev/loop looproot=/dev/mmcblk0:/giz/giz.img |
| 02:15.44 | tmzt | set CMDLINE "root=/dev/loop looproot=/dev/mmcblk0:/giz/giz.img rootdelay=7" |
| 02:16.01 | tmzt | use diam500 MTYPE |
| 02:16.31 | tmzt | then, make a folder on linux pc |
| 02:16.52 | tmzt | extract the msm tar.bz2 into it AS ROOT |
| 02:17.02 | tmzt | touch dev/* |
| 02:17.12 | tmzt | cd .. |
| 02:17.30 | tmzt | du -hs thefolder |
| 02:18.18 | tmzt | dd if=/dev/zero of=giz.img bs=8M count=32 |
| 02:18.30 | tmzt | mke2fs -j giz.img |
| 02:18.40 | tmzt | mkdir mnt |
| 02:18.56 | tmzt | mount -o loop giz.img mnt |
| 02:19.12 | tmzt | cp -a thefolder/* mnt/ |
| 02:19.20 | tmzt | as ROOT |
| 02:19.29 | tmzt | umount mnt |
| 02:20.00 | tmzt | copy giz.img to internal sd folder giz |
| 02:20.06 | tmzt | run haret |
| 02:20.15 | tmzt | boot linux |
| 02:20.29 | onlysoaa | Ahh! Sorry, I got distracted. I'll test it out later, since I'm on Windows right now. |
| 02:20.36 | tmzt | if that works, just tmzt: ping |
| 02:20.37 | onlysoaa | Thanks for the guide. (: |
| 02:20.46 | onlysoaa | Alright. |
| 02:20.53 | tmzt | ok, log are at irclog.netripper.com |
| 02:21.39 | tmzt | you can test the first part from windows |
| 02:26.17 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 02:29.46 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 02:33.15 | *** join/#htc-linux AndIrc (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 02:36.44 | *** join/#htc-linux AndIrc (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 02:41.22 | *** join/#htc-linux StarLite (n=nnscript@swaneng.xs4all.nl) |
| 02:47.43 | *** join/#htc-linux AndIrc (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 02:50.54 | *** join/#htc-linux AndIrc (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 03:02.15 | *** join/#htc-linux AndIrc (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 03:05.31 | *** join/#htc-linux AndIrc (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 03:08.57 | *** join/#htc-linux AndIrc (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 03:09.06 | *** join/#htc-linux mrmoku|a` (n=mrmoku@ppp-93-104-102-52.dynamic.mnet-online.de) |
| 03:12.24 | *** join/#htc-linux AndIrc (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 03:19.51 | *** join/#htc-linux AndIrc (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 03:24.18 | *** join/#htc-linux AndIrc (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 03:27.49 | *** join/#htc-linux AndIrc (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 03:32.14 | *** join/#htc-linux AndIrc (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 03:37.02 | *** join/#htc-linux StarLite` (n=nnscript@swaneng.xs4all.nl) |
| 04:05.08 | *** join/#htc-linux Shinto (n=John@f048131111.adsl.alicedsl.de) |
| 04:20.47 | *** join/#htc-linux StarLite (n=nnscript@swaneng.xs4all.nl) |
| 04:51.54 | par | [12:23] <parano|a> don't talk, don't kill anyone, CENTRAL INTELLIGENCE |
| 04:51.57 | par | ahaahahhahha |
| 04:52.09 | par | earned youe name m8 |
| 04:58.27 | *** join/#htc-linux droid0011 (n=mc@p4FDCE2EE.dip.t-dialin.net) |
| 05:04.55 | *** join/#htc-linux StarLite` (n=nnscript@swaneng.xs4all.nl) |
| 05:31.48 | *** join/#htc-linux dzo (n=dzo@121-98-128-127.bitstream.orcon.net.nz) |
| 05:42.16 | *** join/#htc-linux StarLite (n=nnscript@swaneng.xs4all.nl) |
| 06:24.46 | *** join/#htc-linux goxboxlive (n=goxboxli@211.80-202-134.nextgentel.com) |
| 06:32.58 | *** join/#htc-linux StarLite` (n=nnscript@swaneng.xs4all.nl) |
| 06:51.13 | *** join/#htc-linux StarLite (n=nnscript@swaneng.xs4all.nl) |
| 06:52.38 | *** join/#htc-linux timebomb (n=tb@g224064249.adsl.alicedsl.de) |
| 07:02.56 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 07:12.10 | *** join/#htc-linux StarLite` (n=nnscript@swaneng.xs4all.nl) |
| 07:34.22 | *** join/#htc-linux StarLite (n=nnscript@swaneng.xs4all.nl) |
| 07:36.28 | Jos | anyone here ever opened his/hers HTC Touch HD ? |
| 07:36.36 | Jos | Can't get the hooks apart |
| 07:36.36 | Jos | http://lithium.flauw.net/foto/uploads/aae84cdd825cdfd0cc6189507ffb813f.png |
| 07:45.08 | *** join/#htc-linux StarLite` (n=nnscript@swaneng.xs4all.nl) |
| 08:01.08 | tmzt | try #xda-devs |
| 08:03.54 | *** join/#htc-linux Chicago (n=Chicago@c-98-223-72-235.hsd1.in.comcast.net) |
| 08:06.35 | *** join/#htc-linux pH5 (n=ph5@p5485FD50.dip.t-dialin.net) |
| 08:33.40 | *** join/#htc-linux StarLite (n=nnscript@swaneng.xs4all.nl) |
| 08:39.23 | *** join/#htc-linux StarLite` (n=nnscript@swaneng.xs4all.nl) |
| 08:42.19 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d8744aa.pool.einsundeins.de) |
| 08:44.33 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
| 08:45.04 | *** join/#htc-linux timebomb (n=tb@g224064249.adsl.alicedsl.de) |
| 09:20.55 | *** join/#htc-linux exception13 (n=exceptio@testdrive.kgts.ru) |
| 09:24.08 | *** join/#htc-linux skodde (n=skodde@unaffiliated/skodde) |
| 09:28.45 | *** join/#htc-linux StarLite (n=nnscript@swaneng.xs4all.nl) |
| 09:32.45 | *** join/#htc-linux ltxda (n=anon@unaffiliated/ltxda) |
| 09:53.40 | *** join/#htc-linux StarLite` (n=nnscript@swaneng.xs4all.nl) |
| 09:55.33 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
| 10:13.39 | *** join/#htc-linux StarLite (n=nnscript@swaneng.xs4all.nl) |
| 10:15.56 | *** join/#htc-linux hollo (n=hollo@3e6b7b2c.rev.stofanet.dk) |
| 10:51.57 | *** join/#htc-linux nebi_ (n=nebi@user-387g3pr.cable.mindspring.com) |
| 11:06.31 | *** join/#htc-linux nebi- (n=nebi@ip67-152-3-162.z3-152-67.customer.algx.net) |
| 11:10.35 | *** join/#htc-linux MLM (n=mlvdmeid@meide.xs4all.nl) |
| 11:19.14 | *** join/#htc-linux StarLite (n=nnscript@swaneng.xs4all.nl) |
| 11:43.59 | *** join/#htc-linux StarLite` (n=nnscript@swaneng.xs4all.nl) |
| 12:05.56 | *** join/#htc-linux nebi- (n=nebi@ip67-152-3-162.z3-152-67.customer.algx.net) |
| 12:11.16 | *** join/#htc-linux zycho (n=zycho@dslb-088-070-062-141.pools.arcor-ip.net) |
| 12:13.46 | *** join/#htc-linux StarLite (n=nnscript@swaneng.xs4all.nl) |
| 12:27.14 | *** join/#htc-linux cr2 (n=cr2@ip-77-25-127-161.web.vodafone.de) |
| 12:29.22 | cr2 | tmzt: umts works as expected for me with the "stream" patch. don't know why everybody is so lazy just to check it ;) |
| 12:29.35 | tmzt | yay |
| 12:29.46 | tmzt | we need to tell mickey|zzZZzz he's in the other channel |
| 12:29.56 | cr2 | ping mickey|zzZZzz |
| 12:30.00 | cr2 | ~ping mickey|zzZZzz |
| 12:30.01 | apt | pong mickey|zzZZzz |
| 12:30.07 | tmzt | he's on a different client |
| 12:30.29 | cr2 | ok |
| 12:31.15 | *** join/#htc-linux mickey|F9N (n=M@p57929CBF.dip.t-dialin.net) |
| 12:31.18 | mickey|F9N | hi guys |
| 12:31.31 | cr2 | hi mickey|F9N |
| 12:32.02 | mickey|F9N | yo cr2 |
| 12:32.07 | mickey|F9N | tmzt just updated me |
| 12:32.09 | cr2 | mickey|F9N: i've just tested umts, and it works. with the kernel patch that declares all smd channels "stream" |
| 12:32.09 | mickey|F9N | congrats, man |
| 12:32.14 | cr2 | :) |
| 12:32.15 | mickey|F9N | great |
| 12:32.21 | mickey|F9N | can't wait to come back home to test |
| 12:32.24 | mickey|F9N | (I'm on a conference) |
| 12:32.27 | mickey|F9N | please commit :) |
| 12:32.27 | cr2 | ok |
| 12:37.35 | tmzt | cr2: I found a OOPS and put it through ksymoops, but I have no idea what to do with it |
| 12:38.00 | tmzt | this is ppp_asynctty_receive and has constantly been braking ppp for me |
| 12:40.48 | cr2 | we need maejrep for that |
| 12:40.51 | *** join/#htc-linux StarLite` (n=nnscript@swaneng.xs4all.nl) |
| 12:41.04 | tmzt | ah |
| 12:41.11 | tmzt | what about rpc? |
| 12:41.30 | cr2 | the raph[58]00 smd is a bit different |
| 12:41.40 | cr2 | which rpc ? |
| 12:41.49 | tmzt | audio |
| 12:42.09 | tmzt | I mean did you find how to dump/trace rpc's in that smem.bin? |
| 12:43.02 | cr2 | yes, they look very similar to vogue |
| 12:43.35 | tmzt | I should paste the htc-hw changes, I'm not sure how to get them out of git though |
| 12:43.37 | cr2 | first we need to patch the AMSS version, and compile the qdsp+rpc |
| 12:43.46 | cr2 | git diff |
| 12:43.49 | tmzt | it's git diff master |
| 12:44.02 | tmzt | yeah, I committed them locally to keep some changes seperated |
| 12:44.30 | cr2 | i'm not a git expert :) |
| 12:44.47 | *** join/#htc-linux marmotta (n=skodde@unaffiliated/skodde) |
| 12:44.47 | tmzt | I think I can just use the two sha1's |
| 12:45.17 | cr2 | that's why i prefer when somebody else will commit the patches |
| 12:45.17 | tmzt | yes, that worked |
| 12:49.02 | tmzt | cr2: people.openezx.org/tmzt/git-diff-htchw-1.diff |
| 12:49.47 | tmzt | cr2: people.openezx.org/tmzt/git-diff-audioparams-1.diff |
| 12:50.00 | tmzt | the top one is current |
| 12:50.20 | tmzt | you also need AudioParams.c which is for raph500/800 |
| 12:50.29 | tmzt | or you have to convert your own |
| 12:51.03 | cr2 | http://people.openezx.org/tmzt/git-diff-htchw-1.diff |
| 12:51.19 | tmzt | yes |
| 12:51.33 | tmzt | the other one I posted before but I forgot |
| 12:52.21 | cr2 | did you check if the params match with the wince values ? |
| 12:52.24 | tmzt | it uses the same values as dzo's vogue-hw but different sysfs directory |
| 12:52.30 | tmzt | which? |
| 12:52.38 | cr2 | i guess we will need if if booted standalone |
| 12:52.57 | tmzt | the AudioParams.c has the values from AudioPara3.csv |
| 12:52.59 | cr2 | otherwise they are already there. |
| 12:53.29 | cr2 | i think the best solution will be to have it as a firmware loader. |
| 12:53.37 | cr2 | it's more or less firmware after all |
| 12:53.50 | cr2 | we have the same problem with tiacx |
| 12:56.04 | cr2 | i was not be able to trigger the UPDATE_AUDIO dex |
| 12:56.17 | cr2 | only seen it in the wavedev.dll |
| 12:56.55 | cr2 | http://people.openezx.org/tmzt/git-diff-audioparams-1.diff |
| 12:57.06 | cr2 | sometimes i hate firefox |
| 12:58.19 | cr2 | ok, you don't deal with the rpc side |
| 13:07.26 | cr2 | tmzt: wtf is HTC 4G ? |
| 13:10.09 | tmzt | a version of HD I think |
| 13:10.20 | cr2 | ok |
| 13:10.41 | tmzt | not sure if it's wimax or something else, but it's for one isp in one country I think |
| 13:11.44 | cr2 | ok |
| 13:20.11 | *** part/#htc-linux exception13 (n=exceptio@testdrive.kgts.ru) |
| 13:22.29 | *** join/#htc-linux exception13 (n=exceptio@testdrive.kgts.ru) |
| 13:23.07 | cr2 | tmzt: btw, do we know how to create diag.nbh for raph ? |
| 13:23.33 | tmzt | maybe, we were working on that in #xda-devs |
| 13:23.39 | tmzt | with hspl it's not signed |
| 13:23.53 | cr2 | haretless boot is a nice to have. |
| 13:24.02 | tmzt | and linux kernel with a small prefix should work in place of xip.bin |
| 13:24.32 | cr2 | yes, that's the idea. tags+zimage like on haret |
| 13:24.54 | tmzt | can you look at the asm on my account? |
| 13:24.59 | tmzt | I think it's bad |
| 13:25.25 | cr2 | which asm ? |
| 13:25.29 | tmzt | but that's what it's supposed to be, set mtype and atags |
| 13:25.35 | tmzt | .S file? |
| 13:25.53 | tmzt | testbooter.S |
| 13:26.07 | cr2 | write in C like haret, dump and copypaste it. |
| 13:26.18 | tmzt | what? |
| 13:26.28 | cr2 | i've already added nand partition tags this way. |
| 13:26.35 | tmzt | well, I'm trying to learn the asm too |
| 13:26.40 | cr2 | ok |
| 13:27.03 | cr2 | now i've realized that i'm the only one who sees the nand partitions ;) |
| 13:27.07 | tmzt | I have tested it with qemu and it sets r1 or r7 |
| 13:27.13 | tmzt | yeah |
| 13:27.26 | tmzt | but I'm happy to boot from sd card partition |
| 13:27.53 | tmzt | people.openezx.org/tmzt/testbooter.S |
| 13:28.01 | cr2 | ok, but having a linux rom is nice too. |
| 13:28.15 | tmzt | yeah, once things work |
| 13:28.16 | cr2 | http://people.openezx.org/tmzt/testbooter.S |
| 13:28.22 | tmzt | yes |
| 13:28.48 | tmzt | I use a trick from linux kernel to make a ram arm binary from it |
| 13:28.53 | tmzt | raw |
| 13:29.02 | cr2 | compare it with the linload.exe hexdump |
| 13:29.10 | tmzt | where is that? |
| 13:29.34 | cr2 | haret source |
| 13:30.05 | tmzt | I've looked at haret, I thought linload was haret.exe with an embedded zImage/initrd |
| 13:30.07 | cr2 | i think it's more complex than your asm |
| 13:30.25 | cr2 | yes, but the tags are embedded too |
| 13:30.29 | tmzt | the idea is to have a prefix, data, then kernel |
| 13:30.38 | cr2 | so it's tags+zimage+initrd |
| 13:30.46 | tmzt | data will be machtype+tags |
| 13:31.00 | cr2 | ok |
| 13:32.10 | cr2 | i think .globl is a label/address, not just a forward declaration |
| 13:32.23 | tmzt | yeah, it's not neccessary I think |
| 13:32.36 | tmzt | but I strip everything anyway with objcopy |
| 13:32.41 | cr2 | well, i prefer raw asm :) |
| 13:32.51 | cr2 | i see. |
| 13:33.01 | tmzt | how do you assemble that? |
| 13:33.06 | cr2 | probably the assembler lets you to write more readable code. |
| 13:33.36 | cr2 | with 'as' to create .o |
| 13:33.53 | tmzt | yes, but that's not raw is it? |
| 13:33.53 | cr2 | and then you need to use 'ld' directly. |
| 13:34.31 | cr2 | hmm. with right ldscript it may be raw. |
| 13:34.53 | tmzt | I use something like objcopy -O binary -o testbooter.bin -R _start -R data -R machtype -R cmdline -R linux |
| 13:35.01 | tmzt | that creates a raw binary file |
| 13:35.03 | cr2 | did too much disassembling recently |
| 13:35.12 | cr2 | yes, that looks good. |
| 13:35.15 | tmzt | yeah, but I didn't learn ldscript syntax |
| 13:35.29 | cr2 | ok |
| 13:35.53 | tmzt | this works, objdump -b binary gives the same code back |
| 13:36.06 | tmzt | but I don't know the asm instructions to do what I want to do :) |
| 13:36.32 | tmzt | to setup the atags list etc. |
| 13:37.49 | tmzt | I have to look up ATAG_CORE and ATAG_MEM |
| 13:38.11 | tmzt | I see there's a fixup in the raph kernel, I guess we don't need ATAG_MEM? |
| 13:42.59 | tmzt | I just noticed something, I want the machtype in r1 but the address of the atags list in r2 |
| 13:43.07 | tmzt | it can't be the same instruction for both |
| 13:43.45 | cr2 | check the haret .asm |
| 13:43.57 | tmzt | ok, where is that? |
| 13:43.59 | cr2 | sorry, .S now |
| 13:44.35 | cr2 | src/wince/asmstuff.S |
| 13:46.22 | cr2 | and src/wince/kernelfiles.S |
| 13:46.55 | cr2 | wow, .incbin |
| 13:47.20 | tmzt | where is haret source now? |
| 13:48.01 | *** join/#htc-linux zycho (n=zycho@dslb-088-070-062-141.pools.arcor-ip.net) |
| 13:48.14 | cr2 | hh.org CVS |
| 13:48.25 | cr2 | and git.linuxtogo.org |
| 13:48.40 | tmzt | found it |
| 13:51.04 | tmzt | linboot.cpp |
| 14:00.45 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
| 14:01.14 | tmzt | well, that didn't help me much |
| 14:01.24 | tmzt | what did you want me to look at? |
| 14:03.18 | *** join/#htc-linux wdslbr (n=asa@dslb-088-069-204-014.pools.arcor-ip.net) |
| 14:05.04 | cr2 | mmu_trampoline |
| 14:05.40 | tmzt | yeah, but it just jumps to the preloader which is already loaded |
| 14:06.09 | cr2 | preloader is written in C |
| 14:06.15 | tmzt | where? |
| 14:06.23 | cr2 | linboot.cpp |
| 14:07.01 | tmzt | yeah, I don't see where it's defined/declared |
| 14:07.10 | cr2 | setup_linux_params |
| 14:07.54 | tmzt | yes, which is passed the location to put the tags |
| 14:08.24 | tmzt | I can see how to do it that way but I would need an ld script to get the _start to be 0 not 0800 or whatever it is |
| 14:14.15 | cr2 | prepare for blowing nand |
| 14:15.05 | tmzt | ? |
| 14:15.27 | tmzt | I can give you my partition table if that will help |
| 14:15.38 | cr2 | msm_nand_read_oob: unsupported ops->len, 512 |
| 14:15.39 | tmzt | not right now, but when the two devices are back in windows |
| 14:15.55 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 14:16.03 | cr2 | does it want 2048 ? |
| 14:16.18 | tmzt | no idea |
| 14:16.30 | tmzt | I guess it's not even though |
| 14:16.41 | tmzt | or the data blocks themselves are short |
| 14:16.45 | tmzt | you mean erase block? |
| 14:16.51 | tmzt | can you probe cfi? |
| 14:17.00 | cr2 | lol |
| 14:17.16 | cr2 | dd if=/dev/mtd0 bs=2048 | less |
| 14:17.29 | cr2 | �C@�@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ECEC��D��� |
| 14:17.39 | cr2 | looks good :) |
| 14:17.45 | tmzt | ?? |
| 14:17.52 | tmzt | oh, cool |
| 14:17.58 | tmzt | what's the data? |
| 14:18.03 | cr2 | Raphael SPL EVT@Shipped |
| 14:18.05 | tmzt | what's mtd0 |
| 14:18.18 | cr2 | it's the spl |
| 14:18.20 | cr2 | :) |
| 14:18.30 | tmzt | maybe no oob there |
| 14:18.40 | cr2 | hehe |
| 14:18.44 | cr2 | RUUNBH@@Upgrade ROM code error |
| 14:18.48 | tmzt | tfat? |
| 14:19.00 | cr2 | no, it's raw spl partition |
| 14:19.11 | cr2 | fat should be windows ? |
| 14:19.18 | cr2 | mtd4 ? |
| 14:19.24 | tmzt | yeah, I mean were you going to say you got the tfat partition |
| 14:19.35 | tmzt | I think there's imgfs is windows, tfat is data |
| 14:19.37 | cr2 | <PROTECTED> |
| 14:19.55 | tmzt | linux won't mount it readwrite, the two fats are different from each other |
| 14:19.59 | cr2 | MSFLSH50 |
| 14:20.02 | cr2 | on mtd5 |
| 14:20.02 | tmzt | it might work in msdos or readonly |
| 14:20.04 | tmzt | imgfs |
| 14:20.26 | cr2 | i don't know where is fat |
| 14:20.27 | tmzt | what we should replace with yaffs :) |
| 14:20.58 | cr2 | what to do with oob ? |
| 14:21.08 | tmzt | write a driver for it |
| 14:21.14 | cr2 | [ 342.050585] msm_nand_read_oob 2832800 d4a05800 800 00000000 0 |
| 14:21.15 | cr2 | [ 342.050921] status: c03030 ffff0008 c02030 ffff0008 c01030 ffff0008 c00030 ffff0008 |
| 14:21.15 | tmzt | I don't think it's important for ro though |
| 14:21.17 | cr2 | [ 342.050982] msm_nand_read_oob 2832800 800 0 failed -74, corrected 0 |
| 14:21.18 | cr2 | [ 393.229998] MTD_close |
| 14:21.25 | tmzt | except to skip bad blocks |
| 14:21.39 | cr2 | is it different from g1/g2 ?? |
| 14:21.45 | tmzt | that's probably android version |
| 14:21.47 | tmzt | don't know |
| 14:21.53 | tmzt | must be though |
| 14:21.54 | cr2 | well, we want rw of course. |
| 14:22.12 | cr2 | there is some bug #ifdef in the g1 code |
| 14:22.15 | tmzt | sure, but we want to use yaffs2 or jffs2 with it's own bbt |
| 14:22.16 | cr2 | looking for it. |
| 14:22.28 | cr2 | it's hw ecc |
| 14:22.39 | cr2 | g1 uses yaffs2 |
| 14:22.40 | tmzt | so it's the same |
| 14:22.56 | tmzt | maybe it's only part of the oob then |
| 14:23.01 | cr2 | i need to check for the bug |
| 14:23.04 | tmzt | how much is there? |
| 14:23.12 | cr2 | 512 blocks size needs to be fixed somewhere too |
| 14:23.22 | tmzt | what's the erase block? |
| 14:23.37 | tmzt | and what's the total block size with oob |
| 14:26.42 | cr2 | i'm looking for it |
| 14:32.40 | cr2 | hmm. where is it in the git... |
| 14:34.52 | cr2 | found |
| 14:35.07 | cr2 | tmzt: #if SUPPORT_WRONG_ECC_CONFIG |
| 14:35.20 | cr2 | <PROTECTED> |
| 14:35.47 | cr2 | 65 /** |
| 14:35.48 | cr2 | 66 * msm_nand_oob_64 - oob info for large (2KB) page |
| 14:35.49 | cr2 | 67 */ |
| 14:36.36 | cr2 | 68 static struct nand_ecclayout msm_nand_oob_64 = { |
| 14:36.38 | cr2 | 69 .eccbytes = 40, |
| 14:36.39 | cr2 | 70 .eccpos = { |
| 14:36.41 | cr2 | 71 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, |
| 14:36.42 | cr2 | 72 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, |
| 14:36.44 | cr2 | 73 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, |
| 14:36.45 | cr2 | 74 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, |
| 14:36.46 | cr2 | 75 }, |
| 14:36.48 | cr2 | 76 .oobavail = 16, |
| 14:36.50 | cr2 | 77 .oobfree = { |
| 14:36.51 | cr2 | 78 {30, 16}, |
| 14:36.53 | cr2 | 79 } |
| 14:36.54 | cr2 | 80 }; |
| 14:36.56 | cr2 | how can i verify it ? |
| 14:37.31 | cr2 | but first i'd like to know why it used 512byte block, and not 2K |
| 14:37.36 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 14:39.20 | tmzt | I think windows will use the 512byte block, with a 2048 erase block (for writing) and then oob for the erase block and each of the subblocks |
| 14:40.32 | cr2 | tmzt: it's g1 nand driver that complains about 512 |
| 14:41.20 | cr2 | i'm rebooting to check the dmesg again |
| 14:41.33 | tmzt | I guess linux driver is very generic |
| 14:41.47 | tmzt | I don't understand that pdata |
| 14:43.27 | *** join/#htc-linux timebomb (n=tb@80.187.147.37) |
| 14:45.55 | cr2 | <PROTECTED> |
| 14:46.10 | cr2 | [ 6.841021] Creating 6 MTD partitions on "msm_nand": |
| 14:46.11 | cr2 | [ 6.841235] 0x02400000-0x02480000 : "SPL" |
| 14:46.13 | cr2 | [ 6.841418] mtd: Giving out device 0 to SPL |
| 14:46.14 | cr2 | [ 6.841601] msm_nand_read_oob: unsupported ops->len, 68 |
| 14:46.52 | tmzt | 56? |
| 14:47.07 | cr2 | [ 6.984576] hsusb: IDLE -> ONLINE |
| 14:47.09 | cr2 | [ 6.991107] pc_clk_enable: FIXME! enabling a clock that doesn't have an ena |
| 14:47.10 | cr2 | bit or ns-only offset: 37 |
| 14:47.54 | cr2 | [ 7.451708] input: kionix-kxsd9 as /class/input/input3 |
| 14:48.15 | cr2 | [ 7.532885] pc_clk_enable: FIXME! enabling a clock that doesn't have an ena |
| 14:48.17 | cr2 | bit or ns-only offset: 22 |
| 14:49.17 | cr2 | [ 10.423846] msm_nand_read_oob: unsupported ops->len, 512 |
| 14:49.18 | cr2 | [ 10.437976] end_request: I/O error, dev mtdblock0, sector 0 |
| 14:50.46 | cr2 | 358 if (ops->datbuf != NULL && (ops->len % mtd->writesize) != 0) { |
| 14:50.47 | cr2 | 359 /* when ops->datbuf is NULL, ops->len may refer to ooblen */ |
| 14:50.49 | cr2 | 360 pr_err("%s: unsupported ops->len, %d\n", |
| 14:50.50 | cr2 | 361 __func__, ops->len); |
| 14:50.52 | cr2 | 362 return -EINVAL; |
| 14:51.19 | tmzt | ah |
| 14:51.32 | tmzt | '/* when ops->datbuf is NULL, ops->len may refer to ooblen */ |
| 14:51.41 | tmzt | otherwise it doesn't? |
| 14:52.16 | cr2 | ask google ;) |
| 14:52.20 | cr2 | 388 pr_info("msm_nand_read_oob %llx %p %x %p %x\n", |
| 14:52.21 | cr2 | 389 from, ops->datbuf, ops->len, ops->oobbuf, ops->ooblen); |
| 14:52.36 | tmzt | google? |
| 14:52.41 | tmzt | as in San? |
| 14:52.56 | cr2 | [16:21] <cr2> [ 342.050585] msm_nand_read_oob 2832800 d4a05800 800 00000000 0 |
| 14:52.58 | cr2 | [16:21] <cr2> [ 342.050921] status: c03030 ffff0008 c02030 ffff0008 c01030 ffff0008 c00030 ffff0008 |
| 14:52.59 | cr2 | [16:21] <cr2> [ 342.050982] msm_nand_read_oob 2832800 800 0 failed -74, corrected 0 |
| 14:53.01 | cr2 | [16:21] <cr2> [ 393.229998] MTD_close |
| 14:53.17 | cr2 | hehe. no author in the header |
| 14:53.28 | cr2 | 3 * Copyright (C) 2007 Google, Inc. |
| 14:53.32 | tmzt | who could it be? |
| 14:54.07 | cr2 | swetland ? |
| 14:54.25 | tmzt | possibly, I thought the stuff from then had names on it though |
| 14:55.04 | tmzt | are some of the developers at qualcomm now, the aurora thing? |
| 14:55.14 | cr2 | i can check the qcom tree |
| 14:56.27 | cr2 | yeah, it has a different driver ;) |
| 14:57.23 | cr2 | much more generic, and with onenand support |
| 14:57.57 | cr2 | [ 6.819140] nandid: 5501bcec maker ec device bc |
| 14:58.12 | tmzt | onenand is sd though isn't it? |
| 14:59.00 | cr2 | <PROTECTED> |
| 14:59.13 | cr2 | maybe, i'm not sure. |
| 14:59.29 | cr2 | but unlikely, since there is a special driver for it |
| 15:03.57 | cr2 | 1170 mtd->erasesize = mtd->writesize << 6; /* TODO: check */ |
| 15:04.40 | tmzt | how many blocks is that then? |
| 15:04.49 | cr2 | 1167 mtd->writesize = 2048; |
| 15:05.17 | cr2 | (ops->len % mtd->writesize) != 0 |
| 15:05.28 | cr2 | does it make sense ?? |
| 15:05.51 | tmzt | if it's not a multiple? |
| 15:05.56 | cr2 | yes |
| 15:05.59 | tmzt | seems big though, I get 131072 |
| 15:06.15 | cr2 | i mean ops->len |
| 15:06.18 | tmzt | but this works on g1? |
| 15:06.23 | tmzt | yean |
| 15:06.26 | cr2 | i think so |
| 15:06.29 | tmzt | I meant the other thing |
| 15:06.49 | tmzt | 128k? |
| 15:06.58 | cr2 | yes. |
| 15:07.02 | tmzt | that could be right |
| 15:07.03 | tmzt | ok |
| 15:07.47 | tmzt | so we need to know how much of the block is data |
| 15:07.55 | cr2 | <PROTECTED> |
| 15:08.06 | cr2 | <PROTECTED> |
| 15:08.15 | cr2 | but it's not exactly my chip |
| 15:08.27 | tmzt | is it in spl? |
| 15:09.24 | cr2 | qcom |
| 15:10.14 | cr2 | <PROTECTED> |
| 15:10.52 | tmzt | I mean your chip |
| 15:10.57 | cr2 | <PROTECTED> |
| 15:11.03 | cr2 | this is mine |
| 15:11.52 | tmzt | what are the fileds there? |
| 15:11.53 | cr2 | 64 is 0x40 |
| 15:12.05 | cr2 | i'm not 100% sure |
| 15:12.20 | tmzt | where is this from? url? |
| 15:12.33 | cr2 | http://wiki.xda-developers.com/index.php?pagename=MSM_NANDID |
| 15:13.08 | tmzt | blksiz = 0x800? |
| 15:13.25 | tmzt | 2048 |
| 15:13.26 | tmzt | ok |
| 15:13.51 | tmzt | 0x840 is plus oob? |
| 15:13.58 | tmzt | so 64 oob |
| 15:14.27 | cr2 | mtd->oobsize = msm_nand_oob_64.eccbytes + msm_nand_oob_64.oobavail; |
| 15:14.48 | tmzt | that makes sense, is the first field erase block?\ |
| 15:15.05 | tmzt | 4096? |
| 15:15.10 | tmzt | that's only two blocks |
| 15:15.10 | cr2 | 76 .oobavail = 16, |
| 15:15.20 | tmzt | which is hwecc? |
| 15:15.26 | cr2 | 69 .eccbytes = 40, |
| 15:15.39 | tmzt | yeah, 56 |
| 15:15.50 | cr2 | wtf ? |
| 15:16.02 | tmzt | what do you mean? |
| 15:16.18 | tmzt | ecc is fixed in the hardware |
| 15:16.41 | cr2 | ok, it's the same in qcom driver |
| 15:17.26 | tmzt | so there's 8 bytes which I think are used by the ftl or attributes or something |
| 15:17.47 | cr2 | 64bits ? |
| 15:18.07 | tmzt | 64=56 |
| 15:18.13 | tmzt | 64-56 |
| 15:18.19 | tmzt | 64-(40+16) |
| 15:19.47 | cr2 | ok |
| 15:23.05 | tmzt | those 8 bytes might be used for bbt, but I can't find which version is used on msm yet |
| 15:23.48 | cr2 | msm_nand_read(struct mtd_info *mtd, loff_t from, size_t len, |
| 15:23.49 | cr2 | <PROTECTED> |
| 15:23.56 | tmzt | file? |
| 15:23.56 | cr2 | <PROTECTED> |
| 15:24.05 | cr2 | <PROTECTED> |
| 15:24.31 | cr2 | why should i always read in multiples of 2048 ?? |
| 15:24.51 | tmzt | it's a block device? |
| 15:24.57 | tmzt | serial |
| 15:25.33 | cr2 | yes, it's a block device. |
| 15:25.51 | cr2 | i don't understand how 68 & 512 come through. |
| 15:26.04 | tmzt | where? |
| 15:26.11 | tmzt | where are the msm_ nand functions? |
| 15:26.30 | cr2 | [16:21] <cr2> [ 342.050982] msm_nand_read_oob 2832800 800 0 failed -74, corrected 0 |
| 15:26.36 | cr2 | 0x800 here. |
| 15:26.58 | cr2 | ok, it was from dd if=/dev/mtd0 bs=2048 |
| 15:27.34 | *** join/#htc-linux StarLite (n=nnscript@s55916ca6.adsl.wanadoo.nl) |
| 15:27.53 | cr2 | <PROTECTED> |
| 15:30.02 | cr2 | so how does this happen |
| 15:30.05 | cr2 | <PROTECTED> |
| 15:30.38 | cr2 | <PROTECTED> |
| 15:30.54 | tmzt | 21:03 < cr2> ops.len = len; |
| 15:30.55 | tmzt | 21:03 < cr2> ret = msm_nand_read_oob(mtd, from, &ops); |
| 15:30.57 | cr2 | it must be some partiton reading code |
| 15:31.14 | tmzt | I think the 512 should be thought of as virtual blocks |
| 15:31.26 | cr2 | yeah, but the len must be in blocks for a block device |
| 15:31.39 | tmzt | try bs=512 |
| 15:31.55 | cr2 | i can try bs=1 |
| 15:32.32 | cr2 | [ 2956.492541] msm_nand_read_oob: unsupported ops->len, 1 |
| 15:32.38 | tmzt | what len? |
| 15:33.05 | tmzt | bs=blksize count=number of blocks |
| 15:33.21 | cr2 | dd if=/dev/mtd0 bs=1 |
| 15:33.40 | cr2 | it should read 1 block, and pick the 1 byte from it |
| 15:33.52 | cr2 | so i can understand the block device :) |
| 15:33.55 | tmzt | not with mtdblock device I think |
| 15:34.02 | tmzt | only mtdchar |
| 15:34.04 | cr2 | it's not that you can just read 1 byte |
| 15:34.33 | tmzt | this is for mounting a block fs, but only one that supports mtd I think |
| 15:34.50 | cr2 | ok, but why does it happen in the reading partition info ? |
| 15:35.27 | cr2 | [ 3120.688983] msm_nand_read_oob: unsupported ops->len, 512 |
| 15:35.28 | cr2 | [ 3120.689837] end_request: I/O error, dev mtdblock0, sector 0 |
| 15:35.30 | cr2 | [ 3120.689929] __ratelimit: 20 callbacks suppressed |
| 15:35.31 | cr2 | [ |
| 15:35.37 | cr2 | the same problem on mtdblock |
| 15:36.34 | tmzt | we're at the wrong level |
| 15:36.46 | tmzt | oob is out-of-band, it's extra data/metadata |
| 15:37.26 | cr2 | msm_nand_read calls msm_nand_read_oob |
| 15:37.57 | tmzt | yes |
| 15:41.50 | cr2 | <PROTECTED> |
| 15:43.08 | tmzt | oh, why isn't ops->len set in msm_nand_read? |
| 15:43.15 | tmzt | iti is |
| 15:43.20 | tmzt | but to the block size? |
| 15:45.41 | tmzt | sectordatasize |
| 15:45.46 | cr2 | 679 ops.mode = MTD_OOB_PLACE; |
| 15:45.48 | tmzt | sectoroobsize |
| 15:45.48 | cr2 | 680 ops.len = len; |
| 15:46.06 | tmzt | can we find out what MTD_OOB_PLACE means? |
| 15:46.40 | tmzt | it should be ignoring ops->len and using ooblen |
| 15:47.05 | tmzt | what was your error? |
| 15:47.16 | tmzt | msm_nand_read_oob: unsupported ops->len, 512 |
| 15:48.04 | cr2 | yes, and 68 |
| 15:48.20 | cr2 | in the partition code somewhere |
| 15:48.55 | tmzt | I guess it's a sanity check, it's not really trying to read that much oob |
| 15:49.07 | tmzt | is your writesize 2048? |
| 15:49.20 | cr2 | i don't use write yet |
| 15:49.38 | cr2 | why doesn't it happen on g1 ?? |
| 15:49.40 | tmzt | I'm in the wrong function |
| 15:49.46 | cr2 | do we have a g1 dmesg ? |
| 15:49.54 | tmzt | I did |
| 15:50.01 | cr2 | hehe. it maybe because g1 is androed only ;) |
| 15:50.20 | cr2 | you need a debian running on g1 |
| 15:53.07 | cr2 | i'm looking at mDOC code |
| 15:54.05 | tmzt | I had that and proc/config.gz, still looking |
| 15:54.15 | tmzt | what lines do you need? |
| 15:54.35 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
| 15:54.54 | *** join/#htc-linux lupine_85 (n=lupine@forest.lupine.me.uk) |
| 15:55.10 | cr2 | tmzt: do you have such ops->len error messages there ? |
| 15:55.34 | tmzt | haven't found it yet |
| 15:55.41 | tmzt | I was going to have someone grep |
| 15:58.58 | tmzt | found it |
| 15:59.04 | tmzt | nothing ops->len |
| 15:59.08 | tmzt | nand registers partitions |
| 15:59.13 | tmzt | no oob messages at all |
| 15:59.45 | *** join/#htc-linux timebomb (n=tb@p548EDE36.dip.t-dialin.net) |
| 15:59.55 | cr2 | can somebody with g1 try 'dd if=/dev/mtd0 bs=1 count=1' ? |
| 16:05.45 | cr2 | <PROTECTED> |
| 16:05.47 | cr2 | <PROTECTED> |
| 16:05.48 | cr2 | <PROTECTED> |
| 16:05.50 | cr2 | <PROTECTED> |
| 16:06.55 | tmzt | San is sick, no help from him I guess |
| 16:07.14 | tmzt | http://www.infradead.org/pipermail/linux-mtd/2007-February/017412.html |
| 16:07.44 | tmzt | http://markmail.org/message/4sbgyxoxokq2sccg |
| 16:09.48 | tmzt | ooboffs |
| 16:10.54 | cr2 | root@htcraphael:~# nanddump |
| 16:10.56 | cr2 | Usage: nanddump [OPTIONS] MTD-device |
| 16:10.57 | cr2 | Dumps the contents of a nand mtd partition. |
| 16:12.05 | cr2 | lol |
| 16:12.10 | cr2 | root@htcraphael:~# nanddump -p /dev/mtd0 |
| 16:12.11 | cr2 | Unknown flash (not normal NAND) |
| 16:17.15 | cr2 | ok, i gave up for now. |
| 16:17.17 | tmzt | did you see the urls? |
| 16:19.42 | cr2 | yes |
| 16:21.35 | tmzt | we'll have to come back to it |
| 16:21.47 | cr2 | ok |
| 16:22.27 | cr2 | dd if=/dev/mtd0 bs=1 count=1 on g1 may be interesting. |
| 16:22.42 | tmzt | nobody has responded yet |
| 16:25.15 | cr2 | ok |
| 16:26.14 | tmzt | the htc-hw driver I posted is just based on dzo's, I haven't made changes really for raph yet |
| 16:26.19 | tmzt | since I don't know the rpc commands |
| 16:30.13 | cr2 | i will put rpc commands into wiki |
| 16:30.25 | tmzt | cool |
| 16:30.27 | cr2 | the code by dzo has rpc |
| 16:30.43 | tmzt | but it would be helpful if you can tell me how to use them properly |
| 16:30.50 | cr2 | i'm trying to finish the bt power and reset now. |
| 16:30.54 | tmzt | yeah, that's what currently gives me static |
| 16:30.57 | tmzt | oh, ok |
| 16:31.06 | tmzt | is that vreg? |
| 16:35.42 | cr2 | i need to check. |
| 16:41.53 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 16:44.31 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 16:52.21 | *** join/#htc-linux MLM_ (n=mlvdmeid@meide.xs4all.nl) |
| 16:58.02 | cr2 | hmm. i don't understand what maejrep has written |
| 17:01.53 | cr2 | tmzt: look for msm_rpc_call(SND_PROG, 1, &msg, sizeof(msg),15*HZ); |
| 17:02.16 | tmzt | where? |
| 17:02.40 | cr2 | vogue-hw.c |
| 17:02.53 | cr2 | i didn't see any dex calls |
| 17:03.07 | cr2 | and you need to do some adsp changes as well |
| 17:03.16 | tmzt | I didn't see that |
| 17:08.10 | cr2 | int msm_rpc_call(struct msm_rpc_endpoint *ept, uint32_t proc, |
| 17:08.12 | cr2 | 892 void *_request, int request_size, |
| 17:08.13 | cr2 | 893 long timeout) |
| 17:08.40 | cr2 | how did dzo drop *ept ? |
| 17:09.10 | tmzt | what do you mean? |
| 17:09.13 | cr2 | looks like a different api |
| 17:09.53 | cr2 | <PROTECTED> |
| 17:10.03 | cr2 | <PROTECTED> |
| 17:10.22 | cr2 | struct msm_rpc_endpoint *ept, uint32_t proc, |
| 17:10.32 | cr2 | SND_PROG, 1 |
| 17:10.33 | cr2 | ? |
| 17:15.03 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 17:19.40 | tmzt | endpoint is on the arm11 side? |
| 17:19.50 | tmzt | proc is the index of the dsp module? |
| 17:25.40 | *** join/#htc-linux zycho_ (n=zycho@dslb-088-070-062-141.pools.arcor-ip.net) |
| 17:27.02 | cr2 | <PROTECTED> |
| 17:27.15 | cr2 | i think maejrep overstretched it a bit :) |
| 17:28.28 | tmzt | it seems to support all the gpio settings |
| 17:29.00 | tmzt | do you think dvrstr is related to clock frequency? |
| 17:29.16 | cr2 | no |
| 17:29.33 | cr2 | it's a completely different api |
| 17:29.40 | cr2 | and has nothing to do with DEX |
| 17:30.05 | cr2 | googel just tried to obfuscate the gpio setup ;) |
| 17:35.18 | cr2 | hciattach /dev/ttyHS1 texas |
| 17:36.11 | cr2 | [ 61.210345] clock-wince: set_mdns_host_clock: 35, freq=7372800 |
| 17:36.13 | cr2 | [ 61.210620] msm_dmov_enqueue_cmd(11), error datamover stalled, status 0 |
| 17:36.14 | cr2 | [ 61.210681] clock-wince: pc_clk_set_rate: id=35 rate=7372800 |
| 17:36.15 | cr2 | [ 61.210711] clock-wince: set mdns: 35, 7372800; bitidx=26, offset=dc, ns=0 |
| 17:36.17 | cr2 | [ 61.210772] BUG: scheduling while atomic: hciattach/1040/0x00000002 |
| 17:36.19 | cr2 | hmm. power not applied |
| 17:37.22 | cr2 | and reboot does not work. |
| 17:40.00 | cr2 | tmzt: who is calling rfkill ? |
| 17:41.57 | *** join/#htc-linux pH5 (n=ph5@p5485FD50.dip.t-dialin.net) |
| 17:45.56 | cr2 | must be some compile bug |
| 17:49.09 | *** join/#htc-linux _GrndMstrUslss (n=android@c-76-121-157-180.hsd1.wa.comcast.net) |
| 17:53.00 | *** join/#htc-linux _GrndMstrUslss (n=android@32.156.172.3) |
| 17:54.21 | *** join/#htc-linux zycho (n=zycho@dslb-088-070-062-141.pools.arcor-ip.net) |
| 17:55.47 | tmzt | cr2: hci code? |
| 17:59.04 | *** join/#htc-linux _GrndMstrUslss (n=android@32.156.172.3) |
| 18:01.05 | cr2 | ok |
| 18:04.06 | *** join/#htc-linux wdslbr (n=asa@dslb-088-069-204-014.pools.arcor-ip.net) |
| 18:07.19 | *** join/#htc-linux AndIrc (n=android@32.156.172.3) |
| 18:09.15 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 18:10.23 | cr2 | tmzt: what is the nand size on raph ? |
| 18:12.37 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
| 18:17.35 | tmzt | how would I find that? |
| 18:17.47 | tmzt | oh |
| 18:17.56 | tmzt | can't check right now |
| 18:18.58 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d8744aa.pool.einsundeins.de) |
| 18:24.16 | *** join/#htc-linux _chab7_3 (n=kvirc@fibhost-67-206-132.fibernet.bacs-net.hu) |
| 18:24.47 | *** join/#htc-linux _GrndMstrUslss (n=android@32.159.89.162) |
| 18:29.06 | cr2 | stty -F /dev/ttyHS1 speed 115200 |
| 18:29.12 | *** join/#htc-linux _GrndMstrUslss (n=android@32.159.89.162) |
| 18:29.12 | cr2 | oops on that |
| 18:29.25 | *** join/#htc-linux wdslbr (n=asa@dslb-088-069-204-014.pools.arcor-ip.net) |
| 18:29.26 | tmzt | OOPS? |
| 18:30.04 | cr2 | the port gpios are not configured |
| 18:30.25 | cr2 | [ 120.376330] clock-wince: pc_clk_set_rate: id=35 rate=7372800 |
| 18:30.27 | cr2 | [ 120.376422] clock-wince: set mdns: 35, 7372800; bitidx=26, offset=dc, ns=0 |
| 18:30.28 | cr2 | [ 120.390307] clock-wince: set_mdns_host_clock: 35, freq=7372800 |
| 18:30.30 | cr2 | [ 120.390582] msm_dmov_enqueue_cmd(11), error datamover stalled, status 0 |
| 18:30.31 | cr2 | [ 120.390643] clock-wince: pc_clk_set_rate: id=35 rate=7372800 |
| 18:30.33 | cr2 | [ 120.390673] clock-wince: set mdns: 35, 7372800; bitidx=26, offset=dc, ns=0 |
| 18:30.34 | cr2 | [ 120.390734] BUG: scheduling while atomic: stty/1047/0x00000002 |
| 18:30.46 | cr2 | rfkill for powering bt does not look very smart |
| 18:31.39 | cr2 | clk_set_rate+0x180/0x244) |
| 18:31.40 | cr2 | [ 120.391162] [<c002cd74>] (clk_set_rate+0x0/0x244) from [<c015185c>] (msm_hs_set_termios+0x298/0x444) |
| 18:31.42 | cr2 | [ 120.391253] [<c01515c4>] (msm_hs_set_termios+0x0/0x444) from [<c014cc54>] (uart_change_speed+0x88/0x8c) |
| 18:31.43 | cr2 | [ 120.391284] [<c014cbcc>] (uart_change_speed+0x0/0x8c) from [<c014fb5c>] (uart_open+0x420/0x4d8) |
| 18:31.46 | cr2 | [ 120.391345] r4:c0c16000 |
| 18:31.46 | cr2 | [ 120.391345] [<c014f73c>] (uart_open+0x0/0x4d8) from [<c013a10c>] (tty_open+0x198/0x30c) |
| 18:31.47 | cr2 | [ 120.391406] [<c0139f74>] (tty_open+0x0/0x30c) from [<c0094564>] (chrdev_open+0x1dc/0x1fc) |
| 18:31.49 | cr2 | [ 120.391467] [<c0094388>] (chrdev_open+0x0/0x1fc) from [<c008f31c>] (__dentry_open+0x188/0x2a0) |
| 18:32.28 | tmzt | rfkill isn't powering bt, it's supposed to disable it |
| 18:32.45 | cr2 | used for both here |
| 18:33.07 | tmzt | this seems to be the hs driver though, not bt itself |
| 18:34.09 | cr2 | i'll boot with bt on, then the alt gpios will be configured |
| 18:34.42 | tmzt | or are you powering up bt when the hs dev is opened? |
| 18:35.08 | cr2 | no, the software is written in such a way that i can't control it |
| 18:35.23 | tmzt | what software? |
| 18:35.27 | tmzt | what are you using? |
| 18:35.31 | cr2 | it was a problem already on pxa |
| 18:35.36 | cr2 | g1 kernel code |
| 18:35.53 | cr2 | to power the btuart et al. |
| 18:35.58 | tmzt | hsserial? |
| 18:36.34 | cr2 | yes, how do i powerup the hsserial ? |
| 18:37.01 | cr2 | i need to apply power to brf6350 and reset it before doing anything. |
| 18:37.03 | tmzt | I think it's seperate from the bt chip |
| 18:37.23 | tmzt | it appears you can't even set the speed on hsuart though |
| 18:37.27 | tmzt | with stty |
| 18:37.33 | cr2 | hmm. |
| 18:37.55 | cr2 | yeah, braindead design |
| 18:38.05 | cr2 | pH5: are you here ? |
| 18:38.14 | tmzt | it's what hciattach and stty have in common, both set the speed with an ioctl |
| 18:38.48 | cr2 | no, it's a design problem. |
| 18:39.29 | cr2 | it was solved for 2.6.21-hhX with extending the pxa_uart struct |
| 18:40.15 | tmzt | what was? |
| 18:40.36 | cr2 | .power |
| 18:41.12 | tmzt | why is brf power related to the uart? |
| 18:41.30 | tmzt | are you saying uart will panic without the chip powered up? |
| 18:41.39 | tmzt | otherwise we can use sysfs |
| 18:41.42 | pH5 | cr2: here |
| 18:42.06 | pH5 | uart shouldn't be bothered if the chip on the other end is dead |
| 18:44.38 | tmzt | this is cool: http://lists.openmoko.org/pipermail/devel/2009-May/005489.html |
| 18:44.50 | tmzt | if we can adapt it to msm either mdp or gpu |
| 18:45.11 | tmzt | it appears the pmem driver can be used to source things to blit, even if their off screen |
| 18:45.24 | tmzt | but this is only supported on g1 with the gpu closed library |
| 18:45.55 | tmzt | it might also give us extra ram by making offscreen buffers dynamic |
| 18:55.54 | cr2 | tmzt: sysfs is a good idea. |
| 18:56.09 | cr2 | don't know why hsuart oopses on stty |
| 19:34.06 | *** join/#htc-linux MLM (n=mlvdmeid@5ED0BCBD.cable.ziggo.nl) |
| 19:57.31 | *** join/#htc-linux MethoS (n=clemens@host-091-097-242-057.ewe-ip-backbone.de) |
| 20:41.48 | *** join/#htc-linux punkass (i=punkass@unaffiliated/punkass) |
| 20:44.03 | *** part/#htc-linux exception13 (n=exceptio@testdrive.kgts.ru) |
| 20:49.23 | *** join/#htc-linux AndIrc (n=android@32.159.179.12) |
| 21:22.34 | *** join/#htc-linux AndIrc (n=android@32.159.179.12) |
| 21:30.44 | *** join/#htc-linux nebi_ (n=nebi@ip67-152-3-162.z3-152-67.customer.algx.net) |
| 21:31.44 | *** join/#htc-linux marcin (n=marcin@chello089078134143.chello.pl) |
| 21:32.52 | *** join/#htc-linux nebi_ (n=nebi@user-387g3pr.cable.mindspring.com) |
| 21:36.42 | *** join/#htc-linux AndIrc (n=android@32.159.179.12) |
| 21:38.54 | cr2 | everybody is quiet now |
| 21:39.22 | Dunedan | everybody is crying, because of the end of the weekend ;-) |
| 21:40.29 | cr2 | hehe |
| 21:40.51 | cr2 | i was hacking the whole weekend, so it does not matter anyway. |
| 21:56.29 | tcccp | This is the end of the world as we know it |
| 21:56.30 | tcccp | ;-) |
| 21:59.44 | *** join/#htc-linux pH5 (n=ph5@e178213068.adsl.alicedsl.de) |
| 22:01.07 | cr2 | tcccp: once pH5 will have the asic3mmc driver, we can hack on sable. it's much more relaxing ;) |
| 22:01.55 | tcccp | cr2: I have slightly different problems atm |
| 22:02.16 | tcccp | needs a job |
| 22:02.27 | *** join/#htc-linux AndIrc (n=android@32.159.114.75) |
| 22:02.39 | tcccp | hmhm |
| 22:03.00 | pH5 | cr2: http://git.linuxtogo.org/?p=ph5/kernel.git;a=shortlog;h=refs/heads/asic3/ugly-dev |
| 22:03.17 | pH5 | HEAD~1 is working, but it will take a while until I'm happy. |
| 22:04.56 | cr2 | pH5: nice :) i need to check it |
| 22:05.12 | pH5 | I promise this will be cleaned up eventually ;) |
| 22:06.53 | cr2 | pH5: sd_ctrl and sd_config is asic3-only |
| 22:08.29 | *** join/#htc-linux AndIrc (n=android@32.159.114.75) |
| 22:10.14 | pH5 | cr2: tmio has it, too. |
| 22:10.17 | pH5 | it seems to be only w228x that doesn't have sd_config? |
| 22:11.07 | pH5 | is there anything else in the w228x wince driver to power down mmc when not in use? |
| 22:12.40 | *** join/#htc-linux syn-fin (n=alien@m6b0e36d0.tmodns.net) |
| 22:13.57 | cr2 | pH5: the irq and some clock bits are in the "main" area. 2 registers i think |
| 22:14.19 | cr2 | together with other soc irqs, like on w100 |
| 22:14.45 | cr2 | but sd and sdio share all the registers. |
| 22:15.23 | cr2 | since it's mini/microSD i would not put too much value into sdio, actually. |
| 22:24.01 | *** join/#htc-linux AndIrc (n=android@32.159.114.75) |
| 22:25.02 | pH5 | aye, for now I can't do anything about sdio anyway. |
| 22:28.11 | cr2 | ok |
| 22:28.26 | cr2 | hwinit2_irqsafe |
| 22:28.44 | cr2 | i'm only wondering if this one is really needed |
| 22:30.13 | *** join/#htc-linux AndIrc (n=android@32.159.114.75) |
| 22:31.06 | pH5 | maybe not all of it |
| 22:31.07 | pH5 | but at least on asic3 the SD_CONFIG setup to select the correct CTRL register bank (SD or SDIO) and the reset seem to be needed. |
| 22:31.50 | pH5 | this is one of the parts where all my small changes yield lockups. |
| 22:32.42 | cr2 | hmm. |
| 22:33.16 | pH5 | and there seem to be some differences in the power handling |
| 22:34.15 | cr2 | ok |
| 22:34.41 | cr2 | the fmin/fmax should be in the pdev probably. but it's minor thing |
| 22:34.52 | pH5 | I'm not exactly sure what Power1/2/3 are for, and tmio fiddles with different ones than asic3 |
| 22:35.07 | pH5 | yup, fmin/fmax should be derived from the incoming clock frequency. |
| 22:35.22 | pH5 | we can push that through via pdata on the mfd_cell. |
| 22:35.31 | cr2 | asic3_mmc does what wince does, at least in the sd part |
| 22:35.37 | cr2 | ok |
| 22:36.28 | cr2 | i'm thinking about atiw, where the base clock is not 24576, but 80000 |
| 22:36.52 | cr2 | with a prescaler 2 |
| 22:37.46 | cr2 | you have 24000 now, but i think asic3 clock is 24576 in real life. at least it has such clock. |
| 22:41.33 | pH5 | Probably. Does seem to work though. It's only a few percent fast, is there a margin in the spec? |
| 22:42.05 | cr2 | 25 |
| 22:42.29 | cr2 | and 50MHz for sd2.0 |
| 22:42.38 | cr2 | where atiw uses 40MHz |
| 22:43.36 | cr2 | i mean you think that it's 24000kHz while it's 24576kHz when you enable it |
| 22:44.32 | cr2 | 2.5% |
| 22:45.33 | cr2 | but it's a guesswork |
| 22:45.45 | cr2 | on atiw it's 100% sure |
| 22:46.38 | cr2 | about top =40MHz and the divisors |
| 22:47.52 | pH5 | I'll make the base clock configurable and probably split the ctl (SD_CTRL/SDIO_CTRL) resource into sd/sdio parts. |
| 22:48.29 | pH5 | then atiw could just set both resources to point to the same iomem space, would that work? |
| 22:49.36 | cr2 | yes |
| 22:50.06 | cr2 | you use 16bit data access now ? |
| 22:50.39 | cr2 | on atiw it's 32bit, but i've seen "unaligned" 16bit and 8bit options in the driver. |
| 22:50.50 | cr2 | and i've actually seen 16bit accesses. |
| 22:52.42 | pH5 | in mmc_data_transfer? |
| 22:53.27 | pH5 | that one is still unfixed, but it'll use the bus_shift parameter to align to 32bit if needed |
| 22:53.43 | pH5 | or do you have true 32-bit data transfer somewhere? |
| 22:54.44 | cr2 | yes, it's the normal case |
| 22:55.10 | cr2 | only if the data buffer is not 32bit aligned then something happens. |
| 22:56.03 | cr2 | i mean the data itself, not the register offsets |
| 22:56.24 | pH5 | hmmm, I see. I was confused because ASIC3_MMC_REG used in atiw_mmc still has the (volatile u16 *) cast. |
| 22:57.00 | cr2 | <PROTECTED> |
| 22:57.01 | cr2 | 228 if(data->flags & MMC_DATA_READ) { |
| 22:57.11 | cr2 | *buf = sd_ctrl_read16(host, CTL_SD_DATA_PORT); |
| 22:57.16 | cr2 | <PROTECTED> |
| 23:03.01 | pH5 | cr2: where is it configured for 8/16/32bit read/writes on DataPort? |
| 23:05.19 | pH5 | also, do you happen to have an idea what this CLOCK_FOR_SD bit in the SD_CTRL_CardClockCtl register is all about in asic3_mmc? |
| 23:08.15 | cr2 | about DataPort : need to look at the traces. but for a block write (like 512) it's always 32bit |
| 23:08.37 | cr2 | don't remember now about CLOCK_FOR_SD |
| 23:10.13 | pH5 | ok, we'll see. I'll ping you when I have something testworthy. |
| 23:10.16 | pH5 | good night |
| 23:21.06 | par | cr2: were you working on getting bluetooth operational earlier? |
| 23:21.44 | par | i don't know if dzo has that working at all under vogue |
| 23:22.15 | par | i'm hoping some day i will work and will support interfacing a gsm device over bt |
| 23:22.24 | par | by vogue model doesn't have gps |
| 23:22.33 | *** join/#htc-linux MrKeuner (n=This@unaffiliated/mrkeuner) |
| 23:28.53 | par | well on the P3050 is the manual says it has a gps chip |
| 23:29.24 | par | along with an antenna |
| 23:30.01 | par | but i think that its not active .. that its also only a-gps |
| 23:31.11 | par | but no carrier support for a-gps means its just going to stay off an unused |
| 23:43.37 | par | honestly, i'd say trying to add gps support for vogue's native chip isn't worth it because assited gps isn't going to be support by the carrier... |
| 23:43.54 | par | but, gps over bt support is definitely worth doing |
| 23:51.29 | par | if anyone knows i'm wrong plz to tell me kthx |
| 23:54.29 | *** join/#htc-linux timebomb (n=tb@dslb-092-078-122-247.pools.arcor-ip.net) |
