**** BEGIN LOGGING AT Tue May 20 02:59:59 2014 May 20 03:14:41 * mranostay bikes in May 20 03:14:46 after 20 miles whew May 20 03:16:00 Abhishek_: except with ethernet sucks :) May 20 03:16:06 depends on the rev of BB iirc May 20 03:53:20 mranostay: currently on RNDIS/USB May 20 07:19:23 Ping vvu May 20 07:33:20 gm praveendath92_ May 20 07:33:54 Hello av500 May 20 07:34:06 Morning :) May 20 07:35:21 I'm updating the repos. Did you see? May 20 07:36:47 no May 20 07:38:19 av500: https://github.com/praveendath92/bard-linux May 20 07:38:48 Actually I wanted to ask two things. May 20 07:39:22 1. A good IRC client for linux. May 20 07:39:41 2. A good debugging tool for kernel modules. May 20 07:41:42 1. irssi May 20 07:41:44 2. printk May 20 07:41:49 I'm having a strange issue with registering a usb driver and I'm not able to test it with printk May 20 07:41:55 hmm May 20 07:42:20 Just a sec. May 20 07:43:05 https://gist.github.com/anonymous/846386f284d485e5be08 May 20 07:43:47 No printk statements after 45 works. May 20 07:45:09 so usb_register never returns May 20 07:46:32 I think so. May 20 07:46:41 http://stackoverflow.com/questions/19602821/writing-a-usb-driver-from-scratch May 20 07:46:47 have a look at the PDF linked there May 20 07:46:51 LDD chapter 13 May 20 07:47:08 you miss the owner member of the structure May 20 07:47:17 not sure thats the issue, but should be added May 20 07:47:26 I will look at that. May 20 07:47:36 Will let you know the outcome. May 20 08:32:53 yep, read the book May 20 08:33:02 praveendath92_: ^^ that thing helped me during OS Lab May 20 08:33:22 I read it before. May 20 08:33:32 Going over it now. Again. May 20 08:33:45 praveendath92_: oki, anyway speak in a little while....exam is upon my now :) May 20 08:35:52 Oh. Sure. Good luck :) May 20 08:52:40 vvu, av500: I added the owner tag. Here is the error log. https://gist.github.com/praveendath92/4f676ccd8a8d7397a492 May 20 08:53:44 I'm still searching for solution. May 20 08:56:14 praveendath92_: well, then owner is gone May 20 08:56:22 so remove it :) May 20 08:56:27 Haha. May 20 08:56:47 Will do. May 20 09:25:15 vvv: Best of luck :) May 20 09:25:22 *vvu: Best of luck :) May 20 09:48:56 praveendath92: fixed it ? May 20 09:49:00 Nope. May 20 09:49:12 so what is wrong now ? May 20 09:49:12 vvu: How was it? May 20 09:49:39 Abhishek_: spoken exam for advance comp networks, really legit :) May 20 09:50:03 Spoken exam. Sounds cool. May 20 09:50:19 yeah we are 6 people in the class that is why May 20 09:50:23 easier like that May 20 09:50:36 * Abhishek_ is reminded of viva-equivalent written test in labs... May 20 09:51:11 Yeah. Small class have their own advantages. May 20 09:51:22 indeed May 20 09:51:44 like for a math course we are like ~80 peeps May 20 09:52:24 praveendath92: so what is not working now ? May 20 09:52:55 I'm getting the gist link. In a sec. May 20 09:53:21 also change the readme with the link for the blog. May 20 09:54:17 Oh yeah. I forgot to update the links. May 20 09:54:23 Will do after this. May 20 09:57:29 praveendath92: leave links here, i will check it out in ~50 mins...gtg May 20 10:00:16 Okiee. May 20 10:00:20 I think I found someting. May 20 10:00:24 Let me try that, May 20 10:00:35 Links will be here if I couldn't fix. May 20 11:03:33 * vvu thinks praveendath92 fixed it if no wild gists are here May 20 11:18:35 Vlad no. I went for lunch. May 20 11:41:29 ds2, mranostay: Have you used the SLP PRU Instruction before? May 20 12:04:12 vvu ping May 20 12:04:37 Sorry my connection lost due to electricity issue. May 20 12:04:42 Here is the gist: https://gist.github.com/praveendath92/1482c34eb9795debb450 May 20 12:04:44 praveendath92: pong May 20 12:04:53 I commented the issues there. May 20 12:06:10 Can you check how the code is working on your end? May 20 12:06:25 praveendath92: i think if you do not claim the device it will disconnect May 20 12:06:28 automatically May 20 12:06:40 i do not have hardware to test now...from next week i'll have time to help you debug May 20 12:07:01 Oh. It's fine. May 20 12:07:02 check maybe you need to do something more with the device May 20 12:07:27 Actually I'm only working with basic usb driver right now. May 20 12:07:42 This testing is also being done on my laptop and not BB, May 20 12:08:48 praveendath92: http://www.makelinux.net/ldd3/chp-13-sect-4 May 20 12:08:57 check 13.4.3. probe and disconnect in Detail May 20 12:09:17 they explain there when both functions are called May 20 12:10:35 I will go over it again once. May 20 12:10:52 Instead of tweaking this small code I will start over with that. May 20 12:10:59 praveendath92: mainly in the probe function you check if your driver can handle the device and if it does you call usb_register_dev May 20 12:11:26 so in the init function you register your driver with the usb core and in the probe function you say to the core that your driver can handle the specific device May 20 12:11:43 that is why disconnect is called for you...core things your driver cannot handle it May 20 12:11:57 Oh. That explains! May 20 12:11:59 Thanks. May 20 12:12:02 anytime May 20 12:12:22 I will go through that link once. May 20 12:12:22 mainly in the probe function you do sanity checks and stuff like that May 20 12:12:43 * vvu is going back to his m{a,e}th lecture notes May 20 12:13:10 Ciao Vlad :) May 20 12:17:11 praveendath92: so the register calls returns now? May 20 12:17:15 what did you change? May 20 12:20:11 av500: it's a pain with the usb_register because if you call usb_register again before rmmod it will break and you need to do some major cleanups May 20 12:20:29 ah May 20 12:20:33 er May 20 12:20:35 i had the same issue when doing some tcp congestion algorithms as kernel modules...they had the same workflow May 20 12:20:40 panto: I'm trying something with the PRU CYCLE register and it seems to return a constant calue May 20 12:20:43 *value May 20 12:20:46 so you need to call usb_unregister? May 20 12:21:00 is that not in a callback from rmmod? May 20 12:21:03 * vvu does not know if it has usb_unregister May 20 12:21:38 i ended up just doing rmmod a couple of times and from time to time rebooting my vm, kinda sloppy but fixed my thing May 20 12:26:46 void usb_deregister(struct usb_driver *); May 20 12:26:48 exists May 20 12:26:58 http://www.opensourceforu.com/2011/10/usb-drivers-in-linux-1/ May 20 12:27:20 but praveendath92 has that May 20 12:27:52 yep, it should not get tangled up May 20 12:29:55 av500: Nope. The register call didn't work. May 20 12:29:55 It's still not returning anything. May 20 12:30:12 av500 : The article in the link you gave belongs to a friend of mine. he is a member of our local hackerspace :) May 20 12:30:38 praveendath92: so it hangs? May 20 12:36:21 panto : ping! May 20 12:39:20 panto: Have you used the CYCLE register on the PRUs? May 20 12:46:22 * karki_ wonders where panto is..... May 20 12:48:02 I'm back home now May 20 12:48:06 and seriously jetlagged May 20 12:53:06 panto : Approx. when will you be free? I'll wait :) May 20 12:53:33 gimme a couple of hours please May 20 12:54:38 okay :) May 20 14:26:17 mranostay: Turns out reading the CYCLE register on the PRU takes 4 cycles :) May 20 14:30:18 No, 6 cycles actually; LBBO instruction (to load the cycle count) takes 4, SBBO instruction (write it to the RAM) takes another two May 20 15:04:08 More digging and it seems that PRU0 stalls 1 cycle per word written to PRU0's 8KB SRAM May 20 15:04:22 (1 word=4 bytes) May 20 15:41:39 well you are hitting outside the PRU fro the LBBO SBBO instructions May 20 15:41:50 isn't CYCLE just a macro for a loop? May 20 15:42:47 Nope, there's a cycle count register in the PRU to count cycles May 20 15:43:08 Section 5.4.4, page 80 of the PRU reference manual May 20 16:03:04 ok, I'm back May 20 16:03:36 Abhishek_, access to the registers are not 1 cycle May 20 16:04:04 so CYCLE can only be use to be accurate to a few cycles May 20 16:04:15 that's good for most of the things you want to do May 20 16:04:23 there are also timers May 20 16:05:21 panto: Have you used the SLP and wake-on-interrupt in PRUs? May 20 16:06:50 no, I didn't had to May 20 16:07:09 you only need to use it if you care about power draw May 20 16:08:23 what about the XFR instructions? May 20 16:11:07 I was considering this strategy for data transfer: PRU1 writes to a group of registers, I move the registers across the crossbar and wake the sleeping PRU1 which moves all the data to the RAM. May 20 16:12:17 panto : I was thinking about the memory mapping regions b/w ARM and PRU via the driver. I want to know whether where will be a user space access to the mmaped region? May 20 16:12:28 *there May 20 16:12:41 or is it b/w driver and PRU May 20 16:13:42 I could think of a lot of issues with synchronization if the userspace shares memory..... May 20 16:14:03 Abhishek_, the XFER instruction are the fastest possible transfer mechanism May 20 16:15:04 but they can only be used for register<->register transfer, isn't it? May 20 16:16:47 there are banked registers May 20 16:17:13 karki_, the kernel driver will map the PRU area May 20 16:17:20 and then user-space and PRU access it May 20 16:19:19 So if I want to send a script to the PRU, I "dump" it in the shared memory and some how signal the PRU that there is a new script to be executed. right? May 20 16:21:49 panto : the signaling will be done thru the driver as a downcall to the PRU (or something along the lines?) May 20 16:22:13 karki_, err, yes May 20 16:22:14 but May 20 16:22:24 don't send a text script to the PRU to execute May 20 16:25:04 panto : what do you mean? I'm never sending a text script to the PRU, just placing it in the DDR. PRU0 reads the text from the DDR, and tells PRU1 what to do. (there is a bit of processing in between that PRU0 takes care of) May 20 16:25:46 no, don't do that May 20 16:25:56 PRU is ill-suited for text processing May 20 16:27:09 so preprocessing done before hand? May 20 16:28:29 panto : Then it's no more a botspeak interpreter ;) That was the original plan! Changed implementation so that it became a botspeak interpreter. May 20 16:28:53 I didn't say that May 20 16:28:58 I said don't send text :) May 20 16:29:06 tokenize May 20 16:29:48 and if you want to get fancy, generate PRU code using some kind of jit mechanism May 20 16:30:12 ;) May 20 16:30:34 * karki_ has to plan for 2.5 months first! May 20 16:31:07 just a heads up; text processing is bad on the PRU May 20 16:31:30 just the string handling functions from will take quite a bit of your very limited IRAM May 20 16:31:41 now, I can't obviously stop you :) May 20 16:31:44 I was hoping on not doing text processing on the PRU anyway. May 20 16:31:52 * karki_ is relieved :) May 20 16:32:11 something like bytecodes would be good IMO May 20 16:33:24 from what I can tell, bot speak is stupidly easy to tokenize May 20 16:33:34 and not that hard to generate PRU code chunks for May 20 16:33:39 I was thinking of a mechanism where each inst would have a corresponding number and there would be an array of fn handlers (one for each inst, approx) and...... well, yeah bytecode-ish May 20 16:33:59 so DIO could be mapped to 0 May 20 16:34:14 as long as the behavior of none of the botspeak instructions depends on the current state, then you really just need a single lookup table May 20 16:34:41 then basically tokenize instructions to indexes May 20 16:34:49 first 8 bits would imply which inst. and the function which you branch to can extract the params May 20 16:35:13 DIO [1, 1] => 00000001-00000001-00000001 May 20 16:35:20 or something like that May 20 16:35:40 you could even compile it May 20 16:35:47 the PRU compiler can run on the ARM May 20 16:36:10 anyway, you can figure it out :) May 20 16:36:36 oh yeah, compiled code blocks would be a cool way to do it May 20 16:36:37 panto : I didn't get you..... compile it in what sense? JIT sort of stuff? May 20 16:36:54 I don't think you need JIT May 20 16:37:01 I see what you mean now!! May 20 16:37:09 generate C code with some kind of template system May 20 16:37:12 compile it May 20 16:37:13 run it May 20 16:38:44 unfortunately I don't know if all botspeak commands can be supported that way May 20 16:38:52 but, it's something to think about, no? May 20 16:39:31 You mean compile a custom C code for the botspeak code the user gives, compile and load? So no interpreter per se? May 20 16:39:42 * karki_ is tangled May 20 16:40:01 *generate a custom C code May 20 16:40:21 yeah May 20 16:40:35 the user never sees the C intermediate code May 20 16:40:57 botspeak is not for large complicated programs anyway May 20 16:41:25 panto : won't it affect realtime capabilities? May 20 16:41:32 you can even do direct assembly generation May 20 16:41:37 the delay in compile-launch May 20 16:41:58 what about the delay in processing text -> bytecode? May 20 16:42:14 you are going to have a delay, unless you cache May 20 16:42:23 hhmmm..... yeah May 20 16:42:34 but here the cost is much more, no? May 20 16:42:49 not that much May 20 16:42:49 generate + compile + assemble + launch May 20 16:43:00 when in doubt, measure May 20 16:43:24 the ARM is plenty fast, and your code is going to be a few K at most May 20 16:43:40 not only that, while executing a script we may need to interrupt to toggle a pin or something....... (I think this is the main problem) May 20 16:43:56 err, why do you need to interrupt? May 20 16:44:07 jkridner 's requirement May 20 16:44:14 was pretty firm on that May 20 16:44:22 I don't get it May 20 16:44:28 can you explain the reasoning behind it? May 20 16:45:00 * karki_ thinks of a situation May 20 16:47:18 panto: would it be possible to XOUT to the other PRU and signal it to wake in 1 instruction? May 20 16:47:42 yes May 20 16:47:58 how? May 20 16:48:16 transfer the data to the registers of the other CPU May 20 16:48:24 signal the other PRU to wake May 20 16:48:32 not 1 instruction but 2 May 20 16:48:51 yeah, that was what I was thinking too May 20 16:49:21 I wondered if it could be done in 1 instruction somehow May 20 16:50:14 panto : I don't think you remember, but the first time we talked (long ago) I had a similar suggestion : an assembly builder similar to the one we are suggesting now, but not botspeak based. rather something like Core.py ( www.corepy.org ). We decided not to take it up due to some reason..... May 20 16:50:36 the first discussion we had with mdp May 20 16:50:49 well, anyway May 20 16:51:00 you have many options May 20 16:51:14 pick one that doesn't lead to text processing on the PRU :) May 20 16:51:32 affirmative :) May 20 16:52:23 * karki_ will be back in a while.... still has a couple of doubts on driver implementation! May 20 16:58:23 panto: I was currently thinking of PRU sampling, and came up with something like this currently (very dirty code), but I want to insert NOPs between successive R31s, the NOPs would serve as a "window" for doing some intermediate processing https://github.com/abhishek-kakkar/BeagleLogic/tree/prutest/PRULATest/src May 20 16:58:40 err, here: https://github.com/abhishek-kakkar/BeagleLogic/blob/prutest/PRULATest/src/PRUTestFirmware.asm May 20 17:01:29 vvu ping May 20 17:03:54 panto : what kind of file will pru-speak show up as, in the VFS? like block, char etc. (I don't know how this works!) May 20 17:04:34 praveendath92: pong May 20 17:04:53 panto : would I have a "/dev/pru-speak" ? or something different? May 20 17:05:20 Sorry I left earlier. May 20 17:05:39 np May 20 17:05:47 I noticed what is strange about my issue. May 20 17:06:04 You explained about probe and disconnect but.. May 20 17:06:44 https://gist.github.com/praveendath92/1482c34eb9795debb450 May 20 17:07:21 All lines from 42 (till function end) are executed when I unload the module May 20 17:07:28 using 'rmmod' May 20 17:08:32 so u say init is called when u rmmod ? May 20 17:08:40 No no. May 20 17:08:50 that is line 42 May 20 17:09:00 usb_register doesn't return when it has to/ May 20 17:09:21 I meant 44. May 20 17:09:24 Sorry. May 20 17:09:46 When I do rmmod I get all the prink's below it. May 20 17:12:11 mhmh same issue for me May 20 17:12:28 general rule of thumb for /dev entries - May 20 17:12:43 mass storage devices (i.e things that will be the basis for a filesystem) is a block device May 20 17:12:48 everything else is a character device May 20 17:13:06 I looked at couple of examples but they all look similar to this. May 20 17:13:17 block devices have implies certain things relating to caching May 20 17:13:27 No '.owner' tag. May 20 17:13:45 I reference manuals it is mentioned though. May 20 17:14:19 ds2 : where exactly will my driver fall into place? May 20 17:14:54 I don't think it's char cause there is a lot of mmap involved... and it's not a block dev either May 20 17:14:59 karki_: most likely a character device or even a sysfs file May 20 17:15:05 char devices do not need mmap May 20 17:15:23 for example, I rewrote the ADC driver to give me samples through a char device May 20 17:15:27 no mmap at all May 20 17:15:52 mine does have a lot of mmap ( panto wants this so that it's cleaner and quicker! ) May 20 17:16:06 oh you WANT mmap May 20 17:16:12 Yes May 20 17:16:14 you can do that through char devices too May 20 17:16:22 I see! May 20 17:16:25 need to do a few things in your fops structure May 20 17:16:44 for example /dev/fb0 (the frame buffer) can be mmap'ed and it is a char device May 20 17:16:58 praveendath92: have no clue now, will look l8er May 20 17:17:11 * karki_ thought char dev were normally not mmap'd May 20 17:17:27 ds2 : thanks May 20 17:17:29 It's okiee. May 20 17:17:33 nope. no such restrictions May 20 17:17:47 mmap is going to be on a char device May 20 17:17:59 You have any working usb driver modules? May 20 17:18:03 nop May 20 17:18:05 IMO - for the size of the PRU memory, mmap or not don't make a big difference May 20 17:18:11 IIRC it can be done on a sysfs file too (but haven't checked) May 20 17:18:16 just restrict it to a full chunk May 20 17:18:34 yes, look at the old firmware loader stuff...it uses sysfs May 20 17:18:42 well, char devices are not really char devices May 20 17:18:48 Oh. May 20 17:18:57 'char' is for historic reasons May 20 17:19:11 think of char as 'byte accessible device' May 20 17:19:18 a char device is just a non block device May 20 17:21:31 That clears a lot of questions I had :) May 20 17:22:21 what would it mean to map a sysfs file? May 20 17:25:39 same thing as you do a char file May 20 17:26:00 how does the linux kernel treat the sysfs file? if I stat it, would it be listed as a normal file or something else? May 20 17:29:24 it is like a normal file May 20 17:30:33 panto : one more thing, once the userspace code writes in the processed bot speak code in the shared memory, how does it inform the PRU? May 20 17:30:54 downcall May 20 17:31:28 well, it issues a signal to the kernel driver which in turn issues the downcall May 20 17:32:33 how does it issue a signal to the kernel? ( that was my issue ;) ) May 20 17:38:03 a syscall? or something different? May 20 17:53:52 panto : may be call a write( )? May 20 17:55:05 there are a bunch of ways May 20 17:55:15 adding new syscalls to the kernel is something that's frowned upon May 20 17:55:34 writing a sysfs attribute file works too May 20 17:56:29 so just write to the file to ask the kernel to perform the downcall ? May 20 17:57:44 panto : approximately how long would the driver development take? ( or rather how long do you expect someone like me would take? ) May 20 17:58:10 -ENOTENOUGHDATA May 20 17:58:31 start now, see how much progress you make and then estimate May 20 17:58:36 I can't make that estimate for you May 20 18:02:13 panto : I'd like to start with a basic driver (bare necessities), work a bit on the interpreter (make a simple dummy one) to make sure I'm in the right direction. If I can get a couple of iterations done in 10 weeks to put out a useable API, I'd be happy. more complex stuff I can work after GSoC. May 20 18:02:51 sure May 20 18:04:56 This week is gone due to my pracs. I will just be reading material and writing some basic front-end maybe. I want a bit more knowledge on kernel modules and also make sure my high level system design of the interpreter is correct. I'll get deep into the project after saturday (last exam :D ) May 20 18:05:29 panto , ds2 : Thanks! G'nite :) May 20 18:14:47 praveendath92: Hey! Are you from Hyderabad May 20 18:15:02 ? May 20 18:48:54 rseethamraju: Hello. May 20 18:49:26 Not really but I visit occasionally. May 20 18:50:09 oh! I live in hyd May 20 18:51:15 Nice. May 20 18:51:37 I live in Rajahmundry, if you know that place. May 20 19:01:54 ya I do. **** ENDING LOGGING AT Wed May 21 02:59:58 2014