| 02:16.21 | *** join/#openezx sabro1 (n=sab@lns-bzn-31-82-252-245-128.adsl.proxad.net) |
| 02:39.22 | *** join/#openezx sabrod (n=sab@lns-bzn-31-82-252-245-128.adsl.proxad.net) |
| 03:09.58 | *** join/#openezx arne (i=nobody@dslc-082-082-073-080.pools.arcor-ip.net) |
| 03:20.43 | *** join/#openezx gmzhuo (n=gmzhuo@222.210.146.80) |
| 05:06.07 | *** join/#openezx l403 (n=l@85.132.159.239) |
| 05:46.55 | yang | hello gmzhuo |
| 06:36.06 | gmzhuo | Hi yang |
| 06:46.44 | yang | gmzhuo: you got e6 ? |
| 06:48.18 | yang | gmzhuo: how do you llock the touchscreen, there is a tool that timeouts touchscreen after 1 minute, but it has a numpad and an OK and POWER OFF button, which I press many times accidentally |
| 06:48.52 | yang | if you ask me, it should not contain power off |
| 06:55.29 | gmzhuo | I just use lock key,not use soft lock |
| 06:58.34 | *** join/#openezx gmzhuo- (n=gmzhuo@222.210.146.80) |
| 08:05.03 | *** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1) |
| 08:10.56 | *** join/#openezx sabrod (n=sab@82.253.17.97) |
| 08:11.12 | *** join/#openezx WyrM1 (n=wyrm@20158136012.user.veloxzone.com.br) |
| 08:42.02 | *** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 08:47.32 | *** join/#openezx gDD (n=gDD@125.116.12.16) |
| 08:58.01 | *** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 08:58.29 | *** join/#openezx gmzhuo (n=gmzhuo@222.210.146.80) |
| 09:05.40 | *** join/#openezx gDD (n=gDD@125.116.12.16) |
| 09:08.38 | *** join/#openezx gDD (n=gDD@125.116.12.16) |
| 10:27.43 | *** join/#openezx gDD (n=gDD@125.116.0.119) |
| 10:32.29 | *** join/#openezx gDD (n=gDD@125.116.0.119) |
| 10:40.57 | *** join/#openezx gDD (n=gDD@125.116.0.119) |
| 10:46.38 | *** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1) |
| 11:08.50 | *** join/#openezx WyrM (n=wyrm@20158152015.user.veloxzone.com.br) |
| 12:04.45 | gmzhuo | WyrM,are you here? |
| 12:10.34 | WyrM | hi gmzhuo. |
| 12:10.37 | WyrM | I am now. :) |
| 12:20.55 | WyrM | is updating our tree from latest linus git. |
| 12:34.13 | mickeyl | cool |
| 12:34.20 | mickeyl | can i do anything to help with the touchscreen? |
| 12:34.39 | mickeyl | would trying older versions help? |
| 12:34.45 | mickeyl | so that you get a rough idea when it broke? |
| 12:34.52 | WyrM | mickeyl: I think that the interrupt handler is fully broken. |
| 12:35.01 | mickeyl | oh, ok |
| 12:35.09 | WyrM | but it seems to be 2 different problems.. |
| 12:35.18 | WyrM | one is the TS noise. |
| 12:35.34 | mickeyl | right |
| 12:35.42 | mickeyl | the other one is the halting for a couple of seconds |
| 12:35.46 | mickeyl | then resuming |
| 12:35.53 | WyrM | the other one is more recent, and it completelly broke the TS as the ADC is no longer working :( |
| 12:36.00 | mickeyl | uh oh |
| 12:36.02 | mickeyl | i see |
| 12:36.14 | WyrM | mickeyl: this halting seems to be something from userspace/tslib. |
| 12:36.45 | WyrM | I think it halts for some time if some weird coordinates are reported from the kernel driver. |
| 12:36.52 | tmzt | does it happen in evtest? |
| 12:36.59 | mickeyl | oh, that'd be a possibility |
| 12:37.08 | mickeyl | i should strace it to see whether events are still coming in or not |
| 12:37.16 | mickeyl | (if that helps) |
| 12:37.31 | WyrM | yeah, it does. |
| 12:37.40 | WyrM | but don't update the kernel from openezx.git |
| 12:40.59 | gmzhuo | other gpio irq is working,but there only once or zero interupt from pcap |
| 12:41.26 | WyrM | gmzhuo: I noted some interrupt problems with bp_rdy too. |
| 12:42.45 | WyrM | gmzhuo: can you check the "regs" on sysfs. |
| 12:43.03 | WyrM | and check if the irqs are not masked or with pending acks? |
| 12:46.03 | gmzhuo | http://pastebin.com/mb5bd8ea |
| 12:49.03 | gmzhuo | WyrM,yes,have pending acks |
| 12:50.07 | WyrM | gmzhuo: see if a 'echo "00 00100005" > regs' helps |
| 12:51.35 | gmzhuo | still no interupts |
| 12:51.42 | WyrM | also, I see a bit on on the 03 register. |
| 12:51.47 | WyrM | iirc it is INT_SEL. |
| 12:52.11 | WyrM | and if a bit is on on this register, the corresponding interrupt will be sent to BP instead of AP. |
| 12:52.27 | WyrM | I don't remember if we set any interrupt for BP. :) |
| 12:52.51 | gmzhuo | isr become 100004 |
| 12:53.02 | WyrM | nothing on /proc/interrupts? |
| 12:53.10 | gmzhuo | yes |
| 12:53.14 | WyrM | and ISR changes. |
| 12:53.15 | gmzhuo | it's zero |
| 12:53.16 | WyrM | hum... |
| 12:53.28 | WyrM | some thing is wrong with gpio then. |
| 12:54.44 | WyrM | gmzhuo: update from openezx.git |
| 12:54.56 | WyrM | maybe it was already fixed upstream. :) |
| 12:55.19 | WyrM | I will test it as soon as my battery is charged. |
| 12:55.30 | *** join/#openezx florian (n=fuchs@g228129080.adsl.alicedsl.de) |
| 12:59.50 | *** join/#openezx flyhorse|linux (n=flyhorse@116.18.197.46) |
| 13:06.46 | gmzhuo | the kernel is changed too fast :( |
| 13:07.03 | WyrM | gmzhuo: this is good, isn't it? :) |
| 13:07.25 | WyrM | sometimes it breaks stuff, but well, nothing is perfect.. |
| 13:09.21 | gmzhuo | but it's problem for products |
| 13:18.54 | tmzt | WyrM: up20 is sused for otg host on pxa? we're checking for SEOS to see if a usb host cable can be used with this device (blue angel) |
| 13:24.32 | gmzhuo | long time update and long time compiling |
| 13:30.21 | WyrM | gmzhuo: buy a q6600 and overclock it. ;) |
| 13:30.41 | WyrM | tmzt: I think you can.. |
| 13:30.46 | WyrM | tmzt: #htc-linux? |
| 13:31.26 | tmzt | he left, and doesn't have the BA with him |
| 13:31.59 | tmzt | http://www.gpsforless.co.uk/product_details.php?id=5782 |
| 13:32.10 | tmzt | this is the cable |
| 13:32.37 | tmzt | I think it connects to usb client port on the cradle connector |
| 13:35.50 | gmzhuo | still no interrupts |
| 13:37.11 | WyrM | gmzhuo: yeah, something is wrong with mainline code for interrupt. |
| 13:37.31 | WyrM | I noted that bp_rdy changes, but no interrupt is generated. |
| 13:37.45 | WyrM | I think the problem afects only some pins. |
| 13:37.59 | WyrM | as bp_wdi is working fine. |
| 13:38.36 | WyrM | I added code to print the bp_rdy state from time to time, and I see it going high/low, but still no interrupts. |
| 13:42.20 | gmzhuo | key lock is right too |
| 13:42.30 | WyrM | yeah. |
| 13:44.33 | gmzhuo | EOC (GPIO10) IS RIGHT |
| 13:44.44 | WyrM | gmzhuo: only low gpios. |
| 13:44.51 | WyrM | bp_rdy = 0 |
| 13:44.54 | WyrM | pcap = 1 |
| 13:45.02 | WyrM | see a58fbcd8ad17ddaa0c7aadbbbd20de4ebc807fa4 |
| 13:45.15 | WyrM | I think that this commit is the one that broke stuff. :) |
| 13:50.06 | gmzhuo | maybe |
| 13:50.57 | WyrM | I don't see anything else that changes gpio0/1 handling recently. |
| 13:51.18 | gmzhuo | it's a big change |
| 14:12.35 | WyrM | I think this is an ordering issue. |
| 14:13.19 | WyrM | previously GRER was set for all gpios on a pxa_init_gpio |
| 14:14.44 | tmzt | GRER? |
| 14:15.21 | WyrM | GFER/GRER |
| 14:15.39 | WyrM | FE/RE interrupt enable. |
| 14:17.46 | tmzt | and now it's not default? |
| 14:18.56 | gmzhuo | Wyrm,seems these change has been reverted? |
| 14:20.56 | gmzhuo | foget what I said |
| 14:22.16 | WyrM | hum. |
| 14:22.27 | WyrM | irq.c line 135 |
| 14:22.31 | WyrM | looks wrong. |
| 14:22.45 | WyrM | it sets the handler for all gpios. |
| 14:23.00 | WyrM | but then it calls pxa_init_low_gpio_irq() |
| 14:23.09 | WyrM | which sets the handler again for gpio0/1 |
| 14:23.46 | tmzt | it might be pxa3xx changes affecting pxa27x |
| 14:24.04 | tmzt | have you tried eric's tree? |
| 14:24.12 | WyrM | I think it is just a simple mistake.. |
| 14:24.30 | WyrM | gmzhuo: if you have some time, please, change line 135 of irq.c |
| 14:24.44 | WyrM | from PXA_IRQ(0) to PXA_IRQ(2) |
| 14:25.07 | WyrM | currently gpio0/1 are being assigned to 2 different irq_chip structs. |
| 14:25.21 | WyrM | and I think that this is the issue. |
| 14:25.49 | tmzt | if they are routed to a dedicated irq line that would make |
| 14:25.52 | tmzt | sense |
| 14:26.02 | tmzt | for the new pinmux code in 3xx |
| 14:26.21 | WyrM | tmzt: this is unrelated to pxa3xx as far as I know. |
| 14:26.28 | WyrM | it is really just a typo. :) |
| 14:26.43 | gmzhuo | I hate Marvell |
| 14:26.50 | tmzt | and the other banks have a single irq line they all share |
| 14:26.52 | tmzt | ok |
| 14:27.12 | tmzt | not they all share, but all the pins in the bank |
| 14:28.14 | WyrM | the problem is that the code is doing set_irq_chip(0, &pxa_internal_irq_chip); |
| 14:28.37 | gmzhuo | white screen |
| 14:28.38 | WyrM | and just after, it does set_irq_chip(0, &pxa_low_gpio_chip); |
| 14:29.18 | WyrM | 2 irq chips for the same gpios, makes no sense. |
| 14:29.45 | WyrM | gmzhuo: white screen caused by this change? |
| 14:29.50 | gmzhuo | yes |
| 14:31.00 | WyrM | hum. |
| 14:31.19 | WyrM | I see no reason for a white screen because of this change. |
| 14:31.21 | WyrM | weird. :) |
| 14:31.33 | tmzt | what line changed? |
| 14:31.46 | WyrM | tmzt: line 135 of irq.c |
| 14:31.58 | WyrM | from PXA_IRQ(0) to PXA_IRQ(2). |
| 14:32.21 | tmzt | don't have current git |
| 14:32.27 | tmzt | paste? |
| 14:33.26 | WyrM | http://pastebin.com/m5e9cc915 |
| 14:33.49 | WyrM | only the relevant code. |
| 14:34.19 | WyrM | its mainline code, the line that should be changed is highlighted. |
| 14:34.44 | WyrM | see that it is setting 2 irq_chips for gpio 0 and 1 with the current code. |
| 14:34.48 | WyrM | this can't be right. |
| 14:34.59 | l403 | without gnome I have no idea how to bind bluetooth in terminal ;-/ |
| 14:35.14 | WyrM | l403: for ezx? |
| 14:35.34 | l403 | yeah, with moto |
| 14:35.42 | l403 | *to moto |
| 14:35.49 | l403 | from debian on laptop |
| 14:35.59 | WyrM | on host you mean. |
| 14:36.03 | l403 | yeah |
| 14:36.21 | l403 | funny ow everyone hushes on irc when I ask |
| 14:36.30 | l403 | almost as if noone knew how |
| 14:36.51 | WyrM | I think you use hcitool/rfcomm |
| 14:37.00 | WyrM | you want to make what kind of connection? |
| 14:37.13 | l403 | I cant even make it discoverable |
| 14:37.26 | tmzt | rfcomm listen |
| 14:37.29 | l403 | I hhave everything set up for ppp |
| 14:37.37 | tmzt | withbluez 3.x or previous |
| 14:37.42 | l403 | it works when n I binf bluuetooth |
| 14:37.55 | gmzhuo | wait |
| 14:38.21 | tmzt | if you want to make it discoverable you either change hcid.conf or maybe hciconfig flags |
| 14:39.06 | l403 | UP RUNNING PSCAN ISCAN souuld be |
| 14:39.11 | WyrM | hcitool iscan |
| 14:39.12 | l403 | *should |
| 14:39.16 | WyrM | err hciconfig |
| 14:39.37 | gmzhuo | I think 135 should be PXA_IRQ(0) to PXA_IRQ(7) |
| 14:39.41 | gmzhuo | but failed |
| 14:39.50 | WyrM | why 7? |
| 14:39.56 | WyrM | I don't get it. |
| 14:40.18 | WyrM | and it would still be setting 2 irq chips for gpio0 and 1 |
| 14:40.31 | gmzhuo | 8 9 is for gpio 0&1 |
| 14:40.43 | WyrM | ? |
| 14:40.52 | WyrM | you mean.. |
| 14:41.06 | WyrM | PXA_IRQ(8) == IRQ_GPIO0 |
| 14:42.34 | gmzhuo | <6>Calibrating delay loop... |
| 14:42.42 | gmzhuo | then lost |
| 14:44.21 | l403 | ok, I have started inqiryscan on pc and phone keeps asking for pin but no matter what I enter including the pin in hcid.conf no bond is created and tries to bonnd again and again |
| 14:44.32 | tmzt | the pxa code is confusing |
| 14:44.33 | WyrM | #define PXA_IRQ(x)(PXA_ISA_IRQ_NUM + (x)) |
| 14:44.33 | WyrM | #define PXA_ISA_IRQ_NUM (0) |
| 14:44.41 | tmzt | unless low refers to low power? |
| 14:44.53 | WyrM | I can't find IRQ_GPIO0 definition :( |
| 14:45.14 | l403 | this is soo Fail |
| 14:45.37 | WyrM | :#defineIRQ_GPIO0PXA_IRQ(8) |
| 14:48.08 | WyrM | http://pastebin.com/m70016dda |
| 14:48.14 | WyrM | gmzhuo: please, try this ^ |
| 14:48.54 | gmzhuo | the same I think :) |
| 14:48.59 | gmzhuo | just compiling |
| 14:49.20 | tmzt | I think you need to disable encryption on the host |
| 14:50.04 | WyrM | well, not the same.. |
| 14:50.28 | WyrM | gmzhuo: if you change the end of the loop to 7 you will leave most irqs out. |
| 14:50.37 | WyrM | irq_nr is 34 on pxa27x |
| 14:50.58 | gmzhuo | I mean you pastin |
| 14:51.17 | gmzhuo | no white screen now |
| 14:51.26 | WyrM | ahh, you mean you came to the same conclusion? |
| 14:51.28 | WyrM | :) |
| 14:53.28 | WyrM | gmzhuo: works? |
| 14:53.31 | gmzhuo | no |
| 14:54.17 | tmzt | l403: I think you need to disable encryption on the host |
| 14:55.52 | l403 | tmzt, I did hciconf hci0 noencrypt |
| 14:55.57 | l403 | no change |
| 14:56.08 | tmzt | huh |
| 14:56.22 | tmzt | look at /etc/bluetooth/bluetooth.conf |
| 14:56.37 | tmzt | security=none I think |
| 14:58.35 | l403 | I dont have that file |
| 14:58.55 | tmzt | hcid.conf? |
| 14:58.59 | l403 | I dontt even see any rfcomm devices |
| 14:59.03 | tmzt | this is on pc also |
| 14:59.09 | tmzt | you won't |
| 14:59.38 | tmzt | what distribution/version is using? |
| 15:00.19 | l403 | the PC is debian |
| 15:02.06 | tmzt | version? |
| 15:02.12 | tmzt | dpkg -l bluez |
| 15:03.57 | l403 | bluez-utilz is 3.36-3 |
| 15:04.32 | tmzt | so you should have /etc/bluetooth/hcid.conf |
| 15:05.02 | l403 | I do |
| 15:05.14 | l403 | I have set to none now |
| 15:05.32 | l403 | restarting hcid |
| 15:05.35 | tmzt | /etc/init.d/bluetooth resart |
| 15:05.38 | tmzt | yes |
| 15:09.32 | l403 | ok, the PC is now being discoverred |
| 15:09.57 | l403 | now I need to do what the popup asking fo pin does |
| 15:10.40 | tmzt | you can add a pin manually in /var/lib/bluetooth/MAC/keys I think |
| 15:11.03 | l403 | I'll be back later |
| 15:16.00 | gmzhuo | there only once hand_edge_irq for gpio0 and no for gpio1 |
| 15:17.16 | l403 | its linkkey |
| 15:17.29 | tmzt | not linkkey |
| 15:17.47 | tmzt | for pin code |
| 15:17.59 | tmzt | please ask in #bluez-users |
| 15:30.03 | WyrM | gmzhuo: so, the interrupt works once. |
| 15:30.11 | WyrM | but a second interrupt does not work? |
| 15:30.28 | WyrM | then this is the ack() which is not working. |
| 15:30.29 | gmzhuo | Maybe I found the reson |
| 15:30.32 | gmzhuo | reson |
| 15:30.34 | WyrM | why? |
| 15:31.35 | gmzhuo | see kernel/irq/handle.c |
| 15:31.40 | gmzhuo | irq_to_desc |
| 15:32.28 | WyrM | I don't get it |
| 15:32.31 | WyrM | what is wrong? |
| 15:32.40 | gmzhuo | maybe not the reson |
| 15:32.43 | gmzhuo | reason |
| 15:32.55 | WyrM | all irqs are working. |
| 15:33.05 | WyrM | only 0/1 are not working... |
| 15:33.15 | WyrM | why the generic irq would be the problem? |
| 15:35.41 | gmzhuo | where the irq_chip be set in irq_desc? |
| 15:36.12 | *** join/#openezx l403 (n=l@85.132.159.239) |
| 15:36.41 | gmzhuo | should no problem |
| 15:52.23 | *** join/#openezx l403 (n=l@85.132.159.239) |
| 17:05.56 | *** join/#openezx muromec (n=muromec@212-178-23-142.broadband.tenet.odessa.ua) |
| 17:06.02 | muromec | hi |
| 17:06.03 | WyrM | muromec: hi :) |
| 17:06.29 | WyrM | trouble with eoc/pda_power ordering? |
| 17:06.35 | muromec | yep |
| 17:06.57 | WyrM | btw, eoc is specific to gen2. |
| 17:07.08 | WyrM | so eoc_regulator should be specific to gen2 too. |
| 17:07.19 | muromec | so i moved it to machine file |
| 17:07.50 | WyrM | not a problem for now. |
| 17:08.11 | WyrM | later it will be on ezx-eoc.c but it doesn't really matter... |
| 17:08.46 | WyrM | im looking at how the i2c bus platform_device gets registered. |
| 17:08.55 | WyrM | I had a similar problem with the SPI bus. |
| 17:09.04 | muromec | hm |
| 17:09.17 | WyrM | because mci/udc was being initialized before the SPI bus. |
| 17:09.26 | WyrM | and it depends on the pcap driver.. |
| 17:10.34 | muromec | i moved platform_device_register(&power_supply); to the end of function |
| 17:10.43 | muromec | but didn`t help |
| 17:10.55 | WyrM | yeah, this just registers the p_device. |
| 17:11.06 | WyrM | it doesn't guarantee the p_driver ordering. |
| 17:11.12 | WyrM | which is what matters. |
| 17:11.15 | muromec | damm |
| 17:26.46 | WyrM | muromec: the i2c subsystem abstracts the platform_device creation.. :( |
| 17:27.07 | WyrM | this makes it hard to get a pointer to the eoc platform_device. |
| 17:28.31 | muromec | damm |
| 17:29.46 | WyrM | but I think you can make the pda_power platform_device child of the i2c bus itself. |
| 17:29.48 | muromec | really my problem is pda_poer |
| 17:29.53 | muromec | not i2c |
| 17:30.03 | WyrM | not really ;) |
| 17:30.14 | WyrM | you can easily set the pda_power parent. |
| 17:30.30 | WyrM | as it uses standard platform_device_register (or add) |
| 17:30.42 | WyrM | but you can't get the parent pointer to set it to. |
| 17:30.46 | tmzt | should it be an i2c chip |
| 17:30.50 | WyrM | because of i2c abstraction. |
| 17:31.03 | tmzt | or should you have an eoc/pcap bus |
| 17:31.10 | WyrM | tmzt: it is an i2c_device |
| 17:34.16 | muromec | if i set .parent pointer to eoc_regulator it can help? |
| 17:35.02 | WyrM | muromec, add .parent = &pxa_device_i2c->dev; |
| 17:35.31 | WyrM | you will probably need to add an extern struct platform_device pxa_device_i2c; too. |
| 17:35.52 | WyrM | and this will make it child of the bus. |
| 17:35.57 | WyrM | not of the chip itself. |
| 17:36.05 | WyrM | so, its not correct either. :) |
| 17:36.40 | muromec | i`l try |
| 17:36.51 | tmzt | can probe do something like EAGAIN? |
| 17:37.07 | WyrM | tmzt: I think no. :/ |
| 17:37.41 | WyrM | linux is very broken when you need to deal with platform_device/driver ordering. |
| 17:38.10 | WyrM | broken because of excessive abstraction done by subsystems in my opinion. |
| 17:38.15 | tmzt | I think platform-bus is intended for things whose resources are always available |
| 17:39.15 | tmzt | and other things should use a different bus |
| 17:39.27 | tmzt | i2c host is always there |
| 17:39.35 | tmzt | i2c chips are not |
| 17:41.07 | WyrM | tmzt: so, you think that pxa_device_i2c, pxa_device_spi, etc.. shouldn't be platform_devices? |
| 17:41.39 | WyrM | they are all p_devices, set by mach-pxa/devices.c |
| 17:42.07 | tmzt | I said they should be |
| 17:42.22 | tmzt | i2c host is always there |
| 17:42.30 | WyrM | and as it is done on devices.c it is impossible for the board code to set mci to be the child of spi for example. |
| 17:42.46 | WyrM | and we need it, because mci probe wants to set the card voltage. |
| 17:42.53 | tmzt | mci is mmc isn't it? |
| 17:43.05 | WyrM | yes |
| 17:43.22 | WyrM | we need spi/pcap to set the card voltage. |
| 17:43.53 | WyrM | but devices.c (pxa_set_mci_info), doesn't allow us to set it as a child of the pcap driver.. |
| 17:44.02 | tmzt | mmc layer wants to set that? |
| 17:44.12 | WyrM | yes. |
| 17:44.15 | tmzt | not the mci driver? |
| 17:44.21 | WyrM | same with the UDC. |
| 17:44.35 | tmzt | or you give it those ops through pdata? |
| 17:44.40 | muromec | WyrM: kernel panic again |
| 17:44.44 | WyrM | but with udc it is the UDC driver. |
| 17:44.49 | WyrM | mmc it is the core itself. |
| 17:44.54 | tmzt | huh? |
| 17:45.48 | WyrM | tmzt: no, you are right. |
| 17:46.02 | tmzt | how can it possibly be probing a card before pcap/eoc is ready? |
| 17:46.10 | WyrM | we pass it via platform_data to the pxamci driver. |
| 17:46.30 | WyrM | static struct pxamci_platform_data ezx_mci_platform_data = |
| 17:46.38 | WyrM | .setpower = ezx_mci_setpower |
| 17:46.52 | WyrM | but I can't set pxamci parent! |
| 17:47.23 | WyrM | anyway, I hacked a pxa_set_mci_parent on devices.c |
| 17:47.36 | WyrM | so now I can set the pxamci parent. |
| 17:47.49 | WyrM | but I can't get a pointer to the pcap platform_device. |
| 17:48.17 | tmzt | extern? |
| 17:48.27 | tmzt | it's static isn't it |
| 17:48.41 | WyrM | because it is abstracted by the spi subsystem, created from the spi_board_info struct |
| 17:50.09 | WyrM | tmzt: what? |
| 17:50.18 | WyrM | the pcap platform_device? |
| 17:50.38 | WyrM | I think its created with platform_device_alloc. |
| 17:51.15 | WyrM | anyway, I got sick with this, so I made MCI/UDC childs of the SPI platform_device. |
| 17:51.25 | WyrM | instead of the pcap platform device as it should be. |
| 17:51.44 | WyrM | and even to make them childs of the SPI, I had to hack devices.c. |
| 17:55.12 | tmzt | why is it alloced? |
| 17:56.10 | tmzt | is parent used for this? is it a pointer |
| 17:56.37 | tmzt | I thought parent was for containers or is that something else |
| 17:57.13 | tmzt | no |
| 17:58.50 | WyrM | .parent is a pointer to the parents struct device isn't it? |
| 17:59.31 | tmzt | not string? |
| 18:00.09 | tmzt | your right |
| 18:00.14 | WyrM | heh |
| 18:00.20 | tmzt | just gitgrepd it |
| 18:00.25 | WyrM | if it was a string it would be much easier... |
| 18:00.34 | WyrM | ;) |
| 18:01.35 | tmzt | but why are you allocing the pdev? |
| 18:01.44 | tmzt | I think that's for busses |
| 18:05.53 | tmzt | interesting, set-pxa-fb-parent (struct device *parent-dev) |
| 18:06.25 | WyrM | tmzt: because I can't get pcap's struct device pointer. |
| 18:06.51 | WyrM | so I made mmc/udc child of the spi bus. |
| 18:07.01 | tmzt | which is an i2c chip? |
| 18:07.06 | WyrM | spi chip |
| 18:07.21 | tmzt | ok |
| 18:07.30 | WyrM | abstracted by set_spi_board_info |
| 18:09.14 | WyrM | the platform_device/driver model is good, it works fine. But abstraction done by subsystems and by platforms makes it very hard to do proper ordering.. :/ |
| 18:09.47 | tmzt | what is spi-match-device? |
| 18:10.20 | WyrM | its not exported |
| 18:10.38 | WyrM | and its their own version of platform_device_match... :) |
| 18:11.20 | WyrM | drivers/base/platform.c, platform_match(). |
| 18:13.04 | tmzt | do you know chipselect? |
| 18:13.36 | tmzt | bus fond device by name |
| 18:13.46 | WyrM | tmzt: ahh, I could make it child of the pcap driver by using spi_alloc_device instead of spi_register_board_info... |
| 18:13.56 | tmzt | find |
| 18:14.01 | tmzt | yeah |
| 18:14.22 | tmzt | and spi add device |
| 18:14.29 | WyrM | I will change it to do this later.. :) |
| 18:15.00 | WyrM | better than be the child of the bus. |
| 18:15.05 | WyrM | but how about i2c? |
| 18:15.25 | WyrM | (muromec already lost his patience and left, but anyway....) :) |
| 18:22.31 | tmzt | same I think |
| 18:23.54 | tmzt | i2c-new-device |
| 18:25.38 | WyrM | hum. |
| 18:25.43 | WyrM | I don't think it will work. |
| 18:25.56 | WyrM | see the comment on i2c-boardinfo.c |
| 18:26.04 | WyrM | * The I2C devices will be created later, after the adapter for the relevant |
| 18:26.04 | WyrM | <PROTECTED> |
| 18:26.05 | WyrM | <PROTECTED> |
| 18:26.05 | WyrM | <PROTECTED> |
| 18:26.05 | WyrM | <PROTECTED> |
| 18:34.15 | tmzt | not sure I understand |
| 18:34.47 | tmzt | that's for boardinfo which is registered before the bus |
| 18:35.12 | tmzt | and then bound to a platform-device later |
| 18:35.32 | tmzt | using i2c new device I assume, I'll check |
| 18:36.52 | WyrM | yes. |
| 18:40.06 | tmzt | I'm saying you should be able to call that yourself |
| 18:40.21 | WyrM | call i2c_new_device? |
| 18:40.59 | WyrM | i2c_new_device(struct i2c_adapter *adap, |
| 18:41.12 | WyrM | what should I pass as "adap" ? ;) |
| 18:43.19 | WyrM | if I understand this thing, at the board_init() the i2c_adapter is not registered yet. |
| 18:46.36 | WyrM | back to the gpio0/1 interrupt breakage. |
| 18:46.43 | WyrM | I think its more important. |
| 18:51.10 | tmzt | yeah |
| 18:51.30 | tmzt | no idea what happened to that? |
| 18:51.42 | WyrM | eric miao broke it. |
| 18:51.57 | WyrM | im sure that the commit I pointed earlier is the cause. |
| 18:52.08 | WyrM | and I already found a little mistake.. |
| 18:52.17 | WyrM | but gmzhuo said it was still not working. |
| 18:52.45 | WyrM | I will test it now and continue debugging it. |
| 18:57.35 | tmzt | do you have a url for that commitdiff? |
| 18:58.08 | WyrM | a58fbcd8ad17ddaa0c7aadbbbd20de4ebc807fa4 |
| 18:58.25 | WyrM | I used git-log :) |
| 18:59.29 | WyrM | indeed, all GPIO-l IRQS are broken. |
| 18:59.37 | WyrM | and my fix has no effect. :( |
| 19:02.25 | tmzt | do pxa docs say anything about internal routing? |
| 19:03.22 | WyrM | what do you mean? |
| 19:03.32 | WyrM | I think that 0 and 1 are "special". :) |
| 19:04.06 | tmzt | yes |
| 19:04.58 | tmzt | looking at old pxa init gpio |
| 19:05.29 | tmzt | but all banks have 32? |
| 19:06.29 | tmzt | well, on msm each bank of gpios has an irq |
| 19:07.04 | tmzt | so you get an interrupt and have to find the gpio in order to call the correct handler |
| 19:07.44 | tmzt | we know this because haret only reported the raw (muxed) irqs |
| 19:08.20 | tmzt | and you had to read the regs to demux it |
| 19:09.12 | tmzt | 0 and 1 are not muxed on pxa |
| 19:09.21 | tmzt | but still in gedr |
| 19:12.00 | tmzt | is the second chip called muxed-gpio or internal now? |
| 19:12.05 | WyrM | internal |
| 19:14.39 | tmzt | so the old code didn't overlap? |
| 19:15.30 | WyrM | the old code was moved, but with some changes... |
| 19:19.32 | tmzt | plat-pxa? |
| 19:20.29 | tmzt | http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-02/msg08551.html |
| 19:21.40 | tmzt | wrong ne |
| 19:21.43 | tmzt | one |
| 19:22.08 | tmzt | http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-02/msg08551.html |
| 19:22.35 | WyrM | ? |
| 19:22.36 | WyrM | same |
| 19:23.03 | tmzt | , |
| 19:23.28 | tmzt | http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-02/msg08548.html |
| 19:36.13 | tmzt | http://git.kernel.org/?p=linux/kernel/git/ycmiao/pxa-linux-2.6.git;a=summary |
| 19:38.33 | tmzt | old? |
| 19:42.54 | *** join/#openezx WyrM1 (n=wyrm@20158135106.user.veloxzone.com.br) |
| 19:45.16 | WyrM1 | I still don't get what you want me to see. |
| 19:45.27 | WyrM1 | mach-mmp/pxa168 |
| 19:45.42 | WyrM1 | and ycmiao tree summary.. |
| 19:48.54 | tmzt | http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git |
| 19:49.06 | tmzt | trying to find current pxa tree |
| 19:49.25 | tmzt | the point wasn't pxa168 it was plat-pxa |
| 19:49.50 | tmzt | but I guess the kernel your working with doesn't have that |
| 19:50.01 | WM | im working on mainline. |
| 19:50.19 | WM | and it has plat-pxa. |
| 19:50.19 | tmzt | so no? |
| 19:50.24 | tmzt | yes |
| 19:50.25 | tmzt | ok |
| 19:50.42 | tmzt | what do you mean gpio code was moved |
| 19:50.45 | WM | but gpio is working. |
| 19:50.54 | WM | no, irq code was moved. |
| 19:51.00 | WM | from gpio.c to irq.c |
| 19:51.01 | WM | :) |
| 19:51.06 | tmzt | oh |
| 19:51.12 | WM | but there were some changes.. |
| 19:51.16 | WM | not just the move. |
| 19:51.22 | WM | and GPIO is working fine. |
| 19:51.32 | tmzt | which is why I couldn't find it in irq.c |
| 19:51.32 | WM | I can see level changes on gpio0/1. |
| 19:51.36 | WM | but no interrupts! |
| 19:52.29 | tmzt | if your right about gpio chip it's not registering |
| 19:52.32 | tmzt | 0 and 1 |
| 19:52.42 | WM | it is |
| 19:52.48 | WM | I can see on /proc/interrupts |
| 19:52.58 | WM | the correct gpio chip, GPIO-l |
| 19:53.07 | tmzt | ok |
| 19:53.08 | WM | for the others its just GPIO |
| 19:53.16 | tmzt | right |
| 19:53.30 | tmzt | can you add a printk to demux? |
| 19:55.25 | WM | but its not a chained handler. |
| 19:55.31 | WM | there is no demux on gpio0/1 |
| 19:55.38 | WM | others are working fine :) |
| 19:56.02 | tmzt | so it's pxa regs then? |
| 19:56.11 | tmzt | not set correctly |
| 19:56.25 | WM | probably. |
| 19:56.58 | tmzt | and those are still in init-gpio? |
| 19:57.15 | WM | no |
| 19:57.32 | WM | on pxa_init_irq() -> pxa_init_low_gpio_irq |
| 19:57.37 | WM | both on irq.c |
| 20:04.12 | WyrM | hum. |
| 20:04.40 | WyrM | I added a printk to pxa_set_low_gpio_type() |
| 20:04.44 | WyrM | its never called. |
| 20:05.50 | tmzt | and git grep? |
| 20:06.14 | WyrM | static struct irq_chip pxa_low_gpio_chip = { |
| 20:06.14 | WyrM | <PROTECTED> |
| 20:06.32 | WyrM | it should be used when set_irq_type() is called. |
| 20:08.27 | WyrM | we call it in 2 places on our code.. |
| 20:08.40 | WyrM | both with gpio_to_irq() |
| 20:08.49 | WyrM | maybe gpio_to_irq is wrong.. |
| 20:11.11 | WyrM | no, this is correct. |
| 20:16.58 | WyrM | oh, sorry, I see the printk. |
| 20:17.09 | WyrM | Im blind :/ |
| 20:20.07 | tmzt | ok |
| 20:21.02 | tmzt | the old gpio.c says 0 and1 should always be masked |
| 20:21.27 | tmzt | is that in the new one |
| 20:23.46 | WyrM | - GPIO_IRQ_mask[0] = 3; |
| 20:23.53 | WyrM | no, I don't see this on the new code |
| 20:24.00 | tmzt | why does low have it's own irq-type? |
| 20:24.26 | WyrM | because 0/1 are special. |
| 20:24.29 | WyrM | not muxed. |
| 20:24.52 | WyrM | have their own bits on ICMR/ICLR |
| 20:25.25 | WyrM | all others share a single ICMR/ICLR bit |
| 20:25.38 | tmzt | the old code just sets grer/gfer |
| 20:26.04 | tmzt | in pxa-gpio-irq-type |
| 20:27.02 | WyrM | yes. |
| 20:27.12 | WyrM | the type doesn't seem to be the problem. |
| 20:28.25 | WyrM | pxa_set_low_gpio_type: 8 0 R00000001 F00002000 |
| 20:28.25 | WyrM | pxa_set_low_gpio_type: 9 1 R00000002 F00002008 |
| 20:28.32 | tmzt | and the mask? |
| 20:28.36 | WyrM | bit 1 of RE is lost? |
| 20:28.39 | WyrM | weird. |
| 20:29.00 | tmzt | what? |
| 20:29.02 | WyrM | I don't remember disabling this interrupt.. |
| 20:29.42 | WyrM | 8 = irq number, 0 = gpio number, R=GRER F=GFER |
| 20:30.21 | WyrM | I don't know why GRER=0x1 is missing on the second GRER read. |
| 20:30.28 | *** join/#openezx rubberducky (n=rubberdu@83.101.31.19) |
| 20:30.30 | rubberducky | tmzt, hi |
| 20:30.37 | tmzt | hello |
| 20:30.43 | tmzt | I have the address |
| 20:30.53 | rubberducky | ok, i've telnetted into haret, what do i do now? |
| 20:31.59 | tmzt | print "%8x" p2v(0x40600020) |
| 20:32.07 | tmzt | print "%08x" p2v(0x40600020) |
| 20:32.22 | tmzt | second one |
| 20:32.24 | rubberducky | ae600020 |
| 20:32.26 | rubberducky | ah ok |
| 20:32.28 | rubberducky | one sec |
| 20:32.43 | rubberducky | ae600020 |
| 20:32.47 | tmzt | sorry |
| 20:32.58 | rubberducky | that's the result for both 1 and 2.. |
| 20:33.15 | tmzt | pd 0x40600020 4 |
| 20:33.31 | rubberducky | 40600020 | 00000000 | .... |
| 20:33.57 | tmzt | up2ocr is 0??? |
| 20:34.00 | tmzt | no seos |
| 20:34.19 | rubberducky | what? |
| 20:34.21 | tmzt | but is that you usb port |
| 20:34.36 | rubberducky | i don't know |
| 20:34.51 | tmzt | your plugged in with cradle/usb now? |
| 20:35.14 | rubberducky | yes |
| 20:35.48 | tmzt | pd 0x40600000 4 |
| 20:36.28 | rubberducky | 40600000 | 00000003 | .... |
| 20:36.55 | tmzt | udc active/udc enable |
| 20:37.28 | tmzt | and 0 is active interface? |
| 20:37.45 | rubberducky | udc |
| 20:37.54 | rubberducky | is not a recognized command |
| 20:38.19 | tmzt | pd 0x40600024 4 |
| 20:38.21 | WyrM | what is this? usb host for htc? |
| 20:38.28 | tmzt | yeah |
| 20:38.41 | rubberducky | 40600024 | 00000009 | .... |
| 20:38.45 | tmzt | no, udc |
| 20:38.50 | rubberducky | WyrM, for the Blue Angel |
| 20:39.00 | tmzt | but he wants to use it as host with powered cable |
| 20:39.17 | tmzt | if there's no SEOS that should work? |
| 20:39.23 | rubberducky | tmzt, what do i do with udc, it's not a command? |
| 20:39.25 | rubberducky | SEOS? |
| 20:39.29 | tmzt | nothing |
| 20:39.43 | rubberducky | sorry, i really don't seem to know a lot about this subject... |
| 20:40.32 | tmzt | WyrM: if there's no SEOS that should work? |
| 20:40.38 | tmzt | but he wants to use it as host with powered cable |
| 20:41.00 | rubberducky | http://www.gpsforless.co.uk/product_details.php?id=5782 |
| 20:41.03 | rubberducky | this is the product |
| 20:42.15 | tmzt | and the port it connects to is the one he's using now as udc, assuming it's the same pins |
| 20:48.06 | rubberducky | ? |
| 20:49.34 | WyrM | let me check the manual. |
| 20:49.43 | WyrM | what is the default for the device? |
| 20:49.48 | WyrM | default SEOS? |
| 20:50.12 | tmzt | I think it's 0 |
| 20:50.25 | tmzt | up2ocr is 0 |
| 20:50.49 | WyrM | SEOS(0) is OFF. |
| 20:51.03 | WyrM | I mean, the default with the usb cable connected, and usb working. |
| 20:51.26 | tmzt | it is |
| 20:51.36 | WyrM | hum.. |
| 20:51.42 | tmzt | telnet is over usb |
| 20:51.57 | WyrM | then it is using the builtin transceiver.. |
| 20:52.36 | WyrM | with the builtin transceiver you don't need to change SEOS for host operation.. |
| 20:53.02 | WyrM | how is HXOE and HXS configured on the default configuration? |
| 20:53.22 | WyrM | HXOE=1 and HXS=0? |
| 20:54.31 | tmzt | pd 0x40600020 4 |
| 20:54.39 | tmzt | rubberducky: |
| 20:54.56 | rubberducky | 40600020 | 00000000 | .... |
| 20:55.53 | WyrM | both 0. |
| 20:55.58 | tmzt | he doesn't have the cable now |
| 20:56.19 | tmzt | and otg is not supported in wm I think |
| 20:56.45 | tmzt | so why would usb2 host be active? |
| 20:57.03 | WyrM | its not. |
| 20:57.31 | tmzt | we were just wondering if patching ba.c to enable it might work |
| 20:57.35 | WyrM | for usb host with the builtin transceiver, HXS needs to be 1 |
| 20:58.07 | tmzt | he wanted know before buying the cable |
| 21:01.26 | WyrM | how is pull up controled on blueangel? gpio? |
| 21:03.17 | tmzt | probably haven't lloked in a while |
| 21:04.13 | WyrM | as UP2OCR is all 0, it is not using the builtin D+/D- PU/PD. |
| 21:04.59 | WyrM | so I think you should disable the PD via gpio and then use the builtin resistors for host operation. |
| 21:07.51 | WyrM | im not sure, but I guess that the correct UP2OCR for host operation on blueangel would be HXS | DPPDE |
| 21:08.29 | tmzt | detect, puen |
| 21:09.46 | WyrM | puen is gpio? |
| 21:10.10 | tmzt | yes |
| 21:10.12 | WyrM | and I guess you have no pden gpio, right? ;) |
| 21:11.09 | tmzt | struct pxa2xx_udc_gpio_info blueangel_udc_info = { |
| 21:11.09 | tmzt | .detect_gpio = {&pxagpio_device.dev, GPIO_NR_BLUEANGEL_USB_DETECT_N}, |
| 21:11.09 | tmzt | .detect_gpio_negative = 1, |
| 21:11.09 | tmzt | .power_ctrl = { |
| 21:11.09 | tmzt | .power_gpio = { &blueangel_asic3.dev, ASIC3_GPIOC_IRQ_BASE + GPIOC_USB_PUEN}, |
| 21:11.12 | tmzt | .power_gpio_neg = 1, |
| 21:11.15 | tmzt | }, |
| 21:11.18 | tmzt | }; |
| 21:11.46 | tmzt | 2.6.21-hh20 |
| 21:12.42 | tmzt | no pden? what is that for? |
| 21:13.05 | WyrM | pull down |
| 21:14.12 | rubberducky | and:P? |
| 21:15.06 | WyrM | the device was not designed for host operation... But if you disable the external pullup, and then use the builtin pull down it might work.. :) |
| 21:15.19 | WyrM | I think you have to test it to be sure.. :) |
| 21:15.27 | tmzt | thank you |
| 21:16.32 | rubberducky | how do i test? |
| 21:16.50 | tmzt | rubberducky: I don't think you'll get a better answer without trying it |
| 21:17.05 | rubberducky | so buy cable? |
| 21:17.42 | tmzt | without the power ijector? I don't think you can really test |
| 21:18.11 | WyrM | also, maybe the cable has a pull down by itself.. |
| 21:18.20 | rubberducky | whats pulldown |
| 21:18.23 | WyrM | are there any reports of this cable working? |
| 21:18.32 | rubberducky | i've searched |
| 21:18.44 | rubberducky | but i havent found |
| 21:18.51 | rubberducky | blueangel is listed as supported |
| 21:19.01 | tmzt | freerunner has something similar |
| 21:19.15 | WyrM | I think you can make a cable like this.. |
| 21:19.30 | WyrM | arne: ping. |
| 21:19.52 | WyrM | arne made usb host cable for ezx. |
| 21:20.07 | WyrM | I think that the same cable would work for blueangel. |
| 21:20.13 | rubberducky | what is ezx? |
| 21:20.21 | tmzt | with ispxx or pxa? |
| 21:20.30 | WyrM | tmzt: PCAP |
| 21:20.42 | tmzt | pxa/pcap? |
| 21:20.57 | WyrM | but for the cable, it shouldn't matter |
| 21:21.04 | WyrM | yes |
| 21:21.22 | tmzt | ba doesn't have miniusb it has a custom connecter |
| 21:21.26 | rubberducky | uhu |
| 21:21.39 | WyrM | but he has a device cable.. |
| 21:21.52 | WyrM | you just need to buy an adaptor. |
| 21:22.03 | WyrM | male/female |
| 21:22.06 | tmzt | so a to b plus power? |
| 21:22.16 | tmzt | a to a |
| 21:22.21 | WyrM | ohh, yeah, plus power |
| 21:22.36 | WyrM | a male to a female. |
| 21:25.23 | rubberducky | so..? |
| 21:26.17 | WyrM | no, sorry. a female / a female. |
| 21:26.28 | rubberducky | ??? |
| 21:26.50 | WyrM | rubberducky: your device cable.. |
| 21:26.52 | rubberducky | yes |
| 21:26.54 | rubberducky | usb? |
| 21:26.59 | WyrM | has an A male connector right? |
| 21:27.47 | rubberducky | uhm |
| 21:27.58 | rubberducky | just standars usb male |
| 21:28.25 | tmzt | the computer side is called A |
| 21:28.32 | tmzt | the device side B |
| 21:28.38 | rubberducky | ah ok |
| 21:28.47 | rubberducky | then yes |
| 21:28.52 | rubberducky | a is usb male |
| 21:29.35 | WyrM | tmzt: no. |
| 21:29.49 | WyrM | B is the printer-like connector. |
| 21:29.59 | rubberducky | the more rectangular one? |
| 21:30.20 | rubberducky | the cable is male usb on pc side, and just goed into the cradle, no connector |
| 21:30.20 | WyrM | the square one is B. The standard is A. |
| 21:30.29 | WyrM | there is female and male for both kinds. |
| 21:31.06 | rubberducky | ok |
| 21:31.12 | rubberducky | so, can i make this cable myself then? |
| 21:32.46 | WyrM | http://i8.ebayimg.com/03/i/000/e6/52/a19e_1.JPG |
| 21:32.48 | tmzt | WyrM: well, at one point those were A and B |
| 21:32.54 | WyrM | ^ Afemale to Afemale |
| 21:33.46 | tmzt | there is now miniB and microB |
| 21:34.01 | tmzt | as well as miniA and miniAB |
| 21:34.13 | WyrM | too much cables. |
| 21:34.14 | WyrM | lol |
| 21:34.15 | rubberducky | so what's the best guess? make the cable? |
| 21:34.15 | WyrM | :) |
| 21:34.24 | WyrM | yes. |
| 21:34.31 | WyrM | arne is off. |
| 21:34.32 | tmzt | miniAB is a socket |
| 21:34.34 | rubberducky | and will i use the cradle? |
| 21:34.46 | WyrM | he can give you instructions on how to build it. |
| 21:35.02 | rubberducky | and do you guys think usb host will work on the BA? |
| 21:35.37 | WyrM | rubberducky: I think it will. |
| 21:35.58 | rubberducky | and will it use the cradle inbetween, or where will i get a blueangel connector? |
| 21:36.26 | WyrM | ahh, there is a craddle. :/ |
| 21:36.33 | rubberducky | yes |
| 21:36.41 | WyrM | then it is better to just buy the cable ;) |
| 21:36.57 | tmzt | and a battery of some kind |
| 21:37.07 | rubberducky | to power the host? yes |
| 21:37.22 | rubberducky | so i just plug in the cable |
| 21:37.23 | tmzt | some openmoko users have that |
| 21:37.34 | rubberducky | and i can use host in wince with devices that support it |
| 21:37.58 | rubberducky | and i can run linux (build custom kernel with host function?) and connect every usb device i want? |
| 21:38.02 | tmzt | ask cmonex about that |
| 21:38.21 | rubberducky | where do i find him? |
| 21:38.30 | rubberducky | can i attach a usb hub to the cable? |
| 21:38.31 | tmzt | in the other channel |
| 21:38.46 | WyrM | rubberducky: yes, if usb works you can use any device supported by linux. |
| 21:38.49 | tmzt | with powered hub you don't need power |
| 21:38.56 | WyrM | *if the cable works. |
| 21:38.59 | rubberducky | uhu |
| 21:39.08 | tmzt | and only 1.1 speeds |
| 21:39.17 | rubberducky | but if i want to use it on the road, i need a battery that powers the hub probably |
| 21:39.25 | WyrM | rubberducky: yes |
| 21:39.46 | rubberducky | sounds really nice:-) |
| 21:39.57 | rubberducky | high powered USB wifi device |
| 21:40.04 | rubberducky | crack wep |
| 21:40.08 | rubberducky | (my own ofcourse) |
| 21:40.27 | WyrM | ;) |
| 21:40.40 | rubberducky | but the card needs 2 usb connections |
| 21:40.46 | WyrM | BA has an SD sized slot? |
| 21:40.50 | WyrM | or TF? |
| 21:40.53 | rubberducky | SD |
| 21:40.54 | WyrM | for the memory card? |
| 21:41.04 | rubberducky | but SDIO to usb host doesn't exist |
| 21:41.31 | WyrM | you can use sdio wifi. :) |
| 21:41.47 | tmzt | oh, sdio wifi |
| 21:41.57 | rubberducky | i'll have a look at that to |
| 21:42.05 | rubberducky | an interface that supports monitor/injection |
| 21:42.08 | rubberducky | and ofcourse g |
| 21:42.13 | tmzt | would probably say libtertas |
| 21:42.32 | tmzt | you already have acx100 that doesn't work right |
| 21:42.38 | rubberducky | injection works |
| 21:42.40 | rubberducky | but it's a b card |
| 21:42.54 | rubberducky | and i would like to run a test with airpwn |
| 21:43.03 | rubberducky | but bcards can't sniff g data |
| 21:43.08 | rubberducky | on most occasions |
| 21:43.17 | rubberducky | it worked in ubuntu with iwlwifi drivers for the victim pc |
| 21:43.24 | rubberducky | but i never figured out why.. |
| 21:44.13 | tmzt | you probably had a b device connected |
| 21:44.54 | tmzt | WyrM: figure out the gpio problem? |
| 21:45.02 | rubberducky | yeah |
| 21:45.11 | rubberducky | but still then it never worked in windows XP on the same laptop |
| 21:45.18 | rubberducky | with b device connected |
| 21:45.57 | rubberducky | does a router send all it's packets at B speed as soon as a b device is connected? |
| 21:46.33 | tmzt | ezx are motorola phones, mostly the older ones |
| 21:48.30 | tmzt | I think so |
| 21:52.13 | WyrM | tmzt: no. :/ |
| 21:57.58 | *** join/#openezx agd5f (n=alex@c-69-143-4-28.hsd1.va.comcast.net) |
| 21:57.58 | *** join/#openezx methril|fix_part (n=Methril@213.27.233.98) |
| 21:57.58 | *** join/#openezx Dominus (i=unices@195-241-252-199.ip.telfort.nl) [NETSPLIT VICTIM] |
| 22:00.35 | tmzt | the gpio thing? |
| 22:29.58 | WyrM | tmzt: well, its not a gpio thing. |
| 22:30.03 | WyrM | as the gpios are working. |
| 22:30.15 | WyrM | its an interrupt thing ;) |
| 22:34.43 | tmzt | yeah |
| 22:36.09 | tmzt | but I meant only to seperate it from the wifi thing and the motorola thing |
| 23:36.31 | *** join/#openezx Rubberducky (n=rubber@83.101.31.19) |
| 23:36.35 | Rubberducky | arne, hi? |
| 23:37.32 | Rubberducky | tmzt, to use the USB host in linux, will that be hard? |
| 23:38.45 | WyrM | use is easy. |
| 23:38.53 | WyrM | hard is to get it working ;) |
| 23:38.59 | Rubberducky | hehe |
| 23:39.04 | Rubberducky | and will it be really hard? |
| 23:39.10 | WyrM | no. |
| 23:39.14 | WyrM | just joking. |
| 23:39.23 | Rubberducky | cause it;ll cost about 30dollars to get it to me.. |
| 23:39.36 | WyrM | if the hardware really supports it, its just a little bit of hacking. |
| 23:39.40 | Rubberducky | so as i understand it, kernel patch? |
| 23:40.19 | WyrM | yes, probably less than 5 lines of code for a quick hack. |
| 23:40.44 | WyrM | more if you want to runtime switch between device/host, but also not that hard. |
| 23:41.31 | Rubberducky | ok |
| 23:41.44 | Rubberducky | i hope the hardware supports it |
| 23:41.45 | Rubberducky | any way to find it out beforehand? |
| 23:42.03 | WyrM | no :/ |
| 23:42.33 | Rubberducky | damn |
| 23:42.59 | tmzt | s3c-uhci kernel hasthe sysfs stuff |
| 23:44.01 | Rubberducky | what? |
| 23:48.18 | Rubberducky | then if i connect a battery powered usb hub to it i can do anything... |
| 23:56.49 | sabrod | On "arne/stefan"'s USB host cable, there is no pull down, Power is separated too, connected to both sides. |
| 23:57.10 | sabrod | just reverse engineered the cable :) : Say thanks ;) |
| 23:57.33 | WyrM | thanks! |
| 23:57.57 | sabrod | smd soldering a female mini usb was hard as hell ;) |
| 23:58.49 | sabrod | Heh, it's kind from stefan to have send this cable to me! |
| 23:58.55 | WyrM | you should have used hot air. :) |
| 23:59.33 | sabrod | Well, I prefer my hands not to be on the hot air direction. :) |
