**** BEGIN LOGGING AT Fri Aug 02 02:59:59 2013 Aug 02 11:49:17 koen: ping Aug 02 15:31:23 jj2baile, ping Aug 02 21:58:42 ds2: ping Aug 02 22:02:59 vvu: pong Aug 02 22:03:17 are you free a bit to answer some question about gadgetFS? Aug 02 22:03:35 ask away... I am unpacking but I should be able to try Aug 02 22:03:40 i`m trying to move from g_serial communication to gadgetFS Aug 02 22:03:54 ok Aug 02 22:04:03 i started to look into the example code from http://www.linux-usb.org/gadget/usb.c Aug 02 22:04:05 what driver on the host side does gadgetFS use? Aug 02 22:04:12 there seems to be too many names Aug 02 22:04:33 mhmh gadgetFS emulates an USB device, right? Aug 02 22:04:49 all gadget devices do that Aug 02 22:05:03 does it enumerate as mass storage? MTP? PTP? other? Aug 02 22:05:24 MTP i would want it to emulate, my goal is to transfer a big .img file Aug 02 22:06:55 ah okay Aug 02 22:07:22 i`m a bit lost in the code from the link i gave you, that code is the example one they supply Aug 02 22:07:37 let see Aug 02 22:07:52 i have an idea how it works but in major terms Aug 02 22:08:05 okay Aug 02 22:08:10 and you want to do this in userspace? Aug 02 22:08:14 yes Aug 02 22:08:24 any specifc reason? Aug 02 22:08:38 g_serial is buggy with big files, this is the only one Aug 02 22:09:03 you should be able to do it kernel land Aug 02 22:09:08 let me look. give a few Aug 02 22:09:10 ok Aug 02 22:10:51 it`s the 1st time when i face some advance *to me* code Aug 02 22:11:03 don`t have a strong knowledge about threading Aug 02 22:12:42 why not do it kernel space and just use the g_android? Aug 02 22:12:47 it implements MTP Aug 02 22:13:26 mtp specific code is in f_mtp.c Aug 02 22:13:33 android.c is the glue for all the crap Aug 02 22:13:43 if you hack that a bit it can default to MTP Aug 02 22:13:52 not sure if i can follow you... Aug 02 22:14:06 okay, let me start from the beginning Aug 02 22:14:07 so BBB would present itself as MTP to android host Aug 02 22:14:12 with g_android Aug 02 22:14:13 ? Aug 02 22:14:26 you are trying to use MTP to transfer an image to avoid buffer issues with g_serial, right? Aug 02 22:14:31 vvu: yes. Aug 02 22:14:34 yep Aug 02 22:14:54 so if you use g_android, all the MTP work is done for you. you just need to take care of the backend Aug 02 22:15:03 g_android is built from android.c Aug 02 22:15:11 which _includes_ f_mtp.c Aug 02 22:15:22 so here i need to hack android.c to save my image to eMMC Aug 02 22:15:25 if you don't see it in your tree, I cna find a tree you can pull it from Aug 02 22:15:36 actually Aug 02 22:15:46 why don't you just use usb mass storage? Aug 02 22:16:01 and export the eMMC so the android device can handle all the writing? Aug 02 22:16:14 that way the BBB's eMMC will appear as a giant USB memory stick Aug 02 22:16:53 true here but my knowledge with this thingie to work is limited, have no idea from where to start to write to this gigant usb memory stick Aug 02 22:16:58 giant Aug 02 22:17:26 if you export /dev/mmcblkN with USB mass storage, it should appear exactly as if you were writing to /dev/mmcblkN locally Aug 02 22:17:38 so if you partition it, it should follow Aug 02 22:17:54 i jut need to dump bytes to it Aug 02 22:17:58 yep Aug 02 22:17:58 the .img is partitioned already Aug 02 22:18:17 so just bulkTransfer to my device would work? Aug 02 22:18:31 so 'dd if=somestupid.img of=/dev/sdN bs=16k' Aug 02 22:18:36 yes Aug 02 22:18:46 USB mass storage is solely bulk ep's Aug 02 22:18:51 mhmhh can`t dd on Android Aug 02 22:18:53 root problem Aug 02 22:18:59 but from USB Host api Aug 02 22:19:01 oh Aug 02 22:19:06 blah Aug 02 22:19:17 but most android USB host will grab a mass storage device Aug 02 22:19:21 hmmm Aug 02 22:19:28 then fall back to mtp I guess Aug 02 22:19:32 and use g_android Aug 02 22:20:35 still gadgetFS i think is better, discussed with jkridner and he suggested that a nice thingie is to create SD cards for other boards using a BBB Aug 02 22:20:49 and here i need to read from Host and write to SD Aug 02 22:20:54 not just save the image locally Aug 02 22:21:02 i have 512mb space, all running in RAM Aug 02 22:21:23 I don't see a difference Aug 02 22:21:48 but if you really would like to reinvent the wheel using gadgetFS, go right ahead Aug 02 22:21:55 so threads..what about them? Aug 02 22:22:15 nop, if this means reinventing stuff i think g_android is a good thingie ! Aug 02 22:22:42 if you want to do MTP, the code for it is in g_android Aug 02 22:22:50 all the icky constants and protocol stuff Aug 02 22:22:57 you can mod that to send the output elsewhere if you like Aug 02 22:23:07 and i need to hack the code there to do whatever i want Aug 02 22:23:12 but if you did it in gadgetFS, you would need to write all the protocol stuff Aug 02 22:23:36 the only way I can see it being simplier is if you ignore all the standard protocols and just implement a bulk pipe Aug 02 22:23:54 in that case, I'd suggest looking at g_zero on the BBB side Aug 02 22:24:00 and use the host API on android Aug 02 22:24:00 mhmh in gadgetFS i was thinking to do it more stupider, listen to some messages 1st to see where to pipe the things i will receive then receive and save Aug 02 22:24:24 okay.. if you like... that works Aug 02 22:24:30 but that also means you are not doing MTP Aug 02 22:24:39 (MTP is a specific protocol) Aug 02 22:24:42 yeah Aug 02 22:24:54 having sorted that out... what about threads? Aug 02 22:24:58 true, want to do it simpler and more specific to what i need Aug 02 22:25:08 did not understand the code in usb.c Aug 02 22:25:28 that code simulates bulk transfer to receive and echo same thingie that will receive i think Aug 02 22:25:39 and can do it in async mode or normally Aug 02 22:25:47 Okay Aug 02 22:25:52 got specific questions? Aug 02 22:25:55 and i was wondering to modify code there and use it for my application Aug 02 22:26:24 not kinda, just wanted to verify my suspicions if the code there is read/echo style? Aug 02 22:27:53 okay..give me 1, let me look at it specifically for that Aug 02 22:28:45 i don`t think i`m right. Aug 02 22:28:54 simple_source_thread function is for writing to endpoint Aug 02 22:29:05 and before write it has len = fill_in_buf (buf, sizeof buf); Aug 02 22:29:11 it can be setup to send data and read data from stdip Aug 02 22:29:21 but no, it doesn't auto echo Aug 02 22:29:24 to fill the buffer with 0 or some %63 stuff Aug 02 22:29:32 it can generate patterns on the send side but it always writes the receive to stdout Aug 02 22:29:40 yep Aug 02 22:29:42 true Aug 02 22:29:54 DO_PIPE will switch it to taking input from stdin Aug 02 22:29:55 mhmh i think i can hack into it to make it work with my stuff Aug 02 22:30:17 just think of threads as another process that runs in parallel Aug 02 22:30:18 not intreted to sending to Android back, just receiving mainly Aug 02 22:30:43 a lazy way is to run this as a child process and read its stdin ;) Aug 02 22:30:48 but that is veyr very very very lazy Aug 02 22:30:58 was thinking at this right now :) Aug 02 22:31:05 OTH, I don't directly fill out your evals so what I think don't matter ;) heheh Aug 02 22:31:37 OTH? not accustomed with acronyms Aug 02 22:31:59 oops. I mean - OTOH - On The Other Hand Aug 02 22:32:19 av500 told me to look at gadgetFS Aug 02 22:32:38 so this plan looks really good if this code will work Aug 02 22:32:43 i can hack easily into it Aug 02 22:32:43 everyone has different view points on it... I personally like to do things in the kernel Aug 02 22:33:07 but you can try this... worse is it'll be slow and unmaintainable but it'll be a workable start Aug 02 22:33:28 here i can modify easily the buffer Aug 02 22:33:49 not really Aug 02 22:33:58 the buffers are still controlled by the kernel side Aug 02 22:34:03 it just appears like you can do that Aug 02 22:34:21 gadgetFS is just a driver that lets you talk to kernel interfaces Aug 02 22:34:46 you are more or less using a mirror of the host API Aug 02 22:35:18 yes but g_serial is really slow and buggy with big files, maybe here it will work smoothly Aug 02 22:35:26 the buffer is the problem...4k size Aug 02 22:35:51 I think the buffer is not from g_serial but from the tty layer Aug 02 22:37:19 anyway at this point i have a working app that flashes the eMMC, transferring the .img.xz to the board takes like 10 minutes Aug 02 22:37:37 then uncompressing and pipeing to /dev/mmcblk takes like 20 minutes Aug 02 22:37:53 tested the app on both galaxy nexus and n7 and it works Aug 02 22:37:58 'k Aug 02 22:38:19 future plans are to implement a way to download the .img from url and flash it Aug 02 22:38:25 and to make sdcard for other boards Aug 02 22:38:45 any new things that you would like to see in the app? Aug 02 22:39:02 so your app transfers the entire image then starts writing or? Aug 02 22:39:24 app transfers the compressed image then it starts writing Aug 02 22:39:37 i tried to transfer the uncompressed image and write at the same time Aug 02 22:39:45 but the buffer issue appeared here Aug 02 22:40:25 I suspect that is going to be bug prone Aug 02 22:40:27 and only chunks of 1024 bytes i could transfer, maybe my code is buggy somewhere else and i`m doing it wrong Aug 02 22:40:45 I can give you an image that is uncompressible Aug 02 22:41:08 but this is a start Aug 02 22:41:56 i want to have a way of sending stuff at highspeed usb Aug 02 22:42:25 how hard is it to add flow control? Aug 02 22:42:44 something like what xmodem or ymodem? Aug 02 22:42:49 any chance of fwrite, fseek to be really slow and the buffer to be overwhelmed in the meantime ? Aug 02 22:43:05 i tried to do something like tftp; send then wait for ack to send again Aug 02 22:43:14 always a chance of that in userspace esp. if you use the same thread to write to flash Aug 02 22:43:28 same thread to read then write Aug 02 22:44:03 beagle side would be - read from ttyg0, locally queue, if local queue is not full, ack it Aug 02 22:44:11 hten in a seperate thread, dequeue Aug 02 22:44:19 that should avoid the kernel buffer issues entirely Aug 02 22:45:55 this weekend i will try my luck with gadgetFS to see if it works and how Aug 02 22:46:08 if this fails i will take 2 steps back and rethink my logic in all the code Aug 02 22:47:23 sounds like a plan Aug 02 22:47:41 for a quick and dirty test, you can use that file in the link more or less directly Aug 02 22:47:50 control it via popen Aug 02 22:48:35 processopen good Aug 02 22:48:45 yep Aug 02 22:48:57 read() on that fd returned will be the data from that process's stdout Aug 02 22:49:07 mhmh i will put a hexDump in my receive function and send some demo data like a small text Aug 02 22:49:37 1st lets pray Android kernel will behave nicely with it, no more rndis type of problems Aug 02 22:49:40 or you do it a little better - call pipe, then dup on of hte fd as stdout of the child after a fork() but before exec() Aug 02 22:49:55 hahaha Aug 02 22:50:07 we are thinking too ahead right now Aug 02 22:50:12 true Aug 02 22:50:23 during this project i learnt to take things one step at a time Aug 02 22:51:12 :) Aug 02 22:52:26 ds2: any idea if releasing the app to playstore is a goal ? Aug 02 22:52:52 vvu: that I don't have any idea of Aug 02 22:53:31 at the very least, I would hope the raw apk's would be available for download either directly or maybe via f-droid Aug 02 22:54:14 if time allows me after we finish the project i would like to make a version for the BB-xM Aug 02 22:54:26 or at least try to Aug 02 22:54:58 BB classic might be better Aug 02 22:55:05 it has onboard NAND Aug 02 22:55:10 the BB-xM has no onboard memory Aug 02 22:55:42 bb-xm relies only on sdcard? Aug 02 22:56:17 yep Aug 02 22:57:23 maybe for BB clasic no more android kernel problems Aug 02 22:57:56 will see how things evolve, until then i need to get some sleep. thank you for the tips about gadget stuff! have a great day! Aug 02 22:57:59 I donno about that Aug 02 22:58:06 okay. u too **** ENDING LOGGING AT Sat Aug 03 03:00:00 2013