00:00.33 | miknix | BabelO has done an excelent job on his artemis, and his contributions are on htc-omap branch |
00:00.47 | miknix | thats the reason |
00:01.06 | tmzt | ok |
00:03.02 | miknix | btw: wizard support is also on htc-omap |
00:08.26 | *** join/#htc-linux konsta (n=asds@host81-157-60-163.range81-157.btcentralplus.com) |
00:09.33 | miknix | feels like wanting to migrate to ext4 |
00:12.24 | Pure4Real | is it ready for use then? |
00:12.31 | ali1234 | supposedly |
00:13.14 | ali1234 | ubuntu 9.04 beta has/will have it as an install time option |
00:13.27 | Pure4Real | yeah, i just read it |
00:13.52 | Pure4Real | but i guess its not stable enough for a normal system if they only put it in the beta |
00:14.21 | Pure4Real | or maybe they won't put ext4 support in 8.x ubuntu |
00:14.59 | ali1234 | it wasn't marked stable in the kernel when they made 8.10 |
00:15.38 | ali1234 | new features go in a new version |
00:16.00 | Pure4Real | mm, yes |
00:21.58 | miknix | its stable now |
00:22.06 | miknix | at least not marked as *EXPERIMENTAL* |
00:22.08 | miknix | anymore |
00:22.15 | miknix | at .28 |
00:24.04 | miknix | anyway, I'm thinking in only moving my rootfs from XFS to ext4 |
00:24.20 | miknix | <PROTECTED> |
00:25.25 | Pure4Real | from what i read on wikipedia it has alot of nice new features |
00:26.02 | miknix | didnt read. just wanting it for the sake of the *change* |
00:28.59 | miknix | it is not all days that we can try a new filesystem |
00:29.01 | miknix | : P |
00:29.20 | maejrep | you should change for a reason though :p not just because it's a change |
00:30.08 | maejrep | we benchmarked ext4 vs ext3 at work, and the results were enough for us to consider changing |
00:33.17 | miknix | heh, I'm happy with XFS. it has a huge cache. I can copy a movie over and delete it and sometimes it doesnt even get written to the disk in the process :P |
00:33.21 | NetRipper | ext4 is faster? |
00:33.32 | NetRipper | by much? |
00:33.51 | miknix | but I have to try ext4 : D |
00:34.13 | NetRipper | i've always used ext3.. and used reiserfs once (which wasn't really as performing as i heard)... im trying out jfs on my laptop now, quite pleased with that so far ;) |
00:34.59 | NetRipper | i don't like huge caches ;) means a crash can cause more loss :P |
00:35.14 | miknix | heh, one more reason to run stable : ) |
00:36.01 | miknix | but this is a laptop.. power outages can happen that my battery will keep it alive. |
00:36.25 | Pure4Real | i've used reiserfs for some time now and it might be just subjective, but i got the feeling that it's a bit faster |
00:36.41 | miknix | and even in the few times I have to power it off hard, I never lose anything |
00:37.20 | NetRipper | im not using reiserfs anymore.. as it's not maintained anymore |
00:37.24 | miknix | (maybe because I abuse from the sync command :p ) |
00:37.33 | NetRipper | i read the author is in jail? not sure if that's true though |
00:37.34 | NetRipper | :) |
00:40.06 | miknix | NetRipper, last time I read he was on trial |
00:40.16 | Pure4Real | wasnt that a long time ago? |
00:41.22 | Pure4Real | hmm, he pled guilty so he would get a deal |
00:46.14 | *** join/#htc-linux cmonex (n=xy6091@nifl5tpzno.adsl.datanet.hu) |
01:06.42 | *** join/#htc-linux p3t3r__1 (n=peter@134.245.164.105) |
01:17.18 | *** join/#htc-linux p3t3r__2 (n=peter@134.245.164.105) |
01:46.16 | *** join/#htc-linux p3t3r__1 (n=peter@134.245.164.105) |
02:03.43 | maejrep | NetRipper: random reads outperformed ext3 by a huge margin. random writes were higher too, but not by the same amount |
02:04.03 | maejrep | i don't have the final results here right now |
02:04.11 | maejrep | i'm using XFS on my desktop, and it's been great |
02:04.59 | maejrep | I used to always use reiser3, but I've had disk crashes with it, and it makes recovery virtually impossible. Unless you have mission critical information on the disk, it's more viable to just reformat and start over, then to spend the time trying to recover anything |
02:05.37 | maejrep | I tried reiser4, and was pleased with it. even had a disk crash, and recovery was painless |
02:05.44 | tmzt | batch gpios http://lwn.net/Articles/316626/ |
02:06.58 | maejrep | that could be useful |
02:09.30 | tmzt | yeah, I'd like to get mfp implemented on all the soc's though, I don't know if this helps with that or not |
02:15.34 | *** join/#htc-linux dzo_ (n=dzo@121-98-128-127.bitstream.orcon.net.nz) |
02:16.46 | maejrep | mfd in what sense? |
02:16.57 | maejrep | s/mfd/mfp/ |
02:17.54 | *** join/#htc-linux p3t3r__2 (n=peter@134.245.164.105) |
02:18.14 | tmzt | it's implemented for pxa at least and allows alt functions to be managed from pdata |
02:20.14 | tmzt | what have you and cr2 found about the clocks on msm? |
02:20.30 | tmzt | it seems you have a function call that takes m, n, d, etc. |
02:20.38 | tmzt | does that mean we know what they mean? |
02:20.46 | maejrep | I dont' think so |
02:21.06 | maejrep | we just have names for them, and those names don't really make sense yet |
02:21.34 | maejrep | were in the same boat when we found out they call them "MD" and "NS" |
02:21.56 | maejrep | but we could also set alt functions via pdata |
02:22.03 | maejrep | unless i'm missing the point |
02:22.25 | maejrep | what is mfp? |
02:22.47 | *** join/#htc-linux p3t3r__1 (n=peter@134.245.164.105) |
02:23.36 | tmzt | static int __mfp_config_gpio(unsigned gpio, unsigned long c) |
02:24.25 | maejrep | we can still do that, we just do it via a struct instead |
02:25.28 | tmzt | I think the idea is to let the core kernel infrastructure handle it, it calls that function for you |
02:26.09 | maejrep | ok, so the app still needs to do the drvstr/altfunc/pull packing itself, before calling that function? |
02:26.31 | maejrep | even if its done via macro |
02:26.36 | tmzt | yeah, you would have header file implementing the known alternatives |
02:26.55 | tmzt | we know what drvstr is, what is pull? |
02:26.57 | maejrep | i guess i'd have to see an example to know how its different from what we're doing now |
02:27.47 | maejrep | from what i know, pull is basically the ability to keep a line high, even if another line on the chip tries to pull it low |
02:27.57 | maejrep | but i could be confused about that |
02:28.36 | tmzt | #define GPIO85_GPIO MFP_CFG_IN(GPIO85, AF0) |
02:28.56 | tmzt | #define GPIO85_FFUART_RXD MFP_CFG_IN(GPIO85, AF1) |
02:29.16 | maejrep | so those are different configurations for gpio 85? |
02:29.24 | tmzt | pxa3xx_mfp_config(ARRAY_AND_SIZE(littleton_mfp_cfg)); |
02:29.26 | tmzt | yeah |
02:29.54 | maejrep | is mfp_config a linux standard? and should we implement our config in that way instead? |
02:30.09 | tmzt | static mfp_cfg_t littleton_mfp_cfg[] __initdata = { /* LCD */ GPIO54_LCD_LDD_0, GPIO55_LCD_LDD_1, GPIO56_LCD_LDD_2, |
02:30.23 | tmzt | no multiline paste |
02:30.36 | tmzt | look at arch/arm/mach-pxa/littleton.c |
02:31.16 | tmzt | it generalizes the concept of pin muxing, for pxa3xx it even goes beyond gpio and supports all the pins on the package |
02:32.31 | tmzt | more interesting though, how is the wifi going on raph? |
02:32.32 | maejrep | i haven't had a chance to do anything with it |
02:32.32 | maejrep | been working long nights at work, getting ready for a feature launch |
02:33.39 | maejrep | the concept sounds a lot like the config tables used in the board-mmc files |
02:37.26 | maejrep | i started trying to get the lcd panel initialized properly, and didn't get a chance to get that fully working yet |
02:49.21 | AstainZZZZZZ | hey maejrep |
02:50.13 | *** join/#htc-linux tcccp (i=hey@ballbreaker.hey-ix.net) |
02:50.57 | *** join/#htc-linux Shinto (n=John@g227179120.adsl.alicedsl.de) |
02:51.17 | maejrep | hi |
03:17.21 | *** join/#htc-linux AstainZZZZZZ (n=AstainHe@unaffiliated/astainhellbring) |
03:25.41 | *** join/#htc-linux Zack84a (n=zack84a@r74-192-0-176.bcstcmta01.clsttx.tl.dh.suddenlink.net) |
03:27.34 | *** join/#htc-linux arto_ (n=arto@c-67-164-195-234.hsd1.ut.comcast.net) |
03:29.41 | *** join/#htc-linux Arto (n=AstainHe@unaffiliated/astainhellbring) |
03:55.27 | *** join/#htc-linux AstainZZZZZZ (n=AstainHe@unaffiliated/astainhellbring) |
04:09.51 | *** join/#htc-linux arto_ (n=arto@c-67-164-195-234.hsd1.ut.comcast.net) |
04:20.20 | *** part/#htc-linux p3t3r__1 (n=peter@134.245.164.105) |
04:48.11 | *** join/#htc-linux dzo_ (n=dzo@121-98-128-127.bitstream.orcon.net.nz) |
05:18.35 | *** join/#htc-linux dzo_ (n=dzo@121-98-128-127.bitstream.orcon.net.nz) |
05:29.32 | tmzt | maejrep: did you try wpa_supplicant? |
05:29.44 | maejrep | doesn't that rely on wireless extensions? |
05:30.04 | maejrep | either way, I didn't try it |
05:30.23 | tmzt | it appears that either wpa_supplicant works or the one in android.git.kernel.org works but I'm trying to see what they changed |
05:30.49 | tmzt | solca's patches were to support wireless extensions in android, not to add wireless extensions to tiwlan |
05:30.56 | tmzt | so that's not what's needed |
05:33.16 | maejrep | trying to figure out how clkregime works with the mddi clock ;o |
05:33.44 | tmzt | ah, as far as I can find it has two clk's the grp one and mddi one |
05:33.50 | tmzt | what is not working? |
05:33.57 | maejrep | looks like it sets or clears 0x800|0x200 on CLK_CTL+0x8c |
05:34.17 | tmzt | we still don't know what those bits mean? |
05:34.28 | maejrep | just trying to imitate wince as much as possible |
05:34.45 | maejrep | I don't think so. 0x8c is listed as "mddi_clk" / "PMDH Ns" |
05:35.00 | maejrep | but I'm not sure if 0x200 and 0x800 are meant to be clock bits |
05:35.19 | maejrep | would be strange to set them in 0x8c instead of CLK_CTL |
05:35.28 | maejrep | but I know not all the clocks work the same way |
05:36.14 | maejrep | tracing that through "mddi bridge power up" |
05:37.21 | tmzt | could it be because this is an A clock? |
05:37.42 | tmzt | I mean not considered part of the arm9 part, still not sure about that though |
05:38.33 | *** join/#htc-linux dzo_ (n=dzo@121-98-128-127.bitstream.orcon.net.nz) |
05:40.58 | maejrep | not entirely sure what that means |
05:41.39 | tmzt | A clocks and B clocks |
05:41.53 | maejrep | nope ;x |
05:41.57 | tmzt | I think A is application and B is broadband |
05:42.30 | tmzt | ok, do all the other clocks have enable bits in CLK_CTL? |
05:44.21 | maejrep | only those documented with bitmasks, afaik |
05:44.43 | maejrep | it looks like it tries to enable clock 0x38 |
05:45.43 | maejrep | then if i'm reading the asm right (not entirely sure that I am), that's when it sets 0x800 and 0x200 in CLK_CTL+0x8c |
05:46.05 | maejrep | but because 0x8c is marked as mddi_clk, I think its right |
05:48.00 | maejrep | looks like: |
05:48.02 | maejrep | CMP R5, #0 |
05:48.02 | maejrep | LDR R3, [R2,#0x8C] |
05:48.02 | maejrep | ORRNE R3, R3, #0x800 |
05:48.02 | maejrep | STRNE R3, [R2,#0x8C] |
05:48.02 | maejrep | LDRNE R3, [R2,#0x8C] |
05:48.03 | maejrep | ORRNE R3, R3, #0x200 |
05:48.05 | maejrep | STRNE R3, [R2,#0x8C] |
05:48.17 | maejrep | R2 is assumed to be CLK_CTL |
05:48.48 | maejrep | (asm doesn't reveal the value, seems to be an internal buffer that gets populated at some point) |
05:50.13 | maejrep | i'm sure if the clock rpc call is consistent, it would be a lot easier to implement than this ;) |
05:50.35 | maejrep | without rpc, we're going to have to make per-clock exceptions for anything that's not MD/NS based |
05:50.48 | tmzt | is mddi always set from spl, never from ce itself? |
05:50.56 | tmzt | s/set/setup/ |
05:53.47 | maejrep | which part? |
05:53.59 | tmzt | the clocks |
05:54.05 | maejrep | i'm reading through disptools.dll and it does set clocks |
05:54.15 | tmzt | the way you said? |
05:54.26 | maejrep | yes, this is all from dlls, not from spl |
05:54.39 | maejrep | that asm ^ is from clkregime.dll |
06:00.10 | maejrep | hmm one bad thing about this keyboard is that the spring is so damn loud, i'm always afraid it'll annoy my roommates :p |
06:01.37 | AstainZZZZZZ | the sprints loud? |
06:01.44 | AstainZZZZZZ | *spring |
06:03.07 | maejrep | yeah |
06:03.32 | AstainZZZZZZ | hmm mines rather quiet |
06:03.34 | maejrep | das keyboard.. think old ibm model m |
06:03.35 | maejrep | ;p |
06:04.18 | AstainZZZZZZ | ahh |
06:04.41 | AstainZZZZZZ | maejrep know anyone that would be looking to buy a sprint touch pro? |
06:10.30 | maejrep | no, virtually everyone i work with has an iphone ;p |
06:10.39 | maejrep | i think i'm the only one with sprint |
06:11.21 | maejrep | what are you asking for it? ;) |
06:18.19 | AstainZZZZZZ | not 100% sure yet I will have either 1 or 2 spares that I will be selling as I dump some leaches off my account |
06:18.22 | *** join/#htc-linux evildarknigh1 (n=charles@41.207.133.55) |
06:23.32 | maejrep | leaches? |
06:24.25 | AstainZZZZZZ | some ppl that were friends that got into situations that they needed $ I loaned and now they don't seem to wanna repay |
06:24.58 | maejrep | i see.. and you loaned them touch pro phones? :P |
06:25.33 | AstainZZZZZZ | kinda |
06:26.06 | AstainZZZZZZ | I loaned them ppc phones as well as $ and the phones slowly got upgraded to Touch pros so now I have 3 |
06:27.06 | maejrep | lol |
06:32.49 | *** join/#htc-linux dzo_ (n=dzo@121-98-128-127.bitstream.orcon.net.nz) |
06:36.39 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbfdf1c.pool.einsundeins.de) |
06:47.54 | maejrep | hmm, i'm not seeing the navi driver being initialized for some reason |
06:52.30 | *** join/#htc-linux dzo_ (n=dzo@121-98-128-127.bitstream.orcon.net.nz) |
07:41.45 | *** join/#htc-linux ewasx (n=armin@5-157.surfsnel.dsl.internl.net) |
08:40.57 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d87c1f4.pool.einsundeins.de) |
09:13.15 | *** join/#htc-linux imfloflo (n=imfloflo@cap31-6-88-180-73-121.fbx.proxad.net) |
09:19.18 | *** join/#htc-linux goxboxlive (n=goxboxli@185.84-48-126.nextgentel.com) |
09:21.25 | *** join/#htc-linux pH5 (n=ph5@p5485C082.dip.t-dialin.net) |
09:27.08 | tmzt | pH5: you are familiar with gpio_vbus on pxa27x? |
09:27.21 | tmzt | is this the same as using otg_transceiver |
09:32.45 | pH5 | hi tmzt. I should, I wrote it. |
09:32.58 | pH5 | otg_t... is just the interface |
09:33.12 | pH5 | gpio_vbus implements it |
09:33.24 | tmzt | ah ok, so this can be used for any pxa27x with a detect or pull-up using a gpio? |
09:33.50 | pH5 | yes |
09:33.59 | pH5 | and soon pxa25x, too |
09:34.11 | pH5 | not sure about other arches right now |
09:35.41 | *** join/#htc-linux myxor (n=myxor@pdbn-4d08956a.pool.mediaWays.net) |
09:35.56 | *** join/#htc-linux timebomb (n=tb@e176127053.adsl.alicedsl.de) |
09:37.51 | tmzt | pH5: http://pastebin.com/m6be6a3d8 what does this do and is there a more general way to do it than put this in every pxa board? |
09:38.44 | tmzt | I hope I have that right, on moto q and htc apache at least it's need to even see the modem on usb host |
09:40.08 | pH5 | tmzt: that ioremapping is useless, there are register defines for those |
09:40.30 | pH5 | 4c... and 406... are udc/ohci register space iirc |
09:40.47 | pH5 | maybe one of them is UP2OCR? |
09:41.05 | pH5 | look in the pxa headers for those addresses |
09:42.08 | pH5 | the other register probably can be set indirectly via the ohci mach_info's .flags field |
09:43.20 | tmzt | UP3OCR it seems |
09:43.49 | tmzt | #define UP3OCR __REG(0x40600024) |
09:44.50 | tmzt | it seems there are no defines for the bits in 2.6.29? |
09:45.07 | tmzt | there are UP2OCR_* but not UP30OCR_* |
09:45.46 | tmzt | you don't use usb host on magician right? |
09:45.51 | pH5 | might be, but I think they should be the same. do you have the docs? |
09:45.59 | tmzt | only pdf |
09:46.10 | pH5 | I do but UP3 is 0x0 here |
09:46.50 | pH5 | good. look it up, add the flags, send a patch :) |
09:47.30 | tmzt | is there a header for ohci? |
09:47.44 | *** join/#htc-linux nebi (n=nebi@170.ftth2.cust.fyrobs1.upps.se.borderlight.net) |
09:49.37 | pH5 | I think no, it's in the ohci driver code. |
09:49.59 | pH5 | 4C000064 can be set via .flags |
09:52.27 | tmzt | inf->flags or is that something else? |
09:53.04 | tmzt | http://git.openezx.org/?p=openezx.git;a=blob;f=drivers/usb/host/ohci-pxa27x.c;h=e44dc2cbca24006e1b81d57cf589213ee823295c;hb=HEAD |
09:53.44 | *** join/#htc-linux dream_kill (n=nospam@92.56.48.66) |
09:54.11 | tmzt | where is 0x4c000064 set via flags? |
09:54.23 | *** join/#htc-linux cr2 (n=cr2@ip-77-25-79-239.web.vodafone.de) |
09:55.01 | pH5 | right - the register in question is UHCHR |
09:55.06 | pH5 | hi cr2 |
09:55.15 | tmzt | oh yeah, I see that now |
09:55.34 | tmzt | does that just enable the port 3 then? |
09:56.51 | pH5 | and port2 |
09:57.00 | tmzt | yeah, ok |
09:57.06 | tmzt | we can do that with flags |
09:57.12 | pH5 | (1<<10) |
09:57.14 | cr2 | hi |
09:57.16 | pH5 | ok |
09:57.32 | cr2 | i've fall asleep at about 1:00 ;) |
09:57.56 | cr2 | maejrep: there is nothing magic in 0x800|0x200 for mddi |
09:58.11 | cr2 | maejrep: 0x800|0x200=0xa00 |
09:58.32 | cr2 | maejrep: which is a "basic" clock setting for the NS register |
09:58.50 | cr2 | B-clock means 0xA|1 |
09:59.07 | tmzt | pH5: is the a set_ api for ohci platform_data? |
09:59.12 | tmzt | s/the/there/ |
09:59.30 | cr2 | so if this '1' bit is set, then the A clock (uses only the NS) becomes a B-clock (uses MD too) |
10:01.07 | cr2 | maejrep: the MD means clock M(ultiplier) which is MSW, and D(uty) which is LSW |
10:01.57 | cr2 | maejrep: D(uty) is used to implement PWM, so for a normal clock it's 1/2 of N |
10:02.33 | *** join/#htc-linux Xime (n=xime@bankize.net) |
10:02.54 | cr2 | maejrep: N is the MSW of NS, and is the clock divisor. S is the LSW, and its black magic :) |
10:03.34 | tmzt | what kind of values does s have? |
10:03.42 | cr2 | maejrep: the 0xa00 (for A clock) and 0xb00 (for the B clock) are inside S |
10:04.12 | cr2 | so 0xb00=(0xa|1)00 |
10:04.19 | cr2 | and means "use MD" |
10:04.34 | pH5 | tmzt: like pxa_set_ohci_info? |
10:04.40 | tmzt | yeah |
10:04.49 | cr2 | tmzt: S has 4 parameters in a table, which can differ |
10:05.35 | cr2 | pH5: there is OTG on msm7201A, and it even works. but there are no docs, as usual. |
10:05.43 | tmzt | where is that in MSM_CLK? |
10:06.04 | cr2 | tmzt: for PMDH ? |
10:06.27 | tmzt | that's what maejrep is looking for |
10:06.29 | cr2 | tmzt: not all clocks have the MD register (i2c for example) |
10:06.38 | tmzt | I was more wondering what you meant about the table |
10:06.54 | cr2 | tmzt: and not all clocks have a respective MSM_CLK aka GlblClkEna bit |
10:07.17 | cr2 | they are "always" there, like the TCX0=19.2MHz it seems |
10:08.15 | cr2 | tmzt: i think that the "table" says which base clock source you should take, if the MD is used, maybe something else |
10:08.48 | cr2 | tmzt: i't difficult to say without the cpu docs. and the g1 code is of no use here. |
10:09.18 | tmzt | the crystal names are pretty standardized though, aren't they? |
10:09.34 | tmzt | I've been trying to find more information on that but I've header it mentioned before |
10:09.49 | tmzt | heard |
10:11.17 | *** join/#htc-linux liba2k (n=liba2k@194.90.149.193) |
10:11.28 | tmzt | pH5: ah, there it is and even in magician.c |
10:11.29 | cr2 | tmzt: i think they have a crystal for 19.2 |
10:11.45 | tmzt | I mean names like TXC |
10:11.46 | cr2 | tmzt: they also need a 48MHz crystal for usb |
10:11.56 | tmzt | and sd? |
10:12.02 | *** part/#htc-linux liba2k (n=liba2k@194.90.149.193) |
10:12.08 | cr2 | tmzt: but the rest is a pll maze |
10:12.42 | tmzt | the arm11 clock is on the arm9 side, it has a single divider from a main clock source? |
10:13.14 | tmzt | it was mentioned the other clocks where related to that but I would have to search some logs to find it |
10:13.21 | cr2 | tmzt: the 144kHz clock is derived from 19.2MHz, the rest are from 768MHz accroding to my calculations |
10:13.53 | cr2 | usually you can divide clocks (easy) and multiply clocks (more dificult) |
10:14.07 | cr2 | M and N |
10:14.12 | cr2 | *M/N |
10:14.53 | cr2 | base_clock*M/N |
10:15.07 | tmzt | yeah |
10:15.37 | cr2 | so i can easilly show you that the 144kHz clock is derived from 19.2MHz |
10:16.06 | cr2 | but if i apply the same logic to the other SD clocks |
10:16.12 | cr2 | then i get 768MHz |
10:17.07 | cr2 | the S difference is the par6=s2 |
10:17.25 | cr2 | for 144kHz it's =0 |
10:17.36 | tmzt | <PROTECTED> |
10:17.46 | tmzt | something added to 2.6.27 |
10:17.57 | *** join/#htc-linux liba2k (n=liba2k@194.90.149.193) |
10:18.07 | cr2 | so it seems that the s2=0 selects the 19.2MHz |
10:18.21 | cr2 | tmzt: it's in the SD spec |
10:18.41 | tmzt | I mean support was added in cupcake for g1 with 50mhz cards |
10:18.51 | cr2 | tmzt: the SD divisors for a fake 48MHz entry give 32MHz |
10:19.32 | cr2 | you can easily see it from the relations between the 12:24 and 48 MHz clocks |
10:20.36 | *** part/#htc-linux liba2k (n=liba2k@194.90.149.193) |
10:20.39 | *** join/#htc-linux DJWillis (i=djwillis@82-46-19-72.cable.ubr02.bath.blueyonder.co.uk) |
10:21.54 | *** join/#htc-linux liba2k (n=liba2k@194.90.149.193) |
10:23.46 | cr2 | tmzt: you can bump the divisor to support real 48MHz, but i don't know if it will work. |
10:26.12 | cr2 | NetRipper: i'm not sure what do they mean when they say 32MB SRAM |
10:26.54 | cr2 | NetRipper: but the fact is that i can't access many parts of it. |
10:30.27 | tmzt | cr2: the trout amss calls just take the raw frequency? |
10:34.27 | cr2 | probably |
10:38.54 | *** join/#htc-linux radem205 (n=aaa@e144118.upc-e.chello.nl) |
10:38.58 | radem205 | hey dzo |
10:39.28 | radem205 | is it difficult to build the battery driver and let the charger work? |
10:40.37 | *** join/#htc-linux Pure4Real (n=pure4rea@89-97-140-219.ip17.fastwebnet.it) |
10:41.02 | dzo | hi radem205, for kaiser you mean? no, not too difficult, want to try? |
10:45.39 | radem205 | yes for kaiser. I'm sorry but I think I don't have the knowledge to work on it. I was only wondering :), because then Android would become very usefull for daily use |
10:46.17 | *** join/#htc-linux Pure4Real_ (n=pure4rea@89-97-140-219.ip17.fastwebnet.it) |
10:47.46 | radem205 | you said the red led is displayed when the phone is in sleepmode? Is that right? I have a polaris, so I think this isn't working on our device yet |
11:07.24 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
11:07.40 | *** join/#htc-linux hdfhefgaert43t (i=bite@gateway/tor/x-102d23dfb24289a5) |
11:12.01 | *** join/#htc-linux miknix (n=miknix@gentoo/developer/miknix) |
11:17.41 | *** join/#htc-linux br1ck (n=br1ck@xdslcb089.osnanet.de) |
11:20.50 | *** join/#htc-linux StarLite (n=nnscript@s55916ca6.adsl.wanadoo.nl) |
11:27.01 | *** join/#htc-linux ImCoKeMaN (n=imcokema@pool-98-111-118-30.hrbgpa.fios.verizon.net) |
11:32.04 | *** join/#htc-linux tsdogs (n=tsdogs@net203-187-146.mclink.it) |
11:34.11 | *** join/#htc-linux opennandra (n=opennand@afrodita.advanet.sk) |
11:52.29 | *** join/#htc-linux tsdogs (n=tsdogs@net203-187-146.mclink.it) |
12:06.02 | *** join/#htc-linux dream_kill (n=nospam@92.56.48.66) |
12:18.50 | cr2 | hm. interesting |
12:19.52 | tmzt | what? that pH5 always leaves five minutes before you arrive or something else |
12:21.17 | cr2 | no |
12:21.30 | cr2 | titan uses dex16/17 for vibra |
12:21.49 | tmzt | ah, not the generic vreg |
12:21.51 | cr2 | and the battery response layout is like on raph800 |
12:51.49 | *** part/#htc-linux Balsat (n=kll@87.72.13.87) |
12:57.37 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
13:00.35 | *** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes) |
13:04.16 | *** join/#htc-linux evildarknigh1 (n=charles@41.207.133.55) |
13:05.53 | *** join/#htc-linux hdfhefgaert43t (i=bite@gateway/tor/x-fbad02b6485bd612) |
13:10.41 | cr2 | old devices are interesting |
13:11.14 | kiozen | ...you can always make a tea from the dust inside |
13:12.34 | cr2 | hi kiozen |
13:12.43 | kiozen | hi :) |
13:12.52 | cr2 | kiozen: if you'll buy triton, get 2 |
13:13.13 | kiozen | lol, ok :) |
13:13.35 | kiozen | but the longer I read about magellan the more I panic |
13:13.56 | cr2 | why ? |
13:13.56 | kiozen | I really wonder what their firmware developer does as main job |
13:14.04 | cr2 | lol |
13:14.26 | kiozen | magellan has a lot in common with social democratic party of germany |
13:14.27 | cr2 | you'd tell me about the cpu, and gps receiver |
13:14.33 | cr2 | LOL |
13:14.50 | kiozen | their marketing is selfdestructive |
13:14.57 | cr2 | kiozen: which cpu does it use ? |
13:15.04 | kiozen | no clue |
13:15.21 | cr2 | and gps is sirf3 ? |
13:15.45 | kiozen | http://www.magellanboard.de/viewtopic.php?t=650&sid=6b3123d4ca3b528c8606d55fd42de05c |
13:15.50 | kiozen | yes sirfII |
13:15.55 | kiozen | sirf III |
13:16.15 | kiozen | inkognito is very close to magellan |
13:16.25 | kiozen | thus this information is good |
13:17.10 | cr2 | CPU = Samsung 2412/SLC, RAM = 32 MB, ROM = 64 MB, SIRF III, SD Card Map Storage. |
13:17.22 | cr2 | hmm. i think there is 2412 linux support |
13:17.47 | cr2 | 32MB looks better than 2MB |
13:18.27 | tmzt | does that use ce? |
13:18.35 | kiozen | afaik yes |
13:19.30 | *** join/#htc-linux diogene31 (n=rj@mur31-2-82-243-122-54.fbx.proxad.net) |
13:19.34 | kiozen | cr2: 32MB, that will be tough for qt |
13:20.01 | kiozen | right now the M footprint with linux/qt and M is ~40 MB |
13:20.21 | NetRipper | swap ;) |
13:20.27 | kiozen | :))) |
13:20.31 | kiozen | better not |
13:21.32 | cr2 | NetRipper: solder one more on top :) |
13:22.42 | NetRipper | wow, ambitious;) |
13:22.48 | cr2 | kiozen: but how much junk is included in qtopia4, that can be droped ? |
13:23.13 | tmzt | stuff like dbus clients? |
13:23.29 | tmzt | kioslaves |
13:23.45 | cr2 | like svg rendering, sql support |
13:23.52 | cr2 | qdsync |
13:25.26 | cr2 | kiozen: ok, then 1500 is the only choice. |
13:25.33 | kiozen | surely quite some stuff, but that has been placed into seperate libs anyway |
13:25.33 | cr2 | 2442 is very well supported. |
13:26.04 | tmzt | are you using qws? |
13:26.04 | kiozen | 1500 has no compass and barometric sensor. |
13:26.15 | cr2 | and 500 has ? |
13:26.24 | kiozen | tmzt: yes |
13:26.28 | kiozen | cr2: yes |
13:26.45 | cr2 | kiozen: what is the difference between 1500 and 2000 ? cam ? |
13:27.04 | kiozen | sensors and cam (and afaik audio) |
13:27.05 | tmzt | what size initramfs are you using or do you intend to use nor flash? |
13:27.51 | cr2 | kiozen: so the magnetometer and pressure sensor are on 2000 too ? |
13:27.58 | kiozen | tmzt: think we first have to get one of these to decide |
13:28.06 | kiozen | cr2: yes |
13:29.35 | tmzt | would testing with qemu help? |
13:30.50 | kiozen | tmzt: you mean simulating the stuff before wrecking the device? |
13:31.00 | kiozen | think that's not cr2's style ;) |
13:31.14 | tmzt | I mean testing whether you can fit what you need in 32 megs |
13:31.18 | tmzt | <PROTECTED> |
13:32.12 | cr2 | kiozen: LOL |
13:32.31 | cr2 | kiozen: can we convince somebody to run haret ? |
13:32.49 | kiozen | I live in a 100% Garmin area |
13:32.59 | cr2 | it's also a question how high is the security on these devices. |
13:33.11 | cr2 | kiozen: ok, how much does 2000 cost ? |
13:33.22 | kiozen | ~500-600 bugs |
13:33.34 | kiozen | 500 is ~260 only |
13:33.35 | tmzt | there's some discussion of these in hpcdev, not explicitly garmin but media players and gps units |
13:34.02 | cr2 | tmzt: is it possible to install software on them ? |
13:34.21 | tmzt | some it appears, some just load a .exe from sd card with a certain name |
13:34.55 | kiozen | there is a file on the triton |
13:35.12 | kiozen | if you replace it you can start what ever wince app you want |
13:35.18 | kiozen | eg oziexplorer |
13:35.36 | cr2 | ok. |
13:35.41 | kiozen | thus haret should be possible |
13:35.44 | cr2 | so haret should not be a problem |
13:36.00 | kiozen | it's more a question about how to read information |
13:36.08 | cr2 | them we can dump rom,nand,ram and trace gpios |
13:36.29 | tmzt | rapi? |
13:36.51 | kiozen | there is no network on the device |
13:37.00 | tmzt | no usb? |
13:37.06 | kiozen | and I doubt usb works like expected |
13:37.11 | cr2 | tmzt: i think somebody can be convinced to produce earlyharetlog.txt |
13:37.20 | kiozen | expected == syncce |
13:37.29 | cr2 | kiozen: the SD is enough |
13:37.33 | kiozen | ok |
13:38.07 | cr2 | and the scripts can be run from a text file |
13:38.20 | tmzt | since itsutils.dll uses code running on the device, is there some reason no application exists to dump the doc/nand to sd card? |
13:38.25 | cr2 | i had some problems with ppp on a medion navi |
13:38.45 | cr2 | but solved them by pinging the device from a separate window |
13:39.29 | cr2 | tmzt: the itsutils could not dump doc on n560 |
13:40.06 | cr2 | but ymmv on triton |
13:40.12 | kiozen | http://gpstracklog.typepad.com/gps_tracklog/2007/08/more-on-the-mag.html |
13:40.32 | kiozen | look at and for feature overview |
13:40.57 | kiozen | but prices are more in EU |
13:43.24 | kiozen | http://www.ppm-gps.de/pages_de/consumer/handheld/handheld.html |
13:43.30 | cr2 | 1500/2000 has a ts |
13:43.35 | kiozen | that is exclusive ditributor for DE |
13:43.40 | kiozen | cr2: yes |
13:43.55 | kiozen | but it's not satisfying |
13:45.18 | cr2 | i think there is no reason to buy 1500 |
13:46.40 | kiozen | yes it's either 500 or 2000 |
13:46.55 | cr2 | 2.7" qvga |
13:47.58 | cr2 | for that size qvga is ok |
13:47.59 | *** join/#htc-linux asj_xda (n=asj@130.78.broadband3.iol.cz) |
13:48.25 | cr2 | usb data cable |
13:48.33 | asj_xda | Hi guys :) |
13:49.28 | kiozen | http://www.taxnav.de/product_info.php/info/p14242-Magellan-Triton-500.html |
13:49.50 | *** join/#htc-linux Zoolooc_ (n=fredsiba@nrbg-4dbfdc97.pool.einsundeins.de) |
13:50.02 | cr2 | (optional externe Antenne |
13:50.20 | asj_xda | Is here now anyone who is interested in Kaiser Android porting? I have some questions.... |
13:51.02 | cr2 | 500 is 2.2" |
13:52.05 | kiozen | but is it worth 300€ more |
13:52.26 | cr2 | kiozen: i think BabelO was running M on qvga |
13:52.34 | kiozen | yes |
13:52.56 | cr2 | no ext antenna on 500 ? |
13:54.04 | cr2 | what about SDHC ? |
13:54.16 | cr2 | well, with linux it should not be a problem :) |
13:55.02 | cr2 | 2442 will certainly use builtin SD |
13:55.08 | tmzt | asj_xda: you can ask you questions, dcordes and dzo are mostly working on kaiser now but most stuff should be the same/similar on all msm |
13:56.10 | cr2 | tmzt: not the cpld/gpio/leds |
13:56.25 | cr2 | keyboard |
13:57.27 | tmzt | I mean android stuff |
13:57.29 | asj_xda | cr2: yes, well I am trying to get more involved and I encountered some issues, so I was looking for answers |
13:57.41 | cr2 | tmzt: ok |
13:57.55 | asj_xda | cr2: But I guess dzo would be sleeping now :D |
14:00.40 | asj_xda | is there separate Android Channel? |
14:01.00 | tmzt | for non-g1, not really, but there is #android |
14:04.56 | cr2 | kiozen: i'm for the US version of 2000 |
14:05.57 | cr2 | and an external antenna |
14:06.33 | kiozen | cr2: if you find a dealer willing to export you have to pay tax and in case of waranty you are boned |
14:06.43 | kiozen | cr2: and you need warranty |
14:06.54 | kiozen | cr2: this cheap chineese stuff |
14:07.30 | kiozen | cr2: there are devices that work, and a good share has to be sent in again after purchaise |
14:08.01 | asj_xda | OK, I'll wait for dzo, cause it is quite confusing. After kaiser sleeps a while on wake up I have only strips on my screen :( |
14:08.18 | kiozen | magellan != garmin; magellan == SPD |
14:08.19 | asj_xda | but perhaps you'll not be able to give me hint what |
14:08.26 | asj_xda | what is wrong |
14:08.29 | cr2 | kiozen: philippines :) |
14:08.35 | asj_xda | CU L8r |
14:08.36 | kiozen | right :) |
14:08.45 | kiozen | but same mess |
14:08.48 | cr2 | kiozen: the first goolge hit http://www.pixmania.com/de/de/729337/art/magellan/gps-outdoor-marine-triton.html |
14:09.18 | cr2 | marine, lol |
14:09.37 | kiozen | cr2: I bought my 1st beamer from pixmania |
14:09.44 | cr2 | lol |
14:09.56 | kiozen | cr2: I will never buy there e second time ;) |
14:10.10 | *** join/#htc-linux opennandra_ (n=opennand@afrodita.advanet.sk) |
14:11.19 | cr2 | ok |
14:11.58 | tmzt | it seems we should have a ohci pdata with certain flags set and call pxa_set_ohci_info |
14:12.04 | tmzt | sorry |
14:12.13 | cr2 | kiozen: (Unverbindliche Preisempfehlung: € 654.00 |
14:12.55 | *** join/#htc-linux m4D (n=m4D@ppp83-237-246-61.pppoe.mtu-net.ru) |
14:13.01 | cr2 | kiozen: beamer and a small gadget are different |
14:13.08 | cr2 | kiozen: where are they located ? |
14:13.12 | kiozen | france |
14:13.42 | kiozen | http://www.taxnav.de/index.php/cat/c1671_Triton-2000.html |
14:14.03 | cr2 | ok, that's bad. |
14:14.10 | kiozen | 580.- is more the usual |
14:14.54 | cr2 | http://www.futurumshop.de/product/6065-0007-N0804/magellan-triton-2000-gps.phtml |
14:15.37 | cr2 | hmm. not anymore |
14:16.47 | asj_xda | cr2: BTW: would you think that there would be any possibility to see something like system.log in android running? |
14:16.52 | opennandra_ | kernel booting on HTC Oxygen |
14:17.17 | opennandra_ | after 3 weeks of testing and learning it works hooray :D |
14:17.53 | cr2 | asj_xda: i have no idea about android. never used it. |
14:20.06 | m4D | <PROTECTED> |
14:21.00 | tmzt | how new is Xfbdev? |
14:21.15 | m4D | from latest xorg release |
14:21.47 | m4D | xorg-server-1.5.1 |
14:22.02 | tmzt | that has built-in tslib support? |
14:22.20 | m4D | yes. i configured with -enable-tslib |
14:22.55 | tmzt | just to start with, try strace Xfbdev -mouse tslib 2>&1|grep lib |
14:23.29 | cr2 | kiozen: i think that the cheaper devices are the US version |
14:23.52 | tmzt | you're really going to want to build X with -g at least and run it with gdb |
14:23.55 | cr2 | but i can't find an antenna |
14:24.17 | m4D | lot's of strings, like: open("/usr/local/lib/libts-0.0.so.0", O_RDONLY) = 3 |
14:24.59 | kiozen | cr2: you have to add tax and the loss of waranty |
14:25.09 | tmzt | is that where you installed it? |
14:25.21 | tmzt | ldconfig -v /usr/local/lib |
14:25.21 | m4D | yes |
14:25.44 | tmzt | and /usr/local/lib is in $LD_LIBRARY_PATH for Xfbdev? |
14:25.55 | m4D | yes |
14:25.55 | tmzt | obviously since it is in the strace |
14:26.15 | tmzt | what version of tslib is it? |
14:26.28 | m4D | 1.0 release, from berlios site |
14:26.43 | m4D | it's identical to svn |
14:27.37 | m4D | look like i really need to build gdb... that'll take some time |
14:27.40 | tmzt | it's very hard to follow a segfault without gdb, but try the strace without grep and paste the last few lines before the segfault |
14:27.45 | tmzt | yeah |
14:27.57 | *** join/#htc-linux cr2_ (n=cr2@ip-77-25-82-1.web.vodafone.de) |
14:28.40 | m4D | strange line just before segfault |
14:28.43 | m4D | open(NULL, O_RDONLY) |
14:29.01 | m4D | i dunno what is that, can't find it in fbdev.c |
14:29.06 | tmzt | no, makes sense |
14:29.30 | tmzt | try Xfbdev -mouse tslib,,device=/dev/input/eventX |
14:30.09 | *** join/#htc-linux myxor (n=myxor@pdbn-4d08956a.pool.mediaWays.net) |
14:30.30 | m4D | hmm) started without segfault... strange, TSLIT_TSDEVICE is defined |
14:30.41 | tmzt | it's not really used anymore |
14:30.52 | m4D | ok. thank you) |
14:30.53 | tmzt | except by tslib-utils |
14:31.13 | tmzt | although I thought 1.5 would have the evdev based touchscreen driver |
14:31.40 | m4D | it has, but it works ugly |
14:32.26 | tmzt | ah |
14:33.12 | tmzt | how fast is Xfbdev in 1.5 |
14:33.12 | tmzt | and what kind of memory usage |
14:33.16 | tmzt | also, I assume you are using pxafb |
14:34.47 | m4D | fast enough) mm... i dunno how to check real mem usage) top sez about 200kb |
14:35.06 | m4D | yes, pxafb |
14:35.14 | tmzt | resolution? |
14:35.34 | m4D | 480x640 |
14:35.57 | tmzt | nice, so it supports portrait as well |
14:36.20 | tmzt | I have a 240x320 and kdrive from debian armel won't support the resolution |
14:36.49 | tmzt | what did you have to do to build Xfbdev from x.org git? |
14:36.57 | tmzt | what kind of dependencies? |
14:37.18 | m4D | lots of deps) packet by packet |
14:37.38 | cr2_ | haha, very interesting. |
14:38.09 | m4D | be back a bit later |
14:41.27 | *** join/#htc-linux TripleQ (n=joost@ip49-198-173-82.adsl2.static.versatel.nl) |
14:47.23 | *** join/#htc-linux nebi (n=nebi@170.ftth2.cust.fyrobs1.upps.se.borderlight.net) |
15:05.34 | cr2_ | lol |
15:06.20 | cr2_ | quote -> "HTC: Use CLK API, just return, need to review" |
15:07.15 | tmzt | where? |
15:08.32 | cr2_ | titan cif.dll |
15:09.07 | cr2_ | yeah. M, NOT_N_M, NOT_2D |
15:09.16 | cr2_ | i think we know these already. |
15:09.54 | tmzt | what dll is that? |
15:10.12 | cr2_ | camera |
15:10.41 | tmzt | yeah got that after a minute, I was thinking qif was camera for some reason |
15:10.44 | tmzt | it uses mddi though? |
15:10.46 | cr2_ | and then the +0x40 changes wrapped in rex_int_lock/rex_int_free |
15:11.05 | cr2_ | CameraInterFace |
15:11.28 | cr2_ | ok, 40 and 2c |
15:13.18 | cr2_ | 3c |
15:13.34 | cr2_ | so it's called VFEHW |
15:14.01 | cr2_ | VFE? i think i've seen it in the g1 clock code |
15:15.16 | tmzt | video front-end? |
15:19.00 | *** join/#htc-linux acsviluppo (n=acsvilup@151.67.24.12) |
15:19.03 | cr2_ | a funny name for the cam sensor ? |
15:19.27 | cr2_ | 122 CLOCK("vfe_clk", VFE_CLK, NULL, OFF), |
15:19.47 | tmzt | I think something else that allows the video to be passed to dsp |
15:19.59 | cr2_ | 123 CLOCK("vfe_mdc_clk", VFE_MDC_CLK, NULL, OFF), |
15:20.14 | cr2_ | and what is VDC ? |
15:20.27 | cr2_ | video display controller ? |
15:20.39 | tmzt | where? |
15:21.05 | cr2_ | 121 CLOCK("vdc_clk", VDC_CLK, NULL, OFF | MINMAX), |
15:21.38 | cr2_ | nice. i've lerned that the btaudio pins are called BTPCM in tita |
15:22.43 | cr2_ | hmm. now i'm missing the usb clocks, tv out and mdp |
15:23.07 | tmzt | does VDC include mdp? |
15:23.46 | *** join/#htc-linux pawel (n=pawel@195.205.38.92) |
15:25.01 | cr2_ | i think so |
15:25.41 | Balsat | asj_xda: /system/bin/logcat |
15:26.33 | asj_xda | Balsat: I've allready found that the only tink I need is >su >logcat |
15:27.46 | asj_xda | Balsat: anyway I have currently some issue with strips on my display after wakeup from power save and I do not see anything in the log :( The log is only runtime or is there possibility to store it and get it after reboot? |
15:28.20 | tmzt | dzo is still working on power management |
15:29.03 | asj_xda | tmzt: I know.. but it seems like I am currently the only one having that issue |
15:29.45 | *** join/#htc-linux pH5 (n=ph5@e178212099.adsl.alicedsl.de) |
15:30.03 | Balsat | asj_xda: logcat is the only way i know of |
15:31.38 | asj_xda | Balsat: I was trying to get something like logcat > logcat.log but I am not able to write > on the hardware keyboard and I haven't found a way to launch soft KB |
15:32.12 | Balsat | Can't you make a script? |
15:33.00 | asj_xda | in WinMo and just launch it in Android? |
15:33.11 | asj_xda | that would maybe work |
15:33.14 | Balsat | Yes |
15:33.32 | asj_xda | OK, I'll give it a try.. |
15:35.28 | asj_xda | waht shell it uses? |
15:36.56 | tmzt | cr2_: huh, SanMehat said it might be variable focus engine, and autofocus is done by dsp |
15:37.10 | tmzt | is this a clock or pwm? |
15:37.51 | Balsat | sh |
15:39.08 | cr2_ | tmzt: i think clock |
15:41.53 | tmzt | uh |
15:42.00 | tmzt | Camera / Video Front End clock |
15:42.12 | tmzt | VFE_CLK 40 Camera / Video Front End clock |
15:42.23 | tmzt | VFE_MDC_CLK 41 VFE MDDI client clock |
15:42.43 | cr2_ | ok |
15:42.48 | cr2_ | hehe. |
15:42.49 | tmzt | also, it appears the msm is a mddi client to the camera interface (video front end??) |
15:42.53 | tmzt | that's in android git |
15:43.08 | cr2_ | the smi size value is hardcoded as 0x20 on raph800 |
15:43.18 | cr2_ | tmzt: yes. |
15:43.32 | tmzt | the comments in clock-7x01a.c are useful |
15:43.40 | cr2_ | yes |
15:43.43 | tmzt | you might have been the one to say that, can't remember |
15:44.43 | tmzt | ACPU_PLL_TCX0, ACPU_PLL_0,1,2,3 |
15:45.03 | tmzt | a11clk_src_sel |
15:45.13 | tmzt | a11clk_src_div |
15:45.21 | tmzt | ahbclk_khz |
15:45.26 | tmzt | ahbclk_div |
15:45.34 | tmzt | what is ahbclk? |
15:46.06 | cr2_ | something very lowlevel |
15:46.16 | cr2_ | i doubt that we need to control it |
15:46.23 | tmzt | #define A11S_CLK_CNTL_ADDR (MSM_CSR_BASE + 0x100) |
15:46.31 | tmzt | #define A11S_CLK_SEL_ADDR (MSM_CSR_BASE + 0x104) |
15:46.46 | tmzt | what is CSR and what are these offsets? |
15:46.53 | cr2_ | it's already handled separately |
15:47.07 | tmzt | ok, is sel the same as s? |
15:47.29 | cr2_ | hm. |
15:47.34 | cr2_ | don't know |
15:49.01 | tmzt | http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=arch/arm/mach-msm/acpuclock.c;h=6ea137be23e8dbb5086f4fec42267b32d557b6f9;hb=android-msm-2.6.27 |
15:54.15 | AstainHellbring | morning |
15:54.16 | cr2_ | 390 /* CLK_SRC0_SEL */ |
15:54.17 | cr2_ | 391 sel = (readl(A11S_CLK_CNTL_ADDR) >> 12) & 0x7; |
15:54.32 | cr2_ | this one looks god, but on a different place |
15:55.04 | tmzt | thinking A11S is arm11 source |
15:55.08 | tmzt | can't confirm |
15:55.33 | tmzt | is MSM_CSR_BASE the base you find in ce? |
15:57.01 | tmzt | 0xE0001000 |
15:57.12 | tmzt | 0xC0100000 phys |
15:57.57 | cr2_ | NetRipper: the ram size is stored in nand ;) |
15:58.30 | cr2_ | tmzt: yes, it's a different area |
15:59.39 | tmzt | I guess that's just smem since A11 int and everything else is offset from there |
15:59.54 | tmzt | A2M_INT |
15:59.55 | tmzt | I mean |
16:01.22 | NetRipper | cr2_, how are we supposed to read that when the kernel is still in its very early boot stage |
16:02.30 | cr2_ | NetRipper: maybe on raph800 only |
16:02.52 | cr2_ | NetRipper: we should set the right memory size in haret |
16:05.59 | NetRipper | cr2_, ok then we still have left how to determine 32 or 64mb sram |
16:06.09 | cr2_ | 32 only |
16:07.29 | cr2_ | NetRipper: [16:43] <cr2_> the smi size value is hardcoded as 0x20 on raph800 |
16:08.14 | cr2_ | NetRipper: but i guess we can use the first 8 or 9 MB of sram |
16:08.50 | cr2_ | because oemsbl is at 0x930000 and amss is at 0xa00000 |
16:10.06 | *** join/#htc-linux zycho (n=zycho@a89-183-76-201.net-htp.de) |
16:10.31 | cr2_ | NetRipper: does vogue decode teh dex batt response ? |
16:11.13 | NetRipper | i dont know |
16:11.20 | NetRipper | i think maejrep has looked into that a bit already |
16:20.22 | *** join/#htc-linux m4D (n=m4D@ppp85-140-86-67.pppoe.mtu-net.ru) |
16:26.37 | cr2_ | NetRipper: http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=arch/arm/mach-msm/battery.c;h=7948f4a0cb628755e6781243b202c0b73ba558ad |
16:26.51 | cr2_ | NetRipper: static int htc_get_batt_info(struct battery_info_reply *buffer) |
16:27.11 | cr2_ | NetRipper: it's the same location on raph800 |
16:27.33 | tmzt | you said on titan, titan was the same |
16:27.43 | tmzt | as raph800? |
16:27.55 | cr2_ | NetRipper: we have it at +0xfc110 |
16:28.02 | cr2_ | tmzt: yes |
16:28.13 | cr2_ | NetRipper: and they at +0xfc140 |
16:28.25 | tmzt | having a lot of fun with git |
16:28.36 | cr2_ | hehe |
16:28.37 | tmzt | moving things around and trying to break it |
16:29.04 | tmzt | mostly trying to save some space which is not working well |
16:30.11 | *** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey) |
16:34.20 | cr2_ | NetRipper: do you have raph+wince+haret somewhere close ? |
16:37.11 | arto_ | cr2_, I do... |
16:40.59 | NetRipper | cr2_, i do (too) |
16:41.04 | cr2_ | AstainEEE: can you start dumping at 0x0 ? |
16:41.38 | cr2_ | i'm interested when the dump will start failing (<10MB) |
16:41.50 | NetRipper | memory dump? |
16:41.57 | cr2_ | yes |
16:42.08 | NetRipper | physical or virtual address 0? |
16:42.16 | cr2_ | pwf smi 0x0 0xa00000 |
16:43.23 | AstainEEE | k started that in haret console |
16:43.26 | NetRipper | got a file of 9441280 bytes |
16:43.38 | NetRipper | short write detected' |
16:43.41 | cr2_ | 0x930000 ? |
16:43.42 | AstainEEE | Short write detected while writing to file |
16:44.22 | AstainEEE | same thing on 930000 |
16:44.29 | cr2_ | 9633792 |
16:44.46 | cr2_ | 9437184 is 9MB |
16:44.59 | NetRipper | 0x901000 |
16:45.01 | *** join/#htc-linux hechu (n=hechu@221.5.86.42) |
16:45.18 | cr2_ | ok, so you can't read oemsbl |
16:45.27 | cr2_ | makes sense ;) |
16:45.49 | NetRipper | does it ;) |
16:46.00 | NetRipper | bunch of teasing people over at htc |
16:47.12 | cr2_ | ok, so we can use 9MB |
16:48.35 | NetRipper | 9mb of what... 0x0 is not the location of the memory module |
16:48.52 | cr2_ | for FB and such |
16:49.19 | cr2_ | NetRipper: let's optimize your memory layout now :) |
16:51.27 | tmzt | is mdp already using that or is it using external sdram? |
16:51.31 | NetRipper | don't we need a piece of actual memory for fb |
16:51.48 | cr2_ | tmzt: it depends on the device |
16:52.09 | cr2_ | tmzt: g1 has an extra 32MB bank |
16:52.55 | cr2_ | and NetRipper uses some crippled setup with 76MB for linux :) |
16:53.32 | tmzt | huh, how much ram does raph100/800 have? |
16:53.56 | cr2_ | NetRipper: you need ram for fb. the kind of this ram does not matter. |
16:53.56 | NetRipper | if i let linux figure it out for itself (i..e remove the mem=) then android wont boot, probably because it writes in wrong data |
16:53.56 | cr2_ | tmzt: 128+128+9 |
16:53.56 | tmzt | I got some numbers from San for 2.6.27, I can look them up if you want |
16:54.38 | cr2_ | NetRipper: it's not about mem, but the hardcoded mem layout |
16:55.07 | tmzt | for 2.6.27 (cupcake) on g1 |
16:59.29 | cr2_ | gpu0, gpu1,adsp and mdp need some memory |
17:03.55 | NetRipper | i fucked up my git |
17:03.59 | NetRipper | need to checkout again |
17:05.42 | *** join/#htc-linux cr2__ (n=cr2@ip-77-24-111-25.web.vodafone.de) |
17:07.05 | NetRipper | dinnertime, bbl |
17:17.05 | *** join/#htc-linux cr2__ (n=cr2@ip-77-24-111-25.web.vodafone.de) |
17:31.08 | cr2__ | NetRipper: the g1 setup is not less strange than yours :) |
17:38.57 | *** join/#htc-linux hamx0r (i=hamx0r@ip70-181-218-195.sd.sd.cox.net) |
17:47.22 | *** join/#htc-linux opennandra (n=opennand@afrodita.advanet.sk) |
17:47.29 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
17:51.59 | AstainEEE | so cr2__ whats needed to get this full mem mapping done? |
17:55.37 | cr2__ | AstainEEE: we need to test some modifications |
17:56.32 | cr2__ | NetRipper has diverged from g1 too much. |
17:57.06 | cr2__ | i don't understand why both don't use the 110-128MB area |
17:58.40 | AstainEEE | ok what can I do to help? |
18:01.06 | m4D | hey guys, how to set kdrive's mouse protocol? 'switching to protocol xxx' makes me mad... |
18:22.16 | asj_xda | dzo: Are you online? |
18:27.13 | cr2__ | AstainEEE: let's first shift the memory top to 128MB |
18:30.16 | AstainEEE | ok cr2__ how we do that one? |
18:30.33 | *** join/#htc-linux dzo_ (n=dzo@121-98-128-127.bitstream.orcon.net.nz) |
18:43.31 | *** join/#htc-linux metter (n=metter@173-221.62-81.cust.bluewin.ch) |
18:44.24 | cr2__ | AstainEEE: in the board-htcraphael.h |
18:44.44 | cr2__ | change #define MSM_EBI_SIZE 0x6e00000 |
18:44.51 | cr2__ | to #define MSM_EBI_SIZE 0x8000000 |
18:45.03 | *** join/#htc-linux tsdogs_ (n=tsdogs@net203-187-146.mclink.it) |
18:45.13 | cr2__ | and #define MSM_LINUX_SIZE 0x4c00000 |
18:45.14 | cr2__ | to |
18:46.12 | cr2__ | #define MSM_LINUX_SIZE 0x6600000 |
18:46.35 | cr2__ | compile, and check if it'll boot :) |
18:50.55 | *** join/#htc-linux Arto (n=AstainHe@c-67-164-195-234.hsd1.ut.comcast.net) |
18:51.49 | cr2__ | AstainHellbring: lost my last message ? |
18:51.57 | *** join/#htc-linux arto_ (n=arto@c-67-164-195-234.hsd1.ut.comcast.net) |
18:51.59 | AstainHellbring | yah think so what was it? |
18:52.26 | *** join/#htc-linux shoragan (n=shoragan@debian/developer/shoragan) |
18:54.13 | cr2__ | [19:44] <cr2__> AstainEEE: in the board-htcraphael.h |
18:54.13 | cr2__ | [19:44] <cr2__> change #define MSM_EBI_SIZE 0x6e00000 |
18:54.13 | cr2__ | [19:44] <cr2__> to #define MSM_EBI_SIZE 0x8000000 |
18:54.13 | cr2__ | [19:44] --> tsdogs_ has joined this channel (n=tsdogs@net203-187-146.mclink.it). |
18:54.13 | cr2__ | [19:45] <cr2__> and #define MSM_LINUX_SIZE 0x4c00000 |
18:54.13 | cr2__ | [19:45] <cr2__> to |
18:54.13 | cr2__ | [19:46] <cr2__> #define MSM_LINUX_SIZE 0x6600000 |
18:54.13 | cr2__ | [19:46] <cr2__> compile, and check if it'll boot :) |
18:56.02 | AstainHellbring | ahh ic |
18:57.38 | cr2__ | if it will boot, please pastebin the dmesg |
18:58.34 | NetRipper | cr2__, because smem is there? we can't use tahat area |
18:59.05 | NetRipper | everything above 92m cant be used on the first bank |
18:59.26 | NetRipper | don't ask me why 92m.. it's unstable when using 96m |
19:01.24 | cr2__ | NetRipper: btw, you don't have 8MB for the camera, and the 128K for "console" in your map |
19:01.46 | cr2__ | 2M for the fb is an overkill, but it's another issue |
19:02.07 | NetRipper | let me note that i have nothing to do with the current memory map :P |
19:02.16 | cr2__ | ? |
19:02.36 | NetRipper | the .h file is not my work |
19:03.05 | cr2__ | where does it come from ? |
19:03.30 | NetRipper | it was part of the initial 2.6.25->2.6.27 commit by maejrep |
19:04.08 | NetRipper | hence i dont know much about memory layouting |
19:04.51 | cr2__ | ok |
19:05.04 | cr2__ | AstainHellbring: does it work ? |
19:05.14 | NetRipper | it won't work |
19:05.17 | NetRipper | he'll get a white screen |
19:05.43 | NetRipper | not sure if i used 0x66* though |
19:05.57 | AstainHellbring | I haven't tried it yet |
19:06.11 | AstainHellbring | having to file an insurance claim on one of my cell lines |
19:06.23 | NetRipper | sue those bastards! |
19:07.26 | NetRipper | cr2__, btw 'gitk' is a lovely tool.. sorta like gitweb but in a local client |
19:07.43 | NetRipper | allows you to see diffs really fast and easily |
19:07.46 | cr2__ | ok |
19:08.03 | cr2__ | NetRipper: can you check the different memory layout ? |
19:08.15 | NetRipper | the LINUX_BASE change you mean? |
19:08.33 | NetRipper | and EBI |
19:09.19 | cr2__ | yes |
19:09.28 | cr2__ | i think EBI is not used anywhere |
19:09.35 | cr2__ | but just to be sure |
19:09.54 | cr2__ | hmm |
19:09.58 | cr2__ | 434 clk = clk_get(&pdev->dev, "mdp_clk"); |
19:10.35 | cr2__ | what does this call return ? afaik the mdp clk is not known. maybe 0x200 though. |
19:12.24 | cr2__ | sometimes i'm amazed that the kernel boots at all :) |
19:15.40 | NetRipper | cant find where the msm_clocks are defined :p |
19:16.25 | NetRipper | ah |
19:16.27 | NetRipper | <PROTECTED> |
19:16.38 | NetRipper | clock-7x01a.c |
19:16.49 | NetRipper | the msm_clocks array |
19:18.37 | NetRipper | cr2__, |
19:18.47 | NetRipper | with your modifications, the kernel booted, but msm_fb fails |
19:18.52 | NetRipper | getting a white screen |
19:19.05 | NetRipper | i can telnet to it though, so any commands you want me to check? |
19:19.32 | NetRipper | still using mem=76M though |
19:19.58 | NetRipper | dont think that should cause the issue |
19:19.59 | cr2__ | free |
19:20.10 | NetRipper | MemTotal: 73924 kB |
19:20.10 | NetRipper | MemFree: 70052 kB |
19:20.19 | cr2__ | pastebin the dmesg |
19:20.24 | NetRipper | sec |
19:20.35 | cr2__ | ok, the mem=102M |
19:21.29 | NetRipper | http://netripper.pastebin.com/d627bfaff |
19:21.58 | cr2__ | ok |
19:22.44 | cr2__ | try 102 |
19:22.47 | NetRipper | will do |
19:22.55 | cr2__ | hmm, this is not nice: [ 0.190000] WARNING - Bad VDD (0 != 7) for this freq |
19:23.04 | NetRipper | been there since the start |
19:23.30 | NetRipper | arf elite rom gives me headaches |
19:23.52 | NetRipper | 33% of the time it hangs when booting |
19:24.11 | AstainHellbring | NetRipper: rc3? |
19:24.14 | NetRipper | yes |
19:24.20 | cr2__ | [ 0.650000] msm_i2c_probe: clk_ctl 35d, 100000 Hz |
19:24.22 | cr2__ | [ 0.650000] msm_i2c_interrupt: IRQ but nothing to do! |
19:24.26 | NetRipper | AstainHellbring, it's a known issue |
19:24.26 | AstainHellbring | wierd its never done that to me |
19:24.32 | cr2__ | don't know how the i2c_clk is handled too. |
19:24.57 | NetRipper | AstainHellbring, it's the tf3d inititialzing problem.. on those boots i dont get the 'loading touchflo 3d...' message.. |
19:25.04 | AstainHellbring | ahh hanging there |
19:25.13 | cr2__ | hmm |
19:25.18 | cr2__ | [ 0.825406] clk_set_rate 7:19200000 |
19:25.20 | cr2__ | [ 0.825467] unknown clock! |
19:25.28 | cr2__ | at least some reasonable message |
19:25.45 | NetRipper | cr2__, you already mentioned that... 7 is the clock that is unknown |
19:25.59 | cr2__ | what is 7 ? |
19:26.04 | NetRipper | general purpose |
19:26.10 | cr2__ | ah, ok. |
19:26.29 | cr2__ | it's known, but needs some more careful research. |
19:26.48 | cr2__ | because it touches the registers in teh non-divisor area |
19:27.17 | NetRipper | same behaviour with 102 |
19:27.19 | NetRipper | M |
19:27.33 | cr2__ | same ? |
19:27.37 | NetRipper | MemTotal: 100324 kB |
19:27.38 | NetRipper | MemFree: 96404 kB |
19:27.43 | cr2__ | post the dmesg |
19:27.46 | *** join/#htc-linux opennandra_ (n=opennand@afrodita.advanet.sk) |
19:27.47 | NetRipper | msmfb fails - white screen |
19:28.14 | cr2__ | well, the lcd is so fucked up, that i'm amazed that it works at all ;) |
19:28.43 | NetRipper | http://netripper.pastebin.com/d6bcec3f7 |
19:28.48 | cr2__ | thanks |
19:29.09 | NetRipper | msmfb works when i reset those values to not overlap smem |
19:29.10 | NetRipper | :) |
19:29.20 | cr2__ | smem ? |
19:29.42 | NetRipper | mdp/adsp/gpu1 overlap smem now, dont they |
19:29.50 | cr2__ | no |
19:30.14 | cr2__ | they are just above 102MB |
19:30.26 | cr2__ | 102+8+8+8+2 |
19:30.45 | cr2__ | LNX+MDP+ADSP+GPU1+FB |
19:31.16 | cr2__ | the GPU0 is in SRAM 0x0-0x800000 |
19:31.33 | cr2__ | but g1 has 7MB instead |
19:31.44 | cr2__ | and i have no idea who is using it. |
19:31.53 | NetRipper | but wasn't the last 32mb of the first bank used by modem? |
19:32.15 | NetRipper | first bank has 128mb, 96-128 is used by modem = smem, isnt it? |
19:32.23 | cr2__ | 9MB is oemsbl, 10-31 is amss, and 32 is SMEM |
19:32.23 | NetRipper | am i confused about something? |
19:32.30 | cr2__ | no |
19:32.36 | cr2__ | there are 3 RAM areas |
19:33.11 | cr2__ | SMI, EBI@0x10000000 and EBI@0x20000000 |
19:33.37 | cr2__ | the SMI is 0-9 GPU0, 9MB is oemsbl, 10-31 is amss, and 32 is SMEM |
19:34.22 | NetRipper | ok |
19:34.23 | cr2__ | EBI1@0x10000000 is 128MB for linux and MDP+ADSP+GPU1+(CAM)+FB. |
19:34.46 | cr2__ | we can actually move FB into SMI |
19:35.03 | cr2__ | and the rest needs some discussion too |
19:35.20 | cr2__ | ADSP+MDP can't be revised, probably |
19:35.55 | cr2__ | so 104MB for linux is not a problem |
19:36.31 | *** join/#htc-linux Pure4Real (n=pure4rea@89-97-140-219.ip17.fastwebnet.it) |
19:37.32 | cr2__ | btw, the 102MB dmesg does not whine abut the cpu voltage ? |
19:38.24 | NetRipper | it doesnt? |
19:38.32 | NetRipper | indeed it doesnt |
19:39.09 | cr2__ | don't understand this one [ 0.981107] msm_serial: probe of msm_serial.0 failed with error -2 |
19:39.36 | cr2__ | [ 0.997800] usb_probe() io=c6806000, irq=47, dma=ffc01000(16227000) |
19:39.43 | cr2__ | need to check this one too |
19:39.56 | cr2__ | where does 16227000 come from |
19:40.16 | cr2__ | [ 0.991361] logger: created 64K log 'log_main' |
19:40.17 | cr2__ | [ 0.991879] logger: created 256K log 'log_events' |
19:40.18 | cr2__ | [ 0.992337] logger: created 64K log 'log_radio' |
19:40.26 | cr2__ | and this one too |
19:40.43 | NetRipper | ah that may be ram console |
19:41.05 | NetRipper | printk(KERN_INFO "usb_probe() io=%p, irq=%d, dma=%p(%x)\n", |
19:41.06 | NetRipper | <PROTECTED> |
19:41.09 | NetRipper | <PROTECTED> |
19:41.11 | NetRipper | oops |
19:41.56 | cr2__ | you didn't reserve ram for cnsole |
19:42.02 | cr2__ | 128K |
19:42.36 | cr2__ | if it's needed at all. for non-android operation |
19:42.57 | *** join/#htc-linux zycho_ (n=zycho@a89-183-76-201.net-htp.de) |
19:42.57 | cr2__ | btw, what is the purpose of 'diag' ? |
19:43.00 | cr2__ | [ 1.001553] usb_bind_func() 'diag' |
19:43.22 | NetRipper | dont know, it's htc/qc specific |
19:43.48 | NetRipper | we can remove it, just like adb, which i havent found a use for either |
19:44.24 | cr2__ | ok |
19:44.44 | cr2__ | usb0 for cdc-ether is ok |
19:44.48 | cr2__ | [ 1.569180] mmc0: DM non-cached buffer at ffc03000, dma_addr 0x16237000 |
19:44.49 | cr2__ | [ 1.584500] mmc0: DM cmd busaddr 0x16237000, cmdptr busaddr 0x16237300 |
19:44.56 | NetRipper | isn't console ram allocated withint he linux_base part? |
19:45.01 | cr2__ | the 0x16* area is loved by dma :) |
19:45.19 | cr2__ | android console ram is a fixed allocation |
19:46.55 | cr2__ | 36 #define MSM_RAM_CONSOLE_BASE MSM_EBI_BASE + 0x6d00000 |
19:46.56 | cr2__ | 37 #define MSM_RAM_CONSOLE_SIZE 128 * SZ_1K |
19:47.39 | cr2__ | make FB 1MB instead of 2MB and put the console above it. |
19:47.54 | NetRipper | what file is that from? |
19:47.59 | cr2__ | g1 |
19:48.09 | cr2__ | MSM_EBI_BASE + 0x6d00000 needs to be changed of course |
19:48.20 | NetRipper | i see |
19:48.20 | cr2__ | where is the logger driver ? |
19:49.59 | NetRipper | allocate the 1mb substracted from fb to ram console? |
19:50.16 | cr2__ | wait |
19:50.20 | NetRipper | btw we dont have a MSM_RAM_CONSOLE_* defined now, and it compiles... so it isnt using it |
19:50.29 | cr2__ | drivers/misc/logger.c |
19:51.12 | NetRipper | whats up with it? |
19:51.15 | NetRipper | remove it? |
19:51.48 | cr2__ | ANDROID_RAM_CONSOLE default n |
19:52.36 | *** join/#htc-linux MethoS- (n=lem@host-091-097-241-080.ewe-ip-backbone.de) |
19:52.44 | cr2__ | ok, you have enabled it |
19:53.09 | NetRipper | i can disable it just as easily ;) |
19:53.20 | NetRipper | dont know why it was enabled |
19:53.23 | NetRipper | we had it disabled in .25 |
19:53.34 | *** join/#htc-linux dzo (n=dzo@121-98-128-127.bitstream.orcon.net.nz) |
19:54.09 | cr2__ | _probe prints ram_console: |
19:54.27 | cr2__ | don't see it in your log |
19:54.40 | NetRipper | because im not using console ram |
19:54.45 | cr2__ | ok |
19:54.48 | NetRipper | it's a in-memory dmesg like wince has |
19:54.57 | cr2__ | now the dma |
19:55.26 | cr2__ | the 76MB setup has it at 0x14 |
19:55.42 | *** join/#htc-linux skodde (n=skodde@unaffiliated/skodde) |
19:56.10 | cr2__ | 0x16* is 96MB+ |
19:56.27 | cr2__ | should be ok for kmalloc |
19:56.39 | cr2__ | 0x14* is 64MB+ |
19:56.53 | cr2__ | looks ok for me |
19:57.13 | cr2__ | at first i thought it can overwrite the MDP and such. |
19:57.17 | NetRipper | i'll disable ram console |
19:57.21 | cr2__ | ok |
19:57.28 | cr2__ | and usb 'diag' |
19:57.44 | NetRipper | android_pmem allocator? |
19:57.48 | *** join/#htc-linux shoragan (n=shoragan@debian/developer/shoragan) |
19:58.22 | cr2__ | yes. leave it for now |
19:59.56 | NetRipper | should we include CAM in memory layout? |
19:59.58 | NetRipper | like in trout |
20:01.29 | NetRipper | /* 102 + 8 + 8 + 8 + 1 + 1 */ |
20:01.32 | NetRipper | /* LIN + MDP + ADSP + GPU1 + CONSOLE + FB */ |
20:01.36 | NetRipper | is what i have now |
20:04.31 | cr2__ | ok, if it boots, add the cam |
20:04.52 | cr2__ | 102-8=94 |
20:05.26 | cr2__ | but you may change GPU0 size to 0x7, and put FB there |
20:05.43 | cr2__ | like g1 |
20:06.10 | cr2__ | int the 8th MB |
20:06.13 | cr2__ | in smi |
20:06.37 | cr2__ | i think that's the best we can do |
20:06.38 | NetRipper | it boots (at least the navi is responsive) but no usb and no fb... think i screwed something up regarding usb |
20:06.48 | cr2__ | ok |
20:07.05 | cr2__ | usb is usb0 instead of usb1 now ? |
20:07.11 | NetRipper | oh crap |
20:07.20 | NetRipper | forgot that |
20:07.27 | NetRipper | im still checking usb1 |
20:07.28 | NetRipper | ;x |
20:07.44 | cr2__ | i was pissed from the very beginnng :) |
20:07.52 | cr2__ | that it's usb1 |
20:08.01 | NetRipper | well, you wouldnt, if you had just read the wiki FAQ |
20:08.02 | NetRipper | ;) |
20:08.13 | cr2__ | i never read docs |
20:08.22 | NetRipper | evidently |
20:08.25 | cr2__ | the software should be user-friendly :) |
20:08.44 | NetRipper | M$ has been attempting that for years |
20:09.23 | NetRipper | think im going to flash another rom soon again |
20:09.24 | NetRipper | ;) |
20:09.25 | cr2__ | usb1 is completely non-obvious |
20:09.56 | NetRipper | we had it working.. |
20:10.05 | NetRipper | after a long time |
20:10.08 | NetRipper | so we kinda were like |
20:10.11 | NetRipper | DONT TOUCH IT |
20:10.14 | cr2__ | :) |
20:10.42 | cr2__ | and i still don't understand why it works only with network class removed |
20:11.42 | cr2__ | we also need to check who uses GPU0 and GPU1 |
20:13.29 | cr2__ | maejrep: are you here ? |
20:14.16 | cr2__ | NetRipper: i'll be away for about 30min |
20:14.21 | NetRipper | ok |
20:14.35 | NetRipper | im out soonish too |
20:21.54 | NetRipper | cr2__, 1MB is not enough for msmfb |
20:22.10 | NetRipper | [ 0.838040] allocated resource is too small for fb |
20:22.10 | NetRipper | [ 0.838223] msm_panel: probe of msm_panel.0 failed with error -12 |
20:37.31 | cr2__ | NetRipper: 640x480x2 ? |
20:37.36 | NetRipper | no |
20:37.37 | NetRipper | sec. |
20:38.00 | NetRipper | unsigned long size = msmfb->xres * msmfb->yres * |
20:38.01 | NetRipper | <PROTECTED> |
20:38.18 | cr2__ | 0x96000 |
20:38.25 | NetRipper | 16bpp |
20:38.39 | cr2__ | yes, 2bytes per pixel |
20:38.46 | cr2__ | 640*480 pixels |
20:39.54 | cr2__ | where does tis line come from ? |
20:40.04 | NetRipper | msm_fb.c |
20:42.10 | cr2__ | * 2 ? |
20:42.56 | cr2__ | NetRipper: can you remove *2 ? |
20:43.15 | NetRipper | cr2__, the *2 is because it holds the framebuffer twice |
20:43.25 | NetRipper | one is a back buffer |
20:43.39 | NetRipper | msmfb also writes to the y offset |
20:43.45 | cr2__ | ok |
20:44.08 | cr2__ | 0x12c000 |
20:44.30 | cr2__ | for the FB size |
20:45.01 | *** join/#htc-linux BabelO (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
20:45.42 | NetRipper | what does the >> 3 do? |
20:45.47 | NetRipper | im no star in bitshifting |
20:45.49 | cr2__ | <PROTECTED> |
20:45.55 | NetRipper | ah |
20:45.56 | cr2__ | bits to bytes |
20:46.57 | cr2__ | if the 9th smi MB is writable, i'll put FB at 0x700000 |
20:47.19 | cr2__ | can you dump the 9th MB ? |
20:47.35 | cr2__ | pwf qcsbl 0x800000 0x100000 |
20:47.39 | NetRipper | Archive 9441280 2009-02-08 17:42:44 smi |
20:47.42 | NetRipper | oh |
20:47.56 | cr2__ | ok, the full dump is ok too |
20:48.09 | NetRipper | that's how much i could dump starting at 0x0 |
20:48.15 | cr2__ | yes |
20:48.23 | cr2__ | where can i get it ? |
20:48.27 | cr2__ | bz2 |
20:48.28 | NetRipper | you want it? :P |
20:48.30 | NetRipper | sec |
20:48.41 | cr2__ | i'd like to look at the 9th MB |
20:48.46 | cr2__ | if it's qcsbl |
20:49.27 | *** join/#htc-linux rm (n=rm@fsf/member/rm) |
20:55.37 | *** join/#htc-linux craxyham (i=hamx0r@ip70-181-218-195.sd.sd.cox.net) |
20:58.15 | NetRipper | cr2__, netripper.com/raphael/smi.gz |
20:59.20 | cr2__ | ok |
20:59.22 | cr2__ | got it |
20:59.35 | NetRipper | ok |
20:59.38 | NetRipper | removed it |
20:59.48 | NetRipper | dunno if it contains secret info |
20:59.49 | NetRipper | :) |
21:01.13 | NetRipper | hm i need a better terminal than Eterm.. something that supports clicking urls |
21:01.17 | NetRipper | ;) |
21:02.11 | cr2__ | it has spl only |
21:02.44 | NetRipper | eh? you can read spl from wince? |
21:02.46 | NetRipper | funny |
21:02.46 | cr2__ | don't see the qcsbl, so it's just a matter of testing if the 9th MB is writable |
21:02.57 | cr2__ | the spl is at 0x0 ;) |
21:04.20 | NetRipper | but i doubt we can make GPU0 7mb |
21:06.59 | cr2__ | g1 ha 7MB |
21:07.42 | NetRipper | ah, i see |
21:07.56 | cr2__ | 15 #define MSM_PMEM_GPU0_BASE 0x00000000 |
21:07.57 | cr2__ | 16 #define MSM_PMEM_GPU0_SIZE 0x00700000 |
21:08.32 | cr2__ | hehe |
21:08.36 | cr2__ | [ 1.839719] clock_late_init() disabled 19 unused clocks |
21:09.03 | cr2__ | the code needs to be much more verbose, and not just fall through on many clocks |
21:13.13 | *** join/#htc-linux cmonexaway (n=xy6091@nifl5tpzno.adsl.datanet.hu) |
21:14.01 | *** join/#htc-linux marmotta (n=skodde@unaffiliated/skodde) |
21:25.41 | NetRipper | oooooooh sweet cr2__ |
21:25.45 | NetRipper | im getting console |
21:25.56 | NetRipper | with FBRAM in SMI |
21:26.33 | *** join/#htc-linux dzo (n=dzo@121-98-128-127.bitstream.orcon.net.nz) |
21:27.33 | NetRipper | cr2__, this is what i have now http://netripper.pastebin.com/d3d8bca1b |
21:27.49 | NetRipper | only 6 mb for gpu0, not sure if that'll be enough in the future |
21:28.24 | *** join/#htc-linux Venny (i=Travis@h216-45-127-2.dynamic.platinum.ca) |
21:29.02 | cr2__ | nice |
21:29.20 | NetRipper | im still not sure about the high end of the 128 memory module |
21:29.37 | NetRipper | how are we able to use the 32 mb reserved for modem |
21:30.02 | cr2__ | <PROTECTED> |
21:30.09 | cr2__ | and it's 128K anyway |
21:30.26 | NetRipper | true |
21:30.28 | cr2__ | 32MB reserved for the modem is SMI |
21:30.45 | cr2__ | then you'll have 104MB :) |
21:30.52 | NetRipper | eh? |
21:31.04 | NetRipper | so the modem does nothing in the 128mb memory module? |
21:31.12 | cr2__ | #define MSM_LINUX_SIZE 0x6800000 /* 104mb */ |
21:31.16 | cr2__ | yes |
21:31.33 | cr2__ | and we need to enable the second 128MB bank too :) |
21:32.02 | NetRipper | there must be something in the 128mb bank we can't use.. as there are errors when we use too much memory |
21:32.51 | NetRipper | and why wouldnt the FB work when it was in RAm |
21:33.02 | NetRipper | mm |
21:36.16 | cr2__ | but the dma to 0x16* works |
21:48.02 | *** join/#htc-linux Arto (n=AstainHe@c-67-164-195-234.hsd1.ut.comcast.net) |
21:52.24 | Venny | Hey i know this is Htc linux but im having a problem with my windows mobile phone lol, and im hopeing someone can help me |
21:54.45 | Venny | someone? |
21:55.44 | NetRipper | you should ask in #xda-devs :) |
21:55.59 | Venny | K, i dont know any irc chans so thanks :) |
21:56.11 | NetRipper | they're the forum.xda-developers.com guys |
21:56.18 | NetRipper | (you should check that forum first probably) |
21:56.19 | NetRipper | :) |
21:56.39 | Venny | ive checked i seem to be the only one with the problem lol |
21:57.00 | NetRipper | ok ;) |
22:00.35 | *** join/#htc-linux dzo_ (n=dzo@121-98-128-127.bitstream.orcon.net.nz) |
22:16.30 | *** join/#htc-linux gmarzioz (n=gmarzioz@host245-100-dynamic.6-87-r.retail.telecomitalia.it) |
22:18.29 | *** join/#htc-linux MrFeetio (n=MrFeetio@pool-98-117-23-186.hrbgpa.fios.verizon.net) |
22:19.15 | *** join/#htc-linux Venny (i=Travis@h216-45-127-2.dynamic.platinum.ca) |
22:22.31 | *** join/#htc-linux dzo_ (n=dzo@121-98-128-127.bitstream.orcon.net.nz) |
22:29.35 | gmarzioz | hallo |
22:29.43 | gmarzioz | to you |
22:32.34 | *** join/#htc-linux infernix (n=nix@unaffiliated/infernix) |
22:37.07 | *** join/#htc-linux venny_ (i=Travis@h216-45-127-2.dynamic.platinum.ca) |
22:41.12 | *** join/#htc-linux Venny (i=Travis@h216-45-127-2.dynamic.platinum.ca) |
22:42.45 | *** join/#htc-linux venny_ (i=Travis@h216-45-127-2.dynamic.platinum.ca) |
22:50.35 | *** join/#htc-linux dzo (n=dzo@121-98-128-127.bitstream.orcon.net.nz) |
22:51.55 | *** join/#htc-linux Venny (i=Travis@h216-45-127-2.dynamic.platinum.ca) |
23:01.12 | dcordes | arr |
23:01.34 | asj_xda | hi |
23:05.31 | asj_xda | dcordes: BTW, you are working in Kaiser port of Android Right? |
23:13.10 | asj_xda | dcordes: Can we have a small talk? |
23:13.22 | NetRipper | uh-oh, that doesn't sound good |
23:14.02 | asj_xda | NetRipper :) seems so.. |
23:14.22 | NetRipper | it's how all bad-news conversations start |
23:14.22 | NetRipper | ;) |
23:14.45 | asj_xda | hopefully not :D |
23:15.52 | asj_xda | NetRipper I just wasted all the day pissed off by some strange issue with Android on my kaiser and I am not starting by arr :D |
23:16.21 | asj_xda | but Gee I am lost now, I am waiting for dzo or dcordes to have some questions answered... |
23:16.38 | asj_xda | but I am not sure if they are really here :D |
23:28.03 | maejrep | others might be able to answer them, if you ask |
23:29.32 | asj_xda | maejrep: I've tried few times, everybody just said, wait for those two... |
23:29.53 | maejrep | ah |
23:30.07 | asj_xda | maejrep: But anyway.. I am not sure what is wrong, but it seems that I am the only one with that issue now.. |
23:31.16 | asj_xda | maejrep: So when my Kaiser goes powersafe with Android, it does not come back, in fact everyhting seems to be running, just the screen displays white and green stripes (or lines) on the black background |
23:31.45 | asj_xda | and I haven't seen anyone confirming that nor dza was quite surprised |
23:31.54 | asj_xda | dzo, not dza :D |
23:40.17 | cr2__ | maejrep: i have checked the titan battery, and it's the same as raph800 |
23:40.38 | cr2__ | http://wiki.xda-developers.com/index.php?pagename=RaphaelMemoryMap |
23:41.51 | maejrep | why is it 2 bytes per for raph100, and 4 bytes for raph800? |
23:45.39 | cr2__ | maejrep: don't know, but it's so |
23:47.07 | cr2__ | maejrep: sorry, for titan. don't know about raph800 :) |
23:47.19 | cr2__ | but the buffer address is +0xfc140 |
23:47.26 | maejrep | it is 4 bytes in raph800 also |
23:47.42 | maejrep | 4 * 5 |
23:49.47 | cr2__ | ok |