**** BEGIN LOGGING AT Thu Jun 27 02:59:58 2013
Jun 27 03:01:40 <ds2> ~
Jun 27 07:56:23 <vvu> av500: small ping
Jun 27 08:03:07 <av500> jo
Jun 27 08:04:08 <vvu> i suggested ds2 to get right into the kernel in the urb submit function and dump there directly hexdumps of the data being sent to analyze that stuff
Jun 27 08:04:18 <vvu> because tcpdump lacks details
Jun 27 08:04:26 <vvu> to have a clue of what is happening there
Jun 27 08:10:13 <av500> so
Jun 27 08:10:44 <av500> with rndis enabled, you get ROM code to show up in java?
Jun 27 08:10:49 <av500> but not uboot?
Jun 27 08:11:00 <av500> and without rndis, neither
Jun 27 08:11:11 <vvu> yes
Jun 27 08:11:45 <av500> since we cannot debug rom code, we can debug uboot
Jun 27 08:12:00 <av500> so why see on uboot side why it does not send tftp data?
Jun 27 08:12:48 <vvu> tartarus told me that the android is not setting up its part of the usb gadget
Jun 27 08:19:18 <av500> ?
Jun 27 08:22:21 <av500> vvu: still
Jun 27 08:22:25 <av500> you have uboot
Jun 27 08:22:27 <av500> it does tftp
Jun 27 08:22:32 <av500> but we dont see the request
Jun 27 08:22:35 <av500> we can find out why
Jun 27 08:22:38 <av500> why not
Jun 27 08:23:21 <vvu> but i think the problem is lower than rndis
Jun 27 08:23:31 <av500> vvu: whatever it is
Jun 27 08:23:44 <av500> find out
Jun 27 08:23:50 <vvu> a good thing is to find the urb_submit from u-boot and dump there data
Jun 27 08:24:05 <av500> yes
Jun 27 08:24:23 <vvu> BBB uses musb?
Jun 27 08:24:31 <vvu> or ehci ?
Jun 27 08:24:43 <av500> musb
Jun 27 08:26:32 <vvu> u-boot/drivers/usb/ has musb and musb-new
Jun 27 08:26:47 * vvu is confused, new seems kinda ok
Jun 27 08:34:17 <vvu|Mobile> av500: void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len, const u8 *src) seems right by you?
Jun 27 08:36:12 <av500> yes
Jun 27 08:37:12 <vvu> drivers/usb/musb-new/musb_core.c:249 there
Jun 27 08:48:54 <vvu> bad place there
Jun 27 09:00:29 <vvu> any idea how i can activate the output of dev_dbg ? read on google that "debug" needs to be passed at kernel arg but i want it in u-boot
Jun 27 09:18:04 <vvu> av500: musb_gadget_queue is the function that puts the urbs into the queue to be sent
Jun 27 09:19:43 <vvu|Mobile> av500: http://pastebin.com/6QzCvRmP
Jun 27 09:20:09 <vvu|Mobile> ignore the random 3 printed there, it`s from a function to decide if it is highspeed usb or not
Jun 27 09:24:44 <av500> ok
Jun 27 09:24:53 <av500> so what does Sent means?
Jun 27 09:24:58 <av500> how many bytes?
Jun 27 09:25:10 <av500> only 8?
Jun 27 09:25:17 <vvu> yep, that is on the bus
Jun 27 09:25:27 <vvu> just that thing
Jun 27 09:25:29 <av500> 01 00 00 00 00 00 00 00
Jun 27 09:25:35 <av500> and we do not get that
Jun 27 09:25:44 <av500> check rndis spec
Jun 27 09:25:45 <vvu|Mobile> i have there struct usb_request *request
Jun 27 09:25:58 <vvu|Mobile> usb_request has buf and legth
Jun 27 09:28:00 <vvu|Mobile> mhmh i don`t think it is like any rndis message, init is not for sure
Jun 27 09:29:11 <vvu|Mobile> does not fit with any of the rndis messages
Jun 27 09:55:17 <vvu> av500: i think workflow is like this musb_enqueue then when that is set up musb_g_tx is called to actually send the data
Jun 27 09:55:32 <vvu> tested my board with a linux machine to see what i should see
Jun 27 09:58:33 <av500> ok
Jun 27 09:58:34 <av500> and?
Jun 27 09:58:53 <vvu> w8 lemme do a pastebin
Jun 27 09:58:58 <vvu> to caputre a full bootp sent
Jun 27 10:08:24 <vvu> av500: http://pastebin.com/e2KHDJv6
Jun 27 10:08:40 <vvu> i just put some printfs to see which function is called and the order
Jun 27 10:09:02 <av500> yes
Jun 27 10:09:19 <av500> so, after the 4x 8 bytes
Jun 27 10:09:25 <av500> what did it receive?
Jun 27 10:09:45 <vvu> when SENT appears it is from musb_gadget_queue
Jun 27 10:10:00 <av500> yes
Jun 27 10:10:10 <av500> but it must have gotten a response
Jun 27 10:10:36 <vvu> lemme do it again, i should put my hexdump at the start of the function, maybe the buffer is cleared
Jun 27 10:10:53 <av500> I mean, dump also the rx
Jun 27 10:10:58 <av500> not just the tx
Jun 27 10:11:11 <vvu> i`m dumping the queue, shouldn`t that be tx+rx ?
Jun 27 10:11:25 <av500> no idea
Jun 27 10:11:33 <av500> but between old and new pastebin
Jun 27 10:11:35 <vvu> because if you look down it receives stuff, like my hostname of the linux achine
Jun 27 10:11:36 <av500> something changed
Jun 27 10:11:38 <av500> so what?
Jun 27 10:11:58 <vvu> i think i`m printing also the rx
Jun 27 10:11:58 <av500> between line 15 and 16
Jun 27 10:12:23 <av500> so line 20
Jun 27 10:12:26 <av500> is the rx?
Jun 27 10:12:35 <vvu> yep i think so
Jun 27 10:12:38 <av500> because it is printed after USB RNDIS network up!
Jun 27 10:12:50 <av500> I would have expected to see it printed before
Jun 27 10:14:10 <vvu> yeah but what s with those 8 bytes 01 00 00 00 00 00 00 00
Jun 27 10:14:45 <vvu> some other function except musb_g_rx, tx is putting them in the queue
Jun 27 10:17:25 <vvu> this needs to be fixed because same rndis src files are used when spl is built
Jun 27 10:18:46 <vvu> i`ll be afk a bit, 2night i will speak with tartarus to see if he knows something.
Jun 27 19:53:47 <vvu> av500: understood why it did not work the uboot
Jun 27 19:54:08 <vvu> or at least a bit
Jun 27 19:54:42 <vvu> u-boot is configured to receive the bootp message really fast, needs some data to be received not to hit the timeout. dunno what data does it expect but if i send something to it it does not timeout that fast
Jun 27 20:08:31 <Tartarus> vvu, sure
Jun 27 20:08:48 <vvu> Tartarus: thx! i hacked a bit in u-boot source for the musb code
Jun 27 20:09:00 <vvu> to see exactly the function were urbs are sent over to USB
Jun 27 20:09:37 <Tartarus> ok
Jun 27 20:09:44 <vvu> drivers/usb/musb-new/musb_gadget.c
Jun 27 20:09:51 <vvu> that file in the enqueue function
Jun 27 20:10:22 <vvu> when i issue bootp command in u-boot 4 sets of 8 bytes are sent over the network
Jun 27 20:10:40 <vvu> http://pastebin.com/8QRXap4q
Jun 27 20:11:03 <vvu> these. and i have printfs in the rx, tx functions to see if they come from there but nothing...
Jun 27 20:11:11 <vvu> any idea from where are these bytes sent ?
Jun 27 20:15:01 <Tartarus> hm
Jun 27 20:15:20 <vvu> i made a hexdump function and put it there to dump the buffer from the usb_request struct
Jun 27 20:15:26 <Tartarus> net/bootp.c ?
Jun 27 20:16:35 <vvu> but why isn`t musb_g_tx called for those packets ?
Jun 27 20:16:46 <vvu> they are in the queue but not sent ?
Jun 27 20:18:10 <Tartarus> Not sure
Jun 27 20:19:08 <vvu> and there is a lot of DMA code, not sure what DMA is for start...need to read about it
Jun 27 20:19:29 <vvu> i`m not sure with what the android should send back
Jun 27 20:20:28 <vvu> rom code is not so *checks filled* and that is why i think works
Jun 27 20:23:57 * vvu is so lost in code
Jun 27 20:24:39 <Tartarus> Well, like I was saying the other day
Jun 27 20:24:47 <Tartarus> You can debug this part with standard linux PC talks to android
Jun 27 20:24:53 <Tartarus> Get the communicating
Jun 27 20:25:04 <Tartarus> Then worry about the possible finickyness of u-boot
Jun 27 20:25:26 <Tartarus> Step 1 would be just doing a static set of IPs on each end and ping'ing
Jun 27 20:25:55 <vvu> mhmh not sure how can i set that up because on android i don`t have it to act like a rndis gadget
Jun 27 20:25:59 <vvu> just a host
Jun 27 20:29:52 <vvu> if i would know what u-boot expects back i can just make the timeout bigger send what it is needed and then maybe bootp requests start flowing *dream on!*
Jun 27 20:30:36 <vvu> because sending stuff to u-boot in this situation works, the rx function is called when i send something to it
Jun 27 20:38:41 <Tartarus> Right
Jun 27 20:39:12 <Tartarus> I'm saying, I think you might have easier luck determining what you need to do on the Android side if you have a standard linux box (and all the normal tools, debug entries, etc, etc, available) in place of U-Boot
Jun 27 20:39:18 <Tartarus> Linux can be the rndis gadget :)
Jun 27 20:39:25 <Tartarus> U-Boot uses the kernel's code here, adapted
Jun 27 20:39:48 <Tartarus> If you wanna get funny with it, you can do it with the beagle in Linux as the Linux gadget
Jun 27 20:40:14 <Tartarus> My main point is that there's lots of known debugging tools and google results on debugging crap from within Linux, but not so for U-Boot
Jun 27 20:48:58 <vvu> mhmh have another way to debug stuff...linux with bootp server and hook u-boot from BBB there and check what is sent
Jun 27 20:49:13 <vvu> hexdump the s**t out of the packets
Jun 27 21:31:13 <vvu|Mobile> Tartarus: this thingie i receive over usb. dumped right from musb_g_rx the receive function think it is
Jun 27 21:31:39 <vvu|Mobile> curious thing is that USB RNDIS UP is before anything received...
Jun 27 21:31:54 <vvu|Mobile> this output is done by hooking u-boot with a linux machine
Jun 27 21:39:20 <Tartarus> tcpdump/wireshark are your friends for examining packets :)
Jun 27 21:40:49 <vvu|Mobile> the packets after RNDIS USB UP are useless now, before that i need to figure out what happens
Jun 27 22:06:55 <vvu> Tartarus: ether.c line 1839 the comment seems interesting and clears away some fog
Jun 27 22:29:01 <ka6sox> jj2baile, are you here?
Jun 27 22:34:26 <vvu> Tartarus: ok, hacked u-boot to receive stuff
Jun 27 22:34:36 <vvu> the problem is that the RNDIS_ACK is not made
Jun 27 22:34:46 <vvu> i just hardcoded to think it has the ack done already
Jun 27 22:34:57 <vvu> i`m so messing around things here and no doing it the right way...
Jun 27 22:43:08 <jj2baile> ka6sox: Yes, Good day.
Jun 27 22:43:33 <jj2baile> ka6sox: I recall you mentioning something about a GPIO exclusion one could take? How does that work? Or if you can refer me to somewhere in the documentation
Jun 27 22:57:38 <ka6sox> yes, which ones do you need to exclude?
Jun 27 23:00:37 <jj2baile> well I haven't decided what pins or anythin, but i just wanted to read up on it, since it seems like something that I could possibly need.
Jun 27 23:00:54 <jj2baile> I would probably try to apply it to my example program which manipulates the pin connected to USR0
Jun 27 23:00:57 <jj2baile> (the LED)
Jun 27 23:28:29 <ka6sox> okay is that one of the pins attached to the PRU (either one)
Jun 27 23:29:16 <ka6sox> http://www.elinux.org/Ti_AM33XX_PRUSSv2#Beaglebone_PRU_connections_and_modes
Jun 27 23:32:46 <jj2baile> I don't believe so.
Jun 27 23:33:30 <jj2baile> thus why I was using the slower way (accessing non-PRU memory
Jun 27 23:34:13 <jj2baile> Is the "exclusion" thing done by pru only?
Jun 27 23:34:35 <ka6sox> no
Jun 27 23:35:00 <ka6sox> exclusive-use (a DT term) just says your cape uses that pin (and it isn't available)
Jun 27 23:36:01 <jj2baile> ooh. Ok. I see. I was thinking about it in another way. but that is sufficient too, for the actual implementation of the jtag stuff
Jun 27 23:36:04 <jj2baile> thanks.
Jun 27 23:36:46 <ka6sox> for the implementation of the JTAG stuff we will use the pins that directly attach to the PRUs
Jun 27 23:36:54 <jj2baile> Yes. Definitely.
Jun 27 23:37:21 <ka6sox> which are the ones in that table
Jun 27 23:42:25 <ka6sox> jj2baile, you okay with swapping weeks 3 and 4?
Jun 27 23:43:51 <jj2baile> ka6sox: That is fine.
Jun 27 23:47:05 <ka6sox> that works better for me too
Jun 27 23:47:46 <ka6sox> jj2baile, as I don't have any confidence in the c compiler for this yet I think we should stick with assembly
Jun 27 23:47:57 <ka6sox> also we should look into using Bas' version
Jun 27 23:51:29 <jj2baile> alright
Jun 27 23:51:39 <jj2baile> be back in a few minutes
Jun 27 23:52:52 <ka6sox> kk
Jun 28 01:40:56 <jj2baile> ka6sox: Which c compiler are you referring to ?
Jun 28 01:52:15 <ds2> TI has a C compiler for the PRU
Jun 28 01:52:21 <ds2> but it is new hence hte lack of confidence
Jun 28 01:55:25 <jj2baile> Ah ok. yeah im perfectly fine with assembly in either case.
**** ENDING LOGGING AT Fri Jun 28 02:59:58 2013