IRC log for #htc-linux on 20080623

00:00.21cr2dzo: i thought they are already known ?
00:00.33dcordeskaiser mmu with new haret at: http://linuxtogo.org/~lgorris/haretlog-20080623_015359.log
00:00.50dzolast bit of code i saw just wrote to them all and crashed the radio..
00:01.55dcordesdzo: with our current state of kaiser-smd.c, I write one character to the AT device node, and the modem returns critical errors and stays silent
00:02.19dcordesdzo: martin__ had the idea that we probably write to a wrong area which makes the modem crash
00:02.52dzodcordes, that's what I mean, it should only write to one address in MSM_CSR+0x400
00:02.52cr2dcordes: it's not the latest haret
00:03.34*** join/#htc-linux mistadman2 (n=mistadma@adsl-156-124-98.msy.bellsouth.net)
00:04.05cr2mistadman2: do you have gps and bt working ?
00:04.18dcordesdzo: right we have gps working on kaiser now
00:04.28dcordescr2: I used haret-20080622-mmu2.exe for that dump
00:05.02dcordesdzo: MSM_CSR?
00:05.04cr2dcordes: http://www.handhelds.org/~koconnor/haret/haret-20080622-mmu3.exe
00:05.10dcordesoh darn
00:05.12dzogood, I haven't looked at it on vogue, just another smem channel i think.
00:05.30dcordesyep maybe you wanna look at our kaiser-smd.c will pastebin
00:07.23mistadman2cr2: Haven't gotten that far. Sorry.
00:08.16dzothe code I see in notify_other_smd writes to 16 locations, only one of those will be correct, some of the others will do horrible things.
00:08.32dcordeslike crashing the modem?
00:08.42dzolook like it
00:08.49dzos/look/looks/
00:09.32dzocan you not mmutrace MSM_CSR?
00:09.38dcordesdzo: http://rafb.net/p/L2xsnR36.html that's what martin__ made out of kaiser-smd.c. it has the AT read working and does the described on AT write attempt. GPS works when you have it switched on on boottime
00:09.57cr2mistadman2: finish the dpram first.
00:10.11dcordesdzo: what's MSM_CSR?
00:10.14cr2good night.
00:10.18dcordesnight
00:10.35mistadman2cr2: I will. And thanks for you help!!!
00:10.36cr2dcordes:  0xb4e00000   0xb4f00000   0xc0100000   1   MSM_CSR/MSM_GPT
00:11.06dcordesb4f0 is familiar
00:11.21dzoline 117,118 is the problem, MSM_CSR+0x400 is a range of memory where the A11 writes to tell the A9 something, each address means something different.
00:11.42dcordesaah we were thinking of irqs to be the problem with notification
00:12.04dzoit is an irq to the A9, yes.
00:12.07cr2dzo: does vogue use an uart ? i see uart3 being referenced on diamond.
00:12.44dcordesdzo: so how would I figure what's wrong there?
00:12.51dzoit could do for BT but that's low down my list of things to do.
00:13.03cr2ok.
00:13.25cr2dcordes: got bt running on kaiser ?
00:13.50dzoaddlist mmutrace 0xb4f00400 0x100
00:14.37dcordescr2: http://linuxtogo.org/~lgorris/kaiser-mmu3.txt
00:14.40dzoor another address that maps to 0xc0100000 with the correct TEX bits set.
00:14.56dcordescr2: no we weren't able to try because I haven't the bluetooth rootfs done yet
00:15.27dcordesdzo: tex bits? will do addlist mmutrace 0xb4f00400 0x100
00:15.30cr2ok.
00:16.09dzomay be 0x4a201400 rather than b4f00400
00:16.36dzoor 4a30e400
00:16.38dcordesHaRET(1)# addlist mmutrace 0xb4f00400 0x100
00:16.38dcordesHaRET(2)# wirq 50
00:16.38dcordesTerminating haret due to unhandled exception (pc=00016864)
00:16.58dzoor 4fc01400
00:17.12cr2dzo: there are 16 channels ?
00:18.38cr2added to kaiser wiki
00:19.05dzoyes, on vogue  3 and 4 do SMEM channel notify 6 is proc_comm 5 is smsm
00:19.35cr2ok.
00:19.57cr2good night :)
00:20.25dcordesharet-20080622-mmu3.exe always dies on wirq
00:21.02dcordesI'll use the version I used before
00:21.20dcordesharet-20080613-swp3.exe
00:24.16dcordesdzo: ok "mmutrace 0xb4f00400 0x100" produces a lot of output, no matter if modem is on/off
00:26.33dzook, paste some of it and i'll have a look.
00:27.46dzoor try mmutrace 0xb4f00400 0x40
00:27.49dcordeshttp://rafb.net/p/vE50rf87.html
00:28.15dcordeswith 0x4a201400 it deadlocked after I turned on the phone in wince
00:28.23dzook, do mmutrace 0xb4f00400 0x38
00:29.19dcordesbooting..
00:33.06dcordeslol now what's that
00:33.33dcordesI had the phone off, then while running  mmutrace on 0xb4f00400 0x38 I tried to enable it
00:33.40dcordesbut it just stayed off with no error message
00:34.09dzodid the trace print anything?
00:34.19dcordesno
00:34.23dzotry with the phone already on
00:34.32dcordesdoing that now
00:37.24dcordeshmnothing
00:37.36dcordesdzo: also dialed customer service
00:37.51dcordesno reads/writes on 0xb4f00400 0x38
00:39.42dzoof, it's probably mapped from one of the other addresses try 0x4a201400 0x38 instead (assuming 4K and 1K page tracing works)
00:40.49dzoalso, bear in mind those mappings may change when you reboot the phone.
00:41.22dzoso do dump mmu and look for 0xc00100000
00:41.37dzos/0xc0100000
00:41.51dcordesagain a lock
00:41.54dzos/0xc00100000/0xc0100000
00:42.08dcordestraced 0x4a201400 0x38, turned off phone, lock
00:42.22dcordesand no output
00:42.42dzohave you been able to trace 4k pages before?
00:43.09dcordesone second I have some logs of 4k traces I think
00:43.17dzotry one of the other mappings e.g. 4a30e400
00:43.42dcordesthere are always two 4K pages that map to smem phys (0x01f*
00:44.25dcordesare you using http://linuxtogo.org/~lgorris/kaiser-mmu3.txt for referrence?
00:44.43dzoyes i was, and mmu2.txt
00:46.51dcordesaddlist mmutrace 0x4a30e400 0x38 -> nothing
00:47.07dcordesI should get accesses when I dial a number, shouldn't I?
00:47.42dzoyes, but only when you press call.
00:48.08dcordesI did
00:48.33dcordesdzo: can you look at this trace I made a few days ago? http://rafb.net/p/KDZF2b87.html
00:49.52dzothats the audio parameters being sent to to the ADSP to route audio to the handset.
00:50.55dcordesso that's not the MSM_CSR thing we are looking for, but still useful isn't it?
00:52.17dzoyes, useful but not for a while and android does all that in userspace.
00:52.31dcordesok
00:53.16dzoOk, I've got to go, have a pile of work to do. keep tracing.
00:53.39dcordeshm what where in the map do I look up the regs?
00:54.02dzowhich regs? MSM_CSR?
00:54.12dcordesjust things that map to 0xc0100000?
00:54.47dzodump mmu then grep for c0100000
00:55.40dcordesthe reason for redoing the mmudump is, the virtual mapping to that area can change after a reboot?
00:56.04dzoyes possibly, may not though.
00:57.34dzook bye
01:01.25*** join/#htc-linux dcordes_ (n=dcordes@unaffiliated/dcordes)
01:02.32dcordes_martin__: http://linuxtogo.org/~lgorris/console-bluetooth.tar.gz extract, add firmware and inside the rootfs folder do "find ./ | cpio -H newc -o | gzip > ../initrd-bla.cpio.gz" to package for initrd use
01:02.51dcordes_it should have all the bluetooth stuff, good night
01:48.13Kevin2http://www.handhelds.org/~koconnor/haret/haret-20080622-mmu4.exe  --  should fix wirq.
01:56.59*** join/#htc-linux lama__ (i=lama@netbsd.pl)
01:57.53DesktopMapoke me when I need to test stuff
01:58.01DesktopMaI'm at work so only following this channel with half an eye :P
02:56.39*** part/#htc-linux ali1234 (n=al@62.24.214.38)
04:20.12*** join/#htc-linux goxboxlive (n=goxboxli@195.159.97.196)
05:14.25*** join/#htc-linux kiozen (n=oeichler@p54929E65.dip0.t-ipconnect.de)
05:46.05*** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbfb340.pool.einsundeins.de)
06:28.31*** join/#htc-linux rob_w|laptop (n=rob@p549B9323.dip0.t-ipconnect.de)
06:59.46*** join/#htc-linux BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net)
09:48.01goxboxliveHi BabelO
10:16.59*** join/#htc-linux pigeon (n=pigeon@60-241-137-179.static.tpgi.com.au)
10:41.33*** join/#htc-linux Tonny (n=chatzill@set25-1-88-166-169-49.fbx.proxad.net)
10:54.51*** join/#htc-linux ginge_ (n=baz@cpc6-ward3-0-0-cust579.manc.cable.ntl.com)
10:59.07*** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes)
11:20.33*** join/#htc-linux mikeones_ (n=mikeones@75.53.33.83)
11:20.34*** join/#htc-linux BabelO (n=Fabrice@unaffiliated/babelo) [NETSPLIT VICTIM]
11:20.34*** join/#htc-linux kiozen (n=oeichler@p54929E65.dip0.t-ipconnect.de) [NETSPLIT VICTIM]
11:20.34*** join/#htc-linux Sliss__ (n=chatzill@250.110-65-87.adsl-dyn.isp.belgacom.be) [NETSPLIT VICTIM]
11:20.34*** join/#htc-linux AstainHellbring (n=Administ@unaffiliated/astainhellbring) [NETSPLIT VICTIM]
11:20.34*** join/#htc-linux GPFaway (i=GPF@cpe-76-187-41-132.tx.res.rr.com) [NETSPLIT VICTIM]
11:20.37*** join/#htc-linux exco (n=excogita@scenicl-69.itm.mw.tum.de)
11:20.37*** join/#htc-linux hollo_ (n=hollo@3e6b025d.rev.stofanet.dk) [NETSPLIT VICTIM]
11:20.37*** join/#htc-linux pof (n=pof@81.184.114.62.dyn.user.ono.com) [NETSPLIT VICTIM]
11:20.37*** join/#htc-linux ecze (n=ecze@eczema.ecze.com) [NETSPLIT VICTIM]
11:20.39*** join/#htc-linux goxboxlive (n=goxboxli@195.159.97.196) [NETSPLIT VICTIM]
11:20.39*** join/#htc-linux par (n=par@dipole.idlepattern.com) [NETSPLIT VICTIM]
11:20.53*** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes)
11:20.53*** join/#htc-linux ginge_ (n=baz@cpc6-ward3-0-0-cust579.manc.cable.ntl.com) [NETSPLIT VICTIM]
11:20.53*** join/#htc-linux Kevin2 (n=Kevin@207-237-52-122.c3-0.avec-ubr12.nyr-avec.ny.cable.rcn.com) [NETSPLIT VICTIM]
11:20.53*** join/#htc-linux rmoravcik (n=rmoravci@gtsgw.ttc.cz)
11:21.02*** join/#htc-linux Tonny (n=chatzill@set25-1-88-166-169-49.fbx.proxad.net) [NETSPLIT VICTIM]
11:21.02*** join/#htc-linux LunohoD (n=alex@e180072235.adsl.alicedsl.de) [NETSPLIT VICTIM]
11:21.02*** join/#htc-linux surgex0 (i=surge@pool-71-186-163-107.bflony.fios.verizon.net) [NETSPLIT VICTIM]
11:21.02*** join/#htc-linux who__ (i=who@194.145.250.184) [NETSPLIT VICTIM]
11:21.02*** join/#htc-linux tcccp (i=hey@bmvg.bund.be) [NETSPLIT VICTIM]
11:22.33*** join/#htc-linux ChanServ (ChanServ@services.)
11:22.33*** join/#htc-linux marajin (n=marajin@87-194-102-189.bethere.co.uk)
11:22.33*** join/#htc-linux hlbot (n=adm@iclem.net)
11:22.33*** join/#htc-linux andy_ (n=andy@207.96.50.10) [NETSPLIT VICTIM]
11:22.33*** join/#htc-linux Zba_Phy (n=none@2a01:e35:8a13:a2b0:21c:c0ff:fe25:ff68)
11:22.33*** join/#htc-linux jeebster (n=kanakana@a88-114-192-27.elisa-laajakaista.fi)
11:22.34*** join/#htc-linux pigeon (n=pigeon@60-241-137-179.static.tpgi.com.au) [NETSPLIT VICTIM]
11:22.34*** join/#htc-linux toi (n=pleemans@d5152D3B4.access.telenet.be) [NETSPLIT VICTIM]
11:22.34*** join/#htc-linux Dinde (n=kayser@sur-internet.net) [NETSPLIT VICTIM]
11:22.34*** join/#htc-linux StyleWarz (i=stylewar@fbettag.qs-housing.net) [NETSPLIT VICTIM]
11:22.34*** join/#htc-linux raph_ael (i=raphael@kikoolol.orbus.fr) [NETSPLIT VICTIM]
11:22.34*** join/#htc-linux paulproteus (n=paulprot@2002:cbb2:8293:0:0:0:0:1)
11:22.34*** join/#htc-linux cr2 (n=konversa@crpl6.physik.uni-wuppertal.de) [NETSPLIT VICTIM]
11:22.34*** join/#htc-linux Funklord (n=cow@c-ecd572d5.014-46-73746f28.cust.bredbandsbolaget.se) [NETSPLIT VICTIM]
11:22.34*** join/#htc-linux dase (i=dase@p1atin.de) [NETSPLIT VICTIM]
11:22.34*** mode/#htc-linux [+o ChanServ] by irc.freenode.net
11:24.29*** join/#htc-linux univac_ (n=univac@suita.chopin.edu.pl)
11:24.32*** join/#htc-linux hlbot870 (n=adm@iclem.net)
11:24.37*** join/#htc-linux lama (n=lama@estel.wpia.uw.edu.pl)
11:24.39*** join/#htc-linux martin__ (n=martin@the.earth.li)
11:24.39*** join/#htc-linux TeringTuby (n=maarten@195-241-125-243.ip.telfort.nl)
11:24.43dcordesKevin2: thanks, wirq works again with the update
11:24.44dcordeswhen I trace b4f00000  | c0100000 |   1MB section |    AP=1 T=2
11:24.44*** join/#htc-linux pikapika (n=pikapika@mar75-8-88-164-227-147.fbx.proxad.net)
11:24.45dcordes0xb4f00000 1024*1024 I get a lot of output
11:24.46pikapikahello
11:25.11*** join/#htc-linux BabelO (n=Fabrice@unaffiliated/babelo) [NETSPLIT VICTIM]
11:25.11*** join/#htc-linux kiozen (n=oeichler@p54929E65.dip0.t-ipconnect.de) [NETSPLIT VICTIM]
11:25.11*** join/#htc-linux Sliss__ (n=chatzill@250.110-65-87.adsl-dyn.isp.belgacom.be) [NETSPLIT VICTIM]
11:25.11*** join/#htc-linux AstainHellbring (n=Administ@unaffiliated/astainhellbring) [NETSPLIT VICTIM]
11:25.11*** join/#htc-linux GPFaway (i=GPF@cpe-76-187-41-132.tx.res.rr.com) [NETSPLIT VICTIM]
11:31.02dcordesmartin__: ping
11:31.08dcordesseen the new haret?
11:43.53*** join/#htc-linux rob_w|laptop (n=rob@p549B9323.dip0.t-ipconnect.de)
11:46.51*** join/#htc-linux premy (n=pr@133.190.98-84.rev.gaoland.net)
11:48.18premyHi
11:49.13premyI've been playing with the new haret on my polaris.
11:50.49premyI think I got some interesting traces : addlsit mmutrace 0x4a301400 0x100 shows some activity when placing a call at addresses 0x4a301404 and 0x4a301408
11:52.22premyThese addresses match (MSM_CSR_BASE + 0x400 + 1*4) and (MSM_CSR_BASE + 0x400 + 2*4)
11:57.14premysmem.dll is the module writing at those addresses
12:05.07*** join/#htc-linux skodde (n=skodde@unaffiliated/skodde)
12:07.17*** join/#htc-linux premy (n=pr@133.190.98-84.rev.gaoland.net) [NETSPLIT VICTIM]
12:07.17*** join/#htc-linux BabelO (n=Fabrice@unaffiliated/babelo) [NETSPLIT VICTIM]
12:07.17*** join/#htc-linux kiozen (n=oeichler@p54929E65.dip0.t-ipconnect.de) [NETSPLIT VICTIM]
12:07.17*** join/#htc-linux Sliss__ (n=chatzill@250.110-65-87.adsl-dyn.isp.belgacom.be) [NETSPLIT VICTIM]
12:07.18*** join/#htc-linux AstainHellbring (n=Administ@unaffiliated/astainhellbring) [NETSPLIT VICTIM]
12:07.18*** join/#htc-linux GPFaway (i=GPF@cpe-76-187-41-132.tx.res.rr.com) [NETSPLIT VICTIM]
12:13.54cr2premy: do you see the activity in other channels ? gps ?
12:27.00premycr2: I'm not getting anything from tracing the whole of the shared RAM, even during a call.
12:50.10premymartin__:Hi, I've looked at your new version of kaiser-smd.c
12:50.40premymartin__: I'm not sure, but shouldn't your a11_ptr and a9_ptr be ints rather than shorts ?
12:51.00premymartin__: here's what I get on my polaris:
12:51.15premyHaRET(25)# vdump 0xb51041F0 0x100
12:51.21premyb51041f0 | 00000002 00000100 00000000 0000112f
12:51.29premyb5104200 | 0000112f 00000000 455a5441 3d305330
12:51.58premy....
12:51.59dcordespremy: looks like the start of a fifo
12:52.02cr2premy: looks like ascii to me 455a5441 3d305330
12:52.20cr2dcordes: what is 00000002 00000100 00000000
12:52.33dcordespremy: save it and run it through hexdump -C
12:52.35cr2dcordes: it seems to be the same on all msm7xxx
12:52.45dcordescr2: I talked about it with martin__
12:52.49premyYes that's the start of the send buffer.
12:53.10dcordescr2: I think he said it might be an start indicator or so
12:53.30premyThe thing is that I believe that with the current version of kaiser-smd, a11_ptr and a9_ptr will not catch the right values.
12:53.31dcordespremy: did you try kaiser-smd.c out?
12:53.43premyWhich might explain the modem caughing about it.
12:53.45cr2premy: do you see anything at MSM_CSR_BASE + 0x400 + N*4, for N > 1
12:54.24premycr2: yes, N=2, when placing a call. I've not tried much more than calling, though.
12:54.46dcordespremy: because of *ptr are shorts?
12:55.49premywith a patched version of kaiser-smd.c (with ints instead of shorts). I can write and the modem still works. However a9_ptr never gets updated, as if the modem was not doing anything with my data.
12:56.11dcordesinteresting
12:57.51premyI was hoping that the activity traced with the new haret, we would be able to have the modem react. But nothing for the moment....
12:58.30premyThe current code is actually writing at the addresses where I saw some activity.
13:01.04cr2premy: which code writes to the fifo ?
13:01.11cr2premy: in wince.
13:01.34cr2ah, you don't see it :(
13:01.44premycr2: that's right
13:03.59cr2premy: and the 1 and 2 channels at CSR are controlled by smem.dll ?
13:07.10premysmem.dll: 0x1000d5c8, strr4, [r3, #1028] and 0x1000d5f4: strr4, [r3, #1032]
13:31.55*** join/#htc-linux LunohoD_ (n=alex@e180072190.adsl.alicedsl.de)
13:38.34martin__premy: why do you think they should be ints?
13:39.10martin__Look at a dump of the smem and see the heads and tails. They're 16 bit and aligned as such.
13:40.18cr2martin__: you'd find the code that uses them. then we will look at .S
13:41.00martin__Read will still work if you change the code to int (this is what was there before I modified it in fact - I think they're int on the vogue, which seems to have a quite different smem layout), because the other 16 bits in that word are zeroes.
13:42.03*** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes)
13:43.58martin__I'm at work now, should be able to look at things later.
13:47.57martin__premy: wait, you're right, i'm an idiot, i can't count bits
13:49.26martin__http://void.printf.net/~martin/kaiser-smd.c <- updated with sensible struct
13:49.43martin__dcordes: try the above?
13:49.50martin__premy: thanks!
13:50.02dcordesmartin__: later I'm in bed with illness
13:50.05martin__ok
13:50.15martin__may get a chance myself later
13:50.58martin__ginge_: try it if you get a chance
13:51.24ginge_will try it now
13:51.45martin__if it doesn't work, maybe the assumption the head/tail are swapped for writes is wrong
13:52.09martin__so we can try switching those back
13:52.31martin__if it still doesn't work, we're probably missing the right notify to the arm
13:53.04ginge_It might not boot with the bluetooth driver code I am working on ;)
13:53.49martin__cr2: can you look at a kaiser smem.dll for something that writes a 1 to MSM_CSR_BASE+something?
13:54.25martin__i.e. the equivalent of notify_other_smd() in the linux code
13:54.25dcordesginge_: martin__ you guys seen the bluez-utils image?
13:54.36martin__dcordes: i've dl'ed it, yeah, cheers
13:54.43martin__and the new haret too
13:54.46dcordesit lacks the firmware
13:54.48dcordess
13:54.59dcordesmartin__: you got haret*3.exe or 2?
13:55.01ginge_yeah, just need to put the firmware in it
13:55.04martin__i've got 3
13:55.10dcordesgd
13:55.11dcordesbbl
13:55.21martin__me too
13:57.36martin__ginge_: um, not sure i saved changes to the kaiser-smd.c when i mentioned it above
13:57.48martin__dl it again if you did already
14:01.42ginge_d'oh
14:02.33ginge_martin__: arch/arm/mach-msm/kaiser-smd.c: In function 'smd_read': arch/arm/mach-msm/kaiser-smd.c:202: error: 'volatile struct smd_fifo' has no member named 'flags'
14:02.48ginge_do I need the .h too
14:03.42martin__ginge_: change it to do flags1 and flags2
14:04.08martin__i just edited the file on the webserver, can't try compiling it just now
14:05.01martin__ginge_: updated the file now
14:08.40premymartin_: As I was saying, the latest haret does detect smem.dll writing 1 at MSM_CSR_BASE + 0x404 and MSM_CSR_BASE + 0x408.
14:09.32premyThe bad news is that the current code is supposed to already be writing there, and it still does not work :-(
14:11.57*** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbfb340.pool.einsundeins.de)
14:14.59martin__premy: did you change kaiser-smd.c to match the struct I have now or just change the a9/a11 ptr shorts to ints?
14:15.21*** join/#htc-linux hagisbasheruk (n=hagisbas@78.148.135.168)
14:18.00premymartin__: I did the same kind of changes as you did, with the additional flag int.
14:29.08*** join/#htc-linux Xmoo (n=Info@h241015.upc-h.chello.nl)
14:40.23ginge_can anyone think of a reason that I am only getting haret boot 1 in 20 times instead of the 8 in 10 times I had before. I moved all the new files off and did a clean install, and still the same.
14:44.13*** join/#htc-linux TeringTu1y (n=maarten@195-241-125-243.ip.telfort.nl)
14:55.59martin__ginge_: I've found it's more reliable when triggered over haretconsole than by pressing the run button on the device
14:56.05martin__fuck knows why.
14:56.37ginge_interesting trying that. Was about to give up because I was on try 14 without boot. Damn thing
14:56.38martin__premy: okay, and that got you working read and no response to writes, but without the errors?
14:58.00martin__re-reads what you wrote above
14:59.09martin__okay, lemme rewrite this thing back to the common head/tail arrangement
14:59.27ginge_holy crap. remote boot worked!
15:01.29*** join/#htc-linux AstainHellbring (n=Administ@unaffiliated/astainhellbring)
15:04.34ginge_martin__: okay, booted into your zimage
15:04.56martin__Kevin2: any idea why triggering boot over haretconsole would work more reliably than by pressing 'Run' on the touchscreen or using the keyboard?
15:06.13ginge_so how do I test?
15:06.52martin__cat /dev/smd0 && echo "ATZ" > /dev/smd0
15:08.38ginge_holy crap.
15:08.46martin__what?
15:08.57ginge_I see loads of data. loads and loads
15:09.11martin__yeah it sends a lot of crap all the time
15:09.12ginge_inclusing a load of phone numbers
15:09.35ginge_okay control c anyone?
15:09.44martin__windows key then c
15:09.56ginge_no dice
15:10.08martin__feck
15:10.31ginge_any other vts?
15:10.31martin__it used to work, think maybe it broke in newer kb drivers in git or something
15:10.50ginge_I must remember to use screen :)
15:11.10martin__screen's no help if you've got no control key!
15:11.29ginge_I know some control keys work as I am using nano
15:11.39martin__huh, weird
15:12.20ginge_okay, so um what was that supposed to do?
15:14.26martin__you should have got OK back from the modem
15:14.31martin__in response to the ATZ
15:14.49martin__there's a terminal program called cu in that image i think
15:14.58martin__not used it but dcordes keeps going on about it
15:16.05dcordesI think in screen it worked last time I tried
15:16.16dcordeswhen I typed stuff it showed the same behaviour as cat & echo
15:16.23ginge_ok will try cu
15:16.27dcordes(critical errors)
15:17.20dcordescat /dev/smd0 & echo -e 'ATZ\r' > /dev/smd0 ?
15:21.29ginge_it vanishes off the screen before I can see the output
15:27.32*** join/#htc-linux dcordes (n=dcordes_@unaffiliated/dcordes)
15:29.33martin__i don't think it's going to work anyway
15:29.38martin__premy tried the same thing
15:29.59martin__but i've rewritten it with the normal head/tail setup now
15:30.12martin__along with the alignment fixes from premy
15:30.30martin__gimme a sec to confirm this version compiles ok
15:30.41ginge_good work. I am willing to test
15:31.32martin__make is rebuilding the entire kernel, dunno why
15:31.59martin__eh, screw it
15:32.12martin__http://void.printf.net/~martin/kaiser-smd.c <- again
15:33.52martin__I think this is the most likely version ever
15:36.53martin__wait
15:36.54martin__dammit
15:37.22martin__ginge_: don't boot that
15:37.37ginge_ooo just in time
15:37.40martin__premy: what you're seeing on your polaris doesn't match the kaiser
15:38.10martin__this is from kaiser:
15:38.12martin__000041f0  02 00 00 00 00 01 00 00  00 00 00 00 df 1e 00 00  |................|
15:38.15martin__00004200  df 1e 00 00 00 00 00 00  40 53 59 53 54 45 4d 54  |........@SYSTEMT|
15:38.23martin__see the two "df 1e"s
15:38.39martin__those are the head and tail, and they're shorts
15:38.51martin__the following zeros never change
15:40.03*** join/#htc-linux GPFerror (n=gpferror@cpe-76-187-41-132.tx.res.rr.com)
15:41.28martin__argh
15:41.36martin__premy: you're looking at it in the opposite byte order
15:42.55*** join/#htc-linux pH5 (n=ph5@e178210153.adsl.alicedsl.de)
15:43.17*** part/#htc-linux hagisbasheruk (n=hagisbas@78.148.135.168)
15:46.05premymartin__: I think we're seeing the same thing. My output was copied from haret, which groups 4 bytes at a time
15:47.01premySo your 02 00 00 00 match my 00000002 (= unsigned int flags1)
15:48.03martin__yeah, it's an endianness thing
15:48.11martin__but i still had the sizes wrong
15:50.24premymartin__: have you tried mytail = ch-> recv->a9_ptr at line 205. It think it would be the equivalent of what I have in my code.
15:51.10martin__the reason there's a9_ptr and a11_ptr
15:51.15martin__rather than head and tail
15:51.32martin__is i had a theory the roles of the pointer locations were swapped for read/write channels
15:51.57martin__i.e. the arm9 always wrote to one location and the arm11 the other, regardless of which way the data was going
15:52.10martin__that doesn't seem to be the case on any other htc
15:52.31martin__it was something of a desperate guess
15:52.47martin__so the version up now goes back to head/tail
15:53.53martin__this is what i'm putting now:
15:53.56martin__struct smd_fifo
15:53.56martin__{ volatile unsigned int flags1; volatile unsigned int flags2; volatile unsigned int empty1; volatile unsigned short head; volatile unsigned short empty2; volatile unsigned short tail; volatile unsigned short empty3; volatile unsigned int empty4; volatile char buffer[BUF_SIZE];
15:54.02martin__};
15:54.26premyuntil we figure out how the write works, we can't tell if your theory is right or not....
15:54.53martin__no, but we can try both ways
15:56.14martin__http://void.printf.net/~martin/kaiser-smd.c <- updated
15:56.17martin__got to do some work
15:56.19martin__back later
15:56.22martin__ginge_: try this one?
15:59.01*** join/#htc-linux rob_w (n=bob@X05cc.x.pppool.de)
16:04.01*** join/#htc-linux goxboxlive (n=goxboxli@160.84-48-176.nextgentel.com)
16:21.57*** join/#htc-linux rob_w (n=bob@X17b1.x.pppool.de)
16:34.44*** join/#htc-linux skodde (n=skodde@unaffiliated/skodde)
16:37.13*** join/#htc-linux JohnnyK (n=johnnyk@nfx-nat-229.pilsfree.net)
16:44.59*** join/#htc-linux pikapika (n=pikapika@mar75-8-88-164-227-147.fbx.proxad.net)
17:03.08*** join/#htc-linux LunohoD_ (n=alex@e180076116.adsl.alicedsl.de)
17:08.09*** join/#htc-linux Tonny_ (n=chatzill@set25-1-88-166-169-49.fbx.proxad.net)
17:36.51*** join/#htc-linux diogene31 (n=rj@mur31-2-82-243-122-54.fbx.proxad.net)
17:49.48*** join/#htc-linux TimRiker (n=timr@68-27-149-104.area1.spcsdns.net)
17:58.27*** join/#htc-linux Othello__ (i=Magorium@gateway/tor/x-73d7fccc7b5e806f)
18:08.08*** join/#htc-linux kiozen (n=oeichler@rgnb-5d865f3d.pool.einsundeins.de)
18:08.19kiozenhi
18:12.26*** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes)
18:29.44BabelOhi kiozen
18:29.48BabelOhi goxboxlive
18:30.41kiozenhi BabelO
18:35.50dcordesmartin__: seems like the kernel dies after write attempt with latest kaiser-smd.c
18:36.01*** join/#htc-linux marex (n=marex@85-132-216-250-eth3-gwfm10-user.802.cz)
18:36.11dcordeshi martin__
18:36.13dcordesmarex:
18:36.34marexhi
18:39.57dcordesmartin__: rebooted, created node, wrote, kernel died again
18:48.33dcordesjust the second you put "echo something > /dev/smd0" it locksup
19:24.56cr2kiozen: thanks :D
19:25.15kiozenwellcome :)
19:25.34kiozencr2: lube that brain :P
19:25.54cr2:)
19:26.13cr2i don't drink so much :)
19:26.41kiozenI guess so, but maybe on a bad day...
19:27.01kiozenbut don't forget how to merge the kernel!
19:27.49cr2yeah, i'm a bit disappointed that we can't finish full support for any of our devices...
19:28.16cr2patching the kernel goes always :-)
19:28.52kiozenyes it's a pitty. but aren't we close for the n560?
19:29.06cr2i can start windows just for fun, but will never consider it for anything serious.
19:29.33cr2yes, the n560 looks most promising because it doesn't have phone and weird asics.
19:30.32kiozenaren't the phones just like modms with a AT command set?
19:31.34cr2yes, but you are also troubled by the gui support and issues, wakeup+gui problems and such things.
19:32.14kiozena qtopia issue?
19:32.56cr2if the modem control is on an uart, then it's relatively easy. but it may be on DPRAM or this confusing arm9<->arm11 ipc on msm.
19:33.05cr2qtopia issues too.
19:33.36cr2qtopia seems to be most close to real phone support, but it's unfinished too.
19:33.50*** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbfb340.pool.einsundeins.de)
19:34.01kiozenqtopia is strange
19:34.06cr2these are just minor things that spoil the final result.
19:34.40kiozenI always wonder if it is worth writing M for QT, afaik it should run with qtopia too
19:34.43cr2i don't mind to run x11+qt4-core, but it's probably a bad option for 64MB devices.
19:34.54kiozenhm, ok
19:35.39kiozenis there a way to define some reachable short term goals for the loox?
19:35.56kiozenI would like to see it boot savely and to run M
19:35.59cr21. fix haret to boot reliably.
19:36.17kiozeneg. sound is not so important, we can skip that
19:36.31cr22. check why the wm9750 support can't be configured and compiled in. it's some kernel Kconfig issue.
19:37.20cr2i may export the led/cpld gpios to /sys, because i'm not sure which gpio controls which LED.
19:37.23kiozenif I understood you right suspend/resume works now 100%?
19:37.33cr2then you can play from userspace with the gpios.
19:37.46cr2the LCD resume/suspend works 100%
19:37.58kiozenok, leds are nice but not necessary for the 1st shot
19:38.05cr2and it's the most hungry power sink.
19:38.21kiozenyes 100% lcd control is important
19:38.49cr2with 2MB offset i've done almost everything i could to not break the resume process.
19:39.00cr2lcd and bkl are 100% supported.
19:39.15cr2and the blue led key backlight.
19:39.48cr2gps works 100%
19:39.59kiozenoh yeah that obnoxious little blue led thing
19:40.13cr2bt is detected, but i need the clean userspace to support it.
19:40.31kiozenbt is kind of important as the internal gps is bad
19:40.47cr2imvho the kernel bt side is finished. (power+reset)
19:40.51cr2yes.
19:41.11kiozenthus so far it is haret support and bt...
19:41.29cr2the cpu frequency+voltage is a userspace issue too.
19:41.35kiozenok
19:41.44cr2ok, haret support is my problem :)
19:41.54cr2how do you suggest to test bt ?
19:42.14kiozenyou need a gps mouse?
19:42.23kiozenI can send you one
19:42.38kiozenwith static navigation :P
19:42.44cr2i'd obviously need to fix haret and make it boot 100% reliably. like on most other non-msm phones
19:42.52cr2no, i have it.
19:43.14cr2i need a new qtopia rootfs.
19:43.41cr2with the bluez et al.
19:43.41kiozenme too, installed suse11 repartitioned my hdd
19:43.57cr2and debian, or whatever.
19:44.08kiozenthink I should spent the next days compiling oe and qtopia
19:44.14cr2or angstrom-console, i don't care.
19:44.21cr2ok.
19:44.44kiozenlet's hope this works without testing all steps :)
19:45.07cr2i hope so.
19:45.44cr2we can take this 'titchy' (?) debian for the uni, if everything else fails.
19:45.52kiozenok, that sounds like a plan to me: you try to fix haret, I do the rootfs stuff, then you can do bt hopefully
19:46.16kiozenand then we should have something to start with.
19:47.07kiozenI am realy looking forward to proofe that Garmin isn't the only decision
19:48.47kiozenafaik I don't need a kernel for oe / qtopia, right?
19:49.15diogene31cr2: Are you on arm based cpu ? If yes, Angstrom has support for bluetooth out of the box. I also have a rootfs I used to debug the usb driver, with pan support for ssh login over bluetooth.
19:49.28Xmoodcordes
19:49.33Xmoosatherday venlo? :P
19:50.09BabelOcr2: take the one from BA or artemis is better , should be ok for you, there is M inside too
19:50.46BabelOcr2: http://www.linuxtogo.org/~htcpxa/htcartemis/qtopia/QtopiaPhone-artemis-image.rootfs.tar.bz2
19:52.42cr2diogene31: n560 is a pxa270 based pda. the bt (brf6150) is on btuart, so it's nothing more than your slightly modified driver there.
19:53.02cr2to support power and reset. it's all in the hh.org CVS
19:53.47diogene31cr2: So, if you need a rootfs with bluetooth and Qtopia (mine, to be replaced by yours), I can give one for free.
19:54.05ginge_hx4700 stuff supprts the brf6150
19:54.10cr2diogene31: the resume is a real PITA, because it goes through the ipl to spl (resident in ram), enables the MMU and then jumps to wince. it's the most complex resume path i've ever seen on htc devices.
19:54.34cr2diogene31: lol, give me the url :)
19:55.02diogene31cr2: Ouch. Normally IPL has a test to jump directly to RAM. What you describe ... really stinks :)
19:55.39*** part/#htc-linux premy (n=pr@133.190.98-84.rev.gaoland.net)
19:55.55cr2ginge_: brf6150 is everywhere, you don't really need support for it.
19:56.02*** join/#htc-linux Babel1 (n=BabelO@lun34-2-82-238-28-28.fbx.proxad.net)
19:56.28cr2ginge_: hx4700 had a modified hciattach to upload .bts firmware fixes
19:56.44ginge_no, but you need to initialise the hardware using gpios. The 4700 tree has good examples of how that works. iirc
19:56.46kiozen: ahh BabelO has now splitted personality
19:57.02cr2ginge_: but it's not very useful to upload the same firmware on all other devices (including the phones)
19:57.26ginge_cr2: true enough
19:58.31cr2ginge_: yes, but it's only about power and reset. the hx4700 support for bt on btuart, with busy looping on the RTS is a hack at its best. but since nobody has written better code, it's reused all over the place :)
19:59.01Babel1kiozen: swimminng pool, yes ;)
19:59.08kiozenLOL
19:59.22kiozenhave to look in google earth :P
20:00.10kiozen: if I still had these coords :)
20:00.42*** join/#htc-linux ellisway (n=ellis@80-46-67-47.static.dsl.as9105.com)
20:02.03kiozengot no pool, just a river
20:05.04Babel1kiozen: really bad coord then ;)
20:05.39kiozenBabel1: for the river ore the pool?
20:07.45*** join/#htc-linux AstainHellbring (n=Administ@unaffiliated/astainhellbring)
20:16.52diogene31cr2: Sorry, my coffee machine ... exploded a bit ... I made a mess of it.
20:16.58Babel1kiozen: pm
20:17.03diogene31cr2: Here is the link: http://belgarath.falguerolles.org/download/mio_a701/rootfs/mio_current_rootfs.tar.gz
20:28.22*** join/#htc-linux kiozen (n=oeichler@rgnb-5d865f3d.pool.einsundeins.de)
20:28.35kiozengrrr, this suse 11 is broken
20:30.58cr2diogene31: thanks, downloading.
20:31.33diogene31cr2: OK. Be prepared, at 128kb/s, it will be ... long.
20:31.51*** part/#htc-linux Babel1 (n=BabelO@lun34-2-82-238-28-28.fbx.proxad.net)
20:36.47cr2diogene31: 100k is ok.
20:42.09martin__dcordes: hmm, that's a new one
20:42.34martin__dcordes: try turning on the debug printks?
20:44.26cr2diogene31: downloaded.
20:45.08diogene31cr2: Good. My internet provider improved.
20:54.14dcordesmartin__: did you already test it?
20:58.41cr2diogene31: you'd clean ./var/spool/at/ :)
21:09.29cr2hmm
21:09.52cr2diogene31: you don't start sshd on usb ?
21:10.18diogene31cr2: Cleanup ... yes, my wife is always telling me :)
21:10.35diogene31cr2: And yes, I do actually start sshd on usb (called dropbear).
21:19.09cr2strange.
21:33.00*** join/#htc-linux LunohoD_ (n=alex@e180066036.adsl.alicedsl.de)
21:34.40diogene31cr2: Why strange ? Can't you logon onto your PDA ?
21:44.37martin__dcordes: I'm still at work :(
21:45.46dcordesmartin__: I doubt printk will help
21:45.54dcordeswhat did you change regarding the write?
21:46.14dcordesI wonder where it writes now that causes the arm11 to freeze and not the modem
21:47.29cr2diogene31: no. maybe the modules do not match. but it's strange anyway. i think i have the usb ethernet in the kernel, and i see the cdc-ether device.
21:48.35diogene31cr2: what happens in kernel logs ? (dmesg)
21:50.25diogene31cr2: Especially, do you see something like : usb0: full speed config #1: 100 mA, Ethernet Gadget, using CDC Ethernet Subset
21:51.43martin__dcordes: I swapped the head and tail back to normal again
21:52.34dcordesmartin__: the short/int thing?
21:53.21*** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes)
21:55.08*** join/#htc-linux surgex (i=surge@pool-71-186-163-107.bflony.fios.verizon.net)
22:00.08martin__dcordes: no, the a9/a11 vs head/tail thing
22:00.34martin__but after fixing the smd_fifo struct after premy pointed out it was wrong
22:00.51martin__he already tried it with a fixed struct and a9/a11
22:02.19dcordesmartin__: did you read yesterday's logs?
22:04.46dcordesdzo had some ideas on kaiser-smd.c
22:15.09cr2diogene31: i can't log in, so there is no dmesg
22:15.28cr2diogene31: it's the same kernel that i was using the the rootfs compiled by kiozen.
22:15.45cr2s/using the/using with/
22:16.28diogene31cr2: The message I'm talking about is triggered by unplug+plug of usb cable. Can you see it on the screen ?
22:19.18cr2diogene31: no, it's some backlight issue. backlight is not switched off at boot.
22:19.37cr2hmm. it seems i need to recompile the kernel
22:19.57cr2i hate the braindead pxafb driver ;)
22:20.21diogene31cr2: Rewrite it :)
22:31.02*** join/#htc-linux SmallR2002 (n=SmallR20@c-67-162-60-33.hsd1.il.comcast.net)
22:35.29cr2diogene31: switching to 2.6.26+ may be a better idea. but i need pH5 for that :)
22:36.16AstainHellbringcr2 i know mistadman did something with the pxafb driver...
22:36.38diogene31cr2: OK.
22:39.41Kevin2martin__: That is odd.  I'd guess there is something in the kernel that reacts better when wifi/usb (whatever you used haretconsole on) is in an active state.
22:47.08cr2AstainHellbring: ?
22:47.43AstainHellbringmistadman said that he rewrote the pxa display drivers to add double buffering and something else I think...
22:47.45cr2AstainHellbring: athena has an atiw2284 chip. linux kernel uses vsfb now.
22:48.22AstainHellbringok... so it just uses ati not pxda then...?
22:48.43cr2i've written this driver, so i know what i'm talking about :)
22:49.34cr2it uses vsfb, ie. verysimpleframebuffer. just writes to the ati SDRAM already set up by wince.
22:49.49AstainHellbringahh ok
22:50.14AstainHellbringall I had heard was that mistadman said he did some writing to the driver to do something with double buffering
22:50.47cr2double buffering can be done by an application.
22:51.24cr2hehe, we are talking about android here. is the android source available ?
22:52.56cr2Kevin2: did you already gave up with hermes ?
22:54.12cr2Kevin2: i've found the newer s3c2442 datasheet, maybe we'd make the next try with the serial ports. if the atcmd port will works, a lot of crazy android people will jump in :)
22:55.58*** join/#htc-linux DesktopMa (n=DesktopM@gprs-ggsn5-nat.mobil.telenor.no)
22:56.47Kevin2cr2: I'm not sure what you mean by "gave up".  I still have the Hermes, and would be willing to help.  However, I wont be able to contribute nearly as much as I used to.
22:58.17Kevin2I think the big problem with Hermes was lack of access to any storage.  Modem access would be cool, but really difficult to develop if you can't save/restore programs easily.
22:59.19DesktopMaback at work today, though can only do limited testing. internet is down at work so I'm using my phone
23:07.30cr2Kevin2: ok. once pH5 will make asic3_mmc work, i'll return to atiw_mmc
23:09.33cr2Kevin2: i'm also working on the better pxa27x support for haret. is it possible to make 'testPXA27x', and not only 'testPXA' ? i'll also vote for removing the obsolete pxa-specific commands like GPLR, and 'dump gpio'
23:19.17Kevin2cr2: Sure - you can add a testPXA27x().
23:26.28*** join/#htc-linux AstainHellbring (n=Administ@unaffiliated/astainhellbring)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.