**** BEGIN LOGGING AT Tue Jun 10 02:59:59 2014 Jun 10 05:52:47 panto alexanderhiam ds2 jkridner mranostay : I'm able to successfully execute a blink program in botspeak on the PRU :D ( dynamically loading the program from userspace via a shared memory segment) :D Jun 10 05:56:33 :) Jun 10 06:23:22 :) Jun 10 08:08:54 panto : do you think JIT would be a good idea? (for later that is.... ) I'm just wondering! Jun 10 09:53:11 Great news karki! :) Jun 10 09:53:37 * Abhishek_ yawns Jun 10 09:56:39 :) Jun 10 10:10:20 * karki wonders how his project would be useful to people.......... Jun 10 10:24:25 panto: What could be wrong with this sysfs store that is causing a segfault when I do echo 2 > attr : https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/pru_rproc_bl.c#L2885 Jun 10 10:25:49 karki, yeah Jun 10 10:25:53 jit is the way to go Jun 10 10:26:11 but I want to review the blink thing first Jun 10 10:27:01 Abhishek_, you have static variables (pp_bl) Jun 10 10:27:04 this is a no-no Jun 10 10:27:26 you have a device with private data Jun 10 10:27:28 use that Jun 10 10:27:48 ok Jun 10 10:28:43 then how are you certain that pp_bl->beaglelogic.ctx != NULL? Jun 10 10:28:59 karki: i asked this question many times last year for my stuff Jun 10 10:29:43 panto: This is allocated in a method just below Jun 10 10:30:34 then, kstrtoint int != u32 Jun 10 10:30:39 aren't you getting warnings? Jun 10 10:30:56 yep, I have to sort them out Jun 10 10:31:29 that's a kstrtouint Jun 10 10:32:23 in general no warning are allowed for kernel code Jun 10 10:32:38 usually means something is bad Jun 10 10:35:26 * Abhishek_ remembers getting a couple of warnings while building the whole kernel but then bulk of the stuff compiles fine Jun 10 10:37:49 panto : okay, I'll clean my code by wednesday and push it up for you to review Jun 10 10:38:30 vvu_backup : and did you find an answer ;) Jun 10 10:47:48 panto: Where can a misc device hold private data in it Jun 10 10:58:05 you have a misc_device structure that you use to pass to misc_register Jun 10 10:58:10 this can be embedded in another Jun 10 10:58:42 yep, I have a misc_device structure Jun 10 10:58:51 and you can go from misc_device to the upper level structure via container_of Jun 10 11:00:01 so what would conventionally be a good place to keep this upper level structure? Jun 10 11:00:55 it depends Jun 10 11:01:34 don't you have pruproc in there? Jun 10 11:01:43 yep, I do Jun 10 11:02:18 so, why not put it in beagle logic? Jun 10 11:02:26 ok, here? https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/pru_rproc_bl.c#L278 Jun 10 11:05:37 yes Jun 10 11:07:11 I add the misc_device structure in it, and then I have access to the complete structure via container_of Jun 10 11:08:12 yes Jun 10 11:09:38 Abhishek_: so LOC, much wow :)) Jun 10 11:19:35 yup, thankfully there is hyperlinking in editor, that helps navigate the maze more quickly :) Jun 10 11:51:58 vvu: BTW, how's net noe? Jun 10 11:52:01 *now Jun 10 11:53:24 i am not home, anyway home until 00:00 i have net :) Jun 10 11:53:29 i already got used to it Jun 10 11:57:08 lunch time Jun 10 12:51:34 panto: there's a catch though: 1. The file operations methods (read, write, mmap) are not aware of pruproc or any device structures, I could put something in private_data of file structure there but then I must have a pointer to it (static) 2. in misc_device structure, there's a field this_device but it contains struct device *, and not struct device, so I Jun 10 12:51:34 think I can't use container_of with that Jun 10 12:52:43 you can make them aware Jun 10 12:52:51 grep for misc device examples in drivers/ Jun 10 12:53:40 atm, I was proceeding in a manner similar to how mranostay had put in his lighting stuff Jun 10 12:58:16 dev_get_drvdata should do it. Jun 10 13:06:17 right Jun 10 13:08:13 now, how to make sure that fops gets this drv data? I have just inode information in the function Jun 10 13:08:24 on open Jun 10 13:09:02 yep, in open I set the private_data field, but then how do I get the device information then? Jun 10 13:10:06 dev_set_drvdata? Jun 10 13:10:18 you create the misc_device, set the drv_data Jun 10 13:10:28 ah Jun 10 13:10:41 got it Jun 10 13:13:46 * Abhishek_ didn't realize that dev_get_drvdata would work whenever I have drv_data available Jun 10 13:14:43 panto : Done with the the BotSpeak -> BotSpeak "byte code" compiler :) Now to expose an API for the loader! Jun 10 13:16:20 in python? Jun 10 13:16:29 panto : I'll start code cleanup tomorrow, and before tomorrows meeting I should have a clean driver and API up and running :D Jun 10 13:16:31 yes Jun 10 13:16:37 ;) Jun 10 13:28:03 panto : how much time is it worth investing in the botspeak logic of the PRU, if at the end of the day what we need is a JIT. Plus another thing is, in what ways do you think my project could be useful? [Don't you think it would be easier to develop on the PRU if there was a cleaner remote proc -> userspace interface + clpru libraries rather than all this botspeak stuff? ] Jun 10 13:29:00 botspeak is important in the way it abstracts the PRU away Jun 10 13:29:33 nothing forbid using botspeak in another system, where PRUs are not present Jun 10 13:29:52 the executor of botspeak could be another core, or even an FPGA Jun 10 13:30:21 I have some reservations if botspeak is feature complete but it's a start Jun 10 13:41:40 Yeah we once talked about a libprussdrv-rproc Jun 10 13:47:37 yeah Jun 10 13:49:09 +1 for libprussdrv-rproc Jun 10 13:59:29 what happened to the libprussdrv-rproc idea? Jun 10 14:21:29 what happened? Jun 10 14:52:32 Abhishek_ : who are you asking ;) Jun 10 15:32:40 to the idea, I meant Jun 10 16:12:54 Abhishek_: how goes the kernel interface? Jun 10 16:15:58 mranostay: More fill in the blanks going on Jun 10 16:16:25 Added sysfs attrs for configuration, but storing gives an oops Jun 10 16:16:34 Working on it right now Jun 10 16:20:27 mranostay: until yesterday: https://github.com/abhishek-kakkar/BeagleLogic/commit/bc0c00e2822e6f0f494977f8cce1ac35dda79002 Jun 10 16:21:08 ah well that is probably a null pointer or something Jun 10 16:29:45 On the PRU firmware side, codebase has migrated to CLPRU, downcalls to get version etc are working, and the driver receives the vring interrupts in sequence (that are reused by my driver) Jun 10 16:29:59 (kernel driver) Jun 10 16:32:34 mranostay: what could be wrong with this store function: https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/pru_rproc_bl.c#L2885 ? Jun 10 17:19:56 :) Jun 10 17:21:04 The interface till now - [bytecode generator, loader working behind the scenes ;) ] ------------> https://gist.github.com/deepakkarki/6223ccd116456c3e4d26 Jun 10 17:21:21 alexanderhiam : ^ Jun 10 17:24:19 karki: very cool Jun 10 17:24:36 :) Jun 10 17:26:35 you haven't pushed the pru_speak python lib to github yet? Jun 10 17:32:46 nope! Jun 10 17:33:31 I will in a while Jun 10 17:33:31 is it using mmap like this: https://github.com/deepakkarki/pruspeak/blob/master/src/userspace_lib/2_mmap_test.py ? Jun 10 17:34:10 alexanderhiam : somewhat Jun 10 17:34:15 is it a problem? Jun 10 17:34:38 I have set aside that chunk of memory anyway Jun 10 17:34:55 so it won't disturb the driver. Jun 10 17:36:17 well the problem with that method is that it can't handle concurrency Jun 10 17:36:35 i.e. what happens if two processes try to do that at the same time Jun 10 17:38:28 two processes should not be using the PRU at the same time anyway! Jun 10 17:38:37 that itself will cause a problem Jun 10 17:38:40 as of now Jun 10 17:38:58 right, but how can they know that? you need a way for a process to reserve the pru Jun 10 17:41:16 I plan to add a sysfs entry for that Jun 10 17:41:26 that will contain the state of the PRU Jun 10 17:41:30 ok cool Jun 10 17:42:13 you should also think about how to handle the case of a process crashing before it can un-reserve the pru Jun 10 17:42:58 for everything happening in the kernel (where concurrency could be a problem) I'll be using mutexes! Yeah I have to think about the crashing part! Jun 10 17:44:58 in the original plan, if I remember right, the user space program sent the script to the kernel driver, in which case the driver would act like a bottle kneck and would naturally handle concurrency issues Jun 10 17:45:12 neck* Jun 10 17:45:43 but now you're directly loading the memory that the pru reads from right? Jun 10 17:47:44 yep Jun 10 17:48:07 yeah, that means the user space code has to be a lot more careful Jun 10 17:48:18 yes I see Jun 10 17:48:38 I'll think about it Jun 10 17:49:11 which is not necessarily a bad thing, but does make it a lot less trivial to write a user space library Jun 10 17:50:05 I'll get on it tomorrow Jun 10 17:50:17 I see there are a lot of things to take care of Jun 10 17:50:31 I didn't think much of the crashing case! Jun 10 17:50:58 and of course congrats on the successful blink program! Jun 10 17:52:14 ;) Jun 10 17:54:30 sysfs stores are now working Jun 10 17:54:39 Abhishek_, what was it? Jun 10 17:55:08 I replaced return strlen(buf) by count in the stores Jun 10 17:55:17 hehe Jun 10 17:56:12 alexanderhiam : how about I give a serial interface for read and write? (but that would make stuff slower - which is why I went for the shared memory instead in the first place) Jun 10 17:56:41 implemented the dev_get_drvdata thing so code is a little cleaner now Jun 10 17:57:38 karki: is slower for loading/starting/stopping a bad thing? If you want a few instructions to executre quickly you load them as a single script Jun 10 17:59:53 panto: Isn't this virtio thing just "sugar-coated" coherent buffers? Jun 10 18:00:21 no Jun 10 18:00:28 the buffers are not coherent per-se Jun 10 18:00:46 they are allocated with dma_alloc_coherent in the driver I saw Jun 10 18:00:49 the dma mapping API makes them suitable for non-coherent usage Jun 10 18:01:03 I see Jun 10 18:01:17 normal virtio is on coherent arches Jun 10 18:01:19 alexanderhiam : hmm... I'll see what I can do. will update tomorrow! [but that still does not take care of the single process "locking" for the PRU] Jun 10 18:04:57 karki: oh, you mean a virtio serial port to the pru? Jun 10 18:05:12 not virtio per se Jun 10 18:07:06 if you load scripts through something like a sysfs interface then the kernel driver can resolve all the concurrency issues. If the user space libraries are loading scripts directly to the pru then they're going to have handle it themselves, there's no way around that Jun 10 18:08:09 here the load is just triggered by the sysfs. Jun 10 18:10:01 alexanderhiam : I think I have an idea for the crash handling. I'll get back to you tomorrow on that. I'm too tired now :/ Jun 10 18:10:32 ok cool Jun 10 18:10:48 sleep's good sometimes too I guess Jun 10 18:10:52 :P Jun 10 18:11:26 "sometimes" ;) Jun 10 18:11:32 yep, especially if don't remember what I coded last night... :P Jun 10 18:11:40 Abhishek_ : +1 Jun 10 18:12:30 The longest I ever stayed up coding was about 46hrs - Then crashed :P Jun 10 18:14:12 you must have had some strong coffee then :P Jun 10 18:14:57 Coffee + Redbull ;) Jun 10 18:15:07 hackathons <3 Jun 10 18:15:15 ah good :) Jun 10 18:15:43 ended up winning an Intel tab ;) Jun 10 18:16:11 * Abhishek_ didn't participate in hackathons in the past but looks forward to pounce on the next oppportunity 3:) Jun 10 18:41:44 kernel module now builds with 0 warnings [but dunno how many segfaults now :P] Jun 10 19:25:05 Abhishek_: hackathons are nice Jun 10 19:25:16 did 3 in my life and totally worth it :) Jun 10 19:25:44 yup, considering the perks Jun 10 19:26:31 search for angelhack, they do really legit hackathons Jun 10 19:35:19 thanks for the heads up Jun 10 19:46:48 isn't kzalloc supposed to return zeroed and allocated memory? [looks like memory areas being allocated are not being zeroed for me] Jun 10 19:48:27 kzalloc is guaranteed to return zeroed memory Jun 10 19:51:18 ah got it, my problem was something else actually Jun 10 19:54:12 * Abhishek_ types insmod pru_rproc_bl.ko with fingers crossed Jun 10 20:23:53 which flag would I have to use with dma_set_coherent_mask if I get a warning that coherent DMA mask is unset? Jun 10 20:33:50 I just gave 128 MB of my system RAM to BeagleLogic ;) Jun 10 20:34:45 now, 256 MB Jun 10 20:35:35 I am able to give upto 256 MB of my BBB's RAM to BeagleLogic kernel driver now \m/ Jun 10 20:38:43 jkridner: there Jun 10 20:38:56 's now a sysfs interface for BeagleLogic Jun 10 21:20:00 _av500_: http://www.digifail.com/hacks/qinook.shtml Jun 10 21:22:13 Qi receiver hardwired to the USB port of an eBook reader Jun 10 23:18:21 ds2: Getting about 30 MB/s : __copy_to_user in PAGE_SIZE byte blocks, dd if=/dev/beaglelogic of=/dev/null bs=1M count=20 Jun 10 23:19:09 PRUs are not running at the moment, it could further slow down Jun 10 23:19:59 problem could be cache related; I've set dma_coherent_mask Jun 10 23:20:31 mranostay: any suggestions ^ ? Jun 10 23:24:25 I would need at least > 60 MB/s to guarantee streaming sampling Jun 10 23:28:43 seems a bit low Jun 10 23:29:10 do a quick experiment - Jun 10 23:29:23 rather then really copying all of your allocated space, keep copying the same 4K Jun 10 23:29:33 see if that improves... Jun 10 23:36:19 It's around the same Jun 10 23:37:04 which copy macro are you using? Jun 10 23:37:08 It's around the same, went a little bit up to 34 Jun 10 23:37:13 __copy_to_user Jun 10 23:38:06 hmmm Jun 10 23:39:23 this could have something to do with caching it seems Jun 10 23:39:44 Okay, let's say that is what it is Jun 10 23:39:54 do something like this in your driver Jun 10 23:40:03 static char dummybuffer[4096]; Jun 10 23:40:08 keep copying that out Jun 10 23:40:13 that should be cached after the first pass Jun 10 23:45:08 311 MB/s Jun 10 23:45:13 10x Jun 10 23:46:33 hmm, so how to "cache" the memory only while copying? Jun 10 23:47:10 not easily Jun 10 23:47:27 actually what you want is - Jun 10 23:47:37 make the area cacheable Jun 10 23:47:55 each time you read it, invalidate the cache Jun 10 23:48:03 exactly Jun 10 23:48:20 problem is since you are reading it once, the only benefit is the cache may hide other latencies Jun 10 23:48:38 you need to search for it... I donno an example off the top of my head Jun 10 23:49:30 the PRU interrupts would trigger cache invalidation Jun 10 23:50:31 each incoming buffer would invalidate the cache of the immediately previous bufer Jun 10 23:50:34 *buffer Jun 10 23:52:59 I'm thinking I might have to write a copy_to_user in assembly that would perhaps take care of this but I don't know if it would be worth the effort Jun 10 23:53:43 NO Jun 10 23:53:49 do not do that Jun 10 23:54:43 yep, messing around with this stuff isn't good Jun 10 23:56:46 av500: is Mans around? Jun 11 00:03:39 yes, mru is the guy to ask for this stuff Jun 11 00:21:10 hi VoltVisionSteve Jun 11 00:21:43 Abhishek_: block size will matter Jun 11 00:21:55 mranostay, wassup! Ive heard alot about you lately... Jun 11 00:22:34 yep, it seems to hit a sort of maxima with 128 K and fall if I go either way Jun 11 00:25:18 mranostay: block size of copy_to_user or block size in dd ? Jun 11 00:26:29 this is really annoying.... features needed are scattered in time across 14123123213123213 different kernels Jun 11 00:26:38 merge madness Jun 11 00:29:52 trying with 64K blocks of copy to user now Jun 11 00:30:33 Abhishek_: Planning on putting all this data together in a table in your blog? Jun 11 00:31:30 yep, should get some numbers for today's meeting, with an update Jun 11 00:33:49 great Jun 11 01:15:34 morning karki Jun 11 01:19:28 ds2 mranostay: 64 K copy_to_user blocks do not make a major difference in copy speed, still clocking 26.0 MB/s Jun 11 01:31:08 Unsetting dma_coherent_mask seems to do no improvement Jun 11 02:26:28 * Abhishek_ pushed the commits for the day **** ENDING LOGGING AT Wed Jun 11 02:59:59 2014