**** BEGIN LOGGING AT Wed May 21 02:59:58 2014
May 21 03:16:32 good morning ^_^
May 21 03:18:43 Abhishek_ : I need some help with the PRU, I think it specifically relates to your project.
May 21 03:21:58 * karki_ guesses that Abhishek_ might be sleeping for another two hours.
May 21 03:23:18 zzz
May 21 03:27:27 hehe
May 21 03:36:06 karki: what in the PRU?
May 21 03:44:14 *karki_
May 21 03:46:03 Abhishek_ : I want to know how you are moving the sampled data from the PRU to your userspace application.
May 21 03:47:10 Currently trying two approaches: Writing from PRU to DDR RAM directly or setting up a circular buffer in PRU shared RAM
May 21 03:48:27 Hhmm..... I need to implement PRU->remote proc -> userspace in my driver...
May 21 03:48:35 was thinking of the best way.
May 21 03:48:41 For your application, since you mostly will be moving data from the system RAM to the PRU RAM, your approach may be different, as my approach is mostly to do it as *fast* as possible
May 21 03:49:02 then realized you would have done the hard work ;)
May 21 03:49:13 mine goes both ways
May 21 03:49:37 I need speed for PRU -> userspace
May 21 03:50:08 but doesn't need to be as fast as yours
May 21 03:50:22 why are you not using the SRAM
May 21 03:50:33 wait..... DDR with uio?
May 21 03:50:50 wont there be problems with the cache ?
May 21 03:52:36 I remember panto telling that, I thought the best way for measuring the impact for my application would be to actually try it and see the results
May 21 03:53:45 remoteproc implementation can do things correctly, but I'm going to set up with UIO and move to the remoteproc as the code develops
May 21 04:42:27 try doing shared memory first
May 21 04:42:38 writing to DDR means you have to allocate DMAable memory
May 21 04:42:42 and that can get nasty
May 21 04:42:56 esp. if it is userspace accessible
May 21 04:43:31 ds2: What if the UIO driver allocates it through extram_pool_sz? I'm not using mmap directly in my code
May 21 04:44:16 that can still get tricky to debug
May 21 04:44:46 I'm currently trying broadside register access
May 21 04:45:00 from one PRU to the other
May 21 04:45:02 for you, that is a one way transfer
May 21 04:45:11 2 way xfer is can have other things to watch out for
May 21 04:46:17 so basically one PRU acquires and the other acts as a programmable DMA engine?
May 21 04:46:30 Currently I'm thinking of an approach where PRU1 does only register->register work, PRU0 handles the dirty work
May 21 04:46:34 yes
May 21 04:53:12 ds2: Something like this: https://gist.github.com/abhishek-kakkar/aa5f411304a95d1fb28a
May 21 04:53:38 If only this can be sustained
May 21 04:58:21 what's your current target sample rate?
May 21 05:00:09 I'm targeting as fast as possible that can be sustained [100 MHz, 50MHz, 25MHz].
May 21 05:02:09 are you doing 8 bits or 16bit of data?
May 21 05:03:06 16bits
May 21 05:03:21 There are 12+2 possible HW inputs
May 21 05:37:40 hmmmm
May 21 05:37:54 it might make it easier if you attempt 8 bit first
May 21 05:38:05 cuz with 8 bit, you gain a factor of 4 in speed
May 21 05:38:16 the L3 is 32bit wide so...
May 21 05:40:03 * mranostay kicks the 2.0.0 compiler
May 21 05:40:18 Abhishek_: do 8 bit first
May 21 05:40:39 k, did you see the gist above?
May 21 05:40:40 be sure they all share the same byte
May 21 05:41:01 so you can do one clock cycle or instruction
May 21 05:41:43 i assume you mapped the registers with XCHNG?
May 21 05:41:59 currently doing that part
May 21 05:42:15 btw HUGE stalls if both hit it at the same time
May 21 05:42:29 pru1 has priority over pru0
May 21 05:42:54 you'll want to spinlock till the other pru sends a interrupt
May 21 05:43:11 you can change the priority around with a config register
May 21 05:43:16 mranostay: https://gist.github.com/abhishek-kakkar/aa5f411304a95d1fb28a
May 21 05:43:17 yep
May 21 05:44:34 but better to lock :)
May 21 05:44:51 lock with the SLP instruction?
May 21 05:45:22 hmm SLP
May 21 05:45:28 is that a macro for a loop?
May 21 05:45:50 ah he SLP instruction will sleep the PRU, causing it to disable its clock.
May 21 05:46:14 no you want the other PRU to send an interrupt and you spin on the r31 event
May 21 05:47:07 something like QBNE $$, r31.tXX
May 21 05:47:20 but SLP can be made to work too
May 21 05:47:26 slp is like wfi
May 21 05:47:34 I thought SLP would be nices
May 21 05:47:36 *nicer
May 21 05:47:49 looping is easier to debug...
May 21 05:48:03 yep
May 21 05:49:10 ds2 mranostay: How long before you both leave for tomorrow?
May 21 05:49:38 donno
May 21 05:49:43 depends on when I doze off
May 21 05:50:56 half hour to a hour i guess
May 21 05:52:12 k
May 21 06:39:03 panto : where would my sysfs entry be? ( /sys/class/rproc/pru-speak ?)
May 21 06:56:20 where your platform driver is
May 21 08:14:50 * Abhishek_ finds it interesting to note that the PRU has 16 different kinds on NOPs but wonders why
May 21 08:16:39 maybe if you get tired of one way of doing nothing, you can do it another way ;)
May 21 08:17:04 * Abhishek_ *of
May 21 09:48:00 vmayoral|pc: Hey. did you investigate the PRU issue?
May 21 09:57:09 Abhishek_: I didn't have the time yet. Finishing some modifications to the I2CDriver layer
May 21 09:57:12 Abhishek_: any ideas?
May 21 09:57:41 Abhishek_: before i look at it in more detail i want to try how the Xenomai-patched kernel responds
May 21 10:02:03 k, I saw it in the mailing list, don't have any ideas for now though.
May 21 10:03:36 Let me know of any leads on Xenomai.
May 21 12:31:33 vmayoral|pc : what exactly is Xenomai ?
May 21 12:32:34 karki_: a set of patches for the Linux kernel to convert it in a Real-Time system
May 21 12:32:35 http://www.xenomai.org/
May 21 12:33:05 both the RT_PREEMPT and the Xenomai patches convert the Linux kernel into an RT system. They do it in a different way though
May 21 12:33:53 Xenomai patch does not exist for 3.x kernels?
May 21 12:36:43 * Abhishek_ seems to have been confused between Xenomai versions and Linux kernel versions
May 21 12:40:28 panto, mranostay, ds2: is the C application fast enough to catch two interrupts to the PRU raised in quick succession?
May 21 12:40:58 don't mess with RT_PREEMPT
May 21 12:41:04 it's more trouble than it's worth
May 21 12:41:36 tglx agrees?
May 21 12:41:53 panto: I mean, if I raise two successive PRU0_ARM_INTERRUPTs in quick succession, will I be able to catch both of them from the UIO impl
May 21 12:41:54 well, we can ask him
May 21 12:42:13 Abhishek_, if you depend on that your logic is broken
May 21 12:42:24 panto: then you recommend me to go straight to Xenomai without looking into RT_PREEMPT?
May 21 12:42:32 don't go to either
May 21 12:42:47 standard linux is good enough for a few 10s of ms
May 21 12:42:54 use the PRU for the rest
May 21 12:43:24 you have to understand that no-one developed all those drivers under RT_PREEMPT
May 21 12:43:39 every single one of the drivers you use, plus what ever subsystems you use have to be verified under it
May 21 12:44:06 it might work, or it might not (probably not)
May 21 12:44:12 makes sense
May 21 12:44:32 the dicussion we had (https://groups.google.com/forum/#!topic/beaglepilot/7DKcdm0AEPo) pointed out that the issue might be in the capemgr though
May 21 12:44:41 before you jump into RT patches for linux, evaluate if standard linux + PRU is good enough
May 21 12:44:52 vmayoral|pc, well, I never tried capemgr under it
May 21 12:45:03 and since the lock in question seems to be the devtree lock
May 21 12:45:16 it might even be a problem with the DT locking in general
May 21 12:45:23 you're on 3.8
May 21 12:45:27 yes
May 21 12:45:38 all of the patches for the new overlays is against 3.15
May 21 12:45:45 or will be
May 21 12:46:19 panto: Can you suggest an alternative approach? What I'm trying to debug is: PRU1signals->PRU0 , PRU0 sends an interrupt (so that I know that PRU0 has been signalled), transfers some data into the RAM, and raises an interrupt again.
May 21 12:46:29 so... if you can't pin-point what exactly the problem is I have no inclination to figure out what's broken on 3.8
May 21 12:46:45 and broken under PREEMPT_RT
May 21 12:47:26 mdp & I used to make a good living a few years back figuring out what's broken under random PREEMPT_RT versions
May 21 12:47:41 and most of the time it wasn't something obvious
May 21 12:48:28 panto: thanks for your comments, I honestly don't feel really comfortable with PREEMPT_RT and i'm afraid that it could take me too much time to figure out what's wrong. i'll share your thoughts with the group. Everthing's working fine in vanilla kernel
May 21 12:49:02 and there're plans to move what we need to the PRU.
May 21 12:50:32 if you don't really really need PREEMPT_RT don't use it unless you're willing to fix each and every possibly affected driver
May 21 12:51:51 I'm afraid that'll be too much complexity.
May 21 12:52:18 I appreciate that you shared your thoughts. I'll keep going with vanilla for now.
May 21 12:56:09 Abhishek_, try to use some kind of ack scheme
May 21 12:56:23 don't rely on the other end picking up interrupts fast enough
May 21 12:56:28 this is by definition racy
May 21 13:03:03 panto: Do you have a few minutes to take a quick look at the current firmware?
May 21 13:03:29 https://github.com/abhishek-kakkar/BeagleLogic/blob/prutest/PRULATest/src/pru0fw.asm
May 21 13:03:35 https://github.com/abhishek-kakkar/BeagleLogic/blob/prutest/PRULATest/src/pru1fw.asm
May 21 13:14:34 Hi jkridner
May 21 13:15:38 hi karki_
May 21 13:15:43 jkridner : Could you give panto the link for the google doc for the student hardware requirements?
May 21 13:15:58 if he hasn't already filled it!
May 21 13:16:17 https://docs.google.com/spreadsheet/ccc?key=0AtD7XdBlve3HdFRaU1NEZE40cUgxNFlYTEdjNklYcEE&usp=sharing
May 21 13:16:34 panto : could you please fill this up for me?
May 21 13:16:40 I don't see an entry.
May 21 13:17:31 meeting in 3 hrs?
May 21 13:17:41 2:40
May 21 13:20:47 jkridner_: did you make up your mind about the "Google three day unconference". I'd be interested in participating
May 21 13:20:57 ?
May 21 13:21:05 I started typing a response...
May 21 13:21:11 I really appreciate that you brought it up in public...
May 21 13:21:33 i was unsure if it was the right thing. Glad to hear that
May 21 13:21:42 I guess I was hoping to use the $$$ for myself, but that might be too selfish.
May 21 13:21:50 hi jkridner
May 21 13:21:50 hopefully I can get TI to pay.
May 21 13:22:14 let's discuss in the meeting today. I'll try to get TI to pay for me and Google to pay for you + av500.
May 21 13:22:36 I'll need to see if Google will approve a 3rd person going, but I don't think it'll be an issue.
May 21 13:23:10 I think because you are a 2-time Beagle GSoC'r that it'll be understood. Also helps that you jumped on it fast.
May 21 13:24:55 vmayoral|pc: are you a mentor?
May 21 13:24:58 or student?
May 21 13:25:02 a student
May 21 13:26:19 ok
May 21 13:27:26 ah yes, students can be delegates too
May 21 13:27:28 np then
May 21 13:27:41 yeap
May 21 13:28:08 they changed that for this year
May 21 13:29:45 hey jkridner, tell me you like this: http://diegotc.github.io/bone101/Support/GSOC/BLINKINGTUTORIALS/Blink.html and that the blue color as background is what you don't like :p (And the View All)
May 21 13:31:12 * DiegoTc started to make a list of things to improve, fonts, color, image borders. Guessing jkridner will mentioned it
May 21 13:31:49 DiegoTc: I think it is OK, but I think it could look better.
May 21 13:34:26 jkridner you are referring to the gist view? I have to define fonts and other things at the moment for showing it. Or you mean the way it's
May 21 13:34:54 overall cleanliness
May 21 13:41:51 DiegoTc: what do other people think of it?
May 21 13:42:11 from this one I haven't get feedback
May 21 13:42:58 from the last one, I took Steve idea of parallex
May 21 13:43:17 if you see, you can use arrows from keyboard or the ones of top
May 21 13:47:57 DiegoTc: scrolling with keyboard isn't working on firefox but is fine in chromium
May 21 13:48:30 Abhishek_: thanks!
May 21 13:48:40 Abhishek_: do you feel confortable using it?
May 21 13:50:23 While going from the 4th to the 5th card, IMO it would be better to have it on the same row rather than the animations of going down (others may have a different opinion)
May 21 13:52:09 the bone outline adjusts well on my 1920x1080 screen, could be made a little bigger
May 21 13:52:36 Abhishek_: could you send me a screenshot please :)
May 21 13:57:18 praveendath92, vmayoral|pc karki_ hey guys, could you do me a favor and give me feedback for this: http://diegotc.github.io/bone101/Support/GSOC/BLINKINGTUTORIALS/Blink.html
May 21 13:57:29 do you like it, feel confortable using it
May 21 13:57:32 thanks
May 21 14:00:06 DiegoTc: It's good. I didn't understand the drastic row shift animation for card 5
May 21 14:00:51 ahh i haven't add the css, but the idea is that you connect the BBB, plug the breadboard to it
May 21 14:00:56 Also, it would be nice if you can add support for swipe events. Check onepage.js on mobile device once.
May 21 14:00:59 and you can run the code live
May 21 14:02:34 No. What I meant was all the cards from 1-4 are animating from left-right or the other way while this one is different because of the functionality it offers?
May 21 14:04:07 ahhh, no, I was playing around with it yesteday and like the effect
May 21 14:04:29 there's no special reason for having it
May 21 14:05:27 Oh.
May 21 14:05:29 DiegoTc: http://s9.postimg.org/te83t1q2n/scrshot2.png
May 21 14:06:18 praveendath92, Abhishek_ I will have all cards in the same row :)
May 21 14:06:25 thanks Abhishek_
May 21 14:07:19 DiegoTc: i support jkridner's comment. Make it cleaner. Use big fonts if possible and responsive
May 21 14:09:13 DiegoTc: possible issue in bone layout: http://s17.postimg.org/g878sbn27/scrshot3.png
May 21 14:09:58 jkridner: Hello.
May 21 14:12:00 * jkridner likes the font size at https://learn.adafruit.com/connecting-a-push-button-to-beaglebone-black/you-will-need
May 21 14:12:14 same with https://learn.adafruit.com/connecting-a-push-button-to-beaglebone-black/writing-a-program
May 21 14:15:15 * praveendath92 is having mild fever. I will try to stick around for the meeting. In case I couldn't I want to inform jkridner about this.
May 21 14:16:48 praveendath92: any luck with the module ?
May 21 14:17:13 vvu: Actually I figured that the probing and all are working fine.
May 21 14:17:21 what was the issue ?
May 21 14:17:54 It's just that when I ismod the execution stops or whatever after usb_register.
May 21 14:18:08 However, the driver is being successfully registered.
May 21 14:18:37 so not usb_register does not hang anymore ?
May 21 14:18:58 And also, the prink's of those lines after usb_register are logged when device is first connected.
May 21 14:19:16 did u push the code to github ?
May 21 14:19:20 No. It doesn't. It's just those lines printk are logged late.
May 21 14:19:32 oh ok
May 21 14:19:37 i think u need to put KERN_ALERT
May 21 14:19:42 The code looks messy. I will clean up and push it.
May 21 14:20:08 Was sleeping the whole day due to fever :/
May 21 14:20:20 and a \n at the end to get it pushed in dmesg
May 21 14:21:31 Will do. Was checking with tail -f /var/log/kern.log so didn't have an issue with that.
May 21 14:21:44 ok, cya at the meeting if u can make it
May 21 14:22:28 I will mostly be there.
May 21 14:28:44 vvu: It worked.
May 21 14:29:19 The driver registered message also displayed.
May 21 15:09:05 meeting is in 51 minutes, right?
May 21 15:09:14 yep
May 21 15:09:25 k, thanks Abhishek_
May 21 15:28:39 ds2, mranostay, panto: if I do a XOUT from PRU1, do I need to do a corresponding XIN into PRU0 as well?
May 21 15:34:04 praveendath92: so \n u need to get it out if the ring buffer i think
May 21 15:36:11 Makes sense. It was probably been pushed to the next printk from the driver when \n is not used.
May 21 15:36:47 yep but also printk got dold
May 21 15:36:49 old
May 21 15:37:02 use err smth, i think they have it for the usb core
May 21 15:37:14 run checkpatch.pl on ur file
May 21 15:37:28 to see if it complies witk lk coding style
May 21 15:44:53 jkridner : we have updated our statuses in the google group. So whats todays discussion going to be about?
May 21 15:53:40 Abhishek_: not immediately...there are 3 banks of registers
May 21 15:55:57 karki_: make sure everyone has started coding, providing status updates, getting guidance from mentors, have hardware and generally unblocked.
May 21 15:56:47 ds2: Section 5.2.4.2 of PRU Ref guide, there's this Device ID 14 which says: "Selects other PRU Core (Direct connection Mode)". What does it mean exactly?
May 21 15:56:58 hi cdsteinkuehler
May 21 15:57:30 Hello. The PRU direct connect copies data from one register bank to the other. Both PRU cores must execute complimentary XIN XOUT instructions
May 21 15:57:54 There is a 1024 clock timeout waiting for the other PRU core to execute the complimentary instruction
May 21 15:58:34 Okay, so that means I can XIN before I XOUT from the other PRU, and it will block till data is available?
May 21 16:00:05 Yes, up to 1024 clocks
May 21 16:00:31 shall we do a quick roll call?
May 21 16:00:37 Abhishek_: yes
May 21 16:00:42 present
May 21 16:00:52 * Abhishek_ is present
May 21 16:00:58 same here
May 21 16:01:27 ahoy
May 21 16:01:41 here (on the road @ a temporary office)
May 21 16:01:51 aloha
May 21 16:02:29 Per status reports, I see something from karki_, praveendath92, DiegoTc, disdi (not present?), Abhishek_, vmayoral|pc
May 21 16:02:31 See details in table 4-20 of SPRUH73C
May 21 16:02:41 anyone seen disdi and joel-brb?
May 21 16:03:10 I will need to leave early again this week
May 21 16:03:33 besides the email complaints? :D
May 21 16:03:46 hi all
May 21 16:03:48 about the missing hardware?
May 21 16:04:07 hi disdi_... board still seems to be at TI Bangalore, but hopefully will arrive soon.
May 21 16:04:19 * jkridner doesn't know how long it takes to ship something in Bangalore...
May 21 16:04:36 apparently disdi_'s professor contact was required for shipping due to some policy.
May 21 16:04:43 yep
May 21 16:04:57 jkrinder: yes....
May 21 16:04:58 * karki_ thinks it shouldn't be more than a day
May 21 16:04:58 jkridner: you told me last week you were going to see the hardware related to bone101
May 21 16:05:03 rseethamraju: you around?
May 21 16:05:10 disdi_ : where are you located?
May 21 16:05:21 karki_: new delhi
May 21 16:05:23 I don't need it right now, just a remainder
May 21 16:05:25 DiegoTc: yes. should get there in 3-4 weeks.
May 21 16:05:32 ahh ok
May 21 16:05:53 disdi_ : Then why get it shipped in B'lore?
May 21 16:06:36 ya sorry
May 21 16:06:40