**** BEGIN LOGGING AT Thu Jun 18 02:59:57 2020
Jun 18 14:30:19 <deepankarmaithan> Hello Everyone
Jun 18 14:33:33 <jkridner[m]> hi. my internet is out. :-(
Jun 18 14:34:13 <deepankarmaithan> Hope you can have limited access on phone
Jun 18 14:35:12 <deepankarmaithan> This week i am trying to extend my PRU code and enable it read data from the shared memory. For this i am exploring  RPmesg,  ioremap  paths
Jun 18 14:36:20 <deepankarmaithan> Also went through the TI training slides to understand the Interconnects and interrupt better
Jun 18 14:37:25 <sakethr98[m]> hello! hi deepankarmaithani jkridner
Jun 18 14:37:36 <sakethr98[m]> <jkridner[m] "hi. my internet is out. :-("> oops! 😢
Jun 18 14:37:52 <deepankarmaithan> Also trying to get my head around the Vring
Jun 18 14:38:07 <sakethr98[m]> by shared memory you mean DRAM as ds2
Jun 18 14:38:13 <sakethr98[m]>  * by shared memory you mean DRAM as ds2 the other day?
Jun 18 14:38:38 <deepankarmaithan> I am exploring the possibilities not sure right now
Jun 18 14:39:18 <sakethr98[m]> on common storage end?
Jun 18 14:40:24 * deepankarmaithan uploaded an image: Architecture.png (98KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/qxiaoXuhNljjKZlPghCViAYv >
Jun 18 14:41:14 <deepankarmaithan> There is a  shared space  below L3 connect as shown haree
Jun 18 14:42:03 <sakethr98[m]> okay...
Jun 18 14:42:05 <sakethr98[m]> and....
Jun 18 14:42:28 <deepankarmaithan> Looking towards the mentors to guide me to take a suitable path and a approach that can best suit to minimise latency
Jun 18 14:44:11 <deepankarmaithan> Ds2 mentiond DRAM  i am a little confused if  by DRAM he  ment the same shared memory
Jun 18 14:45:13 <deepankarmaithan> Abhishek_:    Long time  since i saw you here. looking forward to disuss things with you
Jun 18 14:46:28 <deepankarmaithan> sakethr98:  We were discussing the beaglelogic code  and there were some snippets where a shared memory access was implemented. can you point me to the part where it was. May be can use it as  an example
Jun 18 14:47:22 <sakethr98[m]> give me a minute
Jun 18 14:48:43 <sakethr98[m]> https://github.com/abhishek-kakkar/BeagleLogic/blob/master/kernel/beaglelogic.c#L1227
Jun 18 14:48:52 <sakethr98[m]> https://github.com/abhishek-kakkar/BeagleLogic/blob/master/firmware/beaglelogic-pru0.c#L52
Jun 18 14:49:40 <deepankarmaithan> thanks :)
Jun 18 14:59:16 <jkridner[m]> for pru, there is program memory, data memory, shared data memory and external DDR across the L3 bus. DRAM can be confusing, because sometimes the D means data and sometimes it means DDR DRAM, which is double-data rate dynamic random access memory. DDR3 can be thrown in there to say 3rd generation of DDR. DDR is to distinguish from SDRAM, which is synchronous dynamic random access memory. DRAM and SDRAM differ by
Jun 18 14:59:17 <jkridner[m]> using a clock in the interface. Then there is SRAM, which is the type used on-chip, which is made of transistor cells rather than capacitor cells. SRAM is static RAM, rather than dynamic. Any dynamic memory made from capacitors requires refresh cycles to handle capacitive discharge.
Jun 18 14:59:40 <jkridner[m]> So, just ask which D is intended next time to make it clear. ;-)
Jun 18 15:00:34 <jkridner[m]> there is L3 shared memory on-chip, but it is unlikely that is used by the PRU.
Jun 18 15:02:11 <jkridner[m]> for some reason, that diagram leaves off the external 512MB DDR3L SDRAM. (at least I think it is DDR3L)
Jun 18 15:05:49 <deepankarmaithan> Thanks for the long explanation was quite helpful. So what i get is we are going to use the shared memory(shown below L3 interconnect)  where the main processor will write the data and then there will be an interupt which the PRU will check and then will read data from it
Jun 18 15:08:54 <jkridner[m]> I thought it was bigger, but the on-chip shared RAM is just 64kB according to https://www.ti.com/product/AM3358. You’ll see a lot of references to it as OCMC which stands for on-chip memory controller. This is fast memory for messages between cores or performing key algorithms. I don’t know if anything in Linux uses it by default.
Jun 18 15:09:42 <jkridner[m]> What do you plan to use the OCMC for? Cool to give it some usage!
Jun 18 15:11:03 <jkridner[m]> OCMC is different from Shared Data RAM in the PRUSS.
Jun 18 15:12:13 <deepankarmaithan> Okay  i think our data size should be less than 64KB.  What do you think
Jun 18 15:12:20 <deepankarmaithan> sakethr98:
Jun 18 15:13:00 <sakethr98[m]> thanks for thew clarity on memory type s.
Jun 18 15:13:16 <deepankarmaithan> I need to study more about OCMC.
Jun 18 15:13:56 <sakethr98[m]> isn't 64kb large enough memory for a io device to use?
Jun 18 15:16:11 <deepankarmaithan> jkridner:  Does the access mechanism remains the same in case of shared RAM , like writing to the memory by host and then notifing the PRU by interupt
Jun 18 15:16:52 <deepankarmaithan> Can RPmsg be used  to access shared RAM
Jun 18 15:18:17 <sakethr98[m]> i'd say look at beaglelogic code
Jun 18 15:18:49 <deepankarmaithan> okay
Jun 18 15:19:18 <deepankarmaithan> So the next question is to figureout  memory address  range of this shared RAM
Jun 18 15:35:00 <jkridner[m]> <deepankarmaithan "jkridner:  Does the access mecha"> The PRU Shared Data RAM doesn’t go through L3, so it is much faster for the PRUs than OCMC.
Jun 18 15:35:37 * jkridner[m] kicks Comcast
Jun 18 15:37:36 <deepankarmaithan> Ok so it is part of PRU subsystem.  I thought the shared RAM is only shared between the two PRUs and cant be accessed by host.
Jun 18 15:52:48 <jkridner[m]> It can be written by the host.
Jun 18 15:53:02 <jkridner[m]> host = A8
Jun 18 15:56:25 <deepankarmaithan> * waiting for the response to be completed :P
Jun 18 15:57:13 <jkridner[m]> UIO drivers provide access to memory regions that aren’t part of the OS allocated RAM. UIO can be used to give access to the PRU control registers and program memory, but we don’t enable that by default anymore and instead use remoteproc. We do enable UIO to access both the data RAMs for each PRU and the shared data RAM for the PRUSS.
Jun 18 15:59:08 <deepankarmaithan> Okay makes some sense now.
Jun 18 16:01:33 <deepankarmaithan> I will look into the new information provided by you today and will get back with more questions later. Thanks for the response. Just one more last question.  As i understand there are 2 shared RAMs one is a shared RAM which is shared between the two PRUs and the other is this 64KB of shared RAM which can be accessed by PRU and Host
Jun 18 16:23:01 <lorforlinux[m]1> <jkridner[m] "Nice. I guess that is because of"> Affirmative, That's because of using symlinks.
Jun 18 16:26:18 <jkridner[m]> <deepankarmaithan "I will look into the new informa"> Both the PRUs and A8 can access both shared RAMs. The PRUSS shared RAM is really fast for the PRUs and kinda slow for the A8. The OCMC shared RAM is faster for the A8 and slower for the PRUs.
Jun 18 16:29:25 * nwan[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/cXfjcgmwcEBegXCGlcrryZvP >
Jun 18 16:30:38 <lorforlinux[m]1> I think the main problem at this moment is to resolve, how to choose correct macro to allow using the absolute physical address instead of the padconf registers instead of the offset from padconf base?
Jun 18 16:34:46 <sakethr98[m]> deepankarmaithani:  here's a similar issue on SO https://stackoverflow.com/questions/53431040/acessing-shared-memory-between-the-pru-and-beagle-bone
Jun 18 16:35:47 <sakethr98[m]> https://groups.google.com/forum/#!topic/beagleboard/lEZk9488pWA from the archives
Jun 18 16:36:57 <sakethr98[m]> https://github.com/robmurrer/bbb-pru-sharedmem
Jun 18 16:38:58 <lorforlinux[m]1> jkridner: is it possible to use #if #else within DT for makefile to create separate dtb for each board?
Jun 18 16:40:54 <lorforlinux[m]1> Also current cape_pins_default: cape_pins_default {...} for each BBAI overlay must be resolved before we think about single overlay, what can i do to help with that?
Jun 18 16:42:09 <lorforlinux[m]1> One more thing on BBAI we have two pins to consider most of the time which is not the case with BBB and this will also hinder the process of creating unified DT for the boards.
Jun 18 16:46:33 <jkridner[m]> <sakethr98[m] "https://github.com/robmurrer/bbb"> My bitflip example used to be at https://github.com/beagleboard/cloud9-examples/tree/v2020.01/BeagleBone/Black/pru
Jun 18 16:46:54 <lorforlinux[m]1> jkridner: see this -> https://pastebin.com/Q2cReLPf
Jun 18 16:47:09 <jkridner[m]> There's a PocketBeagle example at https://github.com/beagleboard/cloud9-examples/blob/v2020.01/PocketBeagle/pru/bitflip.pru0.c
Jun 18 16:47:20 <jkridner[m]> with ARM host code at https://github.com/beagleboard/cloud9-examples/blob/v2020.01/PocketBeagle/pru/bitflip.arm.c
Jun 18 16:48:19 <jkridner[m]> <lorforlinux[m]1 "jkridner: is it possible to use "> No, that'd be bad, because it would make multiple .dtb files.
Jun 18 16:48:20 <jkridner[m]> er, dtbo
Jun 18 16:50:27 <jkridner[m]> <lorforlinux[m]1 "Also current cape_pins_default: "> You can make the changes I had on that one tree against 2019.04 per https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot .... unless rcn-ee isn't using that version of the bootloader, in which case he needs to update that wiki page.
Jun 18 16:53:43 <jkridner[m]> <lorforlinux[m]1 "One more thing on BBAI we have t"> Indeed, figuring out which pin to enable could be a challenge, but if there is only one selection for uart, qep, etc. and the other pin is in a passive state, it should be OK. The challenge in my mind is that only one of them should have a pull-up/down enabled and that might not be the one that gets configured.
Jun 18 16:54:09 <jkridner[m]> much of this would be better discussed with patches and posted at least to the beagleboard googlegroups list, if not linux-omap.
Jun 18 16:55:35 <lorforlinux[m]1> <jkridner[m] "You can make the changes I had o"> okay, I will try this.
Jun 18 16:56:49 <jkridner[m]> lorforlinux: what you did by making pinsets for each peripheral seems like it solves the problems for overlay!
Jun 18 16:56:50 <lorforlinux[m]1> what is your idea to create a unified dtbo file?
Jun 18 16:57:09 <lorforlinux[m]1> how to resolve padconf macro issue in DT?
Jun 18 16:57:40 <jkridner[m]> you just need to create one of those for each of the '/dev/bone' aliases and have the common overlays use those.... and make the symbol names generic across the base device trees, rather than device-specific entries.
Jun 18 16:58:23 <jkridner[m]> yes, it has always been to create 1 dtbo for BBAI and BBB. man, I've tried to say that SO many times now. not sure how it keeps coming into doubt.
Jun 18 16:58:27 <jkridner[m]> that is the compatibility part.
Jun 18 16:58:41 <jkridner[m]> not source compatibility, binary compatibility.
Jun 18 16:59:01 <jkridner[m]> there is symbol resolution. worst case, we have to use the socket/connector thing that Frank was creating.
Jun 18 16:59:24 <jkridner[m]> but I think creating unified symbols (not aliases) should do everything we need.
Jun 18 16:59:45 <jkridner[m]> the entries for the ADC/touch get more complicated as there are a lot of controller-specific elements.
Jun 18 17:00:11 <jkridner[m]> but, uart, qep, i2c, spi, ... should all have the exact same entries and you just need to map them.
Jun 18 17:00:14 <jkridner[m]> even lcd.
Jun 18 17:00:38 <lorforlinux[m]1> yes I am getting that, but do you have any pointer for me to resolve the padconf part? I talked to rcn-ee he suggested me to create separate dtbo from single dts if possible using #if #else statements.
Jun 18 17:01:10 <jkridner[m]> <lorforlinux[m]1 "how to resolve padconf macro iss"> change the symbol names on the left side of the : to be the same.
Jun 18 17:01:50 <jkridner[m]> and move those definitions into the base tree!
Jun 18 17:02:08 <jkridner[m]> those don't need to be defined in the overlay, they can be in the base tree and only referenced by overlays.
Jun 18 17:02:31 <jkridner[m]> if all the device-specific stuff is created in the base tree, then the overlays can simply use them.
Jun 18 17:03:46 <jkridner[m]> it means the overlays won't be compatible with older base trees, but that's to be assumed. we just want to provide a full working set of examples of all those peripherals such that people can follow the exact same instructions on Black and AI to enable those peripherals at boot, ie., enable the exact same binary overlay.
Jun 18 17:05:35 <lorforlinux[m]1> Yeah it sounds like a plan, will try that thanks. I was thinking to create more BBAI_* overlays that's okay right? OR should I focus on this instead?
Jun 18 17:05:37 <jkridner[m]> <jkridner[m] "Indeed, figuring out which pin t"> I'd forgotten that the pins could be defined in the base tree, so this simply isn't an issue. Simply configure the right number of pins for the peripheral in the entry and give the same symbol names to each, with entries to match the board.
Jun 18 17:06:26 <lorforlinux[m]1> Right that's sounds good to me.
Jun 18 17:06:44 <jkridner[m]> <lorforlinux[m]1 "Yeah it sounds like a plan, will"> The BBAI_* entries are all throw-away to me. If you need to do them to make sure you are able to get the peripheral working, that's fine, but I expect you to delete them all in the end.
Jun 18 17:07:12 <lorforlinux[m]1> okay :)
Jun 18 17:07:36 <jkridner[m]> so, it is clear what I'm suggesting?
Jun 18 17:08:07 <lorforlinux[m]1> wait one more thing
Jun 18 17:13:38 <lorforlinux[m]1> got it, will try it out and let you know :)
Jun 19 01:10:04 <lorforlinux[m]1> jkridner: got same overlay dtbo file to work on both BBAI and BBB 😉
Jun 19 01:28:32 <lorforlinux[m]1> and same user space code is working on both the boards 🤑
Jun 19 01:32:08 <lorforlinux[m]1> one thing to note, I using up to date images from https://beagleboard.org/latest-images. 4.14 on BBAI and 4.19 on BBB
Jun 19 01:33:17 <lorforlinux[m]1> As soon as the 4.19 BBAI image becomes available I will switch over to it.
**** ENDING LOGGING AT Fri Jun 19 02:59:57 2020