**** BEGIN LOGGING AT Sat May 16 02:59:59 2015 May 16 04:50:19 panto : ping May 16 05:14:59 hmmm folks waking up? May 16 05:18:07 extremely sorry for not being able to attend previous meeting. relocation kept me busy May 16 05:18:29 ds2: is this your email hy-gsoc@hy-research.com ? May 16 05:18:54 yes May 16 05:18:58 whatca need? May 16 05:19:09 ah i see it May 16 05:19:10 let me read it May 16 05:20:37 I have my opinions but let see what pantos says - he's pushing things upstream so his views are important May 16 05:21:18 what do you have in mind for 'firmware loading'? May 16 05:21:54 remoteproc already takes care of it May 16 05:22:19 although it restricts the firmware format May 16 05:22:41 can you describe how it restricts it? May 16 05:26:00 documentation says it can only load elf32 May 16 05:29:13 if not the remoteproc way, then taking words out of the firmware and writing to iram is also an option. May 16 05:48:49 ah May 16 05:48:58 seems a bit odd May 16 05:49:09 thought it would use the stock firmware loader and just load a bin May 16 05:49:23 do you know why it wants an ELF? May 16 05:57:47 maybe because remoteproc is supposed to be generic and elf is widely supported by diff platforms May 16 06:01:11 https://github.com/beagleboard/linux/blob/3.8/drivers/remoteproc/pru_rproc.c#L2798-L2812 takes care of the firmware type May 16 06:01:35 diff handlers fir diff type May 16 06:04:35 for* May 16 06:15:13 gm May 16 06:19:46 gm May 16 06:21:07 most other firmware stuff use raw binary files May 16 06:21:36 it should also simplify things unless someone needed to support dynamic relocations, etc in such a tiny space May 16 06:26:03 shubhangi: The 3.8.13 driver supports both binary and elf32 loading May 16 06:28:14 Abhishek_: yes, read that. so firmware loading is not much of an issue. could you please have a look at the mail i sent May 16 06:30:10 The newer version is developed by TI employees in the USA May 16 06:30:38 Abhishek_: I'll defer this entirely to you :D May 16 06:32:02 ds2: referring to the clarifications? May 16 06:33:00 so i should go with the newer TI version then ? 3.8's code is easier to understand. will be able to comprehend it completely in a day or two and then move on to TI's May 16 06:33:15 Abhishek_: yep May 16 06:33:31 ideally it should be the upstreamed version May 16 08:03:50 Abhishek_: could you briefly tell me how vring, vdevs, virtio work. all resources seem to point at virtualization and stuff but i see it can be used for other purposes as well, such as in the case of remoteproc May 16 08:04:16 panto : ping ^ May 16 12:11:01 moto-timo: ping May 16 12:11:17 without the kext it is useless to run the binary. May 16 12:11:27 which OS X version are you using ? May 16 14:20:08 hi vvu: have a look at this gist http://stackoverflow.com/questions/49478/git-ignore-file-for-xcode-projects May 16 14:20:26 https://gist.github.com/adamgit/3786883 May 16 14:24:48 found a good one May 16 14:28:01 arianepaola_: do you know if in Xcode i can put 2 projects as being in the same group ? May 16 14:28:10 i want to add in the same project the codeless kext and the beagleboot binary May 16 14:31:33 vvu: I have not tried this before, but have a look here, seems to be what you want to do: May 16 14:31:41 http://stackoverflow.com/questions/5483909/how-should-i-manage-dependencies-across-projects-in-an-xcode-workspace May 16 22:16:48 praveendath92: did you ever try to send smaller packets in your implementation? I'm kind of confused about the size of packets that AOA protocol can handle. May 16 22:18:53 azizulhakim: No. Not really. Why? May 16 22:19:58 I was trying to work with RLE. So my idea was to send a small packet of 4 bytes which will say how many bytes to read for the new frame May 16 22:20:42 but every time the application tries to read 4 byte, it crash May 16 22:20:51 So I tried with some other size May 16 22:21:23 and Strangely it works ok with 100 bytes but not with any other smaller amounts May 16 22:21:44 it does work with 4098 or 4096 or 4100 bytes May 16 22:21:59 but not with some other random figures like 2000 May 16 22:22:40 so just wondering in case you faced any such case May 16 22:26:43 64 is min May 16 22:26:59 64 B - 65xxx May 16 22:27:49 64 didn't work either. By the way, where did you get that number? May 16 22:28:37 Sorry 64 - 16384 May 16 22:28:57 https://developer.android.com/guide/topics/connectivity/usb/accessory.html#communicating-a May 16 22:29:09 64 should work May 16 22:30:01 Any logcat? May 16 22:32:06 It was EIO error on android side, didn't store the logcat though. I tried with many different sizes. Have to do some more tests. May 16 22:32:44 That's actually strange. May 16 22:33:00 BTW, how big are audio packets? May 16 22:33:40 same size, 4096 bytes for audio data and 4 bytes of header May 16 22:35:57 I mean, usually what is the size of one audio packet you receive from the kernel? May 16 22:36:02 To your driver. May 16 22:37:59 depends on how you initialize it with ALSA. You can define a range May 16 22:38:03 https://github.com/azizulhakim/beagleusb/blob/master/beagle-audio.c#L46 May 16 22:39:51 Oh. In that case, I suppose you don't need to bother about very low values of packet size anyway. May 16 22:40:15 Compression makes packet size for video data unpredictable though. May 16 22:41:48 BTW, how are you structuring the driver? Individual drivers or one single driver? May 16 22:42:45 Main concern is for video. Compression might be effective for video. May 16 22:44:02 So far everything is together. But I've organized all drivers as separate module so later if we want we can make them as individual driver with little modification May 16 22:44:17 That's good! May 16 22:44:58 I recommend writing the USB comm. part with configurable size. May 16 22:45:22 That way you can test things a bit and decide what could be a good packet size in general. May 16 22:45:48 I don't see a way of figuring it out with just some theory. May 16 22:47:15 one of the big problem I stuck with is not being able to send variable length packet. without it we won't be able to use any compression effectively May 16 22:48:07 How about this... May 16 22:48:26 You always send packets of size S. May 16 22:49:11 So, after sending some packets, of size S each, for either video or audio data... May 16 22:49:29 You will then send the remaining data again in a packet of size S. May 16 22:49:51 With random data to fill up the unused length. May 16 22:50:28 Of course, this needs that you maintain length byte in each packet. May 16 22:50:36 length value* May 16 22:50:54 If you are keen on avoiding it, that can be worked around too. May 16 22:51:03 I thought about that but it is not a efficient solution I think. Should go on that direction only if nothing else works. May 16 22:51:44 It'll need a lot of extra packet management work, like merging multiple packets together, deciding when to send a packet etc May 16 22:51:54 The ideal solution for you would be to be able to send packets of random lengths. Right? May 16 22:52:04 but why can't we send random lenghts ? May 16 22:52:07 what crashes ? May 16 22:52:32 vvu: Android requires that you specify the length of the data before placing a listener. May 16 22:52:51 Caller will be blocked until that length of data is accumulated May 16 22:53:38 So, though you can send arbitrary sizes from kernel, you will anyway receive fixed len. on Android. May 16 22:53:47 vvu: android application crash, bone becomes nonresponsive without any kernel log. looks like a deadlock though there is no lock being used. May 16 22:54:28 azizulhakim: USB Control may be locking the bus internally. May 16 22:54:48 Sending arbitrary lengths causes a deadlock? May 16 22:54:50 azizulhakim: why not fix some big length packets and fill up with 0s at the end ? May 16 22:55:09 transfer speed is enough, just processing takes the time...IMHO May 16 22:55:35 That works perfect if transfer speed is not really an issue. May 16 22:55:45 Infact we know the size here. May 16 22:55:56 just put max_AOA_size May 16 22:55:58 40998 May 16 22:56:04 4098* May 16 22:56:22 Sorry 4100* May 16 22:57:02 And that lifts off the need for compression as well. May 16 22:57:30 transfer speed is not good enough. that's why we need compression. May 16 22:58:14 So we are back in the game again. May 16 22:58:57 Actually packet management is comm. intensive on Android side. May 16 22:59:17 I'm sure Android devices now a days are powerful enough for that. May 16 22:59:33 Sorry. Processing intensive* May 16 23:01:25 even with big sizes is taking a lot to send data ? i was expecting that java<->kernel road to take a while with smaller packets May 16 23:01:53 but blocking for a big size array won't have that many switches on its road May 16 23:04:04 vvu: IMO, the small packet size effect may be reduced a bit if we use threads on android size which do very less work other than listening and writing data to buffers. May 16 23:04:53 Let some other thread worry about consuming that data accordingly. May 16 23:06:39 azizulhakim: can't you send before any 'true' packet it's size in another packet. on the android you read for that specific size (get the size of the true packet) then read the true packet. May 16 23:06:53 and like this you keep in sync how much you need to read May 16 23:07:43 That adds high latency. May 16 23:07:50 And packets queue up. May 16 23:07:52 that's what we were talking about. I tried to send a 4 byte packet which just contains the size of the next packet. May 16 23:08:19 oh well i am a bit behind with reading stuff May 16 23:09:24 but for some reason we can't just send any random size. causes application crash and nonresponsive bone May 16 23:09:55 Note: At a lower level, the packets are 64 bytes for USB full-speed accessories and 512 bytes for USB high-speed accessories. The Android accessory protocol bundles the packets together for both speeds into one logical packet for simplicity. May 16 23:10:04 that is some coding error :) May 16 23:11:03 So, in the end everything is either a 64B or 512B transfer in USB May 16 23:12:07 hmm...seems like we have to consider merging multiple packets into one big packet May 16 23:12:13 i'm going offline...need to grade assignments for OS course May 16 23:12:19 have fun debugging this :) May 16 23:12:38 all fun gone debugging this for 3 days :p May 16 23:15:43 azizulhakim: You are planning on sending 2 packets one with size info first? May 16 23:16:03 And the next one with actual data length. May 16 23:16:55 yes, that was the plan May 16 23:17:54 How about this.. May 16 23:18:26 You send a 512B / 64B packet with length info and some data. May 16 23:18:59 Android side, reads the length, if > received data, inits next read size to diff. May 16 23:19:52 yes, may be we've to plan merging multiple packets together if necessary May 16 23:20:15 Here, it's just 2 packets. May 16 23:20:34 Merging shouldn't be so hard like it may be for multiple ones. May 16 23:22:05 hmm. that makes sense May 16 23:22:14 In fact you don't even need to maintain states here. May 16 23:23:06 There may be some rough edges to work around here but it should work. May 16 23:24:46 yes, will try that. see how it turns out. May 16 23:25:15 This could be good. We are asking Android to do the data buffering for us. May 16 23:25:50 Instead of one more buffering layer. Let's see. May 16 23:26:55 thanks :) May 16 23:27:31 Anytime. I'm kind of sad I couldn't take out enough time to contribute code. May 16 23:27:58 Just got off from a paper deadline few hours ago. Relaxed. May 16 23:28:24 cool :) May 16 23:31:48 Sorry I couldn't be of as much help as I aimed to be. Hit me an email if you need anything and I'm not around. May 16 23:31:56 Good luck (y) May 16 23:33:12 you are doing okay. and we still have time. don't worry May 16 23:45:12 * mr_science went to HSU graduation day today... **** ENDING LOGGING AT Sun May 17 02:59:58 2015