**** BEGIN LOGGING AT Sun Jun 29 02:59:59 2014 Jun 29 05:32:15 Morning Jun 29 08:10:42 Abhishek_, are there any changes required to be made in the ARM space for elf generated using new compiler to work Jun 29 08:17:44 sidbh: which kernel version are you using? Jun 29 08:17:50 [uname -r] Jun 29 08:19:34 sidbh: You might have to apply this patch: http://git.io/uCfGKQ [for version < bone56 ] Jun 29 08:34:42 Abhishek_, 3.8.13-bone50 Jun 29 08:34:43 3.8.13-bone50 Jun 29 08:35:27 Abhishek_, I'll apply the said patch and check, thanks Jun 29 15:18:35 karki_, i saw that you have got the PIEP counter working with new compiler for your project, I'm struggling with it to work, somehow it is getting stuck at 0x6, have you any idea regarding this? Jun 29 15:19:02 my internet is BACK :D Jun 29 15:19:09 sidbh : one sec Jun 29 15:19:31 sure, no hurry Jun 29 15:19:55 sidbh : your counter gets stuck at 0x6? do you have code I can see? Jun 29 15:22:29 https://gist.github.com/bugobliterator/cc2bd3399289c5be5b50 Jun 29 15:22:58 checkout line 174 Jun 29 15:23:28 and line #210 Jun 29 15:24:13 ok :) Jun 29 15:25:11 I'm reading PWM_CMD->magic from userspace Jun 29 15:25:26 I see Jun 29 15:26:26 I haven't gone thru panto's code before, gimme a few min! Jun 29 15:26:39 sidbh: panto and mranostay had pointed me about possible arbitration issues if the RAM is accessed by the ARM core while the PRU is running. you might want to halt the PRUs to see if it has any effect Jun 29 15:27:06 +1 Jun 29 15:28:03 sidbh : yeah, you should try what Abhishek_ says while I read the code. Jun 29 15:28:05 sidbh: what is the optimization level of the compiler (-Ox) ? Jun 29 15:28:15 -O3 Jun 29 15:28:21 k Jun 29 15:28:48 did you try reloading the firmware into the PRUs, maybe once or twice before reading stuff from userspace? Jun 29 15:29:12 reloading? Jun 29 15:29:34 use this: echo 0:,1: > /sys/devices/ocp.*/*.prurproc/load Jun 29 15:29:54 s/patch/path Jun 29 15:30:08 ok, trying Jun 29 15:33:12 I'm getting: -bash: echo: write error: No such file or directory Jun 29 15:33:22 sidbh : what method are you using to read the value of "PWM_CMD->magic" into userspace? Jun 29 15:33:48 sidbh: is your firmware under /lib/firmware ? Jun 29 15:33:53 mmap Jun 29 15:34:00 yes Jun 29 15:34:14 did you use O_SYNC with open /dev/mem? Jun 29 15:34:31 yes Jun 29 15:35:04 everything was working fine when i was compiling using PRU1.0.0B1 Jun 29 15:35:13 try semicolon instead of a colon in the echo command Jun 29 15:35:33 ok Jun 29 15:35:34 sidbh: I mean instead of a comma Jun 29 15:37:20 0:/lib/firmware/testpru0 Jun 29 15:37:20 -bash: 1:/lib/firmware/testpru1: No such file or directory Jun 29 15:37:46 both testpru0 and testpru1 are @ /lib/firmware Jun 29 15:37:51 i double checked it Jun 29 15:40:12 weird if everything worked with the older version of the compiler Jun 29 15:40:15 :/ Jun 29 15:40:37 sidbh: did you try rebooting? Jun 29 15:40:48 sidbh : as of now you are mmap'ing 0x00010000, right? Jun 29 15:45:19 karki_, I'm mmaping to 0x4a310000 Jun 29 15:45:28 to be precise Jun 29 15:46:43 why there? (the SHARED_DRAM is #defined to 0x00010000) Jun 29 15:47:06 karki_: 0x4a310000 + 0x00010000 Jun 29 15:47:17 ah, okay Jun 29 15:48:04 possibility that the memory location is cached? Jun 29 15:50:02 karki_, 0x10000 is for PRU Jun 29 15:50:39 I just thought it was global :p Jun 29 15:52:02 karki, Abhishek_ , I've tested the data exchange, it is happening just fine via SHARED_RAM Jun 29 15:52:22 sidbh_: so what was it? Jun 29 15:53:16 the value of PIEP cnt is always 0x6 Jun 29 15:53:43 i.e. it is not ticking Jun 29 15:58:25 Abhishek_, command for reloading is not working for me Jun 29 15:58:41 * Abhishek_ wonders why Jun 29 16:00:31 Abhishek_, I'm only using PRU1 and I've stripped of all the rproc code from it, i.e. no rproc on the PRU side Jun 29 16:00:40 does that matter Jun 29 16:01:41 are you typing : "echo 0:testpru0,1:testpru1 > /sys/devices/ocp.3/4a300000.prurproc/load" Jun 29 16:02:07 I don't think it should Jun 29 16:04:12 this is what i'm using: echo 0:/lib/firmware/testpru0,1:/lib/firmware/testpru1 > /sys/devices/ocp.3/4a300000.prurproc/load Jun 29 16:04:43 ah, I think you should omit /lib/firmware and try that again Jun 29 16:04:53 ok Jun 29 16:06:14 it worked! thanks Jun 29 16:08:55 sidbh: does doing stuff with downcalls work for you? If you can manage to expose your required downcalls to userspace then you should be able to do it in a more cleaner manner than waiting for a "magic byte" to be written into RAM? Jun 29 16:17:14 In the earlier implementation of PWM PRU i was sending pwm values via sysfs but it is too slow for our purpose, is there a way to do downfalls without sysfs being involved Jun 29 16:17:14 ? Jun 29 16:17:14 *downcalls Jun 29 16:18:15 I could think of ioctl's on a character device, like the lighting example Jun 29 16:24:24 if that too isn't enough for your application, then I think shared memory is your best bet Jun 29 16:27:46 Abhishek_, I will check ioctls out and see if they serve the purpose Jun 29 16:27:54 thanks for info Jun 29 17:11:13 12 hours to meeting Jun 29 18:50:27 Abhishek_: pff forgot about it. need to wake up early if so Jun 29 18:56:37 yes you need to halt the prus Jun 29 19:09:21 * KumarAbhishek was Abhishek_ **** ENDING LOGGING AT Mon Jun 30 03:00:00 2014