**** BEGIN LOGGING AT Sat Jul 25 02:59:58 2015 Jul 25 05:13:57 ] Jul 25 14:11:16 is there a way to change script on the browser and test it without changing its file or refresh the page? Jul 25 14:52:44 vmayoral: ping Jul 25 16:37:52 vmayoral:PING Jul 25 16:45:04 ds2 :ping Jul 25 17:04:15 * nerdboy having too much chromeos kernel builds... Jul 25 17:04:21 *fun even Jul 25 19:36:17 Abhishek_ ds2 :ping Jul 25 20:29:22 apaar_: pong Jul 25 20:31:05 Abhishek_ :i am having a issue with accessing more than 4096(pagesize) bytes in pru shared mem both in driver and firmware(i wrote from firmware and flushed usinging mmap looks like only 4096 is being accessed)) Jul 25 20:31:35 link to the code? Jul 25 20:31:57 the flush one or driver/firmware of pru_bridge? Jul 25 20:32:40 Abhishek_ :^ Jul 25 20:35:33 the kernel module/userspace lib Jul 25 20:38:39 https://github.com/Apaar/PRU-Bridge Jul 25 20:44:50 apaar_: sysfs files are 4096 bytes max Jul 25 20:45:08 you cannot have a sysfile attr bigger than 4096 bytes Jul 25 20:45:31 Abhishek_ :the sysfs is only handling one byte at a time... Jul 25 20:45:36 *sysfs Jul 25 20:46:45 What are the steps to reproduce it? Jul 25 20:47:00 (i.e. How do you know it is occuring? ] Jul 25 20:48:46 Abhishek_ :control size is 104 bytes so whenever i try to access 4096-104 = 3992th buffer location onwards and store in this line https://github.com/Apaar/PRU-Bridge/blob/master/src/driver/pru_bridge.c#L93 the print immediatly afterwards gives junk Jul 25 20:50:42 also i wrote this code to check if the shared memory is messing up https://github.com/Apaar/Flush-pru_shm .When i run it i can only write to the first 4096 locations from firmware also the rest is junk Jul 25 20:52:01 why do you close the file after mmaping? Jul 25 20:52:57 12K = 12 * 1024 . Jul 25 20:54:42 oops my bad the code was written in a hurry(pardon the lack of indentation) but still at exactly 4096 onwards it is junk aslo mmap seems to create a copy of the data/retain the mapping Jul 25 20:55:27 also 4096-8192 is junk and 8192 onwards it is all zeros Jul 25 20:59:48 apaar_: Look at the datasheet, where does the shared memory address start? Jul 25 21:01:56 * apaar_ feels very silly :( Jul 25 21:02:41 thank you :P that was a day wasted i assumed the address in the pru_defs would be right and just used it Jul 25 21:03:18 it's okay Jul 25 21:03:26 where's the wrong address? Jul 25 21:04:07 it is in the pru_defs.h 0x00012000 Jul 25 21:04:25 and it is exactly 2 pages in the shm Jul 25 21:04:36 that explains the first page working Jul 25 21:04:42 :P Jul 25 21:05:35 Abhishek_ :Also what time per read in userspace could be considered good for the data transfer?? Jul 25 21:05:56 get some numbers first Jul 25 21:07:30 i have got somewhere near 7-12 micro seconds using the C library for very small data tranfers i have to look at the faster 9 and 10 channels.. Jul 25 21:08:41 but that is with printk statements all over the place Jul 25 21:12:31 test the overhead for writing bytes in sizes of 1, 8, 16, 64, 256, 1024 and 4096 (for example) Jul 25 21:12:40 at a time Jul 25 21:13:16 yes i will do that this was for 1 byte at a time .right now need to catch some sleep Jul 25 21:13:30 Thanks again :) Jul 25 21:13:50 np **** ENDING LOGGING AT Sun Jul 26 02:59:58 2015