00:00.21 | cr2 | dzo: i thought they are already known ? |
00:00.33 | dcordes | kaiser mmu with new haret at: http://linuxtogo.org/~lgorris/haretlog-20080623_015359.log |
00:00.50 | dzo | last bit of code i saw just wrote to them all and crashed the radio.. |
00:01.55 | dcordes | dzo: 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.19 | dcordes | dzo: martin__ had the idea that we probably write to a wrong area which makes the modem crash |
00:02.52 | dzo | dcordes, that's what I mean, it should only write to one address in MSM_CSR+0x400 |
00:02.52 | cr2 | dcordes: it's not the latest haret |
00:03.34 | *** join/#htc-linux mistadman2 (n=mistadma@adsl-156-124-98.msy.bellsouth.net) |
00:04.05 | cr2 | mistadman2: do you have gps and bt working ? |
00:04.18 | dcordes | dzo: right we have gps working on kaiser now |
00:04.28 | dcordes | cr2: I used haret-20080622-mmu2.exe for that dump |
00:05.02 | dcordes | dzo: MSM_CSR? |
00:05.04 | cr2 | dcordes: http://www.handhelds.org/~koconnor/haret/haret-20080622-mmu3.exe |
00:05.10 | dcordes | oh darn |
00:05.12 | dzo | good, I haven't looked at it on vogue, just another smem channel i think. |
00:05.30 | dcordes | yep maybe you wanna look at our kaiser-smd.c will pastebin |
00:07.23 | mistadman2 | cr2: Haven't gotten that far. Sorry. |
00:08.16 | dzo | the 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.32 | dcordes | like crashing the modem? |
00:08.42 | dzo | look like it |
00:08.49 | dzo | s/look/looks/ |
00:09.32 | dzo | can you not mmutrace MSM_CSR? |
00:09.38 | dcordes | dzo: 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.57 | cr2 | mistadman2: finish the dpram first. |
00:10.11 | dcordes | dzo: what's MSM_CSR? |
00:10.14 | cr2 | good night. |
00:10.18 | dcordes | night |
00:10.35 | mistadman2 | cr2: I will. And thanks for you help!!! |
00:10.36 | cr2 | dcordes: 0xb4e00000 0xb4f00000 0xc0100000 1 MSM_CSR/MSM_GPT |
00:11.06 | dcordes | b4f0 is familiar |
00:11.21 | dzo | line 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.42 | dcordes | aah we were thinking of irqs to be the problem with notification |
00:12.04 | dzo | it is an irq to the A9, yes. |
00:12.07 | cr2 | dzo: does vogue use an uart ? i see uart3 being referenced on diamond. |
00:12.44 | dcordes | dzo: so how would I figure what's wrong there? |
00:12.51 | dzo | it could do for BT but that's low down my list of things to do. |
00:13.03 | cr2 | ok. |
00:13.25 | cr2 | dcordes: got bt running on kaiser ? |
00:13.50 | dzo | addlist mmutrace 0xb4f00400 0x100 |
00:14.37 | dcordes | cr2: http://linuxtogo.org/~lgorris/kaiser-mmu3.txt |
00:14.40 | dzo | or another address that maps to 0xc0100000 with the correct TEX bits set. |
00:14.56 | dcordes | cr2: no we weren't able to try because I haven't the bluetooth rootfs done yet |
00:15.27 | dcordes | dzo: tex bits? will do addlist mmutrace 0xb4f00400 0x100 |
00:15.30 | cr2 | ok. |
00:16.09 | dzo | may be 0x4a201400 rather than b4f00400 |
00:16.36 | dzo | or 4a30e400 |
00:16.38 | dcordes | HaRET(1)# addlist mmutrace 0xb4f00400 0x100 |
00:16.38 | dcordes | HaRET(2)# wirq 50 |
00:16.38 | dcordes | Terminating haret due to unhandled exception (pc=00016864) |
00:16.58 | dzo | or 4fc01400 |
00:17.12 | cr2 | dzo: there are 16 channels ? |
00:18.38 | cr2 | added to kaiser wiki |
00:19.05 | dzo | yes, on vogue 3 and 4 do SMEM channel notify 6 is proc_comm 5 is smsm |
00:19.35 | cr2 | ok. |
00:19.57 | cr2 | good night :) |
00:20.25 | dcordes | haret-20080622-mmu3.exe always dies on wirq |
00:21.02 | dcordes | I'll use the version I used before |
00:21.20 | dcordes | haret-20080613-swp3.exe |
00:24.16 | dcordes | dzo: ok "mmutrace 0xb4f00400 0x100" produces a lot of output, no matter if modem is on/off |
00:26.33 | dzo | ok, paste some of it and i'll have a look. |
00:27.46 | dzo | or try mmutrace 0xb4f00400 0x40 |
00:27.49 | dcordes | http://rafb.net/p/vE50rf87.html |
00:28.15 | dcordes | with 0x4a201400 it deadlocked after I turned on the phone in wince |
00:28.23 | dzo | ok, do mmutrace 0xb4f00400 0x38 |
00:29.19 | dcordes | booting.. |
00:33.06 | dcordes | lol now what's that |
00:33.33 | dcordes | I had the phone off, then while running mmutrace on 0xb4f00400 0x38 I tried to enable it |
00:33.40 | dcordes | but it just stayed off with no error message |
00:34.09 | dzo | did the trace print anything? |
00:34.19 | dcordes | no |
00:34.23 | dzo | try with the phone already on |
00:34.32 | dcordes | doing that now |
00:37.24 | dcordes | hmnothing |
00:37.36 | dcordes | dzo: also dialed customer service |
00:37.51 | dcordes | no reads/writes on 0xb4f00400 0x38 |
00:39.42 | dzo | of, it's probably mapped from one of the other addresses try 0x4a201400 0x38 instead (assuming 4K and 1K page tracing works) |
00:40.49 | dzo | also, bear in mind those mappings may change when you reboot the phone. |
00:41.22 | dzo | so do dump mmu and look for 0xc00100000 |
00:41.37 | dzo | s/0xc0100000 |
00:41.51 | dcordes | again a lock |
00:41.54 | dzo | s/0xc00100000/0xc0100000 |
00:42.08 | dcordes | traced 0x4a201400 0x38, turned off phone, lock |
00:42.22 | dcordes | and no output |
00:42.42 | dzo | have you been able to trace 4k pages before? |
00:43.09 | dcordes | one second I have some logs of 4k traces I think |
00:43.17 | dzo | try one of the other mappings e.g. 4a30e400 |
00:43.42 | dcordes | there are always two 4K pages that map to smem phys (0x01f* |
00:44.25 | dcordes | are you using http://linuxtogo.org/~lgorris/kaiser-mmu3.txt for referrence? |
00:44.43 | dzo | yes i was, and mmu2.txt |
00:46.51 | dcordes | addlist mmutrace 0x4a30e400 0x38 -> nothing |
00:47.07 | dcordes | I should get accesses when I dial a number, shouldn't I? |
00:47.42 | dzo | yes, but only when you press call. |
00:48.08 | dcordes | I did |
00:48.33 | dcordes | dzo: can you look at this trace I made a few days ago? http://rafb.net/p/KDZF2b87.html |
00:49.52 | dzo | thats the audio parameters being sent to to the ADSP to route audio to the handset. |
00:50.55 | dcordes | so that's not the MSM_CSR thing we are looking for, but still useful isn't it? |
00:52.17 | dzo | yes, useful but not for a while and android does all that in userspace. |
00:52.31 | dcordes | ok |
00:53.16 | dzo | Ok, I've got to go, have a pile of work to do. keep tracing. |
00:53.39 | dcordes | hm what where in the map do I look up the regs? |
00:54.02 | dzo | which regs? MSM_CSR? |
00:54.12 | dcordes | just things that map to 0xc0100000? |
00:54.47 | dzo | dump mmu then grep for c0100000 |
00:55.40 | dcordes | the reason for redoing the mmudump is, the virtual mapping to that area can change after a reboot? |
00:56.04 | dzo | yes possibly, may not though. |
00:57.34 | dzo | ok bye |
01:01.25 | *** join/#htc-linux dcordes_ (n=dcordes@unaffiliated/dcordes) |
01:02.32 | dcordes_ | 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.51 | dcordes_ | it should have all the bluetooth stuff, good night |
01:48.13 | Kevin2 | http://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.53 | DesktopMa | poke me when I need to test stuff |
01:58.01 | DesktopMa | I'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.01 | goxboxlive | Hi 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.43 | dcordes | Kevin2: thanks, wirq works again with the update |
11:24.44 | dcordes | when 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.45 | dcordes | 0xb4f00000 1024*1024 I get a lot of output |
11:24.46 | pikapika | hello |
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.02 | dcordes | martin__: ping |
11:31.08 | dcordes | seen 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.18 | premy | Hi |
11:49.13 | premy | I've been playing with the new haret on my polaris. |
11:50.49 | premy | I think I got some interesting traces : addlsit mmutrace 0x4a301400 0x100 shows some activity when placing a call at addresses 0x4a301404 and 0x4a301408 |
11:52.22 | premy | These addresses match (MSM_CSR_BASE + 0x400 + 1*4) and (MSM_CSR_BASE + 0x400 + 2*4) |
11:57.14 | premy | smem.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.54 | cr2 | premy: do you see the activity in other channels ? gps ? |
12:27.00 | premy | cr2: I'm not getting anything from tracing the whole of the shared RAM, even during a call. |
12:50.10 | premy | martin__:Hi, I've looked at your new version of kaiser-smd.c |
12:50.40 | premy | martin__: I'm not sure, but shouldn't your a11_ptr and a9_ptr be ints rather than shorts ? |
12:51.00 | premy | martin__: here's what I get on my polaris: |
12:51.15 | premy | HaRET(25)# vdump 0xb51041F0 0x100 |
12:51.21 | premy | b51041f0 | 00000002 00000100 00000000 0000112f |
12:51.29 | premy | b5104200 | 0000112f 00000000 455a5441 3d305330 |
12:51.58 | premy | .... |
12:51.59 | dcordes | premy: looks like the start of a fifo |
12:52.02 | cr2 | premy: looks like ascii to me 455a5441 3d305330 |
12:52.20 | cr2 | dcordes: what is 00000002 00000100 00000000 |
12:52.33 | dcordes | premy: save it and run it through hexdump -C |
12:52.35 | cr2 | dcordes: it seems to be the same on all msm7xxx |
12:52.45 | dcordes | cr2: I talked about it with martin__ |
12:52.49 | premy | Yes that's the start of the send buffer. |
12:53.10 | dcordes | cr2: I think he said it might be an start indicator or so |
12:53.30 | premy | The 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.31 | dcordes | premy: did you try kaiser-smd.c out? |
12:53.43 | premy | Which might explain the modem caughing about it. |
12:53.45 | cr2 | premy: do you see anything at MSM_CSR_BASE + 0x400 + N*4, for N > 1 |
12:54.24 | premy | cr2: yes, N=2, when placing a call. I've not tried much more than calling, though. |
12:54.46 | dcordes | premy: because of *ptr are shorts? |
12:55.49 | premy | with 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.11 | dcordes | interesting |
12:57.51 | premy | I 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.30 | premy | The current code is actually writing at the addresses where I saw some activity. |
13:01.04 | cr2 | premy: which code writes to the fifo ? |
13:01.11 | cr2 | premy: in wince. |
13:01.34 | cr2 | ah, you don't see it :( |
13:01.44 | premy | cr2: that's right |
13:03.59 | cr2 | premy: and the 1 and 2 channels at CSR are controlled by smem.dll ? |
13:07.10 | premy | smem.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.34 | martin__ | premy: why do you think they should be ints? |
13:39.10 | martin__ | Look at a dump of the smem and see the heads and tails. They're 16 bit and aligned as such. |
13:40.18 | cr2 | martin__: you'd find the code that uses them. then we will look at .S |
13:41.00 | martin__ | 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.58 | martin__ | I'm at work now, should be able to look at things later. |
13:47.57 | martin__ | premy: wait, you're right, i'm an idiot, i can't count bits |
13:49.26 | martin__ | http://void.printf.net/~martin/kaiser-smd.c <- updated with sensible struct |
13:49.43 | martin__ | dcordes: try the above? |
13:49.50 | martin__ | premy: thanks! |
13:50.02 | dcordes | martin__: later I'm in bed with illness |
13:50.05 | martin__ | ok |
13:50.15 | martin__ | may get a chance myself later |
13:50.58 | martin__ | ginge_: try it if you get a chance |
13:51.24 | ginge_ | will try it now |
13:51.45 | martin__ | if it doesn't work, maybe the assumption the head/tail are swapped for writes is wrong |
13:52.09 | martin__ | so we can try switching those back |
13:52.31 | martin__ | if it still doesn't work, we're probably missing the right notify to the arm |
13:53.04 | ginge_ | It might not boot with the bluetooth driver code I am working on ;) |
13:53.49 | martin__ | cr2: can you look at a kaiser smem.dll for something that writes a 1 to MSM_CSR_BASE+something? |
13:54.25 | martin__ | i.e. the equivalent of notify_other_smd() in the linux code |
13:54.25 | dcordes | ginge_: martin__ you guys seen the bluez-utils image? |
13:54.36 | martin__ | dcordes: i've dl'ed it, yeah, cheers |
13:54.43 | martin__ | and the new haret too |
13:54.46 | dcordes | it lacks the firmware |
13:54.48 | dcordes | s |
13:54.59 | dcordes | martin__: you got haret*3.exe or 2? |
13:55.01 | ginge_ | yeah, just need to put the firmware in it |
13:55.04 | martin__ | i've got 3 |
13:55.10 | dcordes | gd |
13:55.11 | dcordes | bbl |
13:55.21 | martin__ | me too |
13:57.36 | martin__ | ginge_: um, not sure i saved changes to the kaiser-smd.c when i mentioned it above |
13:57.48 | martin__ | dl it again if you did already |
14:01.42 | ginge_ | d'oh |
14:02.33 | ginge_ | 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.48 | ginge_ | do I need the .h too |
14:03.42 | martin__ | ginge_: change it to do flags1 and flags2 |
14:04.08 | martin__ | i just edited the file on the webserver, can't try compiling it just now |
14:05.01 | martin__ | ginge_: updated the file now |
14:08.40 | premy | martin_: 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.32 | premy | The 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.59 | martin__ | 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.00 | premy | martin__: 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.23 | ginge_ | 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.59 | martin__ | ginge_: I've found it's more reliable when triggered over haretconsole than by pressing the run button on the device |
14:56.05 | martin__ | fuck knows why. |
14:56.37 | ginge_ | interesting trying that. Was about to give up because I was on try 14 without boot. Damn thing |
14:56.38 | martin__ | premy: okay, and that got you working read and no response to writes, but without the errors? |
14:58.00 | martin__ | re-reads what you wrote above |
14:59.09 | martin__ | okay, lemme rewrite this thing back to the common head/tail arrangement |
14:59.27 | ginge_ | holy crap. remote boot worked! |
15:01.29 | *** join/#htc-linux AstainHellbring (n=Administ@unaffiliated/astainhellbring) |
15:04.34 | ginge_ | martin__: okay, booted into your zimage |
15:04.56 | martin__ | 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.13 | ginge_ | so how do I test? |
15:06.52 | martin__ | cat /dev/smd0 && echo "ATZ" > /dev/smd0 |
15:08.38 | ginge_ | holy crap. |
15:08.46 | martin__ | what? |
15:08.57 | ginge_ | I see loads of data. loads and loads |
15:09.11 | martin__ | yeah it sends a lot of crap all the time |
15:09.12 | ginge_ | inclusing a load of phone numbers |
15:09.35 | ginge_ | okay control c anyone? |
15:09.44 | martin__ | windows key then c |
15:09.56 | ginge_ | no dice |
15:10.08 | martin__ | feck |
15:10.31 | ginge_ | any other vts? |
15:10.31 | martin__ | it used to work, think maybe it broke in newer kb drivers in git or something |
15:10.50 | ginge_ | I must remember to use screen :) |
15:11.10 | martin__ | screen's no help if you've got no control key! |
15:11.29 | ginge_ | I know some control keys work as I am using nano |
15:11.39 | martin__ | huh, weird |
15:12.20 | ginge_ | okay, so um what was that supposed to do? |
15:14.26 | martin__ | you should have got OK back from the modem |
15:14.31 | martin__ | in response to the ATZ |
15:14.49 | martin__ | there's a terminal program called cu in that image i think |
15:14.58 | martin__ | not used it but dcordes keeps going on about it |
15:16.05 | dcordes | I think in screen it worked last time I tried |
15:16.16 | dcordes | when I typed stuff it showed the same behaviour as cat & echo |
15:16.23 | ginge_ | ok will try cu |
15:16.27 | dcordes | (critical errors) |
15:17.20 | dcordes | cat /dev/smd0 & echo -e 'ATZ\r' > /dev/smd0 ? |
15:21.29 | ginge_ | it vanishes off the screen before I can see the output |
15:27.32 | *** join/#htc-linux dcordes (n=dcordes_@unaffiliated/dcordes) |
15:29.33 | martin__ | i don't think it's going to work anyway |
15:29.38 | martin__ | premy tried the same thing |
15:29.59 | martin__ | but i've rewritten it with the normal head/tail setup now |
15:30.12 | martin__ | along with the alignment fixes from premy |
15:30.30 | martin__ | gimme a sec to confirm this version compiles ok |
15:30.41 | ginge_ | good work. I am willing to test |
15:31.32 | martin__ | make is rebuilding the entire kernel, dunno why |
15:31.59 | martin__ | eh, screw it |
15:32.12 | martin__ | http://void.printf.net/~martin/kaiser-smd.c <- again |
15:33.52 | martin__ | I think this is the most likely version ever |
15:36.53 | martin__ | wait |
15:36.54 | martin__ | dammit |
15:37.22 | martin__ | ginge_: don't boot that |
15:37.37 | ginge_ | ooo just in time |
15:37.40 | martin__ | premy: what you're seeing on your polaris doesn't match the kaiser |
15:38.10 | martin__ | this is from kaiser: |
15:38.12 | martin__ | 000041f0 02 00 00 00 00 01 00 00 00 00 00 00 df 1e 00 00 |................| |
15:38.15 | martin__ | 00004200 df 1e 00 00 00 00 00 00 40 53 59 53 54 45 4d 54 |........@SYSTEMT| |
15:38.23 | martin__ | see the two "df 1e"s |
15:38.39 | martin__ | those are the head and tail, and they're shorts |
15:38.51 | martin__ | 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.28 | martin__ | argh |
15:41.36 | martin__ | 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.05 | premy | martin__: I think we're seeing the same thing. My output was copied from haret, which groups 4 bytes at a time |
15:47.01 | premy | So your 02 00 00 00 match my 00000002 (= unsigned int flags1) |
15:48.03 | martin__ | yeah, it's an endianness thing |
15:48.11 | martin__ | but i still had the sizes wrong |
15:50.24 | premy | martin__: 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.10 | martin__ | the reason there's a9_ptr and a11_ptr |
15:51.15 | martin__ | rather than head and tail |
15:51.32 | martin__ | is i had a theory the roles of the pointer locations were swapped for read/write channels |
15:51.57 | martin__ | i.e. the arm9 always wrote to one location and the arm11 the other, regardless of which way the data was going |
15:52.10 | martin__ | that doesn't seem to be the case on any other htc |
15:52.31 | martin__ | it was something of a desperate guess |
15:52.47 | martin__ | so the version up now goes back to head/tail |
15:53.53 | martin__ | this is what i'm putting now: |
15:53.56 | martin__ | struct smd_fifo |
15:53.56 | martin__ | { 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.02 | martin__ | }; |
15:54.26 | premy | until we figure out how the write works, we can't tell if your theory is right or not.... |
15:54.53 | martin__ | no, but we can try both ways |
15:56.14 | martin__ | http://void.printf.net/~martin/kaiser-smd.c <- updated |
15:56.17 | martin__ | got to do some work |
15:56.19 | martin__ | back later |
15:56.22 | martin__ | 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.19 | kiozen | hi |
18:12.26 | *** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes) |
18:29.44 | BabelO | hi kiozen |
18:29.48 | BabelO | hi goxboxlive |
18:30.41 | kiozen | hi BabelO |
18:35.50 | dcordes | martin__: 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.11 | dcordes | hi martin__ |
18:36.13 | dcordes | marex: |
18:36.34 | marex | hi |
18:39.57 | dcordes | martin__: rebooted, created node, wrote, kernel died again |
18:48.33 | dcordes | just the second you put "echo something > /dev/smd0" it locksup |
19:24.56 | cr2 | kiozen: thanks :D |
19:25.15 | kiozen | wellcome :) |
19:25.34 | kiozen | cr2: lube that brain :P |
19:25.54 | cr2 | :) |
19:26.13 | cr2 | i don't drink so much :) |
19:26.41 | kiozen | I guess so, but maybe on a bad day... |
19:27.01 | kiozen | but don't forget how to merge the kernel! |
19:27.49 | cr2 | yeah, i'm a bit disappointed that we can't finish full support for any of our devices... |
19:28.16 | cr2 | patching the kernel goes always :-) |
19:28.52 | kiozen | yes it's a pitty. but aren't we close for the n560? |
19:29.06 | cr2 | i can start windows just for fun, but will never consider it for anything serious. |
19:29.33 | cr2 | yes, the n560 looks most promising because it doesn't have phone and weird asics. |
19:30.32 | kiozen | aren't the phones just like modms with a AT command set? |
19:31.34 | cr2 | yes, but you are also troubled by the gui support and issues, wakeup+gui problems and such things. |
19:32.14 | kiozen | a qtopia issue? |
19:32.56 | cr2 | if 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.05 | cr2 | qtopia issues too. |
19:33.36 | cr2 | qtopia 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.01 | kiozen | qtopia is strange |
19:34.06 | cr2 | these are just minor things that spoil the final result. |
19:34.40 | kiozen | I always wonder if it is worth writing M for QT, afaik it should run with qtopia too |
19:34.43 | cr2 | i don't mind to run x11+qt4-core, but it's probably a bad option for 64MB devices. |
19:34.54 | kiozen | hm, ok |
19:35.39 | kiozen | is there a way to define some reachable short term goals for the loox? |
19:35.56 | kiozen | I would like to see it boot savely and to run M |
19:35.59 | cr2 | 1. fix haret to boot reliably. |
19:36.17 | kiozen | eg. sound is not so important, we can skip that |
19:36.31 | cr2 | 2. check why the wm9750 support can't be configured and compiled in. it's some kernel Kconfig issue. |
19:37.20 | cr2 | i may export the led/cpld gpios to /sys, because i'm not sure which gpio controls which LED. |
19:37.23 | kiozen | if I understood you right suspend/resume works now 100%? |
19:37.33 | cr2 | then you can play from userspace with the gpios. |
19:37.46 | cr2 | the LCD resume/suspend works 100% |
19:37.58 | kiozen | ok, leds are nice but not necessary for the 1st shot |
19:38.05 | cr2 | and it's the most hungry power sink. |
19:38.21 | kiozen | yes 100% lcd control is important |
19:38.49 | cr2 | with 2MB offset i've done almost everything i could to not break the resume process. |
19:39.00 | cr2 | lcd and bkl are 100% supported. |
19:39.15 | cr2 | and the blue led key backlight. |
19:39.48 | cr2 | gps works 100% |
19:39.59 | kiozen | oh yeah that obnoxious little blue led thing |
19:40.13 | cr2 | bt is detected, but i need the clean userspace to support it. |
19:40.31 | kiozen | bt is kind of important as the internal gps is bad |
19:40.47 | cr2 | imvho the kernel bt side is finished. (power+reset) |
19:40.51 | cr2 | yes. |
19:41.11 | kiozen | thus so far it is haret support and bt... |
19:41.29 | cr2 | the cpu frequency+voltage is a userspace issue too. |
19:41.35 | kiozen | ok |
19:41.44 | cr2 | ok, haret support is my problem :) |
19:41.54 | cr2 | how do you suggest to test bt ? |
19:42.14 | kiozen | you need a gps mouse? |
19:42.23 | kiozen | I can send you one |
19:42.38 | kiozen | with static navigation :P |
19:42.44 | cr2 | i'd obviously need to fix haret and make it boot 100% reliably. like on most other non-msm phones |
19:42.52 | cr2 | no, i have it. |
19:43.14 | cr2 | i need a new qtopia rootfs. |
19:43.41 | cr2 | with the bluez et al. |
19:43.41 | kiozen | me too, installed suse11 repartitioned my hdd |
19:43.57 | cr2 | and debian, or whatever. |
19:44.08 | kiozen | think I should spent the next days compiling oe and qtopia |
19:44.14 | cr2 | or angstrom-console, i don't care. |
19:44.21 | cr2 | ok. |
19:44.44 | kiozen | let's hope this works without testing all steps :) |
19:45.07 | cr2 | i hope so. |
19:45.44 | cr2 | we can take this 'titchy' (?) debian for the uni, if everything else fails. |
19:45.52 | kiozen | ok, 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.16 | kiozen | and then we should have something to start with. |
19:47.07 | kiozen | I am realy looking forward to proofe that Garmin isn't the only decision |
19:48.47 | kiozen | afaik I don't need a kernel for oe / qtopia, right? |
19:49.15 | diogene31 | cr2: 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.28 | Xmoo | dcordes |
19:49.33 | Xmoo | satherday venlo? :P |
19:50.09 | BabelO | cr2: take the one from BA or artemis is better , should be ok for you, there is M inside too |
19:50.46 | BabelO | cr2: http://www.linuxtogo.org/~htcpxa/htcartemis/qtopia/QtopiaPhone-artemis-image.rootfs.tar.bz2 |
19:52.42 | cr2 | diogene31: 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.02 | cr2 | to support power and reset. it's all in the hh.org CVS |
19:53.47 | diogene31 | cr2: So, if you need a rootfs with bluetooth and Qtopia (mine, to be replaced by yours), I can give one for free. |
19:54.05 | ginge_ | hx4700 stuff supprts the brf6150 |
19:54.10 | cr2 | diogene31: 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.34 | cr2 | diogene31: lol, give me the url :) |
19:55.02 | diogene31 | cr2: 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.55 | cr2 | ginge_: 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.28 | cr2 | ginge_: hx4700 had a modified hciattach to upload .bts firmware fixes |
19:56.44 | ginge_ | no, but you need to initialise the hardware using gpios. The 4700 tree has good examples of how that works. iirc |
19:56.46 | kiozen | : ahh BabelO has now splitted personality |
19:57.02 | cr2 | ginge_: but it's not very useful to upload the same firmware on all other devices (including the phones) |
19:57.26 | ginge_ | cr2: true enough |
19:58.31 | cr2 | ginge_: 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.01 | Babel1 | kiozen: swimminng pool, yes ;) |
19:59.08 | kiozen | LOL |
19:59.22 | kiozen | have to look in google earth :P |
20:00.10 | kiozen | : 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.03 | kiozen | got no pool, just a river |
20:05.04 | Babel1 | kiozen: really bad coord then ;) |
20:05.39 | kiozen | Babel1: for the river ore the pool? |
20:07.45 | *** join/#htc-linux AstainHellbring (n=Administ@unaffiliated/astainhellbring) |
20:16.52 | diogene31 | cr2: Sorry, my coffee machine ... exploded a bit ... I made a mess of it. |
20:16.58 | Babel1 | kiozen: pm |
20:17.03 | diogene31 | cr2: 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.35 | kiozen | grrr, this suse 11 is broken |
20:30.58 | cr2 | diogene31: thanks, downloading. |
20:31.33 | diogene31 | cr2: 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.47 | cr2 | diogene31: 100k is ok. |
20:42.09 | martin__ | dcordes: hmm, that's a new one |
20:42.34 | martin__ | dcordes: try turning on the debug printks? |
20:44.26 | cr2 | diogene31: downloaded. |
20:45.08 | diogene31 | cr2: Good. My internet provider improved. |
20:54.14 | dcordes | martin__: did you already test it? |
20:58.41 | cr2 | diogene31: you'd clean ./var/spool/at/ :) |
21:09.29 | cr2 | hmm |
21:09.52 | cr2 | diogene31: you don't start sshd on usb ? |
21:10.18 | diogene31 | cr2: Cleanup ... yes, my wife is always telling me :) |
21:10.35 | diogene31 | cr2: And yes, I do actually start sshd on usb (called dropbear). |
21:19.09 | cr2 | strange. |
21:33.00 | *** join/#htc-linux LunohoD_ (n=alex@e180066036.adsl.alicedsl.de) |
21:34.40 | diogene31 | cr2: Why strange ? Can't you logon onto your PDA ? |
21:44.37 | martin__ | dcordes: I'm still at work :( |
21:45.46 | dcordes | martin__: I doubt printk will help |
21:45.54 | dcordes | what did you change regarding the write? |
21:46.14 | dcordes | I wonder where it writes now that causes the arm11 to freeze and not the modem |
21:47.29 | cr2 | diogene31: 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.35 | diogene31 | cr2: what happens in kernel logs ? (dmesg) |
21:50.25 | diogene31 | cr2: Especially, do you see something like : usb0: full speed config #1: 100 mA, Ethernet Gadget, using CDC Ethernet Subset |
21:51.43 | martin__ | dcordes: I swapped the head and tail back to normal again |
21:52.34 | dcordes | martin__: 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.08 | martin__ | dcordes: no, the a9/a11 vs head/tail thing |
22:00.34 | martin__ | but after fixing the smd_fifo struct after premy pointed out it was wrong |
22:00.51 | martin__ | he already tried it with a fixed struct and a9/a11 |
22:02.19 | dcordes | martin__: did you read yesterday's logs? |
22:04.46 | dcordes | dzo had some ideas on kaiser-smd.c |
22:15.09 | cr2 | diogene31: i can't log in, so there is no dmesg |
22:15.28 | cr2 | diogene31: it's the same kernel that i was using the the rootfs compiled by kiozen. |
22:15.45 | cr2 | s/using the/using with/ |
22:16.28 | diogene31 | cr2: The message I'm talking about is triggered by unplug+plug of usb cable. Can you see it on the screen ? |
22:19.18 | cr2 | diogene31: no, it's some backlight issue. backlight is not switched off at boot. |
22:19.37 | cr2 | hmm. it seems i need to recompile the kernel |
22:19.57 | cr2 | i hate the braindead pxafb driver ;) |
22:20.21 | diogene31 | cr2: Rewrite it :) |
22:31.02 | *** join/#htc-linux SmallR2002 (n=SmallR20@c-67-162-60-33.hsd1.il.comcast.net) |
22:35.29 | cr2 | diogene31: switching to 2.6.26+ may be a better idea. but i need pH5 for that :) |
22:36.16 | AstainHellbring | cr2 i know mistadman did something with the pxafb driver... |
22:36.38 | diogene31 | cr2: OK. |
22:39.41 | Kevin2 | martin__: 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.08 | cr2 | AstainHellbring: ? |
22:47.43 | AstainHellbring | mistadman said that he rewrote the pxa display drivers to add double buffering and something else I think... |
22:47.45 | cr2 | AstainHellbring: athena has an atiw2284 chip. linux kernel uses vsfb now. |
22:48.22 | AstainHellbring | ok... so it just uses ati not pxda then...? |
22:48.43 | cr2 | i've written this driver, so i know what i'm talking about :) |
22:49.34 | cr2 | it uses vsfb, ie. verysimpleframebuffer. just writes to the ati SDRAM already set up by wince. |
22:49.49 | AstainHellbring | ahh ok |
22:50.14 | AstainHellbring | all I had heard was that mistadman said he did some writing to the driver to do something with double buffering |
22:50.47 | cr2 | double buffering can be done by an application. |
22:51.24 | cr2 | hehe, we are talking about android here. is the android source available ? |
22:52.56 | cr2 | Kevin2: did you already gave up with hermes ? |
22:54.12 | cr2 | Kevin2: 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.47 | Kevin2 | cr2: 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.17 | Kevin2 | I 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.19 | DesktopMa | back at work today, though can only do limited testing. internet is down at work so I'm using my phone |
23:07.30 | cr2 | Kevin2: ok. once pH5 will make asic3_mmc work, i'll return to atiw_mmc |
23:09.33 | cr2 | Kevin2: 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.17 | Kevin2 | cr2: Sure - you can add a testPXA27x(). |
23:26.28 | *** join/#htc-linux AstainHellbring (n=Administ@unaffiliated/astainhellbring) |