**** BEGIN LOGGING AT Mon Jun 22 02:59:57 2020
Jun 22 12:52:30 <nwan[m]> Installation instructions for CTAG Face on BBB and BBAI https://niklaswan.github.io/GSoC-Overview/documentation/#ctag-face-alsa-driver
Jun 22 12:57:41 <nwan[m]> Week 3 progress: https://groups.google.com/forum/#!topic/beagleboard-gsoc/QwMJGBXj8DQ
Jun 22 13:05:07 <deepankarmaithan> ds2:  As you suggested used ioremap to map the shared memory space, i am using OCMC RAM as shared memoy space as suggested by jkridner . Figured out the base address , offsets  and can now read and write to OCMC RAM space. Now working  the other part of the puzzle where i need to figure out how to  kick interrupt on the R31 register when there is new data. Any pointers Abhishek_  sakethr98 .
Jun 22 13:05:15 <deepankarmaithan> https://github.com/deebot/Beaglebone-BidirectionBus/tree/master/MEMdriver
Jun 22 13:15:46 <jkridner[m]> <deepankarmaithan "ds2:  As you suggested used iore"> If you are trying to do fast memory transfer, I suggest you do ring buffers and not interrupts.
Jun 22 13:16:06 <jkridner[m]> <jkridner[m] "If you are trying to do fast mem"> btw, I didn't suggest using OCMC, I just tried to explain what it was.
Jun 22 13:16:40 <sakethr98[m]> the idea was to use a shared RAM space if I'm not wrong
Jun 22 13:18:51 <deepankarmaithan> oh!! sakethr98  we were all time focusing on it.  jkridner  do you think there will be drawback in using this space? i think the 56KB which we have out of 64KB is sufficient for our task
Jun 22 13:19:15 <deepankarmaithan> Looking into ring buffers now
Jun 22 13:19:31 <jkridner[m]> It is quite a bit bigger than the PRUSS shared data RAM.
Jun 22 13:19:44 <jkridner[m]> I'd mentioned the big difference is which core can access it fast.
Jun 22 13:20:07 <jkridner[m]> OCMC is faster for the ARM Cortex-A8. PRUSS shared data RAM is faster for PRUs.
Jun 22 13:22:56 <deepankarmaithan> but dont you think the system will be as fast as the slowest element.  Any way it is going to be slower  at  one of the side.
Jun 22 13:28:40 <deepankarmaithan> sakethr98:  what should be the next plan of action then?
Jun 22 14:37:26 <jkridner[m]> a profile would be needed to see what the overall performance would be.
Jun 22 14:38:12 <sakethr98[m]> which means, go ahead using the OCMC and benchmark it?
Jun 22 14:47:28 <jkridner[m]> lorforlinux: have you seen the buildroot releases of beagle-tester? it is how it is most typically consumed.
Jun 22 14:47:54 <jkridner[m]> <sakethr98[m] "which means, go ahead using the "> I mean benchmark with each OCMC and Shared DRAM.
Jun 22 14:48:10 <jkridner[m]> unless you really need that much memory.
Jun 22 14:48:59 <sakethr98[m]> okay got it.
Jun 22 14:51:00 <jkridner[m]> <jkridner[m] "lorforlinux: have you seen the b"> https://github.com/beagleboard/buildroot/releases/tag/bt-0.1.15
Jun 22 15:11:08 <pratimugale[m]> vedant16: Hey, how's the progress
Jun 22 15:16:40 <vedant16[m]> Hey @pratimugale:matrix.org I'm done with front end, now i started implementation of abstract syntax tree this weekend, finished implementint AST. Right now integrating with parser.
Jun 22 15:31:09 <jkridner[m]> <jkridner[m] "https://github.com/beagleboard/b"> Stuff I've added: https://github.com/beagleboard/buildroot/compare/b9674056fbe8d37c1b11ad524075f21dc5deaa15...beagle-tester
Jun 22 15:32:21 <lorforlinux[m]> <jkridner[m] "https://github.com/beagleboard/b"> yes I have but I didn't knew how to use them, I simply used the commands you provided to install beagle-tester and used it that way.
Jun 22 15:34:03 <jkridner[m]> I wish there was some way to avoid putting overlays into uenv.txt, but I'm not sure how. perhaps if the scan doesn't match, then the uenv.txt could be updated and a reboot could be performed. then, you can test a number of the same capes over-and-over, only rebooting for the power cycle to connect the cape.
Jun 22 15:34:52 <jkridner[m]> for the production testing, Debian boots too slow.
Jun 22 15:35:01 <jkridner[m]> so, we use these buildroot images.
Jun 22 15:35:39 <jkridner[m]> I customize the u-boot environment (guess it isn't uenv.txt) for different capes if they use the overlays.
Jun 22 15:35:45 <lorforlinux[m]> <lorforlinux[m] "yes I have but I didn't knew how"> Commands I used:
Jun 22 15:36:16 <jkridner[m]> if you are going to start using the overlays within beagle-tester, we'll need to update those tests to use the overlays as well.
Jun 22 15:36:54 <jkridner[m]> reason: before the EEPROM is programmed, no overlay is loaded on boot. ... and beagle-tester programs the EEPROM.
Jun 22 15:37:43 <jkridner[m]> I think I can make the change I'm suggesting to the buildroot images.
Jun 22 15:38:11 <jkridner[m]> as I recall, buildroot has the fw_saveenv utility implemented.
Jun 22 15:38:40 <jkridner[m]> and I can use the 'CHOSEN' in /proc/device-tree to see if the overlay is loaded.
Jun 22 15:41:30 <lorforlinux[m]> <jkridner[m] "so, we use these buildroot image"> ohh, It was just to make things faster okay. But, can't we just use the system(command) for setting up the devices and testing each cape and avoid using overlays? This will also allow people to know how they can use the capes without having overlays in place.
Jun 22 15:43:35 <jkridner[m]> system doesn't help avoid using overlays.....
Jun 22 15:43:47 <jkridner[m]> if you have overlays, then you use the device driver interfaces.....
Jun 22 15:43:59 <jkridner[m]> if you don't have overlays, you use the userspace interfaces.
Jun 22 15:44:15 <jkridner[m]> it is best to test the device driver interfaces and therefore to use overlays.
Jun 22 15:44:37 <jkridner[m]> for the capes you have, the EEPROMs are already programmed.
Jun 22 15:45:00 <jkridner[m]> the Debian images should therefore load the overlays using the u-boot cape manager.
Jun 22 15:45:37 <jkridner[m]> The buildroot images don't have the u-boot cape manager and production tests won't have the EEPROMs programmed before running beagle-tester.
Jun 22 15:47:31 <lorforlinux[m]> jkridner: okay, I guess I need some more time with beagle-tester before suggesting something reasonably legit here. I don't know the inner working on cape-manager still, which I really want to know as i want to make it work with BBAI also.
Jun 22 15:47:57 <jkridner[m]> I'll need to add into buildroot something that will program the u-boot environment to load the overlay on the next boot (and print a notification accordingly). you'll need to update beagle-tester to use the device driver interfaces, rather than the userspace interfaces.
Jun 22 15:51:42 <lorforlinux[m]> Okay can we do one thing, create a program that writes the EEPROM id for the cape by asking user what cape is loaded? So that on next boot the overlay is loaded automatically (for build root it's not possible as cape manager is not there)?
Jun 22 15:53:22 <lorforlinux[m]> <jkridner[m] "I'll need to add into buildroot "> I will gradually do that as project progresses, I hope that's okay with you.
Jun 22 15:59:12 <lorforlinux[m]> <lorforlinux[m] "Okay can we do one thing, create"> I don't know if it makes sense here, but it would be nice if we can just use the beagle-tester on any normal beagle-bone image (like IoT image) without having to think about a separate build-root image.
Jun 22 15:59:35 <vedant16[m]> Hey Abhishek_ pratimugale hendersa
Jun 22 16:00:52 <jkridner[m]> <lorforlinux[m] "Okay can we do one thing, create"> Not exactly. Don't worry about it right now. Assume the overlay is loaded.
Jun 22 16:01:44 <jkridner[m]> <jkridner[m] "Not exactly. Don't worry about i"> cape manager isn't the only way to load an overlay from u-boot. It is just a mechanism that uses the EEPROM ID to load the overlay.
Jun 22 16:01:45 <pratimugale[m]> vedant16:
Jun 22 16:01:46 <pratimugale[m]> Hey
Jun 22 16:02:11 <vedant16[m]> So i finished frontend
Jun 22 16:02:37 <vedant16[m]> I have started work on backend, implementing AST, then i can convert AST to assembly or C code
Jun 22 16:03:32 <lorforlinux[m]> <jkridner[m] "Not exactly. Don't worry about i"> okay :)
Jun 22 16:07:08 <pratimugale[m]> vedant16: Nice, anything blocking you?
Jun 22 16:08:36 <vedant16[m]> Nothing right now.
Jun 22 16:08:48 <vedant16[m]> But ast might be a issue
Jun 22 16:09:03 <vedant16[m]> I check several tutorials, that guy directly converted ast to llvm
Jun 22 16:09:16 <vedant16[m]>  * I check several tutorials, that guy directly converted ast to assembly code
Jun 22 16:09:23 <vedant16[m]> I could do that, thus eliminating need for LLVM
Jun 22 16:11:18 <pratimugale[m]> <vedant16[m] "I check several tutorials, that "> Can you send the links
Jun 22 16:12:05 <pratimugale[m]> <vedant16[m] "I could do that, thus eliminatin"> okay
Jun 22 16:12:15 <vedant16[m]> https://github.com/drifter1/compiler
Jun 22 16:12:29 <vedant16[m]> check the readme, machine code generation part
Jun 22 16:13:23 <pratimugale[m]> thanks
Jun 22 16:20:49 <pratimugale[m]> vedant16: I'll have a look at it, I think its OK if LLVM / GCC is difficult, need to check with Abhishek and hendersa
Jun 22 16:22:40 <vedant16[m]> <pratimugale[m] "vedant16: I'll have a look at it"> Okay
Jun 22 16:23:34 <pratimugale[m]> vedant16: Let me know if you have any other questions, I have to go AFK
Jun 22 16:24:03 <vedant16[m]> Nothing as of now, but are Abhishek_ and pratimugale coming today ?
Jun 22 16:25:49 <pratimugale[m]> Don't think think they're around today
Jun 22 16:26:31 <vedant16[m]> Ohk, when should we discuss the project name thing with cwicks
Jun 22 16:28:14 <pratimugale[m]> Let's do it this Wednesday, or if you have anything in mind I'll communicate it to cwicks
Jun 22 16:30:11 <vedant16[m]> Wednesday is okay, we could do it a bit early 9.30 pm ist ?
Jun 22 16:31:45 <pratimugale[m]> Okay
**** ENDING LOGGING AT Tue Jun 23 03:03:14 2020