**** BEGIN LOGGING AT Wed Jun 26 02:59:58 2013 Jun 26 10:33:44 av500: ping Jun 26 10:38:13 jo Jun 26 10:38:34 read the log from last night? did with ds2 some research about the problems with usb communication Jun 26 10:38:56 he believes that the problem is in the usb common code because on all my devices the problem is in the same place Jun 26 10:39:35 hmm Jun 26 10:39:53 vvu|Mobile: can you boot from usb Jun 26 10:39:54 Nexus7 uses EHCI and Galaxy Nexus uses musb and both fail at transfer with timeout*ETIMEDOUT* Jun 26 10:39:55 er Jun 26 10:40:00 can you boot from SD Jun 26 10:40:08 and only tftp from uboot Jun 26 10:40:16 to test if it is ROM code Jun 26 10:40:20 i was thinking to debug that way Jun 26 10:40:34 but last night caught me at like 5AM doing stuff and went to sleep Jun 26 10:40:42 this is the plan for 2day Jun 26 10:40:52 ok Jun 26 10:41:40 also spoke with chainfire on #android-dev and told him the issues. he told me in the end that problem is somewhere deep inside, maybe in kernel stuff Jun 26 10:42:12 but you say it worked once Jun 26 10:42:19 this is the strange thing Jun 26 10:42:20 yes! that is really curious... Jun 26 10:42:35 so, try from uboot Jun 26 10:42:40 if you remember i asked one day about if rndis has some init message Jun 26 10:42:48 and then i tested receiving on android and it worked Jun 26 10:43:13 you think ROM code went off ? Jun 26 10:43:53 how? Jun 26 10:44:18 i don`t think my board is bricked...linux still sees it with rndis when i connect Jun 26 10:44:25 right Jun 26 10:44:33 I assume you can still boot it from linux, no? Jun 26 10:44:58 did not try full sequence, but think so Jun 26 10:45:08 well, you could do that to be sure Jun 26 10:45:17 i will debug in like 2h, i`m not home right now Jun 26 10:45:27 also, please send your status update to gsoc ML Jun 26 10:45:35 okok Jun 26 10:48:44 damn! clicked submit and forgot to edit the subject... Jun 26 10:49:11 send another one Jun 26 10:49:26 spamming like that? Jun 26 10:49:51 heh, you ran into the bootp bug Jun 26 10:49:57 ? Jun 26 10:50:08 koen: bootp bug? Jun 26 10:50:18 the bootp vs dhcp packet thing Jun 26 10:50:22 aaa yes Jun 26 10:50:47 vvu|Mobile: subject is fine Jun 26 10:50:48 people from TI specify the first RFC for bootp but they implement the dhcp format of the packet Jun 26 10:51:11 with variable vendor field length and used flags Jun 26 10:52:30 right Jun 26 10:52:48 heh that thing is now a minor, minor issue Jun 26 10:53:04 TI is not the first to get that wrong Jun 26 10:53:24 cost me a lot of time to figure out how to make my dhcpd+tftp setup work for all cases Jun 26 11:02:06 av500: posted everything on ML Jun 26 11:02:10 ok Jun 26 11:02:11 also with the usb problems Jun 26 11:03:26 if you stick here like 30 mins i will post an update with uboot tftp boot from board, going now to grab my stuff from home. Jun 26 11:03:56 np Jun 26 11:03:58 lunch Jun 26 11:05:36 good idea Jun 26 11:05:47 * koen hunts for the leftover pizza Jun 26 11:05:48 frikandel? Jun 26 11:08:05 that's more of a dinner thing Jun 26 11:09:32 ah Jun 26 11:54:05 av500: http://pastebin.com/LpnLgLd2 any idea ? i have the stock u-boot that comes in the eMMC flasher, do i need to put am335x_evm_usbspl u-boot ? Jun 26 12:37:38 av500: ping Jun 26 12:42:23 jo Jun 26 12:43:32 asked tartarus about http://pastebin.com/H6xns7P9 Jun 26 12:43:56 and he told me that the android device does not set up the connection right, very possible that i need to have rndis driver on android to get things right Jun 26 12:44:41 well, but you are usb host Jun 26 12:44:44 you do all the protocol Jun 26 12:44:46 no? Jun 26 12:44:47 http://pastebin.com/AabgLyhE Jun 26 12:44:49 this is the log Jun 26 12:44:53 yep, i`m the host Jun 26 12:45:18 ah Jun 26 12:45:20 sorry Jun 26 12:45:21 misread Jun 26 12:45:26 this is for the uboot case Jun 26 12:45:30 yep Jun 26 12:45:32 ok, but still Jun 26 12:45:41 isnt uboot sending some data over USB? Jun 26 12:46:14 it should Jun 26 12:46:30 but my device does not receive anything, u-boot timeouts very fast Jun 26 12:47:05 vvu: you have uboot source code Jun 26 12:47:08 i connect device and app automatically loads and starts to read data, but that timeout is really fast. is the data put in a buffer for read ? Jun 26 12:47:14 so, have a look what it expects over usb for rndis Jun 26 12:49:33 av500: here it fails ctrlc() || (get_timer(ts) > timeout) Jun 26 12:49:37 looked in ether.c file Jun 26 12:50:15 then make the timeout longer Jun 26 12:50:25 the gettimer>timeout i get it but ctrlc() what is that? Jun 26 12:50:44 aaa control + c Jun 26 12:50:50 had to read a line up :)\ Jun 26 13:52:45 av500: same thingie Jun 26 13:53:09 my java code is like this http://pastebin.com/Qbgi4L5R Jun 26 13:53:17 when app starts it starts to read from my device Jun 26 13:53:47 and i don`t receive a thing Jun 26 14:03:54 hmm Jun 26 14:04:30 vvu: well, can you add a printf on the uboot side? Jun 26 14:04:35 to see what is being sent= Jun 26 14:04:37 ? Jun 26 14:06:45 in 30 mins, some food is needed. Jun 26 14:51:18 av500: think i made it work! Jun 26 14:51:29 lets not jinx, brb 10 min testing Jun 26 14:52:21 * av500 holds breath Jun 26 14:53:17 * ka6sox drinks coffeee Jun 26 14:55:04 * av500 turns blue Jun 26 14:56:09 YES! Jun 26 14:56:14 did a hack in the kernel Jun 26 14:56:19 need to activate rndis_host Jun 26 14:56:26 at least for my Nexus7 Jun 26 14:57:32 hmm Jun 26 14:57:39 not good Jun 26 14:57:39 CONFIG_USB_NET_RNDIS_HOST Jun 26 14:58:14 * vvu has his dreams shattered! :( Jun 26 14:58:22 well Jun 26 14:58:32 it means we need to patch probably every android device Jun 26 14:58:43 but from the start we need to patch otg stuff Jun 26 14:58:54 every android device which has kernel < 3.4 i think Jun 26 14:59:08 not sure they all have OTG enabled Jun 26 14:59:28 we need a s2/34 to try Jun 26 14:59:30 i tested 2 days ago a samsung galaxy chat, otg enabled Jun 26 14:59:32 3/4 Jun 26 14:59:40 ic Jun 26 14:59:41 I doubt many phones have it turned on Jun 26 14:59:55 mhmh kinda tricky don`t know anybody with s3/s4 Jun 26 14:59:57 ic ? Jun 26 15:00:06 I see Jun 26 15:00:09 maybe i will have a HTC One to test in like a couple of weeks Jun 26 15:00:39 maybe some tablets a could test Jun 26 15:00:43 samsung galaxy tabs Jun 26 15:00:53 the 2 verions Jun 26 15:01:34 i'll test on an N10 tomorrow Jun 26 15:01:35 if OTG is enabled...are you grounding pin4? Jun 26 15:01:46 the cable does Jun 26 15:01:51 cable doing it Jun 26 15:01:59 that part works Jun 26 15:02:15 nexus 4 does not have otg as i remember, or at least what google says Jun 26 15:02:17 ka6sox: the issue with OTG is that BOOT ROM announces HNP Jun 26 15:02:25 oh Jun 26 15:02:27 but does not do it properly Jun 26 15:02:33 and linux kernel hates it then Jun 26 15:02:40 uboot doesnt Jun 26 15:02:43 so it works Jun 26 15:03:12 at least i am happy we have *a way out* kinda Jun 26 15:03:26 well Jun 26 15:03:32 something is better than nothing Jun 26 15:03:35 I am curious to understand what this rndis does Jun 26 15:03:47 but still your point is valid to get it work on stock device Jun 26 15:04:07 for me rndis is a high level protocol over low level usb Jun 26 15:04:15 yep...low level needs to be debugged Jun 26 15:04:21 ds2 told me last night Jun 26 15:04:40 i don`t get it how the kernel knows that there is a RNDIS device Jun 26 15:04:54 vvu: please printf in uboot what usb messages are exchanged Jun 26 15:04:58 activate or deactivate? Jun 26 15:05:05 vvu: from the usb descriptor Jun 26 15:05:30 vvu: that is no mystery Jun 26 15:05:34 usb class etc.. Jun 26 15:06:03 av500: I think what's happening is that the kernel binds to the rndis driver and it just got disabled Jun 26 15:06:04 vvu: so wioth rndis, uboot works or ROM code too? Jun 26 15:06:13 keesj: yes Jun 26 15:06:15 but it should not Jun 26 15:06:17 for USB host Jun 26 15:06:21 it should do nothing Jun 26 15:06:28 rom code Jun 26 15:06:30 it should just pass data to libusb or java Jun 26 15:06:46 at this point i read rom code data Jun 26 15:06:46 * keesj needs proof . can you pastebin the kernel config? Jun 26 15:06:53 the Android Kernel doesn't have CDC enabled? Jun 26 15:07:04 ka6sox: of course not Jun 26 15:07:11 bummers Jun 26 15:07:12 okay Jun 26 15:07:13 well, it depends on the actual unit Jun 26 15:07:16 http://pastebin.com/q9YDdmDJ Jun 26 15:07:18 its not stock android Jun 26 15:07:36 this is the Nexus 7 config Jun 26 15:07:42 vvu: your patched one Jun 26 15:07:45 that works? Jun 26 15:07:47 yep Jun 26 15:07:50 where you enabled rndis Jun 26 15:08:08 CONFIG_USB_NET_RNDIS_HOST=y Jun 26 15:08:15 yes Jun 26 15:09:16 in the menuconfig is marked as experimentel Jun 26 15:09:19 experimental Jun 26 15:09:24 so the unbind fails when no driver is attached. would that be a sensible resoning? Jun 26 15:09:52 reasoning Jun 26 15:10:08 ok taking 5 now to charge all android devices Jun 26 15:10:21 unbind= Jun 26 15:10:21 unbind? Jun 26 15:10:23 np Jun 26 15:10:29 I need to bike home to make the meeting Jun 26 15:10:55 okidokie Jun 26 15:12:53 without rndis nothing works Jun 26 15:13:08 now need to test u-boot to see if it works with this rndis_host=y option Jun 26 15:15:02 meeting start in 45 minutes? Jun 26 15:15:31 yes Jun 26 15:15:32 yep Jun 26 15:16:29 eh, too much win is enough for today Jun 26 15:16:34 u-boot still fails Jun 26 15:30:50 vvu: I just tried your code (boot) on my galaxy SII http://pastebin.com/6jc3q6tG Jun 26 15:31:37 it just hangs (I guess) nothing out of the kernel Jun 26 15:31:59 same here, if you try to debug it hangs at the 1st bulk transfer function Jun 26 15:32:04 in that function it hangs Jun 26 15:32:29 or at the kernel driver release, in the code...can`t remember exactly Jun 26 15:42:20 on the first libusb_bulk_transfer (here) Jun 26 15:42:44 yep Jun 26 15:42:57 same for my N7, Galaxy Jun 26 15:43:13 i`m curious now with the rndis enabled on my nexus Jun 26 15:43:25 need to wait 30 mins to charge the tablet Jun 26 15:46:15 an usb analyser would be really nice right now Jun 26 15:52:56 usbmon should be enough as you already have a "working" sample Jun 26 15:53:56 keesj: what is the difference between * and M in the kernel? M means build as module? Jun 26 15:54:02 +1 usbmon Jun 26 15:54:13 wireshark makes it extra cool :) Jun 26 15:56:35 vvu: you need to fix your warnings! Jun 26 15:57:02 * vvu hides in these moments of warning Jun 26 15:57:49 you are going to hit your head very hard the moment you figure out it's one of those warning that causes your problems. Jun 26 15:57:55 else we will :P Jun 26 15:58:33 with this win i`m of java api i`m hoping of not using C code Jun 26 15:59:06 w8 wrote bulls**t. i`m hoping of using java api ! Jun 26 16:00:19 hi all... answering a couple of quick questions on #beagle. :-) Jun 26 16:00:27 :) Jun 26 16:00:32 <_av500_> vvu: usb analyzer we have Jun 26 16:00:47 usbmon Jun 26 16:01:13 <_av500_> vvu: I have a HW one Jun 26 16:01:16 <_av500_> real one Jun 26 16:01:26 * vvu bows in front of that device Jun 26 16:01:38 but imaginary ones are so much more portable Jun 26 16:01:50 <_av500_> right Jun 26 16:01:54 <_av500_> ours is in paris Jun 26 16:01:57 <_av500_> need to get it sent Jun 26 16:02:39 is that a real Cat? Jun 26 16:02:45 or a cheaper alt? Jun 26 16:03:16 <_av500_> ds2: forgot Jun 26 16:03:47 everyone ready to give *super-quick* updates on progress? I know some of you have made your first (or second or third) blog posts. Jun 26 16:04:11 also, the other thing I need is dates on when anyone becomes blocked on hardware or any other issue. Jun 26 16:05:37 /msg NickServ ghost hatguy Jun 26 16:06:34 i2c driver is coming along. I can read the BBB eeprom with it. I'm working on interfaces now (API from other drivers and the /dev interface). Got BeagleBoard-xM. Waiting on Weather Cape but it isn't blocking my progress. Jun 26 16:07:01 jkridner|work: all of my people have hardware Jun 26 16:07:57 prpplague: thanks! Jun 26 16:08:12 hi Jun 26 16:08:16 jkridner|work: for the android boot project i have a linux port that is working*64bit machine tested*. tried to switch to Android device with the code but there are kernel problems. OTG support needs to be removed, RNDIS_HOST must be activated. at this point the kernel needs to be patched with some config options. no hardware block. more need testing devices like Samsung Galaxy S3/S4 and some tablets. Jun 26 16:08:22 tcort: do you have a date you need the weather cape by? Jun 26 16:09:01 jkridner|work: i have the basic gpio infrastructure up in the Energia code, alongwith the pinmux... we also have a makeshift makefile... working on making it more generic Jun 26 16:09:23 jkridner|work: I'm not sure. Maybe sometime around the mid-term evaluation (in a month). Jun 26 16:09:58 jkridner|work we have a target to get "Blink" working by next week Jun 26 16:10:12 av500: do you understand vvu's issues? Jun 26 16:10:16 <_av500_> yes Jun 26 16:11:20 anujdeshpande, hatguy: do you feel you are able to split the work effectively? are you both able to make coding progress this week? Jun 26 16:11:28 jkridner|work: have created a bash file to compile, upload and execute c code. currently has basic compilation, will include makefile in it this week. Also have covered the generic functions for reading/writing to /sys. that will be integrated with hatguy's work this week. Jun 26 16:12:20 jkridner|work: yepp. we have complemented each other's work till now. this week we are in a position to get it all together and have the blink demo. Jun 26 16:13:09 jkridner|work: yes... like anujdeshpande said, we shall need a day or two to integrate our work each week Jun 26 16:13:48 anujdeshpande, hatguy: will your code work with and without the IDE? The Makefile seems like a couple-hour thing to get out of the way before implementing real functions. Jun 26 16:14:49 anujdeshpande, hatguy: do get Blink, do you have pinMode and digitalWrite working now? have you reviewed it with Linux heads like panto and gregkh to see if it is a reasonably efficient approach? Jun 26 16:15:23 vvu, _av500_: are you able to get the testing devices you need? Jun 26 16:15:48 jkridner|work: some samsung galaxy tabs i can get to test, but i dunno anybody with S2/S3 Jun 26 16:15:56 maybe S2 i can get a hang for one a day or two Jun 26 16:16:04 jkridner|work: the arduino compilation isn't that straightforward since I'm taking some functions from arduino-1.5.x.... the makefile we are using doesn't support that... but it should be done in a day.... Jun 26 16:16:08 <_av500_> vvu: jkridner|work: i should get access to that Jun 26 16:16:22 warning on the US version of the S3 - OTG/Host mode seems to not work. Jun 26 16:16:29 jkridner|work: now i have a nexus 7, a galaxy nexus and a samsung chat Jun 26 16:16:37 jkridner|work: integrating the arm toolchain in the ide isn't a priority right now Jun 26 16:17:17 vvu: I have a galaxy SII and I am not setup so I can help out if needed Jun 26 16:17:45 perfect for this one. will have a nexus 4 after midterm i think Jun 26 16:17:53 and maybe a htc one Jun 26 16:17:57 to test another brand Jun 26 16:18:07 jkridner|work: Blink should be done by next week alongwith some clean up... digitalWrite() and pinMode() works, however i haven't reviewed it with panto or gregkh yet... i will after we integrate anujdeshpande's code Jun 26 16:18:31 jkridner|work, you might be interested to hear that I managed running C code in the PRU Jun 26 16:18:39 panto: sweet! Jun 26 16:18:45 a port of the arduino stuff should be possible Jun 26 16:18:52 even sweeter! Jun 26 16:18:54 awesome Jun 26 16:19:01 where is the PRU guy? Jun 26 16:19:03 but there are lots of niggling problems with linux stuff Jun 26 16:19:09 gregkh, are you here? Jun 26 16:19:21 <_av500_> pesky linux Jun 26 16:19:28 panto: you have C ported to the PRU? Jun 26 16:19:29 I need to talk to someone which knows the virtio layer Jun 26 16:19:32 panto: is that something you'd be looking at doing? it would certainly qualify as one of my spare-time projects. would be good to start a repository for shared contributions. Jun 26 16:19:32 yes Jun 26 16:19:45 I think panto is using the TI C compiler, no? Jun 26 16:19:47 panto: gcc or smallC? Jun 26 16:19:49 jkridner|work, you have no idea how much I have stuff to do Jun 26 16:19:54 TI C compiler Jun 26 16:19:59 ah. so not free Jun 26 16:20:01 even C++ works Jun 26 16:20:02 panto: I do have an idea. :-) Jun 26 16:20:14 but the environment is _constricted_ Jun 26 16:20:23 a full printf blows away all the code space for example Jun 26 16:20:33 <_av500_> no c++? Jun 26 16:20:43 c++ is there Jun 26 16:20:46 I wonder how heavily patented is the PRUSS Jun 26 16:21:00 but run any kind of template crap and you'll blow away that 8K code limit Jun 26 16:21:15 there are also some hardware bugs that no-one mentioned Jun 26 16:21:18 progress: found workaround for issue with uio_pruss I had. so I should be about ready in terms of coding for it. Jun 26 16:21:32 like that access to the data ram of the PRUs when it's running results in garbage Jun 26 16:21:40 panto: I'd want to find some way to get TI to allow dynamic contributions to a replacement standard library such that printf could be implemented with messages to the print services of Linux, without needing to make special code. Jun 26 16:21:42 probably arbitration is not running properly Jun 26 16:21:49 Need to design a more concrete idea of how i plan to implement Jun 26 16:21:50 jkridner|work, I have a better way Jun 26 16:21:59 messages are not needed Jun 26 16:22:16 I have a way to do a PRU syscall to linux that handles all that Jun 26 16:22:20 I meant that in a generic sense.... circular buffers or whatever. Jun 26 16:22:25 jkridner|work: it might useful to create a PRUSS clone in Verilog/VHDL for development purposes (i.e. emulator on a FPGA) Jun 26 16:22:30 jkridner|work: Jun 26 16:22:33 Bricked and then reflashed the BBB. it took a few days of my time ;). Jun 26 16:22:33 panto: cool. Jun 26 16:22:37 Working on the ADC drivers for our 3.8 tree. A good patchset was submitted and accepted in mfd-next. I ported its changes. Jun 26 16:22:41 Debugged the mess because some macros/data structures of IIO had changed between 3.8 and mfd-next. Jun 26 16:22:41 jkridner|work: also a good idea to test is android on BBB to boot another BBB Jun 26 16:22:43 updated koen and gregkh about the progress. Jun 26 16:22:47 Still testing the ADC driver. If all is well *hopefully* I'll look into the changes in the arago tree than can be brought in as well. Jun 26 16:23:05 panto: I'm here, sorry was responding to email in a different window, what's up? Jun 26 16:23:10 hi gregkh Jun 26 16:23:13 jj2baile: are you getting guidance from your mentors on the approach you'll need to take? Jun 26 16:23:21 need to bounce a few things against you Jun 26 16:23:39 jkridner|work, yes Jun 26 16:23:44 panto: go ahead. Jun 26 16:23:46 vvu: are you sure the OTG problem is from the ROM? at a first guess, I'd think the PMIC would kind of block that stuff Jun 26 16:23:58 <_av500_> block? Jun 26 16:23:59 are you familiar with the virtio stuff? Jun 26 16:24:04 jkridner|work: Yes, i think this is going well Jun 26 16:24:05 ds2: dunno what PMIC means Jun 26 16:24:09 <_av500_> ds2: lets discuss this outside Jun 26 16:24:14 _av500_: ok Jun 26 16:24:19 panto: anyway, it would be great if it could be a drop-in replacement for the C standard library such that where the compiler runs you simply get a binary that does the syscalls, etc. without needing to configure anything special. Jun 26 16:24:20 <_av500_> aka later Jun 26 16:24:23 yes Jun 26 16:24:24 we have some use cases that will require extending it Jun 26 16:24:33 vvu: will get back later with av500 Jun 26 16:24:42 jkridner|work, I've done all that before (but for a different SoC) Jun 26 16:24:47 ds2: ping me when discussion starts if i`m not around Jun 26 16:24:57 jj2baile, ZubairLK: will either of you be blocked on hardware at some point? Jun 26 16:24:59 similar idea, but with a different implementation Jun 26 16:25:05 panto: please prefix your messages so I can pick them out from the crowd :) Anyway, why do you want to "extend" virtio? What's wrong with it as-is, and what are you trying to do that doesn't work for you? Jun 26 16:25:34 gregkh, first of all the number/type of virtio devices is not enough for our cases Jun 26 16:25:46 jkridner|work: Not for now. Jun 26 16:25:56 panto: what is your "case"? Jun 26 16:25:57 jkridner|work: Sorta. Not completely blocked I guess. I want to test the touch screen as well. My work could be breaking it v.badly for all i know :p Jun 26 16:26:06 jj2baile: have you been mostly working with ka6sox? Jun 26 16:26:20 koen: have you seen your student on IRC? Jun 26 16:26:20 gregkh, using the PRUs to implement various hardware peripheral Jun 26 16:26:24 *peripherals Jun 26 16:26:35 ds2: Somewhat yes, but the project related discussion has been happening in beagle-gsoc Jun 26 16:26:41 or at least, majority of it... Jun 26 16:26:53 jkridner|work: just fyi, i've had hatguy and anujdeshpande working directly to make sure they have a functional test environment. with that in mind the next step is to get a simple sketch to compile, upload to the black, execute it, and get feedback Jun 26 16:26:53 panto: what's a "PRU"? virtio is for guest operating systems, like kvm guests. are you using kvm? Jun 26 16:26:55 gregkh, think stuff like I2C controllers, PCI bridges in S/W Jun 26 16:27:01 koen: can we let him know that he needs to get on and interact with everyone else? he doesn't need to be on *every* week, but we need him interacting with the group at some points. Jun 26 16:27:14 gregkh, no, it's not just for guest operating systems anymore Jun 26 16:27:26 jj2baile: Okay. just checking. i see some but not a lot but here isn't that much going on yet :D Jun 26 16:27:42 gregkh, people used the underlying transport (vrings) for rpmsg at first Jun 26 16:28:11 and then some guys from STE implemented a modem using a virtio console/serial device Jun 26 16:28:13 prpplague: great. I know everyone is *very* busy, so we'll need to beat people up to actually try it out. If they can make it super simple to get installed and checked out, it'll help get more feedback that we need. A performance test would help too. Jun 26 16:28:36 prpplague: (and thanks again for staying engaged on this.... I know you are stretched thin.) Jun 26 16:28:41 gregkh, that's what mdp also wanted to do with his 6502 PRU demo, but he run out of time Jun 26 16:28:42 jkridner|work: we are no where near looking at performance Jun 26 16:29:07 panto: yes, the underlying "bus" can be used that way, but what are you really trying to do? How about taking this to email, and cc: the virtio developers / mailing list? Jun 26 16:29:12 jkridner|work: this will be look at pure functionality Jun 26 16:29:24 k Jun 26 16:29:49 gregkh, cause I want to talk to you first, and see if my ideas are at least sound Jun 26 16:30:09 gregkh: checked the mail? could bounce ideas here if convenient.. Jun 26 16:30:17 prpplague, hatguy, anujdeshpande, having a tutorial or exactsteps on how to go from a just bought black to using the code would be useful to keep as an evergreen doc Jun 26 16:30:18 oops. sorry for interrupting. Jun 26 16:30:31 panto: please, email works best for stuff like "I wonder if this type of complex thing would work", much better than dribbling it out over irc. Jun 26 16:30:42 bradfa: we will update the steps to the wiki Jun 26 16:30:43 ZubairLK: no interruption. yes, your emails are great. Jun 26 16:30:55 gregkh, I know Jun 26 16:31:10 but you're around so it doesn't hurt Jun 26 16:31:11 bradfa: noted. we actually have that in our to do Jun 26 16:31:21 ZubairLK: parallel conversations are OK here. Jun 26 16:31:23 anujdeshpande, hatguy, ok, good to hear :) Jun 26 16:31:43 ZubairLK: your latest email sounds like you are on the right track, keep up the great work, and good luck with your move. Jun 26 16:31:47 gregkh: thanks. So on the right track? Test ADC then look for arago tree. Jun 26 16:31:54 ZubairLK: yes. Jun 26 16:31:57 gregkh: great. thanks. :) Jun 26 16:32:04 bradfa, were you able to test jj2baile's pru code? Jun 26 16:32:04 gregkh, we know it works btw, since people are using it already Jun 26 16:32:13 panto: that doesn't mean it should be used that way :) Jun 26 16:32:20 gregkh, too late :) Jun 26 16:32:22 I believe I've heard from everyone but vmayoral (sp?) (koen) Jun 26 16:32:26 panto: and if you have patches, then send them. Jun 26 16:32:37 ka6sox, no, sorry, not yet, do we have exact steps for testing it? I've not yet had a chance to take a look at the github jj2baile put up beyond starring it Jun 26 16:32:48 bradfa: my code doesnt really do all that much visibily since the heardbeat pattern justcontinues after anyway Jun 26 16:32:56 gregkh, there are going to be; so far I haven't had to touch virtio/remoteproc core code at all Jun 26 16:33:01 which was excellent Jun 26 16:33:09 does anyone else have topics to be covered or questions for the entire bb.org GSoC? Jun 26 16:33:15 //win 17 Jun 26 16:33:17 welp Jun 26 16:33:19 gregkh, but there's something that's missing Jun 26 16:33:36 jj2baile, either that's some fancy unicode or my irc can't show it :) Jun 26 16:33:56 * jkridner|work does not want to slow actual problem solving Jun 26 16:34:00 Hi Ceriand Jun 26 16:34:00 gregkh, all the other virtio devices (besides rpmsg) assume a cache-coherent system arch that resembles something like smp Jun 26 16:34:12 hi, sorry I'm late Jun 26 16:34:36 no donuts? Jun 26 16:34:42 heh Jun 26 16:35:04 gregkh, so, AFAIKT, the only thing missing to get my case to work is to simply add an option that flags a vring as requiring device dma like mapping Jun 26 16:35:10 panto: and let me guess, that's not like your hardware. Jun 26 16:35:29 panto: again, ask the virtio developers, that's not me, I have enough on my plate as it is. Jun 26 16:35:33 gregkh, yes, it's not cache coherent Jun 26 16:35:41 panto: sorry. and get some real hardware :) Jun 26 16:35:52 gregkh, not at the $45 range :P Jun 26 16:36:03 <_av500_> rpi is only $35 Jun 26 16:36:04 gregkh, 8kB of ram isnt' much and there is no more to be had. Jun 26 16:36:11 bradfa: yea once we have the basic infrastructure working we can do that, but we are still working out some of the actual build environment details Jun 26 16:36:18 prpplague, I understand Jun 26 16:36:42 gregkh, I am trying to avoid writing a completely new driver model for the PRU; re-using code is good, no? :) Jun 26 16:37:03 panto: not if it doesn't fit the same model. don't abuse virtio just because it "is there". Jun 26 16:37:37 gregkh, I don't plan to abuse it - it already does what I need Jun 26 16:37:56 jkridner|work: ping on the touchscreen cape requirement.. Jun 26 16:37:58 or do you know if there is an alternate way of testing the AIN pins to keep going. Jun 26 16:38:00 i'm blind if my work is breaking the other driver. Jun 26 16:38:07 there's only a minor flag missing saying 'this is a device requiring dma accessors' Jun 26 16:38:19 ZubairLK: what do you need to test? Jun 26 16:38:22 AIN can be tested with a variable resistor or fixed resistors. Jun 26 16:38:35 if it is just the ADC, a 10K pot Jun 26 16:38:45 but ADC via the touchscreen driver.. Jun 26 16:38:46 if you need to trigger events, put a resistor ladder with another resistor in series with a switch to trigger an event. Jun 26 16:38:47 wiper to input, one end to GND, the other end to 1.8V Jun 26 16:39:03 ds2: +1 Jun 26 16:39:09 jkridner|work, btw, is the TI PRU compiler going to be free? Jun 26 16:39:13 thats for testing adc only via its adc iio driver. Jun 26 16:39:17 you can fake out a touch screen using 4 resistors Jun 26 16:39:22 for touchscreen, just put another resistor in series with a switch to give quick jumps to the voltage. Jun 26 16:39:27 panto, as in Beer? Jun 26 16:39:27 ds2: thats what i wanted to ask Jun 26 16:39:38 for a given pair, keep the resistance to sub 4.7K Jun 26 16:39:40 panto: yes, free as in beer. Jun 26 16:39:46 and hints on the software side of things? Jun 26 16:39:46 excellent Jun 26 16:39:56 * jkridner|work wants an ARM version, but isn't likely to get it. Jun 26 16:39:59 do i ping the tsc driver via sysfs? Jun 26 16:39:59 we will also need a build for ARM too Jun 26 16:40:05 so that we can run it on the bone Jun 26 16:40:10 look at how a resistive touch screen works (see wikipedia). you want to fake out the 4 wire version (2 are for X, 2 are for Y) Jun 26 16:40:27 tsc should be via the input devices Jun 26 16:40:36 look at evtest.c Jun 26 16:40:46 I'll look into it. Jun 26 16:40:57 ds2: jkridner|work thanks :) Jun 26 16:40:59 if you want to emulate a touchscreen, you can also get two linear pots for the two axises Jun 26 16:41:00 ZubairLK: please review the interfaces to be tested with your mentors. I believe you'll want to test both SYSFS entries as well as any syscalls provided by IIO. Jun 26 16:41:17 <_av500_> panto: or make it a "web compiler" :) Jun 26 16:41:24 Ceriand: agreed, but you'll still need some way to change the resistance quickly. Jun 26 16:41:25 only if the page is pink Jun 26 16:41:26 you know what. thats actually a pretty good question. Jun 26 16:41:28 i Jun 26 16:41:33 panto: prehaps port smallC? Jun 26 16:41:36 * jkridner|work highly recommends using the PWMs to build a self-contained test bench. Jun 26 16:41:39 I'm not certain what has to be tested completely. :) Jun 26 16:41:57 see http://beagleboard.org/support/BoneScript/wired_basic_test/ Jun 26 16:41:57 ds2, the PRU is pretty trivial to implement a c compiler for Jun 26 16:42:02 i'll send an email Jun 26 16:42:07 it is 32 bit after all Jun 26 16:42:19 it's only problem is the very limited insn space Jun 26 16:42:22 panto: yes but gcc has a lot of crap. hence the suggestion of small C Jun 26 16:42:31 small C has been ported to even the 6502! Jun 26 16:42:32 or llvm Jun 26 16:42:38 +1 llvm Jun 26 16:42:39 heh Jun 26 16:42:43 I haven't seen llvm on such small chips Jun 26 16:42:44 panto, +1 Jun 26 16:42:58 * ds2 looks at khem Jun 26 16:43:00 ds2, PRU is not so bad really Jun 26 16:43:02 }:-) Jun 26 16:43:14 panto: is it more stripped down then those small AVR32's? Jun 26 16:43:24 ds2, no, it is not Jun 26 16:43:37 reminds me of old RISCs Jun 26 16:43:49 weird multiply and no division Jun 26 16:44:12 panto, sounds like msp430 Jun 26 16:44:12 hmmm and they have gcc for avr32's Jun 26 16:44:29 the msp430 is 16bit though Jun 26 16:44:31 panto, let me know what is needed for our PRU interface on the other side when ready Jun 26 16:44:36 ds2, true, so msp430 on crack Jun 26 16:44:45 (and jj2baile too!) Jun 26 16:45:00 let me show what I mean... Jun 26 16:45:01 ZubairLK: please get what needs to be tested clarified with your mentors. I recommend using PWMs to test the ADCs with an appropriate set of caps and resistors, that way testing can be automated. Jun 26 16:45:01 http://pastebin.com/h9nJKZKe Jun 26 16:45:05 bradfa: and I think that is the case for the designers of the PRU ;) Jun 26 16:45:16 note that I also have protothreads running Jun 26 16:45:26 jkridner|work: thanks for the tip Jun 26 16:45:28 ZubairLK: I believe all interfaces provided by the ADC IIO driver (SYSFS and IIO syscalls) need to be tested. Jun 26 16:45:30 ZubairLK: what are you studying at school? Jun 26 16:45:41 ds2: Msc embedded systems. Jun 26 16:46:08 ZubairLK: have you gone through RC filters, time constants, etc? Jun 26 16:46:16 please consider the official part of the weekly meeting completed and please continue to interact to solve your project challenges! Jun 26 16:46:29 yes. sysfs and iio syscalls . and also the touchscreen input alongside adc channels working Jun 26 16:46:41 gregkh, so anyway, I wanted to use the standard virtio infrastructure for comms; if that doesn't work, I'll just use custom interfaces anyway Jun 26 16:46:43 ds2: rc. long time ago in a galaxy far away during UG. :) Jun 26 16:47:11 ZubairLK: just wanted to make sure PWM and filtering isn't too much over your head Jun 26 16:47:44 i am wondering if i could generate a sinusoid via audio output of my laptop and read it on the BBB via ain Jun 26 16:47:56 panto: what type of "custom" interface do you mean? Jun 26 16:47:59 And what the hardware implications might be.. Jun 26 16:48:02 hmmm. Jun 26 16:48:20 PRU specific interface between the kernel drivers and the PRU Jun 26 16:48:21 ZubairLK: audio is usually bipolar, whereas the ADC is single-ended IIRC Jun 26 16:48:25 dont really know of voltages. Jun 26 16:48:34 ZubairLK: bias the ADC to 0.9V, then AC couple it. and make sure the P-P of the audio is not > 1.8V Jun 26 16:48:38 instead of transporting generic virt device data Jun 26 16:48:42 adc is single ended indeed. Jun 26 16:48:47 ZubairLK: it might work if you bias it so it's all above 0V Jun 26 16:49:04 ds2: thats the answer Jun 26 16:49:16 tbh. i'm not that good with electronics Jun 26 16:49:18 ZubairLK: a signal generate would probably be the best solution for external equipment Jun 26 16:49:24 *generator Jun 26 16:49:27 Ceriand: isn't single-ended the wrong term in this case? it is really unipolar Jun 26 16:49:36 gregkh, so, if the PRU implements a PWM device, there's going to be a generic virtio_pwm.c driver that will work for the PRU and any other implementation adhering to the interface Jun 26 16:49:40 ds2: correct Jun 26 16:49:47 have access to signal gen in the lab. but my setup and work time is usually night and at home.. Jun 26 16:50:05 gregkh, otherwise there will be a pru_pwm driver that is going to do it via it's own method Jun 26 16:50:11 If I have time, I should look up to see if that ADC can go into differntial mode Jun 26 16:50:34 panto: why not use the pwm interface then? Jun 26 16:50:47 i dont think the driver will like that. dont see any mention anywhere.. dont know the hardware side of things on the processor Jun 26 16:50:48 gregkh, I will; for the user-side facing part Jun 26 16:51:07 gregkh, the idea is that I wouldn't have to write a PWM specific PRU driver Jun 26 16:51:29 the PWM specific part will be in the firmware loaded in the PRU, the kernel driver will just load the firmware Jun 26 16:51:45 panto: ok, I'm lost, please, email works best. Jun 26 16:51:57 gregkh, ok, maybe later tonight Jun 26 16:52:14 in the middle of rebasing on 3.10rc and not a happy camper ATM Jun 26 16:52:46 ds2: i use two 10k res to make a 0.9v bias. Connect that point to ain.. Jun 26 16:52:49 connect the ground of the audio out to ground of bbb. Jun 26 16:52:51 connect the audio signal via a cap to the 0.9v bias. Jun 26 16:53:48 the primitive i have right now is to simple get a battery. ground one end and apply 1.5 v on the adc pin :p Jun 26 16:53:58 simply* Jun 26 16:55:38 ZubairLK: should, work as long as the audio is the standard 1V peak-to-peak Jun 26 16:56:37 thanks. i'll see and assemble some testbench. been a long while since I played with circuits.. Jun 26 17:00:03 okay, off to work Jun 26 17:00:04 bbl Jun 26 17:00:37 av500: should i continue starting to code with this rndis hack to kernel or inspect more what is going on? Jun 26 17:00:48 ZubairLK: watch the value of the cap Jun 26 17:00:57 tips? Jun 26 17:01:12 this is a slow ADC so you can't put in that fast of a signal Jun 26 17:01:28 maybe 22uF ceramics? you need to do the math on this :D Jun 26 17:01:28 <_av500_> vvu: I would like to know what this rndis hack does Jun 26 17:01:44 <_av500_> so, what other data is tranferred besides the bootp data Jun 26 17:02:00 ok so u-boot printfs around Jun 26 17:02:02 ds2: i'll go test it in the lab with a function generator :) Jun 26 17:02:02 PMIC = Power Management IC. it is that big TPS part Jun 26 17:02:03 <_av500_> but you can also code the java part more Jun 26 17:02:16 ZubairLK: problem is the impendence at your ADC matters Jun 26 17:02:16 <_av500_> reply to the bootp Jun 26 17:02:19 ZubairLK, I've used an ipod as a signal generator Jun 26 17:02:25 if you don't need high speed stuff Jun 26 17:02:35 <_av500_> vvu: ds2 bbl Jun 26 17:02:36 absolutely dont need high speed at all Jun 26 17:02:52 I've also used this for signal generation: http://www.gabotronics.com/development-boards/xmega-xprotolab.htm Jun 26 17:02:54 let me do a call... BBL myself Jun 26 17:03:01 Russ: thankyou russ. tips? Jun 26 17:03:06 but the PWM is nice Jun 26 17:03:09 you just need a proper iflter Jun 26 17:03:10 filter Jun 26 17:03:20 and use a high enough base frequency Jun 26 17:04:21 for the ipod, I just generate the wav file, convert to mp3, transfer to ipod, play on loop Jun 26 17:04:35 i think i'll just use a potentiostat.. no need to spend time on something fancy.. Jun 26 17:04:47 interface to adc? Jun 26 17:05:06 or just directly. ground to ground and signal to adc pin? Jun 26 17:05:19 the same thing you were using, capacitor and biasing resistor Jun 26 17:05:26 i see. Jun 26 17:05:27 er, resistors Jun 26 17:05:51 thanks for the help ds2 and Russ Jun 26 17:06:07 i should get going Jun 26 17:06:10 GN folks :) Jun 26 17:07:21 https://plus.google.com/107046448275336404830/posts/bePofShxT7e Jun 26 17:08:15 just watch the impedences Jun 26 17:08:45 actually - for people watching the logs - do NOT use the PWM for this purpose Jun 26 17:09:02 the PWM is a 3.3V signal, the ADC is a 1.8V signal. So if the PWM gets stuck high, you are F'ed Jun 26 17:17:49 ds2, you'd need a capacitor to block dc, and then a resistor network to bias the signal Jun 26 17:20:34 Russ: and you need to work out the attentuation... as you can still exceed the 1.8V range Jun 26 17:23:26 true Jun 26 17:23:39 but getting stuck at DC won't get you there at least Jun 26 17:24:51 http://s-macke.github.io/jor1k/ Jun 26 17:24:57 cool :) Jun 26 17:26:31 woops, looks like I missed a meeting Jun 26 17:48:49 is someone up late 3D printing again? :D Jun 26 17:49:21 nah, 6pm is food time Jun 26 17:49:28 so I missed the reminder and the meeting Jun 26 17:49:38 ah Jun 26 17:49:40 I'll read the minutes Jun 26 17:51:46 koen: don't think ur student was there either Jun 26 17:52:38 koen: upgrading to a startasys printer soon? Jun 26 18:31:09 ds2: unlikely, I'm happy with my current printers Jun 26 18:41:51 koen: do we need the helper that read adc values? Jun 26 18:42:13 I'm able to read them from /sys/bus/iio/device/in_voltage fine. Jun 26 18:42:30 i think the helper tries to show them in mV rather than scaled to 4098 Jun 26 18:43:00 and did you have time to go through the email? Jun 26 18:44:31 at least it reads in one go instead of twice. Jun 26 18:44:56 and for some reason cat in_rawvoltage* to read all values wouldnt work on the previous kernel. now it does. :) Jun 26 18:51:47 for some reason they seem to be out of order :s. Or the labels on the pins are reordered somewhere.. Jun 26 18:52:23 and two of the channels give the value on the second read. Jun 26 18:57:41 av500: ping Jun 26 18:58:51 or ds2 for that matter Jun 26 19:15:54 ZubairLK: the helper was a workaround for missing sysfs entries Jun 26 19:16:13 ZubairLK: in general the adc driver is full of bugs, lot's of fifo problems Jun 26 19:16:21 yea. i can see.. Jun 26 19:16:44 should the output be in mV or is the 4098 scaled values ok? Jun 26 19:16:47 from sysfs.. Jun 26 19:17:58 also.. any idea if the problem is on the ADC driver itself. As in. the actual hardware interaction. or if the wrappers of iio messing things.. Jun 26 19:18:05 wouldnt exactly know i guess. Jun 26 19:18:20 IMO somethign called "in_voltage" should return a voltage, not an dump of the ADC register Jun 26 19:18:38 hmm. correct. should return voltage Jun 26 19:18:49 but I don't know the convention, you'd have to ask the IIO guys to be certain Jun 26 19:21:18 checked an analog devices driver for iio. it has in_voltage raw which is correct. the raw values without scaling or bias. Jun 26 19:21:33 but it also gave in_voltage_scale which was scaled by the driver.. Jun 26 20:04:00 vvu: pong Jun 26 20:04:52 can you explain what you said during the meeting about the block? Jun 26 20:05:46 the PMIC should limit what can be done on the VBUS Jun 26 20:05:59 let me pull up a schematic since I am at a place I can do that Jun 26 20:06:06 ok Jun 26 20:07:52 blah wrong schematics. give me a few more Jun 26 20:10:38 okay Jun 26 20:10:51 if you look at teh schematic, vbus is hooked up to the processor, USB socket, ESD chip, and the PMIC Jun 26 20:11:05 the OTG stuff works by VBUS pulsing Jun 26 20:11:33 in order for it to happen here is if the processor pulses VBUS Jun 26 20:11:42 yep Jun 26 20:11:44 but if that happens, the PMIC will have power issues Jun 26 20:11:50 ds2, btw, there's a way to control vbus without going through the usb driver Jun 26 20:12:02 so if your sole power is the USB, you'd risk reseting yourself Jun 26 20:12:16 panto: you talking about SWwise or HW wise? Jun 26 20:12:35 "USB driver" == FET on the VBUS line or is it the MUSB code you referring to Jun 26 20:12:47 are we talking about the host port vbus, or not? can't tell Jun 26 20:12:53 no, device power Jun 26 20:13:01 USB0 on the AM335x Jun 26 20:13:12 oh, sorry then Jun 26 20:13:14 carry on Jun 26 20:13:24 you mean the VBUS enable GPIO stuff on the host port (USB1)? Jun 26 20:13:46 yes Jun 26 20:13:51 vvu: is my claim making any sense? Jun 26 20:14:15 i`m not an expert in this area but it does, for a non-knower. Jun 26 20:14:24 let me ask my dad, he knows some elctronics here Jun 26 20:14:33 ok Jun 26 20:14:52 vbus is data line ? Jun 26 20:15:20 no Jun 26 20:15:30 the mini USB port has 5 wires on it Jun 26 20:15:38 ID, GND, DM, DP, VBUS Jun 26 20:15:54 ID is used to identify host vs device on initial connect. Jun 26 20:16:02 ok Jun 26 20:16:02 the beagle has that perm. floating so it is a device. Jun 26 20:16:08 GND is obvious. Jun 26 20:16:10 yes Jun 26 20:16:26 DM/DP is the data signals. normal USB is differntial. but there are special meanings for them in single ended mode. Jun 26 20:16:44 voltage bus, VB Jun 26 20:16:47 right ? Jun 26 20:16:53 that leaves VBUS - it is normally use to provide power. Hoewver, OTG, specifically HNP uses pulsing on that line to signal to the otehr side that it may want to switch roles Jun 26 20:17:11 you can look at the OTG supplement. I think it started with USB 2.0. Jun 26 20:17:16 yes Jun 26 20:17:22 and PMIC is powered by the vbus line ? Jun 26 20:17:28 for a simple host/device, VBUS is 5V Jun 26 20:17:42 it`s high, yes Jun 26 20:17:47 PMIC can take power from either the VBUS line, the 5V barrel jack, or the battery input on the power header Jun 26 20:18:06 my config now is having jack 5v powered Jun 26 20:18:24 but the AM335x doesn't know that initially Jun 26 20:18:49 the PMIC does a magic switch. if 5V is in, use that. if there is a battery use that. if there is USB, use it up to the configured limit Jun 26 20:19:15 but whare are the hardware priorities for power for the pmic ? Jun 26 20:19:29 look at the data sheet Jun 26 20:19:59 TPS65217C Jun 26 20:20:03 it should be on ti's site Jun 26 20:21:42 that thing is losing me Jun 26 20:21:49 in what way? Jun 26 20:22:19 usb is pin 12 Jun 26 20:22:22 lemme look a bit Jun 26 20:24:16 i think it starts with usb voltage then switches to jack Jun 26 20:24:45 consider the case where only a USB jack is connected Jun 26 20:24:49 and besides Jun 26 20:25:01 if you put in a hub in there, it will take this entire ROM doing bad OTG out of the equation Jun 26 20:25:16 no, i was saying bullshit. doesn`t makes sense when have only jack Jun 26 20:25:33 not true, tested with a hub in between Jun 26 20:25:44 the hub would have filtered out the OTG signals Jun 26 20:25:48 same HNP stuff Jun 26 20:25:51 as a hub cannot by definition be a device Jun 26 20:26:00 in that case, there is some other crap going on Jun 26 20:26:10 mhmh don`t have a hub right now home to test but i fairly remember that thingie Jun 26 20:26:26 I am not disputing your results. I am disputing the conclusions :) Jun 26 20:26:31 yep :) Jun 26 20:27:24 i think trying to repair all this stuff will take me ages Jun 26 20:27:32 yes Jun 26 20:27:48 not so much repair it as much as figuring a work around with minimal impact Jun 26 20:27:56 this is why i`m trying to patch everything i can to make it work in *some* way, better than nothing Jun 26 20:28:03 OTG on most drivers is broken. that's why most devices are not officially certified as OTG Jun 26 20:28:16 yes Jun 26 20:28:25 and fix it at the end if possible Jun 26 20:28:34 also now i can get data from the ROM Code Jun 26 20:28:40 i can *speak* with it Jun 26 20:28:50 patched the kernel of my android with RNDIS Host support Jun 26 20:29:03 but u-boot still fails miserably there Jun 26 20:29:16 RNDIS support is just moving the driver into the kernel Jun 26 20:29:27 that is cheating based on your prior goals Jun 26 20:29:34 yeah :) Jun 26 20:29:46 how does u-boot fail? Jun 26 20:29:52 http://pastebin.com/EEJ1cQZ9 Jun 26 20:29:54 didn't think U-boot implements RNDIS Jun 26 20:30:13 yep Jun 26 20:30:17 does same thingie as ROM Jun 26 20:30:30 is that paste w/RNDIS enabled in the kernel? Jun 26 20:30:44 yep with rndis enabled Jun 26 20:31:08 CONFIG_RNDIS_HOST i think is the option to enable Jun 26 20:31:24 it almost seems like the host end (N7) didn't see a reason to re-enumerate itself Jun 26 20:31:38 whereas the BBB thinks the bus should be re-enumerating Jun 26 20:31:53 wonder if you need to force a reset on the BBB when U-boot starts Jun 26 20:32:08 i checked the line where it says it fails in ether.c Jun 26 20:32:12 and it checks a timer there Jun 26 20:32:26 and i made the timer way bigger than normal and same result, thought maybe n7 is slow there Jun 26 20:32:34 nah Jun 26 20:32:38 I think the 2 sides are confused Jun 26 20:32:51 do you see the BBB being enumerated again when u-boot starts? Jun 26 20:33:02 yep i get new device in dmesg Jun 26 20:33:11 hmmm Jun 26 20:33:17 that kind of kills my theory Jun 26 20:33:35 * vvu hopes will get something to work in the end! Jun 26 20:33:52 look at it with usbmon? Jun 26 20:34:15 nop i will do in a couple of moments Jun 26 20:34:35 still think they are confused Jun 26 20:36:29 ds2: n7 usb port is bus 2? Jun 26 20:37:52 donno off hand, sorry. Jun 26 20:39:36 ds2: this is the dmesg from when i connect u-boot rndis http://pastebin.com/0f0Gficm Jun 26 20:40:33 ok Jun 26 20:42:49 how can i send you the .pcap received from tcpdump? i`m not an expert in usb communication. can you take a look at it when you have time? Jun 26 20:43:51 ds2: http://vdev.ro/log.pcap Jun 26 20:49:49 vvu: that is a pretty spare trace...can you grab it with the more rebose options? Jun 26 20:51:27 more capture ? Jun 26 20:51:41 yeah Jun 26 20:51:54 normal ethernet uses -s 0 to capture the full stuff... donno if htat works on this Jun 26 20:52:01 or was it -s -1 Jun 26 20:52:02 that is from the start of bootp command in u-boot until it switches to rj45 Jun 26 20:52:03 one of those Jun 26 20:52:17 tctpdump -i usbmon2 -w file Jun 26 20:52:20 I mean more details on what the transactions are Jun 26 20:52:39 try adding '-s 0' to it Jun 26 20:55:07 grab it again from same link Jun 26 20:56:29 no difference Jun 26 20:56:40 ask av500 later... I need to goto a mtg Jun 26 20:57:03 okok Jun 26 21:23:34 sorry missed again, added a reminder to the calendar, hope that'll work (and apologies for missing the meething) Jun 26 21:27:47 eFfeM: here's a log http://tomcort.com/gsoc/meeting-2013-06-26.log Jun 26 21:27:58 tcort: thanks Jun 26 21:28:27 just went over progress / problems for each of the projects Jun 26 21:28:28 will try to behave better, but it is a difficult time for me (6 pm) Jun 26 21:28:49 tcort: don't think you have problems :-) Jun 26 21:28:56 :) Jun 26 21:29:53 thought you already had the cape Jun 26 21:30:11 Ben created a Google doc with the overall design. I'm working through that -- currently working on the interface that will be used by other drivers and the device files /dev/i2c-1 Jun 26 21:30:27 nope. I just have the BeagleBone Black and BeagleBoard-xM. Jun 26 21:31:15 I think I will need to do the same for quite a few other drivers. Jun 26 21:31:52 eFfeM: I also bought some EEPROM chips to test with (the same kind that are on the capes). Jun 26 21:32:29 saw you got eeproms; actually isn't there an i2c device on the bone itself Jun 26 21:33:03 saw the doc of ben Jun 26 21:33:07 the bone has an EEPROM on the first bus, but I wanted to test the other two buses. The BeagleBoard-xM doesn't have an on board EEPROM Jun 26 21:35:46 ah ok Jun 26 21:49:11 calling it a day Jun 26 21:49:35 have a good evening. see ya later. Jun 26 22:35:01 ds2: any chances my cable to be messed up ? Jun 26 22:35:05 the otg adapter? Jun 26 22:35:29 sometimes i need to plug out and plug in the adapter even if i reset the board from the button, to be enumerated right Jun 26 22:38:35 ds2: and i get something like http://pastebin.com/8e49QgM9 Jun 26 22:50:00 vvu: it is possible Jun 26 22:50:06 i know I had one go bad on me Jun 26 22:50:13 and this was a nice one from digikey Jun 26 22:50:18 can that be the root of all problems ?:) Jun 26 22:51:24 donno about the RNDIS one Jun 26 22:51:29 but the rest, it is possible Jun 26 22:51:55 because now Jun 26 22:52:03 same sh*t as yesterday Jun 26 22:52:10 with my .config file cannot read from device Jun 26 22:52:15 and couple of hours ago Jun 26 22:52:16 worked Jun 26 22:52:51 chainfire told me from the start to check another otg cable Jun 26 22:52:59 where did you get the adapter? Jun 26 22:53:24 some random company from my country Jun 26 22:53:28 oh Jun 26 22:53:30 nothing *well-known* Jun 26 22:53:35 try another one if you can Jun 26 22:53:41 and i want to buy a nokia one, maybe will work Jun 26 22:54:08 it`s pissing me off really bad :) Jun 26 22:54:19 i know the feeling Jun 26 22:54:31 hope i will get something to work in a week or so Jun 26 22:54:41 i had a friend who likes to cut up bad cables to prevent it from causing issues Jun 26 22:55:36 this seems ok ? http://www.amazon.co.uk/computers-accessories/dp/B004APRKLS Jun 26 22:55:49 it`s micro usb so it would work unless nokia has some awkward pinout Jun 26 22:56:36 don't see anything obviously wrong with it but I donno for sure Jun 26 22:56:41 some listings on amazons are just wrong Jun 26 22:56:49 which one do you have? Jun 26 22:57:38 let me see if I can find it Jun 26 22:58:36 http://www.amazon.com/Electronics-Micro-USB-OTG-Cable/dp/B005GGBYJ4/ Jun 26 22:58:40 I think that is one of what I have Jun 26 22:59:05 I also have another one from Amazon that cost $0.99 but turned out different from the pictures and another one from digikey Jun 26 23:01:22 what other ideas of debugging do you have? Jun 26 23:01:44 if I were stuck debugging it, I'd pull out a USB analyzer Jun 26 23:01:55 the traces you gave me lacks detail Jun 26 23:02:08 but i don`t have a USB analyzer, a proper one Jun 26 23:02:14 only usbmon Jun 26 23:02:19 that gives what you have seen Jun 26 23:02:21 in theory USBmon should do Jun 26 23:02:42 I am interseted in known the contents Jun 26 23:03:47 contents of the urbs? Jun 26 23:04:02 yes Jun 26 23:04:07 well, contents that gets sent out Jun 26 23:07:08 can`t i edit some kernel files and make printfs in syslog there? Jun 26 23:07:18 if tcpdump does not take everything ? Jun 26 23:07:20 u can Jun 26 23:07:27 it is a bit painful but you can Jun 26 23:07:56 any idea which function is responsable for the sending? Jun 26 23:09:08 actual sending? Jun 26 23:09:11 yep Jun 26 23:09:12 there is urb_submit Jun 26 23:09:18 actual sending is on the per device basis Jun 26 23:09:27 so either something in musb_host.c or ehci Jun 26 23:09:39 ehci for the n7 Jun 26 23:10:05 yes Jun 26 23:13:46 into drivers/usb/host ? Jun 26 23:14:09 yeah Jun 26 23:18:41 ds2: tegra_ehci_urb_enqueue sounds right? Jun 26 23:19:26 sounds like it Jun 26 23:20:25 from here can i dump into syslog ? i dunno how kernel drivers should work Jun 26 23:20:56 dump to dmesg Jun 26 23:21:15 which can get written to syslog if you have the right thing running but on android, tehre isn't Jun 26 23:21:23 you can use printk in the kernel similar to printf in userspace Jun 26 23:23:00 uoke, struct urb has transfer_buffer. this stuff i need to dump Jun 26 23:23:20 include the ep Jun 26 23:29:16 how can i search dmesg for a message ? Jun 26 23:35:44 ok got it to print a hello world from the enqueue function Jun 26 23:46:41 ds2: understood how it goes tegra ehci calls generic ehci Jun 27 00:04:59 ds2: ping Jun 27 00:14:21 got hexdumps of the urb buffer but they are all over dmesg output, can i dump them to a file ? Jun 27 00:21:34 i think they already go to a file Jun 27 00:21:39 in syslog Jun 27 00:22:03 or you could just do dmesg > log.txt Jun 27 00:22:07 and then read that file Jun 27 00:22:27 vvu: Jun 27 00:22:35 yep Jun 27 00:22:45 i did a way Jun 27 00:22:54 to printk(level "") Jun 27 00:22:57 good Jun 27 00:23:05 but i don`t get the levels in android Jun 27 00:23:16 not familiar with android. Jun 27 00:23:16 i have 15 4 1 7 Jun 27 00:23:21 dunno what 15 level is Jun 27 00:23:24 the rest i get Jun 27 00:23:36 personally. dont use levels. just read them direcly. not that many debug statements.. Jun 27 00:23:47 so only printk("blahblah") :) Jun 27 00:24:20 i need to do some hexdumps from usb requests Jun 27 00:24:34 and different messages come into my hexdumps Jun 27 00:24:38 from other parts Jun 27 00:25:08 any hint how to separate them? Jun 27 00:25:12 i was thinking by log level Jun 27 00:25:27 I guess log level would be the way to go. Jun 27 00:25:46 I've used syslog for userspace only though.. Jun 27 00:26:16 sorry. dunno either. Jun 27 00:26:22 i'm off here. its getting late. Jun 27 00:26:27 gn Jun 27 00:27:09 gn dude Jun 27 00:43:41 ds2: in my hexdumps i can see the full bootp request that comes from the BBB Jun 27 00:45:25 ds2: http://pastebin.com/qU6eTNJL Jun 27 00:45:39 so the messages are received but from there on dunno what happens Jun 27 00:50:19 will try and print info about the endpoints too Jun 27 01:17:53 need to change my cable, again it worked to receive data as in the pastebin now i cannot anymore and only some restart no reflashing or changing code Jun 27 01:18:05 anyway gn channel! Jun 27 01:18:36 good night **** ENDING LOGGING AT Thu Jun 27 02:59:58 2013