| 00:00.18 | cr2 | reminds me about the ATI xtal, pll and M,N divisor values ;) |
| 00:01.10 | cr2 | tmzt: the SD frequency is derived from some pll clock using these divisors |
| 00:01.59 | cr2 | it must be some linear dependence |
| 00:02.54 | cr2 | if the equations are not lineary dependent, you need X equations for X unknowns |
| 00:03.05 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
| 00:03.21 | cr2 | yes :) |
| 00:03.37 | cr2 | i have this debug output in my "wince dmesg" :D |
| 00:03.51 | maejrep | :x |
| 00:04.11 | maejrep | as in it dumps the reg values? or how they're used/calculated? |
| 00:04.19 | cr2 | a4 is NsRegs |
| 00:04.32 | cr2 | and a0 is MdRegs |
| 00:04.44 | cr2 | for Sdc1 |
| 00:05.02 | maejrep | what kind of debug output is used? |
| 00:05.43 | cr2 | 0x214 is RowResetReg |
| 00:06.45 | cr2 | maejrep: it's the "ram console", or how g1 calls it |
| 00:07.12 | cr2 | interesting |
| 00:07.34 | cr2 | the logs says SDHC tries to start with 100kHz |
| 00:07.41 | cr2 | and then switches to 25MHz |
| 00:07.43 | *** join/#htc-linux paulproteus (n=paulprot@2002:db69:2513:0:0:0:0:1) |
| 00:08.58 | *** join/#htc-linux gh0ul (n=asds@host81-154-247-76.range81-154.btcentralplus.com) |
| 00:09.33 | cr2 | GlblclkEna is +0x00 ?? |
| 00:09.40 | maejrep | yeah |
| 00:09.44 | maejrep | a8600000 |
| 00:10.05 | maejrep | that register has been (re)moved from the memory map |
| 00:10.14 | maejrep | when it was moved to MSM_CLK |
| 00:10.44 | cr2 | i have moved the bitmasks to the divisors |
| 00:11.54 | cr2 | Config GPIO 62~67 to ALT2 |
| 00:12.42 | maejrep | that's in the dmesg? |
| 00:12.55 | cr2 | yes |
| 00:13.03 | cr2 | SD related |
| 00:13.05 | maejrep | that's useful to know :p |
| 00:14.21 | cr2 | 0x48 |
| 00:14.34 | cr2 | must include ALT2 |
| 00:15.04 | cr2 | it's some combination of 4bit ALT, 2bit pull and 4bit drvstr |
| 00:15.24 | cr2 | tmzt: where is the g1 BT driver ?? |
| 00:15.50 | cr2 | maejrep: what is the most urgent raph problem in your mind ? |
| 00:17.05 | cr2 | Config GPIO 62~67 to GPIO output low |
| 00:17.35 | maejrep | that's a good question :x but probably starting from the bottom up, getting the things that are necessary in order to support other hardware (like vreg, proc comm, gpio config, etc) all working should be done before we start working on other things like wifi and bt, which will require those to be working |
| 00:18.37 | cr2 | agreed |
| 00:19.10 | cr2 | but i consider vreg/dex/gpiocfg more or less understood. |
| 00:19.33 | cr2 | the sd clock situation is more painful |
| 00:21.03 | *** join/#htc-linux BabelO_ (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 00:21.10 | maejrep | yes, understood but not fully implemented in code yet :) |
| 00:22.19 | tmzt | cr2: I don't think there is a specific g1 bluetooth driver, just a new high-speed uart driver in the 2.6.27 kernel |
| 00:22.48 | cr2 | vreg 6 = 0x4|0x2 |
| 00:23.05 | cr2 | MSMP and MSME |
| 00:23.20 | cr2 | ok, it's c and d |
| 00:23.25 | *** join/#htc-linux nizox (n=none@eros.ph0k.eu) |
| 00:23.38 | cr2 | yes, these are 2 vregs for wifi. ok. |
| 00:24.13 | maejrep | o.0 |
| 00:24.55 | cr2 | i'm checking the wince dmesg |
| 00:25.12 | cr2 | maejrep: but hat means that they have combined 2 clocks somehow |
| 00:25.26 | maejrep | how does it mean that? |
| 00:25.30 | pH5 | hi Mullins, are you subscribed to the mobile-linux-discuss mailing list? |
| 00:26.22 | tmzt | cr2: what is drvstr? the wifi is 8bit I think everything else is 1(really 2) spi or 4-bit |
| 00:26.30 | cr2 | maejrep: it's possible to do for dex, but not possible for the radiobl channel |
| 00:26.50 | maejrep | I don't know what that means :p |
| 00:26.53 | cr2 | tmzt: ?? |
| 00:27.33 | maejrep | tmzt: i think "drvstr" comes from the trout PCOM_CONFIG_GPIO macro |
| 00:27.41 | maejrep | or whatever its called |
| 00:27.50 | cr2 | drvstr is drive strength. it's some current definition in proc_comm.h |
| 00:27.54 | cr2 | i think |
| 00:28.03 | maejrep | yeah, 8MA, 4MA, 16MA, etc |
| 00:28.12 | tmzt | ah |
| 00:29.22 | maejrep | brb, gonna get some food |
| 00:30.00 | Mullins | pH5: no, I was registered on projects.linuxtogo.org. I just subscribed to the mailing list there now |
| 00:35.15 | pH5 | Mullins: ok, done. |
| 00:35.42 | Mullins | pH5: excellent. Thanks! |
| 00:35.55 | *** part/#htc-linux mickey_jaw (n=mike@78-105-123-214.zone3.bethere.co.uk) |
| 00:35.59 | tmzt | cr2: it appears the driver is texas, checking android git to see if there are any relevant bluez patches |
| 00:36.36 | maejrep | texas? |
| 00:36.55 | tmzt | ti, the hciattach parameter is texas |
| 00:39.05 | cr2 | maejrep: http://wiki.xda-developers.com/index.php?pagename=MSM_VREG |
| 00:39.23 | cr2 | maejrep: fixed the VREG tables |
| 00:40.00 | maejrep | i didn't know it was wrong :D |
| 00:40.00 | cr2 | so it's easy to use proc_comm_wince , and the wince and g1 compatibility is 100% |
| 00:40.26 | cr2 | i filled the two missing columns "g1name" and "dex" |
| 00:40.33 | tmzt | great, will it be possible to get a proc_comm (generic) driver that can be configured with pdata? |
| 00:40.39 | maejrep | ah cool |
| 00:41.17 | cr2 | maejrep: so if you know the wince vreg idx or g1 vreg name, you can pick the respective proc_comm_wince arg |
| 00:41.33 | maejrep | tmzt: could be configured by AMSS version |
| 00:41.56 | tmzt | yeah, but if we could keep defines out of seperate drivers that might be better |
| 00:42.06 | tmzt | this would mean a proc_comm_ops or something |
| 00:42.14 | cr2 | tmzt: yes, you only need to create the vreg+level arrays to be applied |
| 00:42.39 | maejrep | cool, so are there any outstanding issues with proc comm or vreg? or it all just needs to be fixed in code now? |
| 00:42.47 | tmzt | is the protocol different at the smd level? |
| 00:43.08 | maejrep | in what sense? |
| 00:43.10 | cr2 | tmzt: the "pseudocode" is at the top of MSM_VREG |
| 00:43.19 | maejrep | raph800 implements smd channel 0 and 1 differently than raph100 |
| 00:43.30 | cr2 | the first param is the wince idx, and the third is level |
| 00:43.44 | cr2 | the second one is on/off, so it's not really interesting |
| 00:44.59 | tmzt | I don't see psuedocode |
| 00:45.50 | cr2 | 0xa,1/0,0xa28 lcd related |
| 00:45.50 | cr2 | <PROTECTED> |
| 00:45.58 | tmzt | I see that |
| 00:46.28 | cr2 | so you have 2 params: vreg and level |
| 00:46.31 | tmzt | g1/ce use a different proc_comm command and vreg indexes? |
| 00:47.13 | cr2 | g1 uses different api, and different proc_comm |
| 00:47.21 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
| 00:47.46 | cr2 | maejrep: i think you should not redefine the PCOM_* constants |
| 00:47.57 | cr2 | but rename them DEX_* instead |
| 00:48.31 | cr2 | because it creates the same confudion like with the proc_comm |
| 01:03.02 | cr2 | ac084000 ATLog RAM Base |
| 01:04.45 | cr2 | Read G-sensor calibration data from flash |
| 01:06.18 | maejrep | cr2: so use the same names, but with DEX_* ? and with their dex equivalent values? |
| 01:06.26 | cr2 | MD NS addr d8 / dc for uartdm |
| 01:06.49 | cr2 | maejrep: i think you have already redefined them ? |
| 01:06.58 | maejrep | I didn't, NetRipper did i think |
| 01:07.19 | cr2 | k |
| 01:07.33 | cr2 | but i don't think we should mix them |
| 01:08.12 | maejrep | I think that's a good idea |
| 01:08.20 | maejrep | its way too confusing |
| 01:09.04 | sean_d | I haven't heard much conversation about what the actual issue is with the graphics on the sprint diamond |
| 01:09.57 | cr2 | diam800 ? |
| 01:10.00 | sean_d | yeah |
| 01:10.24 | sean_d | just a lack of a module for the graphics? |
| 01:10.29 | cr2 | i think they are the same as on raph800 |
| 01:10.58 | sean_d | idk |
| 01:12.25 | *** join/#htc-linux Summerspittman (n=secondsu@c-24-99-93-227.hsd1.ga.comcast.net) |
| 01:14.31 | sean_d | is there a hardware listing somewhere? I'd like to devote some time to that problem |
| 01:14.41 | *** part/#htc-linux exco (n=exco@e181075236.adsl.alicedsl.de) |
| 01:15.09 | cr2 | sean_d: hardware listing ? |
| 01:15.36 | sean_d | I guess that wouldn't help much, |
| 01:17.44 | sean_d | just kinda curious how different the video is in the 800 |
| 01:18.33 | cr2 | there are different panels, and the epson "774" chip |
| 01:18.48 | tmzt | it seems the way to initialize the lcd or controller for the 565 mode was/is not known |
| 01:19.05 | tmzt | at least that's how j0b0 explained it I think |
| 01:19.39 | sean_d | I see |
| 01:21.47 | cr2 | there is some spi init sequence, which depends on the panel type |
| 01:22.18 | cr2 | so the first code to be written is to query the toshiba gpios, and calculate the lcd panel id |
| 01:24.08 | tmzt | the panel is connected to the msm with spi and the epson/toshiba with mddi? |
| 01:24.45 | cr2 | it's difficult to say |
| 01:25.04 | tmzt | g1 does not use one of these chips? |
| 01:25.09 | cr2 | but i think that the spi controller is part of the mddi register space |
| 01:25.18 | cr2 | it uses toshiba |
| 01:25.30 | sean_d | mddi? |
| 01:25.42 | cr2 | but since it has a different panel, the params may be different |
| 01:25.50 | cr2 | toshiba is an mfd |
| 01:26.01 | cr2 | mddi+i2c+spi+gpio ;) |
| 01:26.26 | cr2 | and no docs, of course |
| 01:26.38 | sean_d | that's what I'm seeing |
| 01:27.22 | cr2 | sean_d: i've documented many of these for raph100 |
| 01:27.25 | *** join/#htc-linux zycho_ (n=zycho@a89-182-7-170.net-htp.de) |
| 01:27.31 | cr2 | and there is g1 code too |
| 01:28.50 | sean_d | cool, I'd like to put some of my free time into hacking on something with this phone |
| 01:29.24 | cr2 | http://wiki.xda-developers.com/index.php?pagename=RaphaelLCD |
| 01:30.37 | sean_d | thanks |
| 01:33.09 | sean_d | how'd you figure this stuff out? |
| 01:35.27 | cr2 | disassembling the bootloader |
| 01:37.26 | sean_d | haha, I should have guessed |
| 01:37.29 | maejrep | hmm, so my phone keeps rebooting :/ |
| 01:37.37 | maejrep | cr2: do you use ida for the spl? |
| 01:38.08 | cr2 | yes. and old version |
| 01:38.22 | cr2 | which has some annoying bugs |
| 01:38.41 | cr2 | it can't deal with amss properly, for example |
| 01:38.46 | maejrep | where should the entrypoint be in the spl? |
| 01:39.02 | cr2 | use dumprom on it |
| 01:39.09 | maejrep | cause when I open it, it only analyzes a small area |
| 01:39.47 | cr2 | you can even compile the dumprom on 32bit linux. on 64bit there are some bugs ;) |
| 01:41.03 | maejrep | well it has a "rom" file type, and when I open it, there's a dialog that has a checkbox for "Create ROM", starting point 0x00000000, and size 0x100000 |
| 01:41.14 | maejrep | then it tells you to find the entry point and press C to autoanalyze |
| 01:41.23 | cr2 | do you have dumprom.exe program ? |
| 01:41.37 | cr2 | or the dumprom.cpp |
| 01:41.44 | maejrep | maybe, it comes with ida? |
| 01:41.49 | *** join/#htc-linux ltxda (n=anon@unaffiliated/ltxda) |
| 01:41.55 | cr2 | no, it's from itsme |
| 01:42.12 | maejrep | oh ok, then no |
| 01:42.29 | maejrep | my desktop is 64 bit linux ;p |
| 01:43.08 | cr2 | http://wiki.xda-developers.com/index.php?pagename=DumpRom |
| 01:43.12 | cr2 | then use wine |
| 01:43.24 | maejrep | i use virtualbox |
| 01:43.36 | cr2 | my notebook is amd64, so i use wine too ;) |
| 01:44.06 | cr2 | or use gcc -m32 |
| 01:46.53 | maejrep | hmm, it only finds nk.exe? |
| 01:48.48 | cr2 | it creates nk.exe |
| 01:49.07 | cr2 | mkdir JUNKDIR |
| 01:49.21 | tmzt | are you looking for kernel or spl? |
| 01:49.22 | cr2 | wine dumprom.exe -v spl -d JUNKDIR |
| 01:49.39 | cr2 | it will create JUNKDIR/nk.exe |
| 01:49.50 | cr2 | then load nk.exe into ida |
| 01:49.58 | cr2 | it's the spl |
| 01:50.44 | maejrep | ah |
| 01:50.56 | cr2 | ok, i need to sleep a bit |
| 01:51.15 | cr2 | maejrep: have you tried to add the second 128MB bank ? |
| 01:51.17 | maejrep | 4am? ;p |
| 01:51.23 | cr2 | 3am |
| 01:51.23 | maejrep | no |
| 01:51.37 | cr2 | ok. |
| 01:51.47 | cr2 | good night |
| 01:51.52 | maejrep | nite |
| 02:10.07 | *** part/#htc-linux Balsat (n=kll@87.72.13.87) |
| 02:20.42 | *** join/#htc-linux ltxda (n=anon@unaffiliated/ltxda) |
| 03:02.09 | maejrep | so every time i hit the power button to turn the lcd off, my phone is rebooting :x |
| 03:02.16 | maejrep | i think i broke something :) |
| 03:02.35 | tmzt | ah, but the power button works :) |
| 03:16.31 | *** join/#htc-linux Skitzo_ (n=DCLXVI@eth582.vic.adsl.internode.on.net) |
| 03:34.04 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 03:41.01 | *** join/#htc-linux AstainZZZZZZ (n=AstainHe@unaffiliated/astainhellbring) |
| 04:23.00 | *** join/#htc-linux ionstorm (n=ion@ip68-227-226-5.ph.ph.cox.net) |
| 04:25.05 | *** join/#htc-linux Skitzo_ (n=DCLXVI@eth582.vic.adsl.internode.on.net) |
| 04:52.16 | *** join/#htc-linux salleybeo (n=salleybe@pool-71-106-98-124.lsanca.dsl-w.verizon.net) |
| 05:47.25 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 05:55.14 | Skitzo_ | i would just like to say, i love you all and you're all doing fantastic work. |
| 05:56.24 | tmzt | hey, what device do you have? |
| 05:56.32 | Skitzo_ | raph100 |
| 05:57.46 | tmzt | cool, how is that working for you now? |
| 05:58.06 | Skitzo_ | yeah, working well |
| 05:58.18 | Skitzo_ | first time i've tried it, booted without problem |
| 05:58.29 | Skitzo_ | and it's a much nicer OS than winmo |
| 05:59.53 | tmzt | android? |
| 06:00.44 | Skitzo_ | yeah |
| 06:01.26 | tmzt | the hardware keyboard isn't working in those images yet? |
| 06:01.35 | Skitzo_ | not as of yet |
| 06:03.22 | tmzt | it's not in git yet either |
| 06:03.30 | Skitzo_ | git? |
| 06:03.31 | tmzt | how is the vkeyb working with android? |
| 06:03.38 | tmzt | git.linuxtogo.org |
| 06:03.50 | tmzt | git is a program developed for managing linux kernel source code |
| 06:03.51 | Skitzo_ | ahh |
| 06:04.36 | Skitzo_ | ahh |
| 06:04.37 | Skitzo_ | yeah |
| 06:04.47 | Skitzo_ | which device are you running? |
| 06:05.36 | tmzt | well, I have moto q |
| 06:05.45 | tmzt | but I don't use android on it |
| 06:08.32 | Skitzo_ | ahhh fair enough |
| 06:46.18 | *** join/#htc-linux Shinto (n=John@g227194053.adsl.alicedsl.de) |
| 07:01.55 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 07:04.35 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 07:18.57 | *** join/#htc-linux techie (n=blarg@ip24-250-216-85.ga.at.cox.net) |
| 07:21.52 | *** join/#htc-linux goxboxlive (n=goxboxli@185.84-48-126.nextgentel.com) |
| 07:32.37 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 07:37.01 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
| 07:49.53 | maejrep | tmzt: that's in windows, not linux :| it's rebooting whenever the screen turns off I think |
| 07:50.11 | maejrep | cause even if I just lock the keys and let it sit, it'll reboot once the screen goes off |
| 07:51.10 | tmzt | hey |
| 08:10.43 | maejrep | hi |
| 08:19.03 | tmzt | yeah I thought you meant in linux but now I'm really confused |
| 08:21.52 | *** join/#htc-linux Abracadabr4 (n=aaabraca@unaffiliated/abracadabra) |
| 08:22.00 | maejrep | me too :/ |
| 08:22.17 | maejrep | haven't looked into why yet .. working on refactoring those microp drivers |
| 08:22.29 | tmzt | how is that going? |
| 08:22.49 | tmzt | I see the basic keyboard isn't in git but I guess that will what for this work? |
| 08:22.56 | tmzt | s/what/wait/ |
| 08:33.05 | maejrep | i don't have commit access, so that would be NetRipper who commits it to git anyway |
| 08:33.15 | maejrep | but I've also heard reports of some people saying it doesn't work for them |
| 08:33.25 | maejrep | like I think lupine_85 was still having problems with it |
| 08:33.25 | tmzt | on other raph's? |
| 08:33.28 | maejrep | yeah |
| 08:33.32 | maejrep | other models |
| 08:33.38 | tmzt | I saw that, he has 100 or 300? |
| 08:33.51 | maejrep | 100 i think, but possibly 500? |
| 08:34.08 | tmzt | we don't have a keymap for 500 do we? |
| 08:34.21 | tmzt | I think parmaster has one now |
| 08:35.01 | maejrep | yeah I think someone did that |
| 08:35.08 | maejrep | should be 2nd column in the keyboard wiki page |
| 08:36.01 | maejrep | kind of strange that discussion in this channel is mostly about raph/diam :P |
| 08:37.56 | tmzt | why? |
| 08:39.28 | maejrep | just cause it's htc-linux, not specific to raph ;) |
| 08:42.07 | *** join/#htc-linux Ewasx (n=armin@5-157.surfsnel.dsl.internl.net) |
| 09:43.10 | *** join/#htc-linux kiozen (n=oeichler@p5492007C.dip0.t-ipconnect.de) |
| 10:01.01 | *** join/#htc-linux cr2 (n=cr2@ip-77-25-5-22.web.vodafone.de) |
| 10:01.25 | cr2 | hi |
| 10:05.13 | cr2 | tmzt: hciattach is for the uart. which uart is bt on g1 ? |
| 10:15.03 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
| 10:22.56 | *** join/#htc-linux nebi (n=nebi@170.ftth2.cust.fyrobs1.upps.se.borderlight.net) |
| 10:45.20 | *** join/#htc-linux MethoS (n=lem@host-091-096-213-127.ewe-ip-backbone.de) |
| 10:45.33 | cr2 | alt0,nopull,4ma=2 |
| 10:46.48 | cr2 | n |
| 10:46.53 | cr2 | err |
| 10:47.16 | cr2 | alt0,nopull,4ma=1 |
| 10:47.26 | *** join/#htc-linux paulproteus (n=paulprot@2002:db69:2513:0:0:0:0:1) |
| 10:47.27 | cr2 | for the cam |
| 10:48.36 | cr2 | hm. confused |
| 10:49.33 | cr2 | it's different |
| 10:50.50 | *** join/#htc-linux Xime (n=xime@bankize.net) |
| 10:55.15 | *** join/#htc-linux timebomb (n=tb@213.39.244.82) |
| 11:00.16 | cr2 | aha. cpld problem is solved with mem_desc |
| 11:03.49 | maejrep | ? |
| 11:04.13 | cr2 | writel((1U << 16) | (~level & 0xffff),MSM_CLK_CTL_BASE + 0x58); |
| 11:04.36 | cr2 | writel((~127 << 16) | 0xb20,MSM_CLK_CTL_BASE + 0x5c); |
| 11:04.48 | cr2 | <PROTECTED> |
| 11:04.59 | cr2 | looks familiar ? |
| 11:05.32 | cr2 | maejrep: i had a problem on athena, that i could not use the cpld gpios early at boot. |
| 11:05.42 | maejrep | ah |
| 11:05.45 | cr2 | because of the ioremap() for it. |
| 11:06.16 | cr2 | they do not use ioremap, but put a static entry. |
| 11:06.37 | maejrep | getting close to testing the refactored keypad module(s) |
| 11:06.45 | cr2 | good |
| 11:07.09 | cr2 | the 0x58 clock is the famous a0 formula |
| 11:07.39 | cr2 | and for 5c we can also calculate the params |
| 11:08.30 | cr2 | 0xb20 and 0xb58 are 0xa|arg7 halfbyte + lower byte |
| 11:08.37 | cr2 | looks very promising |
| 11:09.26 | cr2 | it seems that when arg7=0, then the second reg is irrelevant (i2c and pmdh) |
| 11:10.02 | cr2 | but when arg7=1, then 0xa|arg7=0xb, and the other fields have some meaning |
| 11:10.02 | *** join/#htc-linux timebomb (n=tb@c192122.adsl.hansenet.de) |
| 11:10.42 | cr2 | and the 0x58/0x5c pair uses gp_clk. also an important information |
| 11:10.56 | cr2 | hmm. i need to add the g1 clk table to wiki |
| 11:12.34 | *** join/#htc-linux radem205 (n=aaa@e144118.upc-e.chello.nl) |
| 11:14.29 | cr2 | maejrep: the latest google kernel code looks much better than before |
| 11:16.32 | cr2 | anf the 0x58/0x5c pair have 19.2MHz frequency |
| 11:16.37 | cr2 | with this config |
| 11:19.06 | cr2 | it seems that androids use a better alt config, because they have many drvstr combinations, while wince has only 1. |
| 11:19.33 | cr2 | which makes splitting the bits a more difficult task, on the other side |
| 11:20.34 | cr2 | it seems that 4ma/nopull does not set any bits |
| 11:24.24 | cr2 | 208 /*.max_dtr = 24000000, Max of chip - no worky on Trout */ |
| 11:24.24 | cr2 | 209 .max_dtr = 20000000, |
| 11:24.34 | cr2 | wifi works with 20MHz ? |
| 11:27.22 | cr2 | interesting. g1 uses mmc" |
| 11:27.29 | cr2 | vreg for wifi |
| 11:28.01 | cr2 | while raph/diam/blac the msme and msmp |
| 11:28.55 | *** join/#htc-linux Skitzo (n=DCLXVI@eth582.vic.adsl.internode.on.net) |
| 11:29.05 | cr2 | something to think about |
| 11:29.56 | cr2 | the idea of tmzt to put vreg config in pdata looks better with every hour :) |
| 11:31.48 | cr2 | the sd is gp6 too. |
| 11:46.20 | *** join/#htc-linux MethoS (n=lem@dyndsl-085-016-166-068.ewe-ip-backbone.de) |
| 11:54.11 | *** join/#htc-linux MethoS- (n=lem@dyndsl-085-016-167-083.ewe-ip-backbone.de) |
| 11:55.48 | maejrep | sweet, just tested the klt module, and on probe it turns on and off each LED, and it works :) |
| 11:56.26 | cr2 | :) |
| 11:56.40 | cr2 | but you don't check the microP id ? |
| 11:57.48 | *** join/#htc-linux kimhoon (n=kimhoon@s559116c1.adsl.wanadoo.nl) |
| 11:59.31 | *** join/#htc-linux MethoS-- (n=lem@dyndsl-085-016-163-073.ewe-ip-backbone.de) |
| 12:01.38 | maejrep | not yet, until we know for sure what versions we need to support |
| 12:01.56 | cr2 | ok |
| 12:02.05 | maejrep | so far i only know of 0685, 0682, and 0005 |
| 12:02.15 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 12:02.17 | cr2 | the detection algorithm is different for 500/800 and 100 |
| 12:02.18 | maejrep | and 0c85 for led (don't know revisions for other models) |
| 12:02.31 | maejrep | which algorithm? |
| 12:02.32 | cr2 | 85 and 82 |
| 12:02.43 | cr2 | are keyboard and leds |
| 12:02.56 | cr2 | id query algorithm |
| 12:03.33 | cr2 | g1 uses uart2DM for BT. it's the same on raph |
| 12:03.36 | maejrep | its not a read from the same i2c data address? |
| 12:04.01 | cr2 | i may check if you're interested |
| 12:04.18 | maejrep | i was asking if that's what you mean |
| 12:04.28 | maejrep | so trout bluetooth should work on raph as well? |
| 12:04.29 | cr2 | uh, these 7200 vs 7200A differences are annoying |
| 12:04.48 | maejrep | :s |
| 12:04.58 | cr2 | maejrep: i have found only the config, and only in the latest kernel |
| 12:05.22 | maejrep | yeah I saw the google commit a few days ago |
| 12:05.48 | cr2 | ok. let's check the 800 microp id |
| 12:06.02 | maejrep | and just add others as we go? |
| 12:06.25 | cr2 | let's hope that the other regs are compatible |
| 12:06.57 | maejrep | :D i like my klt test sequence on insert ;) |
| 12:07.20 | cr2 | cc,30,2,x |
| 12:07.24 | maejrep | [ 25.556537] microp-klt: Initialized MicroP-LED chip revision v0c85 |
| 12:07.24 | maejrep | [ 34.213375] microp-ksc: Initialized MicroP-KEY chip revision v0685 |
| 12:08.15 | maejrep | and the keypad works :D |
| 12:08.36 | cr2 | checks for 85 and 10, 82 and 10 |
| 12:08.54 | maejrep | what does? |
| 12:09.33 | cr2 | and ce,12,2,x |
| 12:10.06 | cr2 | also checks for 85 and 82 |
| 12:10.36 | maejrep | wince checks those? |
| 12:10.54 | cr2 | 0x10 is the border value |
| 12:11.06 | cr2 | ldrcc 0x10 ->raph |
| 12:11.12 | maejrep | border? |
| 12:11.22 | cr2 | sorry |
| 12:11.31 | cr2 | ldrcs 0x10 -> raph |
| 12:11.41 | cr2 | ldrcc 0x10 -> hermann |
| 12:11.47 | cr2 | wtf is hermann ? |
| 12:11.50 | maejrep | :| |
| 12:11.56 | maejrep | hermes? |
| 12:11.59 | cr2 | no |
| 12:12.13 | maejrep | i don't know what you're referring to :( |
| 12:12.25 | cr2 | do you query these 2 bytes ? |
| 12:12.46 | cr2 | cc,30 and ce,12 |
| 12:12.48 | maejrep | yes |
| 12:12.50 | cr2 | 2x2bytes |
| 12:13.42 | cr2 | ok, you should only support 85 and 82 |
| 12:13.50 | maejrep | what what does the "10" mean? |
| 12:13.59 | cr2 | the MSB |
| 12:14.00 | maejrep | I shouldn't add support for 0005 for raph100? |
| 12:14.14 | cr2 | LSB is 85 and 82 |
| 12:14.22 | maejrep | why 10? my revisions are 0685 and 0c85 |
| 12:14.25 | cr2 | i'll check raph100 |
| 12:14.38 | cr2 | <0x10, so you have raph |
| 12:14.46 | maejrep | oh |
| 12:15.09 | maejrep | so check for 82 or 85, and the high byte being <0x10 ? |
| 12:15.40 | maejrep | and >0x10 is hermann ? (apparently htc hermann is a different device) |
| 12:15.41 | cr2 | the MSB differentiates between raph and hermann |
| 12:15.54 | cr2 | >= i think |
| 12:15.57 | maejrep | i see |
| 12:16.04 | cr2 | but need to recheck CC and CS ops :) |
| 12:16.46 | cr2 | you should only support 85 and 82 on 500/800 |
| 12:16.59 | maejrep | kk |
| 12:19.05 | cr2 | 100 checks for 2 and 0xa |
| 12:19.32 | cr2 | 2 is raph, a is hermann |
| 12:19.51 | maejrep | hmm |
| 12:19.55 | cr2 | the rest is wrong |
| 12:19.56 | maejrep | that's odd |
| 12:20.17 | maejrep | others were saying they see "v5" in spl |
| 12:20.17 | *** join/#htc-linux Mullins (n=bw@89.204.249.193) |
| 12:20.31 | cr2 | it's for cc,30 |
| 12:20.31 | *** join/#htc-linux MethoS (n=lem@host-091-097-244-165.ewe-ip-backbone.de) |
| 12:20.43 | maejrep | ok |
| 12:21.18 | maejrep | so what does it check in LSB? |
| 12:21.26 | cr2 | ce,12 checks for !5 -> wrong |
| 12:21.36 | cr2 | version |
| 12:22.06 | maejrep | ah ok |
| 12:22.41 | cr2 | and also 2 and a for raph/hermann |
| 12:23.44 | maejrep | so, KLT should check for <0x10, and 82, 85, or 02. and KSC should check for <0x0a, and 82, 85, or 05. |
| 12:24.35 | cr2 | no, 100/300 is more strict |
| 12:24.42 | maejrep | lol :| |
| 12:24.46 | cr2 | it wants either 2 or 0xa |
| 12:24.49 | maejrep | i thought that was 100 ^ ? |
| 12:24.55 | cr2 | not just <0x10 |
| 12:24.57 | maejrep | oh |
| 12:25.06 | maejrep | ok |
| 12:25.26 | maejrep | so for the 02 and 05 checks, I should be also more strict on the MSB |
| 12:25.36 | cr2 | 5 is only 1 byte, check the second byte |
| 12:25.49 | cr2 | wrong :) |
| 12:25.56 | cr2 | there is only id 5 |
| 12:26.11 | maejrep | i'm lost :( |
| 12:26.33 | cr2 | 2 and a are for raph/!raph |
| 12:26.40 | cr2 | hmm. i'll check again |
| 12:26.57 | cr2 | ok. led first |
| 12:27.10 | cr2 | read cc,30. 2 bytes |
| 12:27.26 | maejrep | this is raph100, right? |
| 12:27.32 | cr2 | yes |
| 12:28.25 | cr2 | if the second byte is 0x2 it prints v%d, first byte |
| 12:29.03 | cr2 | raph led v%d |
| 12:29.03 | maejrep | got it |
| 12:29.03 | cr2 | if the second byte is 0xa |
| 12:29.14 | cr2 | it prints herm led v%d |
| 12:29.25 | cr2 | otherwise -> wrong platform |
| 12:29.36 | maejrep | ok |
| 12:30.15 | cr2 | key now |
| 12:30.44 | cr2 | read ce,12 |
| 12:30.48 | cr2 | 2 bytes |
| 12:31.21 | cr2 | if the second byte !=5 -> wrong platform ?? |
| 12:31.58 | cr2 | hehe |
| 12:32.18 | cr2 | checks for 2 and a in -1 byte |
| 12:32.26 | cr2 | looks like buffer overflow to me :) |
| 12:32.53 | maejrep | lol |
| 12:33.02 | cr2 | i'll look at 300 |
| 12:33.35 | cr2 | i'll sugget just to print both bytes for now. |
| 12:33.54 | cr2 | imho it should be the same as for cc,30 |
| 12:34.50 | maejrep | yeah, the _probe already prints version in dmesg (see my dmesg copies above) |
| 12:35.04 | maejrep | <maejrep> [ 25.556537] microp-klt: Initialized MicroP-LED chip revision v0c85 |
| 12:35.04 | maejrep | <maejrep> [ 34.213375] microp-ksc: Initialized MicroP-KEY chip revision v0685 |
| 12:35.21 | maejrep | so if we find something unusual we can look into whether it can be supported or not |
| 12:35.28 | cr2 | ok |
| 12:35.35 | cr2 | uh |
| 12:35.41 | cr2 | 300 says |
| 12:35.58 | cr2 | vict (led) v%d |
| 12:36.10 | cr2 | sorry, it is diamond ? |
| 12:36.20 | cr2 | yeah, diam/vict |
| 12:36.33 | cr2 | bt i'll check it too |
| 12:37.05 | cr2 | maejrep: the psoc identification is much more fun :) |
| 12:37.09 | maejrep | LED can still be supported by microp-klt |
| 12:37.12 | maejrep | joy! :p |
| 12:37.29 | maejrep | (that is, klt can still support diam LEDs ^) |
| 12:37.37 | cr2 | cc,30 2 bytes too |
| 12:37.58 | cr2 | but it checks for 1 and b |
| 12:38.07 | cr2 | not 2 and a |
| 12:38.22 | cr2 | 1 is diam, b is vict |
| 12:38.30 | cr2 | make sense |
| 12:38.35 | cr2 | diam was before raph |
| 12:38.52 | maejrep | and vict after herm apparently :p |
| 12:39.01 | cr2 | seems so |
| 12:39.40 | cr2 | ok. no keyboard on diam. obviusly :) |
| 12:39.49 | maejrep | yup |
| 12:40.54 | maejrep | and raph800 is 0x0c (mine), so that makes sense :P |
| 12:41.20 | cr2 | ok |
| 12:41.32 | cr2 | so, what is supported now ? |
| 12:41.45 | cr2 | i'm trying to understand the clocks now. |
| 12:41.55 | maejrep | lol |
| 12:43.59 | *** join/#htc-linux MethoS- (n=lem@host-091-097-246-198.ewe-ip-backbone.de) |
| 12:44.00 | maejrep | version < 0x1000 if version & 0xff == 0x85 or 0x82 for raph800. 0x0105, 0205, 0a05, 0b05 for raph100, 300, and diam? |
| 12:45.56 | cr2 | 300 is diam300 |
| 12:47.17 | maejrep | ah |
| 12:47.30 | maejrep | so we don't know raph300 for sure then? |
| 12:48.50 | cr2 | does it exist ? |
| 12:50.21 | maejrep | i think so? |
| 12:50.34 | maejrep | google says yes |
| 12:50.48 | cr2 | what is htc hermann ? |
| 12:51.42 | *** join/#htc-linux MethoS-- (n=lem@host-091-097-243-045.ewe-ip-backbone.de) |
| 12:52.08 | maejrep | not sure, haven't discovered that yet |
| 12:52.18 | maejrep | i see stuff on google about batteries for htc hermann mda |
| 12:52.25 | maejrep | but I don't know what it is |
| 12:53.37 | cr2 | ok |
| 12:53.56 | cr2 | so your keyboard driver works ? |
| 12:57.08 | *** join/#htc-linux MethoS (n=lem@host-091-097-245-041.ewe-ip-backbone.de) |
| 12:58.01 | maejrep | yup |
| 12:58.39 | maejrep | drivers/input/keyboard/microp-keypad.c drivers/i2c/chips/microp-klt.c drivers/i2c/chips/microp-ksc.c |
| 12:59.01 | maejrep | ksc depends on klt. keypad depends on klt and ksc |
| 12:59.23 | maejrep | (leaving klt available even without keypad support, e.g. for diamond) |
| 12:59.43 | maejrep | next step should be the led driver |
| 12:59.55 | *** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes) |
| 13:00.48 | cr2 | ok |
| 13:08.20 | maejrep | i also changed the way the keymap is done |
| 13:08.43 | maejrep | using EV_MSC and MSC_SCAN so that the input driver can remap the keys via userland |
| 13:09.04 | cr2 | ok |
| 13:16.09 | cr2 | maejrep: do you know where is the lavender.t sd patch ? |
| 13:16.25 | maejrep | attached on the forum |
| 13:16.28 | maejrep | will try to find it, sec |
| 13:17.30 | maejrep | http://forum.xda-developers.com/showpost.php?p=3115412&postcount=1303 |
| 13:17.48 | cr2 | ok, thanks |
| 13:17.57 | cr2 | { 19200, ACPU_PLL_TCXO, 0, 0, 19200, 0, VDD_0, 0, 0, 8 }, |
| 13:18.12 | cr2 | this one looks like a 7 parameter formula :) |
| 13:19.00 | cr2 | ok, so TCX0 is 19.2MHz and g1 pwm uses 19.2MHz clock. |
| 13:19.12 | maejrep | except that it's 10 :D |
| 13:21.39 | *** join/#htc-linux MethoS- (n=lem@host-091-096-215-056.ewe-ip-backbone.de) |
| 13:22.47 | cr2 | yes, but it have an advantage of being documented :) |
| 13:26.58 | cr2 | maejrep: the g1 pwm uses 'level' instead of arg3<<1, so it can be odd |
| 13:27.17 | NetRipper | maejrep, should we commit keyboard patch to git or should we wait for other devices to work too? |
| 13:27.31 | NetRipper | maejrep, i'll be home tomorrow again so if it needs comitting, i'll take a look the |
| 13:27.34 | NetRipper | n |
| 13:27.47 | NetRipper | i gtg again soon |
| 13:28.21 | maejrep | NetRipper: do you know what problems are on other devices? |
| 13:30.47 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 13:31.21 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 13:31.58 | NetRipper | maejrep, no i dont, i've been gone this weekend so i havent even had time to test it on my own device |
| 13:32.15 | maejrep | ok, well i have a new version anyway |
| 13:32.33 | maejrep | uses i2c chip drivers for klt and ksc, so that the LEDs can be controlled on diamond as well |
| 13:34.37 | cr2 | http://wiki.xda-developers.com/index.php?pagename=DreamGPIO |
| 13:37.28 | *** join/#htc-linux stefan_schmidt (n=stefan@p5B036CEE.dip.t-dialin.net) |
| 13:50.33 | cr2 | maejrep: but this patch does not change anything in the dividers |
| 13:50.58 | cr2 | it only makes the clk api more sane |
| 13:50.59 | maejrep | it didn't include his original clock-7x00-alt code? |
| 13:51.24 | cr2 | he rescaled the actual_freq values |
| 13:51.30 | maejrep | right |
| 13:51.32 | cr2 | for 400->528 |
| 13:51.33 | maejrep | that's the only patch I know of |
| 13:51.57 | cr2 | but as the sd clock does not depend on it anyway, so it's logical that the dividers did not change |
| 13:52.02 | maejrep | I don't think he patched it for your 7-arg formula |
| 13:52.18 | maejrep | oh right |
| 13:52.32 | cr2 | we need to extend his clk api to the i2c and other clocks anyway |
| 13:52.59 | maejrep | well, it kind of did -- when you request XXMHz, it would use a different divisor than it would have for the 400MHz verion of the same requested frequency |
| 13:53.41 | cr2 | and removed this entry: |
| 13:54.08 | cr2 | +{48000000, 0x20000 - 0xd, 0xfff40b69, 33333333},// 400/13=33.33 |
| 13:54.24 | cr2 | ok |
| 13:54.48 | cr2 | so the code allows to request any frequency ? |
| 13:56.14 | maejrep | it starts at the lowest (fmin) frequency, and keeps increasing until hitting fmax, or until it stops working, I think |
| 13:56.38 | maejrep | cr2, NetRipper, tmzt, lupine_85: http://www.privatepaste.com/f3YsccVqm6 -- new driver(s) |
| 13:56.57 | maejrep | I tested them as modules, and they work with raph800 |
| 13:57.12 | maejrep | lupine_85: if you can identify what the problem is or explain what you're seeing, it would help to track down any issues with it |
| 13:58.38 | cr2 | maejrep: can you add the second 128M bank ? |
| 13:58.41 | NetRipper | cr2, no, the code doesn't allow for any frequency.. there are a few presets which are chosen |
| 13:58.54 | NetRipper | cr2, we'll need to be careful about that second bank.. not all devices have that second bank of memory |
| 13:59.07 | maejrep | cr2: haven't tried |
| 13:59.29 | cr2 | NetRipper: can you compile the linload.exe for me ? |
| 14:00.03 | cr2 | NetRipper: we need to autodetect the SDRAM and SRAM size too |
| 14:00.09 | NetRipper | cr2, i can, but not today.. i can make a full package tomorrow ifyou want me |
| 14:00.16 | cr2 | some have 32MB sram, others 64MB sram |
| 14:00.23 | NetRipper | ok |
| 14:00.23 | *** join/#htc-linux Sparky (n=maik@77-20-236-81-dynip.superkabel.de) |
| 14:00.30 | NetRipper | SRAM being SMEM? |
| 14:00.51 | cr2 | smem is in sram |
| 14:00.55 | NetRipper | ok |
| 14:01.16 | NetRipper | so we'll need some kind of way to detect |
| 14:01.23 | NetRipper | or do we use mtypes for that |
| 14:01.36 | cr2 | NetRipper: can you compile the keyboard+128M+angstrom+linload ? |
| 14:02.09 | NetRipper | cr2, yes but im not at home now.. it'll be tomorrow on the earliest |
| 14:02.18 | cr2 | ok |
| 14:03.50 | NetRipper | maejrep, i have a raph100 so i can see if it works for me.. |
| 14:04.02 | NetRipper | i'll do that tomorrow as well |
| 14:04.06 | NetRipper | gtg, cya laters |
| 14:04.11 | maejrep | bye |
| 14:07.36 | Sparky | hello |
| 14:08.16 | Sparky | does anybody got android successfully run on the htc touch pro? |
| 14:14.03 | cr2 | maejrep |
| 14:14.14 | cr2 | maejrep: do you have a progran |
| 14:14.30 | cr2 | to invert to a0/a4 values ? |
| 14:15.09 | cr2 | s/to a/the a/ |
| 14:17.52 | *** join/#htc-linux Rogro82 (n=rogro82@s5591104d.adsl.wanadoo.nl) |
| 14:18.17 | cr2 | the first entry is strange |
| 14:18.40 | cr2 | the r1=7 too |
| 14:19.16 | cr2 | all others have r1=1 |
| 14:20.33 | cr2 | arg7 is always =1 |
| 14:20.58 | cr2 | both agree with my table |
| 14:21.25 | cr2 | not for 144kHz though |
| 14:24.01 | *** join/#htc-linux infernix (i=nix@unaffiliated/infernix) |
| 14:24.11 | *** join/#htc-linux Zinbolic (n=chatzill@84.238.80.215) |
| 14:24.15 | *** join/#htc-linux MethoS- (n=lem@host-091-097-242-177.ewe-ip-backbone.de) |
| 14:30.12 | *** join/#htc-linux infernix (i=nix@unaffiliated/infernix) |
| 14:57.42 | *** join/#htc-linux Untouchab1e (n=Untoucha@cm-84.209.89.86.getinternet.no) |
| 15:06.18 | *** join/#htc-linux timebomb (n=tb@g224107114.adsl.alicedsl.de) |
| 15:24.57 | cr2 | ok, i have compared my formula with the current hardcoded table |
| 15:25.40 | cr2 | there is only 1 bug, for 144kHz |
| 15:26.47 | cr2 | and the freq and actual_freq are wrong in many cases |
| 15:27.08 | *** join/#htc-linux tsdogs (n=tsdogs@net203-187-146.mclink.it) |
| 15:27.16 | cr2 | scaling 400->528 is completely irrelevant |
| 15:27.31 | cr2 | and confuses the things even more |
| 15:27.37 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 15:28.01 | cr2 | so i'd say that the formula is correect :) |
| 15:28.25 | cr2 | it's only the buggy code that need to be fixed |
| 15:59.14 | *** join/#htc-linux pichurri (n=pichurri@194.230.146.43) |
| 16:09.17 | cr2 | ok, it seems that i should turn to the last remaining big problem. lcd init. |
| 16:28.04 | *** join/#htc-linux p3t3r__ (n=peter@134.245.164.105) |
| 16:30.22 | dcordes | raphael proc_comm works on the xperia |
| 16:31.04 | radem205 | hey Rogro82 |
| 16:31.10 | radem205 | Are you there? |
| 16:33.37 | cr2 | dcordes: i've checked the sd clock settings and found 1 bug. the listed frequences and comments are in most cases wrong |
| 16:42.31 | dcordes | cr2: in the wiki? |
| 16:48.34 | *** join/#htc-linux chab7 (n=kvirc@212.92.4.114) |
| 16:50.13 | Rogro82 | yes im awake :) |
| 16:51.44 | radem205 | haha ok |
| 16:52.09 | radem205 | is het bij jou mogelijk om een inkomend gesprek op te nemen? |
| 16:52.57 | radem205 | want ik heb alle buttons geprobeerd maar geen één werkt en dit geldt ook voor de "menu" button |
| 16:54.33 | *** join/#htc-linux corollagtssrx (n=pocketir@32.159.175.200) |
| 16:55.01 | corollagtssrx | hey, anyone around? |
| 16:57.54 | Rogro82 | yes it works... but ill have to try and find the right button to map to |
| 16:59.28 | radem205 | ok, but it isn't possible to do it with an onscreen option at this moment (without a button), right? |
| 16:59.42 | cr2 | dcordes: no, in the ltg-git |
| 17:00.02 | radem205 | I have searched for the gpio settings for the call button but I can't find it :s |
| 17:00.03 | Rogro82 | i dont know i just used the camera button i mapped to the phone screen :) |
| 17:00.19 | radem205 | ok I will try |
| 17:00.41 | radem205 | do you had any experienced with linux before working on android? |
| 17:00.47 | Rogro82 | nope |
| 17:00.57 | radem205 | then you doing a great job :) |
| 17:01.40 | radem205 | For me android isn't usefull for daily use at the moment but it comes closely to it |
| 17:02.02 | radem205 | it works much better than WM |
| 17:02.11 | Rogro82 | thanks.. yeah i know... if all buttons are properly mapped and sound is working it will be a lot better |
| 17:02.22 | Rogro82 | and sms of course :) |
| 17:04.08 | radem205 | Yes, that's for sure |
| 17:05.14 | radem205 | It is difficult to find the right gpio for the call button, isn't it? |
| 17:05.25 | Rogro82 | dcordes: Did the android-msm kernel have working sound for kaiser? |
| 17:06.06 | dcordes | nope |
| 17:07.31 | *** join/#htc-linux stefan_schmidt (n=stefan@p5B036CEE.dip.t-dialin.net) |
| 17:07.53 | Rogro82 | k... will have to wait then.. |
| 17:11.16 | dcordes | Rogro82: probably the android-msm patch from barry has some audio related things |
| 17:12.25 | dcordes | http://linuxtogo.org/~lgorris/diffs/g1-diff-18-11-08.diff |
| 17:12.43 | dcordes | that one. it adds arch/arm/mach-msm/board-htckaiser-audio-param.c |
| 17:16.04 | cr2 | dcordes: is there anything kaiser-specific in this file ? |
| 17:19.32 | dcordes | cr2: yes. it's a diff against the android-msm-htc-2.6.25 google branch which adds kaiser support |
| 17:20.18 | cr2 | ok |
| 17:20.48 | cr2 | dcordes: does the current kernel version .27 ? boot on g1 ? |
| 17:21.16 | dcordes | but it's old better to use the htc-vogue branch now. btw you were talking about titan sd. DJWillis works on that for the kaiser. he already made ti1251 for on other boards |
| 17:21.47 | cr2 | boards ? |
| 17:21.53 | dcordes | open pandora |
| 17:22.15 | cr2 | do you know where is the sd and wifi on tita ? |
| 17:22.22 | dcordes | no |
| 17:22.41 | dcordes | do you mean this http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.27 kernel? |
| 17:22.48 | cr2 | yes |
| 17:22.56 | dcordes | I don't know. dream_kill might |
| 17:22.56 | cr2 | check http://wiki.xda-developers.com/index.php?pagename=MSM_SDIO |
| 17:23.14 | cr2 | i'd like to add tita there, but i don't have the spl locally |
| 17:23.43 | dcordes | I've seen it. don't know where titan sd is. I only looked through the titan > vogue-branch patches and I did not see something that changed sd stuff |
| 17:24.06 | dcordes | so probably sd is SDC1 like vogue and wifi SDC2 |
| 17:24.38 | cr2 | we have a lot of huge patches , that sometimes reinvent the wheel. i think we should try to create small patches, and push them. |
| 17:24.40 | cr2 | hmm. ok |
| 17:24.59 | dcordes | in the htc-msm-2.6.25 branch or in general? |
| 17:25.14 | cr2 | but to create small patches, we need some clear idea where we are going. |
| 17:25.16 | cr2 | in general |
| 17:26.08 | dcordes | I think it would be good to have code that works for A and non-A |
| 17:26.25 | dcordes | and to use .27 branch |
| 17:27.05 | cr2 | we need to create a standalone support for 3 areas missing in g1: |
| 17:27.30 | cr2 | gpio config, vreg switch and level, and clock control |
| 17:27.39 | Rogro82 | dcordes: thnx ill take a look at the diff file |
| 17:28.15 | cr2 | vreg means also proc_comm_wince |
| 17:29.31 | dcordes | proc_comm_wince works on my xperia |
| 17:30.01 | cr2 | it should work on all wince msm |
| 17:31.40 | cr2 | maybe cleaning up the code and submitting proc_comm_wince or proc_comm_dex should be the first step to mainline . |
| 17:32.40 | cr2 | dcordes: should we fix the sdcc clock errors right now ? |
| 17:34.13 | dcordes | why not. but I don't know if I'm able to help. |
| 17:35.21 | cr2 | you should remove some entries, and replace some frequency values. |
| 17:35.44 | cr2 | then i'll tell you which value should 144kHz have |
| 17:38.35 | cr2 | i'm talking about this one |
| 17:38.39 | cr2 | +struct sdcc_clock_params sd_clock_parameters[]={ |
| 17:40.40 | dcordes | cr2: in arch/arm/mach-msm/clock-7x00a-alt.c ? |
| 17:42.20 | cr2 | yes |
| 17:42.35 | cr2 | this code needs a lot of changes, but ok :) |
| 17:42.48 | cr2 | step by step |
| 17:44.40 | dcordes | ok which values need changing? |
| 17:45.53 | cr2 | first, revert all .freq and .actual_freq values |
| 17:46.02 | cr2 | to the vogue numbers |
| 17:46.25 | cr2 | because this change does not make sense at all |
| 17:47.57 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
| 17:56.13 | *** join/#htc-linux techie (n=blarg@ip24-250-216-85.ga.at.cox.net) |
| 17:59.23 | *** join/#htc-linux marmotta (n=skodde@unaffiliated/skodde) |
| 18:05.47 | *** join/#htc-linux exco (n=exco@e181116151.adsl.alicedsl.de) |
| 18:05.49 | *** part/#htc-linux exco (n=exco@e181116151.adsl.alicedsl.de) |
| 18:05.51 | *** join/#htc-linux exco (n=exco@e181116151.adsl.alicedsl.de) |
| 18:11.50 | dcordes | cr2: where are the .freq and .actual_freq values? |
| 18:13.42 | cr2 | +{2000000, 0x40000 - 0x65, 0xff9e0b78, 190080 }, |
| 18:13.53 | cr2 | the first and the last value |
| 18:15.14 | dcordes | the other three values don't change so we can replace the whole block? |
| 18:15.52 | dcordes | s/replace/reset/ |
| 18:16.05 | cr2 | yes |
| 18:16.08 | dcordes | ok |
| 18:16.28 | cr2 | next. |
| 18:17.23 | cr2 | the 0xff9e0b78 value in the first line should be 0xff9c0b78 |
| 18:17.45 | dcordes | ok |
| 18:18.18 | cr2 | the 4,8,12 MHz .freq lines can be removed |
| 18:18.48 | cr2 | and the 24 MHz line too |
| 18:19.01 | *** join/#htc-linux fnord (n=fnord@24-151-90-116.static.nwtn.ct.charter.com) |
| 18:19.47 | dcordes | ok so only 2,19,23,32,48,64 are present? |
| 18:19.54 | cr2 | and the 64MHz too |
| 18:20.06 | dcordes | ok |
| 18:20.13 | cr2 | now |
| 18:20.36 | cr2 | the 2 MHz line should be 144kHz |
| 18:20.41 | cr2 | .freq |
| 18:21.09 | cr2 | don't know the purpose of .actual_freq, but you can replace it with the same value i guess |
| 18:21.43 | cr2 | to calculate the .actual_freq from 19.2MHz TCX0 one needs to know too much :) |
| 18:22.02 | dcordes | TCX what |
| 18:22.20 | cr2 | base clock source |
| 18:22.40 | cr2 | have you replaced the 2 by 144 ? |
| 18:22.51 | cr2 | 2000000 by 144000 |
| 18:22.58 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
| 18:23.49 | dcordes | {144000,0x40000-0x65,0xff9c0b78,144000}, |
| 18:23.56 | cr2 | ok |
| 18:23.59 | cr2 | now |
| 18:23.59 | dcordes | {144000,0x40000-0x65,0xff9c0b78,144000}, |
| 18:23.59 | dcordes | {19000000,0x20000-0x21,0xffe00b69,14000000}, |
| 18:23.59 | dcordes | {23000000,0x20000-0xb,0xfff60b79,20000000}, |
| 18:23.59 | dcordes | {32000000,0x20000-0x11,0xfff00b69,25000000}, |
| 18:24.00 | dcordes | {48000000,0x20000-0xd,0xfff40b69,33333333}, |
| 18:24.20 | cr2 | the 19 MHz is 12 MHz |
| 18:24.29 | cr2 | the 23 MHz is 19 MHz |
| 18:24.49 | cr2 | the 32 MHz is 24 MHz |
| 18:25.00 | cr2 | 48 is ok |
| 18:25.15 | cr2 | but you may change the .actual_freq to the .freq values |
| 18:25.50 | cr2 | imvho if now it will not work, then there exist some other bugs in the kernel |
| 18:26.45 | dcordes | want me to compile the raphael zImage with that? (can't test myself.) |
| 18:26.58 | cr2 | it should work everywhere |
| 18:27.15 | cr2 | the algorithm is the same from vogue to blackstone |
| 18:27.25 | cr2 | and matches my formula |
| 18:27.41 | dcordes | so it can be tested on kaiser too? |
| 18:27.54 | cr2 | yes |
| 18:28.04 | dcordes | http://privatepaste.com/03BGWjtqMd |
| 18:29.00 | dcordes | maybe somebody else can test it. I need to pack bags |
| 18:29.08 | cr2 | looks good |
| 18:29.10 | dcordes | I can only try it later |
| 18:29.27 | cr2 | ok |
| 18:39.36 | *** join/#htc-linux metter (n=metter@51-87.1-85.cust.bluewin.ch) |
| 18:47.17 | *** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 18:53.45 | cr2 | are there linux usb installation sticks ? |
| 18:55.05 | Rogro82 | radem205: posted a new file |
| 18:55.13 | radem205 | Yes I see, thanks!! |
| 18:55.27 | Rogro82 | let me know if it works :) |
| 18:55.39 | radem205 | But how can I help you with finding the right gpio for the several buttons? |
| 18:55.48 | radem205 | Because I want to help you, but I don't know how :( |
| 18:56.27 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d87cd7e.pool.einsundeins.de) |
| 18:56.32 | Rogro82 | ill post up a new manual on how to build the kernel with the latest adjustments once i have more time |
| 18:57.07 | radem205 | ok thanks, I have Ubuntu installed but "ik zie door de bomen het bos niet meer" |
| 18:57.36 | Rogro82 | hehehe... i know what you mean :) |
| 18:57.50 | radem205 | :) |
| 18:58.05 | radem205 | Is it right when I click the call button it takes a while before the dialer open? |
| 18:58.18 | radem205 | It takes +/- 2 seconds |
| 18:58.30 | Rogro82 | yes happens to me also... its because it isnt actually the right button but it works... for now |
| 18:58.41 | radem205 | haha ok |
| 18:59.14 | Rogro82 | and the volume button? |
| 18:59.38 | radem205 | works, but only, what you said, volume up |
| 18:59.47 | Rogro82 | answering calls works immediatly though |
| 18:59.47 | radem205 | but it works:) |
| 19:01.11 | radem205 | that works great indeed |
| 19:01.24 | Rogro82 | i dont know how the "hang up" on a vogue works... is it the hangup button? |
| 19:02.23 | radem205 | I don't know |
| 19:02.55 | radem205 | I think that would be |
| 19:02.55 | radem205 | plausible |
| 19:03.20 | Rogro82 | heared they had to double press it if im not mistaking.... ill look into it |
| 19:03.46 | radem205 | But how did you find the correct gpio for the call button? Did you try each value and see what happened? |
| 19:05.01 | *** join/#htc-linux Guillaume_ (n=guillaum@nsg93-6-82-246-132-225.fbx.proxad.net) |
| 19:05.06 | radem205 | sometimes I have to double press some buttons too to let it work, for example the power button (I think you have this too) |
| 19:05.10 | Rogro82 | basically... not the right way... but i already seen one that made the 3 buttons work ( its was commented as being the voicerecorder button ) |
| 19:06.17 | Rogro82 | power button only first time |
| 19:06.17 | Rogro82 | and the volume button was just a lucky guess :) |
| 19:06.55 | radem205 | Nice :), the volume button has maybe one button assigned with two directions |
| 19:07.09 | radem205 | Because only the volume up works for now |
| 19:07.32 | radem205 | but when I slide down (volume down) the volume goes up |
| 19:07.42 | Rogro82 | i just mapped it to volume up... somehow up and down are both being triggered using this gpio :S |
| 19:08.18 | radem205 | yes, that's weird and difficult to find out how it's exactly work |
| 19:08.53 | Rogro82 | well I should take sometime and read up on how to monitor them but dont have that much time :) |
| 19:09.10 | radem205 | you can't recognize a pattern in the numbers of the gpio's? |
| 19:09.40 | radem205 | I know, you've already done a lot |
| 19:09.48 | Rogro82 | nah... some are logical grouped and some are apart |
| 19:10.19 | Rogro82 | 1 sec need to smoke :) |
| 19:10.28 | radem205 | ok |
| 19:15.20 | radem205 | are you there? |
| 19:15.22 | radem205 | :) |
| 19:15.47 | radem205 | I have found that haret can output the gpio's |
| 19:17.04 | radem205 | or did you know that |
| 19:18.38 | radem205 | it is very simple I think |
| 19:20.28 | Rogro82 | back again |
| 19:20.37 | Rogro82 | yeah thats what i needed to read :) |
| 19:20.57 | Rogro82 | can you try to find the right ones? |
| 19:21.01 | radem205 | http://www.handhelds.org/moin/moin.cgi/HaRET_20Documentation |
| 19:21.21 | radem205 | yes, but how could Haret save a log file, do you know that? |
| 19:22.10 | radem205 | but I will try to find out |
| 19:22.35 | Rogro82 | k ill also try to look at it in between things :) |
| 19:23.21 | radem205 | I think you are faster, but I will give it a try :) |
| 19:26.56 | radem205 | Do you know how I can make a log file when using haret? |
| 19:28.27 | *** join/#htc-linux stefan_schmidt_ (n=stefan@p5B0355C6.dip.t-dialin.net) |
| 19:34.26 | Rogro82 | i thought placing a file called earlyharetlog.txt on your sdcard |
| 19:34.42 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 19:34.43 | ali1234 | there is a log command |
| 19:34.59 | ali1234 | i think it's log <file> |
| 19:35.36 | ali1234 | the early log is more for debugging haret |
| 19:48.49 | *** join/#htc-linux DasFx (n=John@5354790B.cable.casema.nl) |
| 19:51.39 | *** join/#htc-linux DasFx (n=John@5354790B.cable.casema.nl) |
| 19:52.26 | *** join/#htc-linux DasFx (n=John@5354790B.cable.casema.nl) |
| 20:02.03 | *** join/#htc-linux TeringTuby (n=maarten@195-241-125-243.ip.telfort.nl) |
| 20:04.07 | Rogro82 | why do mulptiple buttons have the same gpio when i trace them using haret? for eg the call and hangup button? |
| 20:04.15 | Rogro82 | multiple |
| 20:05.12 | radem205 | Hmm, what output do you exactly get? |
| 20:05.21 | radem205 | And have you used haretconsole? |
| 20:07.28 | Rogro82 | yes... i get: in1: in1-24(216)=0 and then becomes 1 on both call and hangup button |
| 20:08.28 | radem205 | do you have also an output like this: |
| 20:08.32 | radem205 | HaRET(11)# watch gpios 30 |
| 20:08.32 | radem205 | Beginning memory tracing. |
| 20:08.32 | radem205 | Watching GPIOS(00): Addr b6600004(@56000004) |
| 20:08.32 | radem205 | Watching GPIOS(01): Addr b6600014(@56000014) |
| 20:08.32 | radem205 | ... |
| 20:08.32 | radem205 | 002.269 GPIOS GPGDAT: GPG3(195)=0 <----- button press |
| 20:08.34 | radem205 | 002.481 GPIOS GPGDAT: GPG3(195)=1 <----- button release |
| 20:08.36 | radem205 | HaRET(12)# |
| 20:10.21 | radem205 | It is very strange when you press, for example, the call button also the hangup button is pressed |
| 20:11.21 | Rogro82 | yes... i really dont know how to read it exactly... can anyone help me out on this one? |
| 20:11.55 | radem205 | when you use "watch gpios 30". When you run this you can press for example the call button and see what output haret gives |
| 20:12.37 | radem205 | In each report, the first column (eg, 000.998) is the time, in seconds since command start, that the change was noticed. The second column (eg, GPIOS) is a reminder that one is watching gpios. The third column (eg, GPEDAT) is the name of the architecture register where the change was noticed. The fourth column (eg, GPE5(133)=0) has the individual GPIO name, a HaRET id for it in parenthesis, and the value it has changed to. |
| 20:13.50 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbff4d2.pool.einsundeins.de) |
| 20:16.29 | radem205 | Rogro: http://forum.xda-developers.com/showpost.php?p=2104309&postcount=91 |
| 20:21.54 | radem205 | hi dzo |
| 20:25.13 | *** join/#htc-linux dzo (n=dzo@121.98.128.127) |
| 20:25.15 | radem205 | Any progress by getting such output I have posted Rogro? |
| 20:31.04 | Rogro82 | no thats exactly what i did but i get the same values for pressing the call and the hangup button :S |
| 20:31.58 | radem205 | did you get something like this: "002.269 GPIOS GPGDAT: GPG3(195)=0" |
| 20:34.32 | radem205 | I think that the number between the "haakjes" is the number you have to use. And the 0 and 1 behind the equal sign are respectively pressed and released. But it is very strange when more then 1 buttons have the same number between the "haakjes" :( |
| 20:35.04 | exco | haakjes = brackets? |
| 20:35.21 | Rogro82 | yes both call and hangup button are the same and the inet and the other are the same |
| 20:36.03 | radem205 | :S |
| 20:36.05 | exco | volume up/down have the same "problem" |
| 20:36.36 | Rogro82 | yes... :S |
| 20:36.53 | Rogro82 | what can we do about it? |
| 20:36.59 | radem205 | Here they have the same problem: http://forum.xda-developers.com/showthread.php?t=430422 |
| 20:37.06 | radem205 | but no solution yet :( |
| 20:37.12 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 20:39.14 | Rogro82 | Strange things is if i use the gpio i used in my latest kernel the 3 buttons not mapped are all mapped the same ( call/voicerecorder/nav ) |
| 20:41.38 | radem205 | I think the only one who can help us is DZO |
| 20:47.02 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 20:47.18 | radem205 | Did the volume button(s) also have the same number? |
| 20:47.29 | radem205 | oh sorry, i see it now |
| 20:49.15 | Rogro82 | yes they are the same and share there nr with the voicerecord button |
| 20:49.25 | Rogro82 | so actually 3 the same |
| 20:51.14 | radem205 | Here you find the answer why some buttons have the same gpio: http://forum.xda-developers.com/showpost.php?p=2794232&postcount=1130 |
| 20:51.16 | exco | and the wheel doesn't use any? |
| 20:52.17 | *** join/#htc-linux cr2 (n=cr2@ip-77-25-5-22.web.vodafone.de) |
| 20:56.24 | Rogro82 | ill have to look into it |
| 20:56.32 | Rogro82 | almost have all of them |
| 20:57.05 | cr2 | BabelO: got disconnected |
| 21:05.00 | BabelO | cr2: , i think i found something wrong in sources :) |
| 21:06.35 | cr2 | ok |
| 21:08.13 | tmzt | EV_MSC and MSC_SCAN this is the same as pc serio? |
| 21:09.05 | tmzt | ACPU are the clocks controlled by arm11 aren't they? |
| 21:10.45 | radem205 | I think the easiest way to find out is to ask dzo |
| 21:11.41 | cr2 | tmzt: yes |
| 21:14.04 | *** join/#htc-linux imfloflo (n=imfloflo@cap31-6-88-180-73-121.fbx.proxad.net) |
| 21:14.26 | imfloflo | hi |
| 21:14.46 | tmzt | ram size should be passed from haret with ATAG_MEM, particularly for sparse mem support |
| 21:16.40 | BabelO | cr2: it was that, i did not reserve the page adress earlier in the kernel |
| 21:20.49 | cr2 | BabelO: i thought that all builtin devices are already reserved |
| 21:21.24 | cr2 | tmzt: the _fixup is ok too |
| 21:21.58 | BabelO | cr2: look like it is not the case on omap |
| 21:22.04 | cr2 | tmzt: i think there was an option of mem=0xa@0xb mem=0xc@0xd |
| 21:22.25 | cr2 | BabelO: ok, i'm not that much familiar with omap |
| 21:22.50 | maejrep | cr2: I'm trying the clock changes now |
| 21:26.04 | *** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146) |
| 21:26.07 | Untouchab1e | Good evening |
| 21:26.26 | cr2 | maejrep:ok |
| 21:27.43 | cr2 | maejrep: the most code there can be replaced by creating a full clock table. not only for the sdcc bt also for the other clocks that we need |
| 21:28.19 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 21:28.20 | cr2 | maejrep: and if these new values are ok, they can re replaced with the formula |
| 21:28.21 | maejrep | oh really? all clocks use the same formula (not just sd)? |
| 21:28.27 | maejrep | nice :) |
| 21:28.33 | *** join/#htc-linux Sti_0239 (n=Where_is@78.149-65-87.adsl-dyn.isp.belgacom.be) |
| 21:28.36 | maejrep | guinea pig, booting up ;) |
| 21:28.38 | cr2 | or they are "fixed" |
| 21:28.40 | cr2 | lol |
| 21:29.17 | cr2 | everybody is a guinea pig, before the vreg and lcd init are fixed ;) |
| 21:29.40 | tmzt | cr2: the reason I said ATAG_MEM is openezx tried the mem= thing, it appears to populate the table twice if both are given |
| 21:29.42 | maejrep | cr2: there's a weird bug in git head for raph800 at least, where the display gets pretty badly corrupted, but its kind of like a sync issue |
| 21:30.00 | maejrep | looks like old TVs that you had to control sync,etc manually |
| 21:30.18 | tmzt | caught up here now |
| 21:30.39 | tmzt | Rogro82: radem205: the problem you are seeing is the one maejrep is currently working on |
| 21:30.40 | maejrep | [ 5.331434] clk_set_rate 23:144000 |
| 21:30.40 | maejrep | [ 5.340091] clock-7x00a-alt: set_sdcc_host_clock( 23, 144000 ) |
| 21:30.42 | maejrep | [ 5.390061] mmc0: MMC clock 144000 -> 20000000 Hz, PCLK 66000000 Hz |
| 21:31.04 | cr2 | huh ? |
| 21:31.15 | maejrep | so, looks like the code is currently only picking the first freq, not finding the best freq |
| 21:31.17 | cr2 | 20MHz ? |
| 21:31.30 | maejrep | no, it shows 144KHz - 20MHz range |
| 21:31.40 | maejrep | but set_sdcc_host_clock() is only setting 144KHz |
| 21:31.59 | maejrep | (but it does work :p) |
| 21:32.00 | cr2 | the clock selection should come from the sdio core |
| 21:32.08 | maejrep | :x |
| 21:32.14 | cr2 | it must start with the minimal frequency |
| 21:32.29 | cr2 | pick the card data, and adjust the frequency |
| 21:32.31 | maejrep | oh |
| 21:32.33 | maejrep | nevermind! |
| 21:32.34 | maejrep | [ 8.077904] clk_set_rate 23:20000000 |
| 21:32.34 | maejrep | [ 8.080152] clock-7x00a-alt: set_sdcc_host_clock( 23, 24000000 ) |
| 21:32.38 | maejrep | was 3 seconds later ;) |
| 21:32.50 | maejrep | hmm, why is that 24 |
| 21:32.51 | cr2 | but selecting the right clock is not the clk business |
| 21:33.07 | maejrep | because we only support 24MHz, not 20MHz |
| 21:33.08 | cr2 | for SD it's more or less the maximal frequency |
| 21:33.19 | maejrep | so fmax needs to be increased? |
| 21:33.23 | cr2 | 20MHz is the maximal mmc frequency |
| 21:33.38 | cr2 | fmax should be 48MHz |
| 21:33.43 | maejrep | ok :) |
| 21:33.48 | cr2 | it's the controller capability |
| 21:33.55 | maejrep | so far so good |
| 21:34.21 | cr2 | i don't know the SD 2.0 details, but i guess it has just doubled the max frequency |
| 21:34.23 | maejrep | will the sdcc change the clock based on card? |
| 21:34.31 | cr2 | yes, it should |
| 21:34.45 | cr2 | how can you do it otherwise ? |
| 21:34.45 | maejrep | any way to test that? I really only have a 512MB and a 2GB card |
| 21:34.55 | maejrep | I can use debugfs to change rate |
| 21:35.01 | maejrep | but I don't know if I want to try it :) |
| 21:35.08 | cr2 | microSD is difficult |
| 21:35.19 | cr2 | for a normal SD slot i have a lot of options :) |
| 21:35.32 | cr2 | mmc, mmc4 and a lot of different SD cards |
| 21:35.55 | maejrep | cr2: x,1,0x0c,0x06;1,3,1,1 <-- is there anything special about that ';' ? |
| 21:36.04 | cr2 | microSD is so modern, that i doubt that you'll have problems with 24MHz |
| 21:36.30 | cr2 | maejrep: it'd be the decision on the sdio core |
| 21:36.34 | cr2 | not yours :) |
| 21:36.41 | maejrep | for what? |
| 21:36.50 | cr2 | for going to 48MHz |
| 21:36.54 | maejrep | ah ok |
| 21:37.02 | cr2 | the sdhc capability is there |
| 21:37.07 | maejrep | but is each number there ^ a separate arg? |
| 21:37.19 | maejrep | I'm confused about the ; after the 3rd argument in each line |
| 21:37.36 | cr2 | i guess that by changing the divisors you may increase it, but it'll be out of spec anyway |
| 21:37.44 | tmzt | semi-colon |
| 21:37.57 | cr2 | they are on the stack. was a small self-note by me |
| 21:38.03 | maejrep | yes, the semi-colon :) |
| 21:38.05 | cr2 | now you can remove it. |
| 21:38.15 | maejrep | ok cool |
| 21:38.25 | maejrep | and, what should i do with "mask"? |
| 21:38.28 | cr2 | it's the msvc ABI |
| 21:38.38 | cr2 | where ? |
| 21:38.42 | maejrep | in that table |
| 21:38.47 | maejrep | http://wiki.xda-developers.com/index.php?pagename=MSM_SDIO |
| 21:38.51 | maejrep | 1st column |
| 21:38.58 | *** join/#htc-linux timebomb (n=tb@e176113243.adsl.alicedsl.de) |
| 21:39.15 | cr2 | it's an internal note too |
| 21:39.31 | maejrep | ok, not needed in code then? |
| 21:39.50 | cr2 | raph can do all frequences, but for kaiser et al. 19MHz was the top speed in the spl |
| 21:40.23 | cr2 | 7x00 non-A people should check the fmax |
| 21:41.01 | cr2 | maejrep: the mask is not needed, but it's for the A cpu only |
| 21:41.08 | cr2 | mask -> frequency relation |
| 21:41.28 | maejrep | ok, as long as its not needed I'll ignore it :p |
| 21:41.36 | cr2 | but in linux it should be resolved only by fmax |
| 21:41.42 | cr2 | ok |
| 21:41.55 | cr2 | i don't know if 7x00 can 48Mhz |
| 21:42.12 | cr2 | at leats it is not tested in the spl, which does 19MHz only |
| 21:42.24 | cr2 | and for wifi |
| 21:42.37 | cr2 | it should be stored somewhere in the sdio tuples |
| 21:42.44 | cr2 | how fast it can be driven |
| 21:42.56 | cr2 | so it's not a problem of the clock code |
| 21:43.16 | cr2 | which certainly needs a further cleanup. |
| 21:44.40 | cr2 | it hardcodes the sdc4 as default clock, and does not handle the i2c and other clocks |
| 21:45.13 | cr2 | and it simply has too much code, which can be replaced by a table indexed by id. |
| 21:45.51 | cr2 | we should think about minimizing the differences to androids cvs |
| 21:46.14 | tmzt | does the wifi chip support enumeration or does it require embedded sdio with the sdio tuples in the driver? |
| 21:47.15 | cr2 | tmzt: the sdio subsystem and tiacx will take care about it. |
| 21:47.47 | cr2 | sdio is just like pcmcia, but with a serial and not parallel physical interface |
| 21:48.57 | cr2 | tmzt: enumeration is just part of the sdio init |
| 21:49.06 | maejrep | cr2: fff60b78 vs fff60b79 ? |
| 21:49.11 | maejrep | are we worried about that difference? |
| 21:49.22 | cr2 | maejrep: where ? |
| 21:49.30 | cr2 | 78 is only for 144kHz |
| 21:49.50 | cr2 | maejrep: actually, you can replace this table by the formula |
| 21:49.54 | maejrep | my calculation from the formula comes out to b78, but the table in the clock code has b79 |
| 21:50.01 | maejrep | that's what I'm planning to do |
| 21:50.05 | cr2 | because i have had-checked all the values |
| 21:50.08 | maejrep | but I want to be sure my implementation is sane first |
| 21:50.13 | cr2 | s/had-/hand-/ |
| 21:50.34 | maejrep | so b78 is correct? |
| 21:50.35 | *** join/#htc-linux XD (i=t3st1fy@ircop.com) |
| 21:50.54 | maejrep | and that was for 19MHz, not 144KHz |
| 21:50.55 | cr2 | maejrep: can you paste the table ? |
| 21:51.09 | maejrep | I'm just checking one row at a time |
| 21:51.14 | maejrep | in my own test program |
| 21:51.15 | cr2 | 19 has b79 |
| 21:51.29 | cr2 | ok |
| 21:52.08 | maejrep | hmm |
| 21:52.12 | cr2 | 144k b78 |
| 21:52.32 | cr2 | the rest is b69 |
| 21:53.02 | maejrep | i take that back :x |
| 21:53.07 | tmzt | Hermann and Victor are apparently internal codenames for Touch Pro and Diamond |
| 21:53.07 | cr2 | :) |
| 21:53.07 | maejrep | 19MHz: 0001fff5, fff60b7b |
| 21:53.20 | AstainHellbring | yes tmzt |
| 21:53.27 | AstainHellbring | for the cdma versions |
| 21:53.30 | maejrep | so that looks right ;o |
| 21:54.03 | maejrep | actually, no it doesn't.. I'm getting b7b, not b79 :o |
| 21:54.10 | cr2 | tmzt: now you need to find the right fimrware :) we had a person here who wanted to disassemble it :) |
| 21:54.55 | tmzt | for what? |
| 21:55.13 | cr2 | maejrep: it's arg6, how can it be wrong ? |
| 21:55.37 | cr2 | tmzt: for microP atmel mega x8 |
| 21:55.37 | tmzt | firmware for what? |
| 21:55.44 | maejrep | i'll check again |
| 21:56.12 | tmzt | isn't that embedded in the spl or is it really not flashed at boot? |
| 21:56.34 | maejrep | cr2: my mistake :) had an extra 3 |
| 21:56.37 | *** join/#htc-linux timebomb (n=tb@e176113243.adsl.alicedsl.de) |
| 21:56.44 | cr2 | it is not flashed at boot, but spl has the capability to reflash |
| 21:56.50 | maejrep | 19000: 0001fff5, fff60b79 |
| 21:57.00 | cr2 | tmzt: i don't know where the fw comes from. |
| 21:57.04 | maejrep | 144: 0003ff9b, ff9e0b78 |
| 21:57.17 | cr2 | tmzt: there are more pressing issues. |
| 21:57.34 | maejrep | should that be ff9e or ff9c ? |
| 21:57.37 | tmzt | sure, I thought you where looking for those names from the driver code before |
| 21:57.53 | cr2 | maejrep: where ? |
| 21:57.58 | tmzt | and it looks like maejrep has a working driver nearly |
| 21:58.02 | maejrep | for 144khz |
| 21:58.20 | cr2 | maejrep: i think the original value was wrong |
| 21:58.47 | cr2 | tmzt: leds, luminosity and brightness |
| 21:58.49 | maejrep | I just ran the 144khz numbers through the same formula, and got ff9e0b78 |
| 21:59.23 | maejrep | which i think is what used to be in the table, but you told dcordes to change it to ff9c |
| 21:59.39 | cr2 | ah, sorry. it's my bug now |
| 21:59.47 | cr2 | :) |
| 21:59.52 | maejrep | so ff9e is right? |
| 21:59.53 | cr2 | resolved. |
| 21:59.55 | cr2 | yes |
| 22:00.08 | cr2 | the arg1 is 3, not 1 there |
| 22:01.08 | maejrep | 12000: 0001ffdf, ffe00b69 |
| 22:02.00 | maejrep | 24000: 0001ffef, fff00b69 |
| 22:02.25 | *** join/#htc-linux Summerspittman (n=secondsu@c-24-99-80-238.hsd1.ga.comcast.net) |
| 22:02.33 | maejrep | 48000: 0001fff3, fff40b69 |
| 22:02.36 | maejrep | looks correct :) |
| 22:02.48 | cr2 | maejrep: you can also rename a0 and a4 to MD and NS, how htc calls them in the SD driver |
| 22:03.01 | maejrep | yum I did |
| 22:03.02 | maejrep | er |
| 22:03.03 | maejrep | yup |
| 22:03.04 | cr2 | ok |
| 22:03.35 | maejrep | ok and I'll replace the table with a macro of the formula |
| 22:04.13 | cr2 | what is missing now is the TCX0 -> PLL formula, and how NS and MD are used to divide the PLL |
| 22:04.39 | cr2 | but i guess you need the 7201A manual for that. |
| 22:05.02 | cr2 | the frequencies are certainly approximate |
| 22:05.16 | cr2 | because everything is based on the 19.2MHz clock |
| 22:05.41 | dream_kill | anyone flashed the g1 radio yet :P ? |
| 22:06.23 | cr2 | dream_kill: i don't flash anything without the source code available ;) |
| 22:07.04 | dream_kill | :D |
| 22:08.12 | maejrep | dream_kill: have any insight into that ^ ? ;) |
| 22:08.19 | cr2 | maejrep: by next math challenge is the drvstr+pull+alt for gpios |
| 22:08.31 | maejrep | :) |
| 22:08.43 | *** part/#htc-linux exco (n=exco@e181116151.adsl.alicedsl.de) |
| 22:09.02 | cr2 | but it's only to make our android friends happy |
| 22:09.19 | cr2 | otherwise it's not necessary |
| 22:10.38 | tmzt | cr2: which bt chip has fm? |
| 22:11.03 | cr2 | all |
| 22:11.30 | cr2 | it's the same chip on all msm phones |
| 22:11.46 | cr2 | i think the question is only if it's wired or not |
| 22:11.51 | maejrep | <PROTECTED> |
| 22:11.51 | maejrep | <PROTECTED> |
| 22:11.51 | maejrep | <PROTECTED> |
| 22:11.51 | maejrep | <PROTECTED> |
| 22:11.51 | maejrep | <PROTECTED> |
| 22:11.53 | maejrep | :o |
| 22:12.28 | cr2 | nice :) |
| 22:13.01 | cr2 | but having a pll formula may be even better |
| 22:13.02 | tmzt | where is this from? |
| 22:13.34 | cr2 | i have no idea where does the 66MHz PCLK comes from, which is hardcoded into the current code. |
| 22:13.48 | maejrep | its not hardcoded in wince? |
| 22:14.14 | cr2 | wince contolls only a limited number of clocks |
| 22:14.26 | tmzt | that's the clock for the sdcc itself, the other is for the card? |
| 22:14.37 | cr2 | the core clocks for arm9 and such are inside the amss |
| 22:15.18 | cr2 | tmzt: a cpu clock distribution diagramm is needed to know exactly. |
| 22:15.30 | cr2 | tmzt: now i know why i like pxa ;) |
| 22:15.38 | tmzt | I mean the difference between CLK and PCLK |
| 22:15.46 | cr2 | need to hack on athena again |
| 22:16.06 | cr2 | tmzt: who knows |
| 22:16.50 | tmzt | ok but does it work with PCLK constant? |
| 22:16.51 | cr2 | 66 is not a multiple of 19.2 |
| 22:16.59 | cr2 | so it's something complex |
| 22:17.23 | cr2 | this explicit value is not needed |
| 22:17.37 | cr2 | only for the g1 compatibility there. |
| 22:17.51 | maejrep | http://privatepaste.com/110MmwfIFz#clock-formula :) |
| 22:19.10 | maejrep | cr2: are my names right? md = a0, ns = a4 ? |
| 22:19.47 | *** join/#htc-linux ionstorm (n=ion@ip68-227-226-5.ph.ph.cox.net) |
| 22:19.49 | cr2 | maejrep: why do you need the sdcc clk_bit and clk_offset functions ? |
| 22:20.10 | tmzt | cr2: would it be possible to measure the clock pin of the sd and cycle through these or something? |
| 22:20.24 | maejrep | to turn an id into a globalclkena bit and a clk_ctl offset ? |
| 22:20.38 | cr2 | http://wiki.xda-developers.com/index.php?pagename=MSM_CLK |
| 22:20.53 | cr2 | i'll turn it into a table like in wiki |
| 22:21.14 | maejrep | so use the clock id to return offset and bit? |
| 22:21.24 | cr2 | yes |
| 22:21.32 | maejrep | hmm ok |
| 22:21.46 | cr2 | the mddi, i2c and g1 pwm can be covered by this formula too |
| 22:21.53 | cr2 | i hope that the uart2DM too |
| 22:22.11 | cr2 | but we are not yet working with bt :) |
| 22:22.12 | tmzt | bluetooth |
| 22:22.32 | cr2 | tmzt: which device is bt on g1 ? |
| 22:22.41 | Untouchab1e | Hows it going guys? |
| 22:22.43 | tmzt | the new high-speed uart driver might help here also if it changes the clock handling |
| 22:22.44 | cr2 | as in /dev/myg1bt |
| 22:22.46 | maejrep | but it can't just be a formula .. gonna have to create an actual table for this |
| 22:22.50 | tmzt | haven't found out yet |
| 22:23.32 | cr2 | maejrep: a19 ,a06 and a00 fit well into this formual |
| 22:23.35 | Untouchab1e | have anyone made any progress during hte weekend? |
| 22:23.42 | maejrep | what are those? |
| 22:23.46 | cr2 | even if it's not correct in the hw |
| 22:23.47 | Untouchab1e | Maejrp, did you get the qwerty going eventually? :) |
| 22:23.57 | cr2 | maejrep: MSM_CLK |
| 22:24.02 | maejrep | i'm there |
| 22:24.08 | maejrep | but i don't see a19 etc |
| 22:24.18 | *** join/#htc-linux ALoGeNo (n=alogeno@unaffiliated/alogeno) |
| 22:24.23 | cr2 | +0x8c |
| 22:24.31 | maejrep | oh |
| 22:24.34 | ALoGeNo | hey cr2 :) |
| 22:24.34 | maejrep | :) |
| 22:24.39 | ALoGeNo | lo all |
| 22:24.44 | maejrep | hi |
| 22:24.50 | cr2 | hi ALoGeNo |
| 22:26.05 | cr2 | maejrep: the clk api should cover all clocks, not just the sdcc |
| 22:26.28 | cr2 | and we have only 3 extra clocks under out control |
| 22:26.35 | cr2 | s/out/our/ |
| 22:26.44 | cr2 | so it's not that difficult to do |
| 22:26.57 | *** part/#htc-linux Guillaume_ (n=guillaum@nsg93-6-82-246-132-225.fbx.proxad.net) |
| 22:27.15 | cr2 | didn't see the cam clocks on A, only on the titan |
| 22:30.28 | cr2 | tmzt: sdc_pclk is one clock |
| 22:30.41 | tmzt | for all the sdcc's? |
| 22:31.27 | cr2 | tmzt: i see 31 unique clock in MSM_CLK |
| 22:31.47 | cr2 | in the table picked from g1 code |
| 22:33.36 | cr2 | i think NetRipper has dumped the complete clock area for me once |
| 22:34.13 | cr2 | but it seems that reading the a0/a4 type values is not a good idea |
| 22:34.28 | cr2 | because they do not match the values that are written there |
| 22:34.59 | cr2 | but it may be interesting to check what bits are set at 0x00 |
| 22:37.18 | tmzt | 0x214 sd related, you are saying that's SDC_PCLK? |
| 22:42.21 | cr2 | unlikely |
| 22:42.57 | tmzt | the clock.h in trout, that lists all the clocks there are likely to be? |
| 22:42.59 | cr2 | it may be somewhere deep in the arm9 internals |
| 22:43.05 | cr2 | yes |
| 22:43.37 | cr2 | not to be, but to be useful |
| 22:43.41 | cr2 | for atm11 |
| 22:43.45 | cr2 | s/at/ar/ |
| 22:45.46 | maejrep | cr2: where did you find idx from g1 code? |
| 22:46.05 | cr2 | maejrep: it's the idx for the mask |
| 22:46.16 | cr2 | i'd like to have the idx from g1 too :) |
| 22:46.29 | *** join/#htc-linux Gautam_Kok (n=chatzill@195-241-94-2.ip.telfort.nl) |
| 22:46.35 | Gautam_Kok | Hi guys |
| 22:46.37 | maejrep | right but you said it corresponds to the g1 idx (1<<g1idx) |
| 22:46.44 | cr2 | for vreg |
| 22:46.47 | tmzt | cr2: do you mean the clk_idx passed to clk_ api and proc_comm? |
| 22:46.51 | maejrep | ohh, not clocks? |
| 22:46.51 | cr2 | not for the clk |
| 22:46.57 | maejrep | i see |
| 22:47.26 | cr2 | there is no proc_comm clk api for us |
| 22:47.58 | GautamK | Does anyone know when the first stable version of Android for HTC Touch Diamond will be released? |
| 22:48.03 | tmzt | I know, I mean on g1 what do you mean by idx? |
| 22:48.27 | GautamK | I just tried out version 1, but it's still not completely functioning. But I already am addicted to it. It's so much better than Windows xD |
| 22:49.05 | maejrep | cr2: so my table would have clk_id, offset, and idx (which will be used as 1<<idx to get mask)? |
| 22:49.24 | maejrep | e.g.: |
| 22:49.28 | maejrep | <PROTECTED> |
| 22:49.28 | maejrep | <PROTECTED> |
| 22:51.14 | cr2 | maejrep: name from g1 list ? |
| 22:51.23 | maejrep | and the clk_enable bit would be generated as 1U << .idx, clk_reg would be CLK_CTL + .offset |
| 22:51.30 | maejrep | you want me to add the name? |
| 22:51.36 | maejrep | "sdc1_clk" |
| 22:51.57 | cr2 | how do we keep the compatibility with g1 code ? |
| 22:52.16 | tmzt | cr2: really just clk_ api I think which is same as upstream linux |
| 22:52.17 | cr2 | or do they use the clock ids directly ? |
| 22:52.35 | maejrep | no they fetch clock by name I think |
| 22:52.57 | cr2 | for vregs it is so, but i don't remember about the clk |
| 22:53.36 | maejrep | clk_get(NULL, "sdc1_clk"); etc |
| 22:55.19 | cr2 | ok, then the list should include the name |
| 22:55.52 | cr2 | we don't want to break the drivers that use the api |
| 22:56.34 | maejrep | hmm, the current -alt code doesn't appear to use clock names at all |
| 22:56.49 | maejrep | ie, the 'clocks' array is not defined |
| 22:57.24 | cr2 | don't forget the 7X00 ifdef |
| 22:58.02 | cr2 | some locations are different, and there is no SDC3, SDC4 and uart2DM |
| 23:00.50 | maejrep | i keep forgetting that reboot isn't implemented yet :P |
| 23:01.09 | cr2 | lol |
| 23:02.04 | tmzt | what does kaiser/vogue use for bluetooth if there is no uart2DM? |
| 23:02.16 | cr2 | uart1DM |
| 23:02.36 | cr2 | i think so |
| 23:02.38 | *** join/#htc-linux daspsycho_work1 (n=TimJorda@213.155.79.202) |
| 23:02.41 | tmzt | ah, so it's similar? |
| 23:02.49 | tmzt | DM refers to data mover? |
| 23:02.53 | cr2 | tmzt: where is the hs bt driver ? |
| 23:02.56 | cr2 | yes |
| 23:03.13 | tmzt | in 2.6.27 kernel android.git.kernel.org, don't know how complete it is |
| 23:03.37 | cr2 | i can see only the pdata |
| 23:04.01 | tmzt | it's also not clear whether that's what's missing or if it's patches to hciattach hci_uart to enable the high speed mode |
| 23:05.17 | tmzt | drivers/serial/msm_serial_hs.c |
| 23:06.09 | cr2 | ok |
| 23:06.20 | tmzt | msm_serial_hw_hwreg.h, looks interesting |
| 23:07.55 | cr2 | linux/ ? |
| 23:08.36 | cr2 | ok, see it now |
| 23:09.49 | tmzt | clk_set_rate, so the clk_ api is upgraded too to support this or these rates where always supported? |
| 23:10.54 | maejrep | cr2: any idea why NetRipper is using PCOM_PMIC_VIBRA_ON and _OFF for his test? instead of PCOM_VIBRA_ON, which is for vibra motor? |
| 23:11.23 | maejrep | shouldn't pmic be on, and just turn the motor on and off? |
| 23:11.47 | tmzt | *Bit Rate * .008)/10 what is this for? |
| 23:11.58 | tmzt | s/*B/(B/ |
| 23:12.34 | cr2 | <PROTECTED> |
| 23:13.30 | cr2 | maejrep: on vogue you can pass a param to the vibra 0x4, which means "custom" |
| 23:14.07 | maejrep | command=0x00000004 data1=0x00000000, data2=0x00000000 |
| 23:14.11 | maejrep | he's just passing 0 |
| 23:14.31 | cr2 | tmzt: the clock api should support setting different frquencies |
| 23:14.32 | maejrep | when I was testing it, I used 0x17 and 0x18 for vibra motor on/off |
| 23:14.52 | cr2 | maejrep: both work, but 0x4/0x5 has more capabilities |
| 23:14.57 | cr2 | my guess :) |
| 23:15.01 | maejrep | i see |
| 23:15.06 | tmzt | cr2: yeah I mean I thought it was using a table before and didn't support all the baud rates that uart could |
| 23:15.25 | maejrep | i thought it was safer to not flip pmic like that |
| 23:15.49 | cr2 | tmzt: busybox has problems already with 921600 and 921600/2 |
| 23:16.05 | cr2 | it's certainly not a posixly correct speed :) |
| 23:20.33 | cr2 | maejrep: you have seen that wince does not use the specific ioctls/dex numbers, but calls the generic interface direclty. in most cases |
| 23:21.03 | maejrep | how do you mean? |
| 23:22.11 | tmzt | for vreg/pmic |
| 23:22.38 | cr2 | yes |
| 23:22.45 | cr2 | clk_get(&pdev->dev, "uartdm_clk"); |
| 23:23.09 | cr2 | but i think we know these |
| 23:23.28 | cr2 | but not the MD/NS ? |
| 23:23.42 | cr2 | something to think about |
| 23:24.33 | cr2 | tmzt: i don't see why it's an incomplete driver |
| 23:25.08 | cr2 | stty issues is more a glibc problem. |
| 23:25.23 | maejrep | cr2: is there a way to find the idx/mask/bits for the other clocks, or does that have to be reverse engineered? |
| 23:25.36 | maejrep | +and offsets |
| 23:25.53 | cr2 | maejrep: these are the known clocks that are really used |
| 23:25.57 | maejrep | we have hte clk_id's and names, but not the other informaiton we need |
| 23:26.09 | maejrep | these where? |
| 23:26.21 | cr2 | you can grep through the tree for clk_get |
| 23:26.33 | cr2 | i have put into the wiki all i have found |
| 23:26.50 | cr2 | more RE == disassembling the amss |
| 23:27.06 | cr2 | and it's a nontrivial project |
| 23:27.06 | maejrep | ok, so if its not in the wiki, we can't just guess it from haret or existing code? |
| 23:27.19 | cr2 | yes |
| 23:27.22 | maejrep | k |
| 23:27.37 | cr2 | i have seen some more magic clks in the nk.exe |
| 23:27.51 | cr2 | but there purpose and who uses them is non-obvoius |
| 23:28.21 | cr2 | a8600000 | 2219feaf |
| 23:28.26 | tmzt | cr2: where did you find msm_serial_hs_hwreg.h? |
| 23:28.29 | maejrep | well, I'm not able to get passed fb console handover now with that latest change to clock-alt |
| 23:28.30 | cr2 | here are the bits that are set. |
| 23:28.47 | maejrep | and the first clock i see in an old dmesg is pmdh_clk |
| 23:29.01 | maejrep | which isn't configured to be usable (and in fact wasn't previously either) |
| 23:29.13 | cr2 | return 'ok' for missing clocks |
| 23:29.34 | cr2 | pmdh_clk is mddi in wiki, i think |
| 23:30.01 | cr2 | the lcd init is the most critical problem now |
| 23:30.13 | cr2 | i need to spend most time on it |
| 23:30.27 | maejrep | so don't return invalid |
| 23:30.38 | cr2 | yes |
| 23:30.50 | cr2 | fgrep for clk_get |
| 23:31.06 | cr2 | what clocks are really used by the g1 kernel |
| 23:31.10 | cr2 | ? |
| 23:31.22 | *** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 23:31.56 | cr2 | we will need to do something about them. |
| 23:32.05 | cr2 | but i guess we know all of them |
| 23:34.26 | tmzt | cr2: it looks like viperbjk has some progress with jtag on diamond |
| 23:35.28 | cr2 | i recall it was all epoxy ? |
| 23:36.17 | tmzt | I mean he found test points taking apart a dead diamond I think |
| 23:36.27 | tmzt | in #xda-devs |
| 23:36.31 | cr2 | maejrep: but i can also look at some fun projects like psoc id :) |
| 23:36.45 | tmzt | psoc is navi chip? |
| 23:36.51 | cr2 | ok |
| 23:36.59 | tmzt | the android stuff needs end/call events |
| 23:37.07 | dream_kill | talked to viper |
| 23:37.08 | cr2 | we are a bit away from really bricking the raph |
| 23:37.11 | tmzt | they don't have enough keys |
| 23:37.18 | dream_kill | seems the g1 radio should be safe to falsh in raphael |
| 23:38.18 | maejrep | dream_kill: are you going to try it first? :) |
| 23:38.42 | dream_kill | my device doesn't have warranty anymore |
| 23:38.46 | dream_kill | i would try :D |
| 23:38.51 | dream_kill | othewise :D |
| 23:39.15 | maejrep | lol, i don't think they would warranty replace it after trying something as bold as that ;) |
| 23:39.24 | dream_kill | they will |
| 23:39.28 | dream_kill | as device will be dead |
| 23:39.29 | maejrep | cr2: boots now |
| 23:39.37 | dream_kill | so they can't know if what happened to it :D |
| 23:39.50 | dream_kill | at least not the local service center :D |
| 23:39.54 | maejrep | dream_kill: yeah but if they dig into it and find out that you tried to flash a g1 rom on it, they will certainly know that you mucked with it ;) |
| 23:40.11 | dream_kill | local service center has NOTHING for this |
| 23:40.15 | dream_kill | 200%!!! |
| 23:40.23 | maejrep | do you have anything for dumping the rom? |
| 23:40.25 | dream_kill | even Taiwan office |
| 23:40.31 | dream_kill | they will replace the flash chip :D |
| 23:40.52 | maejrep | the radio flash would replace the modem firmware, right? |
| 23:40.59 | dream_kill | yep |
| 23:41.05 | cr2 | dream_kill: even if flashing will go well, and the arm9 will work, you need a lot of software work afterwards |
| 23:41.07 | maejrep | which means after that, wince will never work with it? |
| 23:41.14 | *** join/#htc-linux dzo (n=dzo@121.98.128.127) |
| 23:41.38 | maejrep | (not that it's a problem for me :p but until linux is ready to fully support the device, it is kind of a large step ;) |
| 23:41.39 | dream_kill | from what i seen in code it should still work |
| 23:42.05 | maejrep | [ 8.120183] clk_set_rate 23:25000000 |
| 23:42.05 | maejrep | [ 8.126164] clock-7x00a-alt: set_sdcc_host_clock( 23, 48000000 ) |
| 23:42.18 | cr2 | maejrep: linux will not works too. you need to adjust gpios, and have psoc & microP & accelerometer driver anyway |
| 23:42.25 | cr2 | lol |
| 23:42.30 | maejrep | dream_kill: how would wince still work? replacing the modem firmware would completely replace the proc_comm implementation, right? |
| 23:42.30 | cr2 | crashed ? |
| 23:42.37 | maejrep | cr2: nope, working fine :) |
| 23:42.49 | cr2 | you have a good sd card |
| 23:42.59 | maejrep | yay :D |
| 23:43.06 | cr2 | :D |
| 23:43.10 | maejrep | [ 5.410061] mmc0: MMC clock 144000 -> 48000000 Hz, PCLK 66000000 Hz |
| 23:43.29 | cr2 | dma on ? |
| 23:43.39 | maejrep | [ 5.436195] mmc0: DM non-cached buffer at ffc03000, dma_addr 0x10c4e000 |
| 23:43.57 | cr2 | ok |
| 23:44.11 | maejrep | that's without the clock names in the table btw |
| 23:44.17 | cr2 | maejrep: enable the extra 128M ram :) |
| 23:44.24 | maejrep | but I only have 6 clocks in the table anyway |
| 23:44.33 | maejrep | cr2: i don't know how :P |
| 23:45.02 | cr2 | check the latest android kernel |
| 23:45.11 | tmzt | add the mem= you pasted earlier? |
| 23:45.25 | maejrep | that should be another major project :) moving to .27 |
| 23:45.37 | maejrep | tmzt: was that to me? |
| 23:45.51 | maejrep | [ 0.000000] Kernel command line: mem=94M msmsdcc_id=3 |
| 23:46.12 | tmzt | sort of, I mean to cr2 but was trying to answer your question (with a question :) |
| 23:46.18 | maejrep | oic |
| 23:46.23 | cr2 | static void __init trout_fixup(struct machine_desc *desc, struct tag *tags, |
| 23:47.06 | tmzt | the mem=ram@addr or whatever which should do the samething but doesn't need compiling the kernel |
| 23:47.11 | cr2 | .fixup = trout_fixup, |
| 23:47.41 | cr2 | not really |
| 23:47.42 | maejrep | tmzt: but that would just replace the current ram with the new address, right? |
| 23:47.53 | cr2 | it was in linux-arm from the old itsy days |
| 23:47.58 | maejrep | we want to combine the 94M with the 128M for discontiguous memory? |
| 23:48.10 | cr2 | yes |
| 23:48.31 | maejrep | cr2: have a link for that fixup function? |
| 23:48.32 | cr2 | <PROTECTED> |
| 23:48.35 | maejrep | I'll try it ;o |
| 23:48.51 | cr2 | you can also check the latest kaiser patch by dzo |
| 23:48.59 | maejrep | ah ok |
| 23:49.03 | cr2 | the discontig mem is enabled for kaiser now |
| 23:49.08 | maejrep | i'll check that since its closer to (my) phone anyway :) |
| 23:49.19 | cr2 | :) |
| 23:49.46 | cr2 | well, i'm trying to do both A and non-A |
| 23:51.29 | cr2 | tmzt: debian on a 528MHz machine with 256MB ram is nice to have |
| 23:51.59 | cr2 | tmzt: maybe we may pick some extra rests from the sram too :) |
| 23:52.05 | tmzt | yeah, which machine? |
| 23:52.12 | cr2 | raph |
| 23:52.55 | tmzt | that is why I want raph but unfortunately the only option now would be raph500 which has less ram |
| 23:53.09 | cr2 | i see |
| 23:53.31 | tmzt | I have debian with 64m on the q and the mp900c and it's usable but not fast |
| 23:54.14 | maejrep | cr2: use 94M for bank[0].size? |
| 23:54.20 | maejrep | and 128M for bank[1] ? |
| 23:54.30 | cr2 | jornada820 had 16MB and i could run twm and xclock :) |
| 23:54.34 | maejrep | know the .start for bank[1] ? |
| 23:54.42 | cr2 | maejrep: yes |
| 23:54.45 | tmzt | it's really a lot easier to test with mem= mem= they go to the same place |
| 23:55.09 | tmzt | of course discontig is completely broken on the q |
| 23:55.12 | cr2 | tmzt: syntax ? |
| 23:55.27 | cr2 | maejrep: 0x20000000 |
| 23:55.30 | tmzt | mem=ram@addr mem=ram@addr |
| 23:55.45 | maejrep | oh, you can specify the parameter multiple times? |
| 23:56.11 | cr2 | maejrep: yes, but sometimes there is an override |
| 23:56.21 | cr2 | like to console= |
| 23:56.45 | maejrep | so should I use the cmdline option, or the fixup option? :P |
| 23:56.50 | cr2 | you can write it 10 times, but only the last will be active |
| 23:57.04 | maejrep | right |
| 23:57.05 | cr2 | try cmdline first |
| 23:57.21 | maejrep | so mem=94M mem=128M@0x20000000 |
| 23:57.42 | cr2 | 94M@0x10000000 |
| 23:58.00 | cr2 | is more politically correct :) |
| 23:58.08 | tmzt | console=tty0 console=ttyS0 works too doesn't it? |
| 23:58.21 | cr2 | only ttyS0 |
| 23:58.48 | tmzt | some parameters work through a callback |
| 23:59.34 | cr2 | maejrep: if it'll boot, post the 'free' output |
| 23:59.48 | cr2 | dmesg may be fun too. |