**** BEGIN LOGGING AT Fri Jun 28 02:59:58 2013
Jun 28 07:31:43 <vvu> av500: ping
Jun 28 07:33:04 <av500> yo
Jun 28 07:33:31 <vvu> made u-boot to speak with android, a hacky way but now i think i know what is happening
Jun 28 07:33:52 <av500> ok, tell me :)
Jun 28 07:34:00 <vvu> u-boot did not receive the ack for RNDIS connection to put the interface in up state
Jun 28 07:34:42 <vvu> in drivers/usb/gadget/ether.c line 1849
Jun 28 07:34:45 <vvu> this is u-boot code
Jun 28 07:34:52 <vvu> the function rndis_control_ack_complete
Jun 28 07:35:04 <vvu> the android kernel does not finish the ack procedure i think
Jun 28 07:35:13 <vvu> and u-boot hangs there and timer expires
Jun 28 07:35:27 <av500> ok
Jun 28 07:35:36 <vvu> i tricked u-boot to think from the start to think that the ack has been done, but not a good way
Jun 28 07:35:39 <av500> but why dont you see the request for the ack in java?
Jun 28 07:36:03 <av500> and what is the ack?
Jun 28 07:36:49 <av500> ah
Jun 28 07:36:51 <vvu> have no clue, how is the data processed? my app starts and tries to read from the endpoint, but if data is received by the android device before android app starts? what happens to it?
Jun 28 07:36:54 <av500> is it a different end point?
Jun 28 07:36:55 <vvu> it is discarded?
Jun 28 07:37:01 <av500> interrupt vs bulk?
Jun 28 07:37:11 <av500> do you see 2 end points?
Jun 28 07:37:14 <av500> in java?
Jun 28 07:37:15 <vvu> ds2 thinks should send the ack on the same bulk enpoint
Jun 28 07:37:36 <vvu> i see 3 eps, ep0 for enumeration and 2 bulk ep for communication
Jun 28 07:37:41 <av500> the comments in ether.c talk about interrupt endpoint
Jun 28 07:38:16 <vvu> ep0 is only one way
Jun 28 07:38:22 <vvu> from device to host
Jun 28 07:39:53 <av500> http://developer.android.com/reference/android/hardware/usb/UsbEndpoint.html
Jun 28 07:39:59 <vvu> at least now we have a clue what is happening wrong, or at least we think
Jun 28 07:40:00 <av500> USB_ENDPOINT_XFER_INT
Jun 28 07:40:50 <av500> vvu: so, in java, do you see the INT endpoint?
Jun 28 07:41:11 <vvu> did not check, lemme wake up a bit and rig phone+board and check :)
Jun 28 07:41:15 <av500> ok
Jun 28 07:41:24 <av500> also, with libusb, do you see int endpoints?
Jun 28 07:41:34 <av500> of course, its hard since your linux kernel has rndis
Jun 28 07:41:37 <vvu> pfff did not even think about that
Jun 28 07:41:44 <vvu> i try to ditch all libusb stuff
Jun 28 07:41:47 <av500> np
Jun 28 07:41:50 <av500> check the java side
Jun 28 07:42:54 <vvu> if i see that ep i should read from it right ?
Jun 28 07:43:23 <av500> /  RNDIS specifies 2 endpoints, EP0 & notification element (interrupt)
Jun 28 07:43:28 <av500> http://powerdevice.googlecode.com/svn/trunk/USB_s3c2443_oal/RNDIS/rndis.c
Jun 28 07:43:49 <vvu> oh ok
Jun 28 07:44:28 <vvu> anyway something is happening wrong in the android kernel. also i want to ditch using the rndis driver too and do all ack from java
Jun 28 07:47:21 <vvu> also had time to see if nexus 10 has otg enabled ?
Jun 28 07:47:30 <av500> no
Jun 28 07:47:32 <av500> can do later
Jun 28 07:47:36 <vvu> okok
Jun 28 07:54:55 <vvu> 06-28 10:54:24.605: D/MainActivity(4529): Endpoint number: 0 => UsbEndpoint[mAddress=130,mAttributes=3,mMaxPacketSize=16,mInterval=9]
Jun 28 07:55:00 <vvu> think this is the one
Jun 28 07:55:07 <vvu> on interface 0 there is only 1 endpoint
Jun 28 07:55:13 <vvu> lemme check it`s type
Jun 28 07:57:49 <vvu> have only 1 endpoint on interface 0
Jun 28 07:57:57 <vvu> and it is a interrupt endpoint
Jun 28 07:58:11 <vvu> then on interface 1 i have 2 endpoints the bulk ones for communication
Jun 28 08:02:04 <av500> right
Jun 28 08:02:13 <av500> and from what endpoint have you been reading from?
Jun 28 08:02:21 <av500> where you got the 450 bytes
Jun 28 08:02:24 <vvu> from the bulk one with IN direction
Jun 28 08:02:43 <vvu> interface 1 ep 0 = bulk with IN
Jun 28 08:02:55 <vvu> and ep1 is with OUT direction
Jun 28 08:03:03 <av500> so we missedto read from interface 0
Jun 28 08:03:47 <vvu> i read a bit about how rnids init should happen
Jun 28 08:06:10 <vvu> av500: can you give me a hint about what request and value fileds need to be ? http://developer.android.com/reference/android/hardware/usb/UsbDeviceConnection.html#controlTransfer(int, int, int, int, byte[], int, int)
Jun 28 08:08:48 <vvu> mhm not good not using control transfer
Jun 28 08:20:10 <vvu> av500: read 0x00000000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jun 28 08:20:15 <vvu> from the endpoint
Jun 28 08:20:43 <vvu> code like this http://pastebin.com/GYVHbFng
Jun 28 08:20:51 <av500> looks like what is being sent, no?
Jun 28 08:21:01 <vvu> yep, think so
Jun 28 08:21:10 <vvu> need to figure out what it means :)
Jun 28 08:21:18 <av500> dont you get a size?
Jun 28 08:21:42 <av500> you read max size, but dont you get how many bytes have been sent?
Jun 28 08:21:52 <vvu> mhmh lemme see if android has something
Jun 28 08:23:32 <vvu> av500: no size...
Jun 28 08:23:42 <vvu> or at least i don`t see it http://developer.android.com/reference/android/hardware/usb/UsbRequest.html
Jun 28 08:24:32 <vvu> lemme do more reads in a row to see what is happening if more data is available after
Jun 28 08:29:24 <vvu> av500: there are available 2 set of 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jun 28 08:29:44 <vvu> if i try to do 3 reads u-boot resets itself and i get set of 00
Jun 28 08:39:54 <vvu> anyway i should do these readings in a non rndis driver device
Jun 28 08:40:10 * vvu flashes again a kernel to his phone
Jun 28 08:56:08 <vvu> av500: when removing the rndis driver from the android kernel cannot get data again
Jun 28 08:56:16 <vvu> not even from interrupt endpoint
Jun 28 09:03:06 <av500> hmm
Jun 28 09:05:57 <vvu> some usb analyzer will be just great now
Jun 28 09:09:43 <vvu> usbmon fails at this job completely does not take full dump or at least not full transactions
Jun 28 09:11:13 <av500> right
Jun 28 09:11:16 <av500> I'll try to get it
Jun 28 09:12:29 <vvu> i tried to do urb hexdump in the musb kernel driver but can`t do it right maybe 2night will get something
Jun 28 09:13:04 <vvu> i`ll try to hook a normal linux box without rndis driver and dump everything that goes rx/tx
Jun 28 09:13:31 <vvu> inittially we thought we do not have any init stuff...but i was doing my C code on a linux box with rndis driver
Jun 28 09:13:42 <vvu> and init was taken care, then i just took over the interface
Jun 28 09:15:22 <av500> right
Jun 28 09:21:05 <vvu> av500: what do you suggest doing now? trying to get a working example with the otg support removed + rndis driver into kernel + u-boot patch applied?
Jun 28 09:21:16 <vvu> and afterwards going back and trying to fix?
Jun 28 09:44:36 <av500> so
Jun 28 09:44:49 <av500> with stock android kernel you do not see the 0x01 00 etc
Jun 28 09:44:55 <vvu> nop
Jun 28 09:44:56 <av500> on the INT endpoint
Jun 28 09:45:01 <av500> :(
Jun 28 09:45:10 <vvu> with stock kernel i don`t see anything from the BBB
Jun 28 09:46:15 <vvu> and with stock kernel not even usbmon works
Jun 28 09:46:23 <vvu> tcpdump says 0 packets received
Jun 28 09:46:40 <vvu> that rndis driver does some *magic* somewhere
Jun 28 10:03:57 <vvu> av500: if you can grab an usb analyzer can you do some dumps? i looked last night at an old GSoC project to use BBxM as usb packet analyzer but has musb problems so no good for the BBB
Jun 28 10:12:09 <av500> I need to get it send here
Jun 28 10:12:29 <av500> might take some days
Jun 28 10:12:48 <vvu> ok...until then i will try to make an app to work with these patches done...not really cool but better than zero
Jun 28 10:13:13 <vvu> 2night i will try to do some dumps using a normal linux box with and without rndis drivers active
Jun 28 10:13:28 <vvu> maybe i will have some luck
Jun 28 10:13:40 <av500> ok
Jun 28 10:14:33 <vvu> did not test the spl though, hope it uses same ether.c and rnid code as u-boot
Jun 28 10:14:57 <av500> should
Jun 28 10:15:07 <vvu> if so we are good with that patch in u-boot
Jun 28 10:15:14 <av500> in the end we do not need spl and uboot
Jun 28 10:15:31 <vvu> please explain a bit
Jun 28 10:15:41 <vvu> and load what after ROM ?
Jun 28 10:15:45 <av500> we dont need all the fancy stuff from uboot
Jun 28 10:15:58 <av500> if spl can load uboot, it can also load the kernel
Jun 28 10:16:03 <av500> etcv
Jun 28 10:16:16 <av500> you need uboot if you want fancy env variables and scripting
Jun 28 10:16:24 <av500> if you knwo what you load, you can drop all that
Jun 28 10:16:48 <vvu> did not know this...so spl can load kernel+initrd ?
Jun 28 10:16:59 <vvu> in one big image ?
Jun 28 10:17:02 <av500> why not
Jun 28 10:17:06 <av500> or 2 images
Jun 28 10:17:22 <vvu> now the spl loads only one image and then runs it
Jun 28 10:17:22 <av500> it does tftpf
Jun 28 10:17:24 <av500> tftp
Jun 28 10:17:26 <vvu> yep
Jun 28 10:17:27 <av500> so?
Jun 28 10:17:31 <av500> code can be changed
Jun 28 10:17:34 <vvu> ok
Jun 28 10:17:53 <av500> but for the moment that does not matter
Jun 28 10:18:05 <av500> but yes, spl and uboot is the same code
Jun 28 10:18:08 <vvu> so a target for know?
Jun 28 10:18:24 <vvu> to know where to focus and not go on a wild goose chase
Jun 28 10:18:24 <av500> well, getting something to work would be nice :)
Jun 28 10:18:47 <vvu> *to work* with all the patches ?
Jun 28 10:18:48 <vvu> :)
Jun 28 10:18:50 <av500> i start to fear that stock android host is useless for BBBBoot
Jun 28 10:19:29 <vvu> anyway that rndis stuff problem is in the stock kernel so a patch needs to be applied there...
Jun 28 10:20:09 <av500> yes
Jun 28 10:20:21 <av500> but if we patch kernels
Jun 28 10:28:42 <vvu> we can trick everything to patch MLO into thinking the connection is established and having rndis driver into android kernel, but not really nice
Jun 28 10:29:38 <vvu> and in the final app to have already compiled MLO to be sent over
Jun 28 10:31:03 <av500> well, we only need to trick ROM code
Jun 28 10:31:11 <av500> after that its all under our control
Jun 28 10:31:16 <av500> we do not need RNDIS
Jun 28 10:31:21 <av500> afterwards
Jun 28 10:31:31 <av500> we can use whatever USB protocol
Jun 28 10:31:44 <av500> we just need to get the "foot into the door"
Jun 28 10:31:49 <av500> and that is MLO
Jun 28 10:32:33 <av500> did you try to see what comes on INT for ROM code?
Jun 28 10:35:01 <vvu> trying now
Jun 28 10:35:46 <av500> if we get ROM code to load something, we can control all the rest
Jun 28 10:40:25 <vvu> can`t see it
Jun 28 10:41:02 <vvu> can claim interface, can get endpoint but cannot receive from it
Jun 28 10:42:51 <av500> sigh
Jun 28 10:43:39 <vvu> i don`t really have tools to debug good what is happening
Jun 28 10:44:24 <vvu> in 2 days i want to supply an app that is sending MLO to ROM, with all the patches found
Jun 28 10:44:50 <av500> ok
Jun 28 10:44:54 <av500> do that
Jun 28 10:45:15 <vvu> if you can get a hang of the usb analyzer that would be great to see what is happening until then i can`t really do anything, i`m *blind* here :)
Jun 28 10:45:43 <av500> working on it
Jun 28 10:46:00 <vvu> ok, i`m going a bit off the radar. bbl
Jun 28 10:46:46 <av500> np
Jun 28 12:42:12 <hatguy> is usleep() a good way to implement an Arduino-like delay in linux?
Jun 28 14:26:19 <ka6sox-away> hatguy, what kind of timing is the delay in arduino?
Jun 28 14:26:30 <ka6sox-away> is it mS, or uS or what?
Jun 28 14:27:59 <hatguy> ka6sox-away, it has both.. a delayMicroseconds() and a delay() for ms
Jun 28 14:28:32 <hatguy> ka6sox-away, it doesn't appear to use delayMicroseconds() in the delay() function, however
Jun 28 14:29:39 <ka6sox-away> I don't remember if this is measured in ticks or not for uSleep
Jun 28 14:29:43 <panto> ok, we have 3.10-rc7 booting
Jun 28 14:29:51 <panto> who's the adc guy?
Jun 28 14:30:04 <ka6sox-away> ZubairLK?
Jun 28 14:30:14 <ka6sox-away> you are talking about upstreaming ADC?
Jun 28 14:30:25 <panto> among other things yes
Jun 28 14:30:36 <panto> I need to start upstreaming my crap too
Jun 28 14:30:52 <koen> yes, zubair is the adc upstreaming guy
Jun 28 14:32:09 <hatguy> ka6sox-away, hmmm...but it should be fine for a userspace application, right?
Jun 28 14:32:50 <ka6sox-away> hatguy, usleep is for microsecond sleeps
Jun 28 14:32:54 <ka6sox-away> but there are minimums
Jun 28 14:33:23 <hatguy> yeah... same goes for Arduino... not very usable below 3 us
Jun 28 14:34:29 <hatguy> and is sleep() based on usleep()?
Jun 28 14:35:22 <panto> hatguy, no
Jun 28 14:35:46 <hatguy> panto, hmmm ok
Jun 28 14:37:17 <panto> hatguy, let me expand on that
Jun 28 14:37:30 <panto> you can't rely on sleep having a particular implementation
Jun 28 14:37:38 <panto> it might be using usleep
Jun 28 14:37:43 <panto> it might be using SIGALRM
Jun 28 14:37:59 <panto> it might use a NULL select or poll with a timeout
Jun 28 14:41:53 <hatguy> panto, I see.. I guess all of them can be relied upon to stop the thread for a while?
Jun 28 14:43:41 <hatguy> I mean, in a userspace scenario it won't matter much will it?
Jun 28 14:46:49 <panto> yes
Jun 28 14:46:59 <panto> just beware of signals
Jun 28 14:47:42 <hatguy> panto: ok, thanks
Jun 28 16:59:10 <vvu> av500: seen 2day on internet android 4.3 for S4. any idea what kernel does it have ?
Jun 28 17:04:57 <vvu> found a random screenshot 3.4.10, maybe otg is fixed there
Jun 28 17:31:42 <mluckham> I have a Samsung S4 (Bell Mobility) Android 4.2.2 kernel 3.4.0-517283
Jun 28 18:13:20 <tcort> hello
Jun 28 19:48:01 <ZubairLK> hi
Jun 28 19:48:19 <ZubairLK> I'm working with ADC drivers for BBB 3.8.
Jun 28 19:48:34 <ZubairLK> when i connect gnd to an analog pin. the driver gives me a correct reading
Jun 28 19:48:51 <ZubairLK> but if i connect it to ain4. all inputs give zero reading all of a sudden..
Jun 28 19:48:59 <ZubairLK> did i mess up the pin? :p
Jun 28 19:50:18 <ZubairLK> i'm thinking i should apply gnd on one pin. and 1.8 v on another and see what happens
Jun 28 19:50:23 <ZubairLK> but dont want to mess them all up :p
Jun 28 19:53:21 <ZubairLK> I guess I shouldnt exactly be looking at floating pins
Jun 28 19:53:39 <ZubairLK> AIN4 pulls floating pins to itself.
Jun 28 19:54:04 <ZubairLK> but when i connected 1.8V to AIN4 and gnd to 5,6. The floating were like AIN4.
Jun 28 19:54:10 <ZubairLK> but AIN5 and AIN6 were gnd
Jun 28 21:17:34 <ZubairLK> koen: ping
Jun 28 23:41:51 * vvu lurks from the darkness to some light
Jun 29 00:21:16 <ZubairLK> *about to go into the darkness* :)
Jun 29 00:21:21 <ZubairLK> gnight folks
Jun 29 00:21:24 <vvu> gn!
Jun 29 00:39:09 <ka6sox> jj2baile, how goes it?
Jun 29 00:47:58 <jj2baile> it goes ok..
Jun 29 00:48:15 <jj2baile> ka6sox: does your JTAG shield have certain pins defined as what shall be used for test yet?
Jun 29 00:48:25 <jj2baile> Or is it supposed to be configurable?
Jun 29 00:59:32 <ka6sox> jj2baile, yes, the schematics are published
Jun 29 01:02:46 <ka6sox> https://github.com/ka6sox/BoneTag
Jun 29 01:02:50 <jj2baile> ka6sox: Where are they?
Jun 29 01:02:52 <jj2baile> oh, oK
Jun 29 01:02:54 <jj2baile> Thanks :P
Jun 29 01:03:01 <ka6sox> YW :P
Jun 29 01:03:29 <mcpherrin> jj2baile: hello
Jun 29 01:03:36 <ka6sox> annother cohort?
Jun 29 01:03:40 <jj2baile> mcpherrin: Good day.
Jun 29 01:03:43 <mcpherrin> Maybe!
Jun 29 01:03:49 <mcpherrin> (I'm actually just sitting next to jj2)
Jun 29 01:03:53 <ka6sox> he he
Jun 29 01:04:08 <jj2baile> heh, He is a friend from the csclub. I decided to get some fresh air.
Jun 29 01:04:44 <jj2baile> Well, that was odd.
Jun 29 01:04:52 * vvu is wondering why is he working only when EU ppl are sleeping and US ppl are up
Jun 29 01:05:10 <ka6sox> vvu, because you love us?
Jun 29 01:05:32 <ka6sox> (or you are a night owl)
Jun 29 01:05:42 <vvu> next year maybe i`m going to visit US a bit, need to see if i get a good internship
Jun 29 01:05:55 <vvu> night_owl++;
Jun 29 01:07:00 <jj2baile> Yeah, the US has a better industry for that kind of stuff than canada as well, for the most part, it seems.
Jun 29 01:07:13 <ds2> the problem is the stupid round earth
Jun 29 01:07:18 <ds2> blame columbus
Jun 29 01:07:41 <mcpherrin> colubmus is a fucker
Jun 29 01:07:49 <jj2baile> ... excuse my friend.
Jun 29 01:08:37 <mcpherrin> you should probably disown me and not apologize.  Pretend you don't know me!
Jun 29 01:09:42 <ka6sox> if it wasn't columbus it would have been someone else.
Jun 29 02:15:17 <ka6sox> jj2baile, does that make sense (the schematics)
Jun 29 02:29:57 <jj2baile> ka6sox: I think I understand, but am unsure. Page 2, left side, is a bunch of interfaces the cape will have exposed right?
Jun 29 02:30:16 <jj2baile> so the standard ARM one, SWD, SBW, AVR, etc.
Jun 29 02:33:39 <jj2baile> Though, I don't think I see the mapping from the pin type (TDO, TMS, etc.) to its physical mapping on the board
Jun 29 02:34:25 <jj2baile> Well, except for the CPLD_T* ones, which I see is mapped to GPIO_8-11
Jun 29 02:35:00 <jj2baile> although It doesn't seem to me that GPIO0_8-11 are directly accesible by the pru
**** ENDING LOGGING AT Sat Jun 29 02:59:58 2013