**** BEGIN LOGGING AT Sat Jun 04 02:59:58 2016 Jun 04 14:10:06 Hello everyone . Been unwell, suffering from stomach infection and resulted in body weakness. Jun 04 14:10:20 Taking medication. Jun 04 14:11:10 Will be online through mobile ... But will not be active much. Jun 04 14:11:52 Abhishek_: ds2 ^^ Jun 04 14:13:04 ZeekHuge: hi, Get well soon! Jun 04 14:18:13 ouch, sorry to hear that ZeekHuge Jun 04 14:53:41 pru_rproc looks to be working fine on 4.4: https://gist.github.com/alexanderhiam/2c4187c710b2c409d8dde8c4015fe007 Jun 04 15:22:30 alexhiam: so no pru problem for 4.4? Jun 04 15:23:14 nope, just done in a different way Jun 04 15:23:34 see my notes on the ml as well Jun 04 15:23:35 https://groups.google.com/forum/#!topic/beagleboard-gsoc/amMNLt4EoHM Jun 04 15:30:47 kiran4399: sensors working? Jun 04 15:34:32 alexhiam: Well.. I came to parents house.. couldn't test it.. I am leaving today and will be in my lab tomorrow morning.. I'll test it then.. :-( Jun 04 15:42:54 hey alexhiam ,mdp Are you there? Jun 04 15:44:03 I have some doubts in the firmware code.Now I have understood regarding that input is defined by r31.What I have not figured out is how to write to the shared mem.. Jun 04 15:45:12 I cannot find a function that does so.So there is no explicit way to write in the shared mem?I mean we can only use RPMsg? Jun 04 15:55:45 alexhiam: that's a good news :), I didn't try that coz was waiting for r-30, as rcn said here https://groups.google.com/forum/m/#!topic/beagleboard-gsoc/aSFxmYjrWuA. ... But then this stomach infection thing :( and weakness. Jun 04 15:58:56 ZeekHuge, Hey what happened? Jun 04 15:59:21 Sick? Jun 04 15:59:31 ZeekHuge: interesting, I missed that post. I assume I must have those changes, since I just built this kernel from rcn's 4.4 branch Jun 04 16:02:25 chanakya_vc: I'm not sure, I haven't seen any recent examples of using the shared memory... Jun 04 16:04:13 chanakya_vc: yes, been suffering from stomach infection and weakness. Bit better now. Jun 04 16:05:20 alexhiam: even to build from source, you must have used a branch with some yag Jun 04 16:05:26 *tag ? Jun 04 16:05:30 Right ? Jun 04 16:06:24 oh, actually, looking at the history it is 4.4.11-ti-rt-r29 Jun 04 16:06:45 So what version it is ... I can start from that version itself, without testing other images Jun 04 16:06:56 Okay Jun 04 16:09:37 I guess rcn hasn't pushed those changes yet.. Jun 04 16:12:11 alexhiam, Okay! Jun 04 16:12:35 ZeekHuge, I hope you get well soon! Take care! Jun 04 16:23:01 alexhiam, I am looking at the communication portion here:http://elinux.org/Ti_AM33XX_PRUSSv2 Jun 04 16:23:28 It talks about the interrupt system.But I believe this is a old document right? Jun 04 16:24:42 yeah, that's using prussdrv Jun 04 16:24:56 so <= 3.8 Jun 04 16:25:03 I think Jun 04 16:26:17 alexhiam, Okay.I did not anticipate all this while researching for the proposal. Jun 04 16:27:16 yeah, I didn't realize it had changed so much Jun 04 16:27:39 alexhiam, I have to figure out a way to let the PRU talk to the ARM.I see no other option than RPMsg.I cannot find a way to directly address the shared mem from the firmware. Jun 04 16:28:27 But then the problem with remoteproc also exists Jun 04 16:28:27 chanakya_vc: have you looked at older code? like pruspeak and beaglelogic? it might still be the same... Jun 04 16:29:18 it's just writing bytes to a memory address, so it really shouldn't be any different Jun 04 16:29:21 No I had a quick glance. But at any rate both are build using remoteproc right? Jun 04 16:29:43 yeah, but totally incompatible w/ the current remoteproc Jun 04 16:30:00 so looks like rcn's 4.4 branch does have all the latest from ti Jun 04 16:30:23 no diff between its remoteproc and the latest on the ti tree Jun 04 16:30:38 on the ti-rt-linux-4.4.y branch that is Jun 04 16:31:00 alexhiam, Yes.That's the problem.I have just got a way to figure out a way to just let the PRU write at certain memory loc .I don't believe that TI has not given a way for that Jun 04 16:31:53 you could just manually set a pointer Jun 04 16:34:14 Data RAM2 = 0x10000 Jun 04 16:37:28 that's on the pru side... Jun 04 16:40:17 alexhiam,Okay. But are you sure?I mean won't this come in conflict with the addresses of the internal registers ?Because they also have the same address Jun 04 16:41:06 Like when you say data ram2= 0x10000,how does the PRU know you are not referring to the first bit of r30 register? Jun 04 16:43:04 chanakya_vc: not sure what you mean.. R30 and R31 are processor registers Jun 04 16:49:00 alexhiam,Sorry for that.I got confused Jun 04 16:49:19 np Jun 04 16:49:27 alexhiam, Forgot that PRU only has internal RAM. Jun 04 16:50:08 So any pointer will result in a memory location in the shared mem. Jun 04 16:50:59 chanakya_vc: oh wait, the PRU_access_const_table example does use shared mem Jun 04 16:51:34 alexhiam, Link? Jun 04 16:51:50 in the pru-software-support-package Jun 04 16:52:24 http://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/examples/am335x/PRU_access_const_table/PRU_access_const_table.c#line102 Jun 04 16:52:46 Okay I will check it out alexhiam. Jun 04 16:53:11 PRU_SRAM volatile uint32_t shared_freq_1; Jun 04 16:53:19 Thanks for your help! Jun 04 16:53:39 * alexhiam is liking this new pru_rproc more and more Jun 04 16:56:00 #define PRU_SRAM __far __attribute__((cregister("PRU_SHAREDMEM", near))) Jun 04 17:01:15 the C28 pointer business is a little annoying Jun 04 17:03:51 I didn't know the PRU-ICSS has it's own eCAP... **** ENDING LOGGING AT Sun Jun 05 02:59:58 2016