**** BEGIN LOGGING AT Wed Jun 19 02:59:57 2019 Jun 19 05:22:20 As @hendersa is not seem online for quite a few days for now because i am not getting any reply from him so any suggestions from other mentor will be quite helpful for me @abhishek_:matrix.org @ds2 Jun 19 05:38:48 pranav_kumar[m]: what do you need? Jun 19 05:40:23 Now i get the assembly code working through the gpio Jun 19 05:41:21 But all the pins are functional in mode 7 only some how Jun 19 05:44:57 I think i should be go further with the kernel modules development and in meantime make changes to the assembly code in accordance with requirements Jun 19 05:46:58 But i am not able to understand how to move further with assembly code and kernel module at the same time plz guide me through that Jun 19 05:50:24 okay... not sure if I understand what you are getting at, so let's break it down Jun 19 05:50:46 so all your assembly code is not time critical? is this right? Jun 19 05:51:29 are you aware of the difference between the mode 7 pins and the pins accessed via r30/r31? Jun 19 05:57:56 Yes i am aware of the pins but as you can see in the device tree file i have created https://github.com/pranav083/pocket_beagle-work/blob/master/pru/PRU-GPIO-EXAMPLE2.dts here the one pin that is in mode i had tried to access it using the SET Aand CLR intruction but i was not able to done that while access the pins in the Mode 7 was possible for me Jun 19 05:57:57 Yes i am aware of the pins but as you can see in the device tree file i have created https://github.com/pranav083/pocket_beagle-work/blob/master/pru/PRU-GPIO-EXAMPLE2.dts here the one pin that is in mode i had tried to access it using the SET Aand CLR intruction but i was not able to done that while access the pins in the Mode 7 was possible for me Jun 19 05:58:37 Time critical means?? Jun 19 05:59:52 The one pin is mode 6 that is p8_11 pin which can act as output Jun 19 06:01:27 pranav_kumar[m]: okay... those mode 7 pins are access by talking over the internal buses to the GPIO block. That internal bus is shared with the ARM processor. What this means is access by the PRU can be queued and may take an unknown number of cycles. Jun 19 06:02:04 In contrast the pins accessed via r30/r31 are directly connected to the PRU. So when you set or clear a bit, it takes effect within one cycle. This gives you very specific timing control. Jun 19 06:02:48 For example, if you had a loop that sets and clears a pin. The mode 7 pin may have a lot of jitter whereas the r30/r31 accessed pin would not have any jitter Jun 19 06:05:50 pranav_kumar[m]: i suggest getting a better handle on these concepts before getting too far.... the direct PRU access works slightly differently as far as the pinmux is concerned - outputs and inputs are different pinmux modes Jun 19 06:07:00 pranav_kumar[m]: the other thing to keep in mind is - access to the mode7 GPIOs needs to be done via memory access. r30/r31 only works on the directly connected GPIOs Jun 19 06:07:29 i have tried that also but not be able to reflect my changes on the pins Jun 19 06:08:33 pranav_kumar[m]: which pins are you not able to reflect your changes? Jun 19 06:08:33 https://gist.github.com/pranav083/5e666ff1b78cfe28f2073b420f2511e0 Jun 19 06:09:33 ds2: How do you access the PRU data and shared memory? Is it through /dev/mem? Jun 19 06:09:44 p8_11 pin Jun 19 06:09:48 in mode 6 Jun 19 06:11:12 or is there any other way it's supposed to be done? Jun 19 06:11:37 and also from the site https://elinux.org/Ti_AM33XX_PRUSSv2#Beaglebone_PRU_connections_and_modes it shows the pin property as pru0_pru_r30_15 as a output pin Jun 19 06:11:55 pratimugale[m]: what do you mean access? from the ARM or ? Jun 19 06:12:13 @ds2 yes, from the ARM Jun 19 06:12:34 pratimugale[m]: which driver? uio or or remoteproc? Jun 19 06:12:42 remoteproc Jun 19 06:13:14 pratimugale[m]: if you must do it from user land, /dev/mem but I strongly advise against that... a proper kernel driver is strongly recommended Jun 19 06:14:14 i was simply runnning SET and CLR command to see the effect in the pins with a small delay of time Jun 19 06:14:58 pranav_kumar[m]: that gist.github.com page shows a lack of understanding...trying to put together something understanding... give me a few Jun 19 06:15:11 @ds2 Okay, thanks Jun 19 06:16:50 regarding comment in the code Jun 19 06:20:10 pranav_kumar[m]: Do you have any documentation/write up on exactly what you are trying to accomplish? Jun 19 06:22:45 pranav_kumar[m]: if not, I suggest you writing it up... prehaps on a blog page Jun 19 06:24:34 yes as said by @henderson that i have to first run assembly code using the pru register avialable to me that is bascially using the register r30 of the pru Jun 19 06:25:04 let me start again Jun 19 06:25:18 access to r30/r31 do not access anything set to mode7 Jun 19 06:25:33 ok Jun 19 06:26:13 yes that right Jun 19 06:27:42 because i have access only those pins which are aceessable by pru register directly that is for output is register r30 and for input it is register r31 Jun 19 06:28:03 yes Jun 19 06:28:12 let's take an example - GPIO1_30 Jun 19 06:28:37 if you set that to mode 7, you will need to access it via the LBBO/SBBO instructions Jun 19 06:29:06 if you set it to mode 6, (aka pr1_pru1_pru_r31_12), you access it via bit 12 of r31 and it is input only Jun 19 06:29:25 if you set it to mode 5, (aka pr1_pru1_pru_r30_12), you access it via it 12 of r30 and it is output only Jun 19 06:29:50 ok that is p8_21 pin Jun 19 06:30:04 yes thats true Jun 19 06:30:04 so to make sense for anyone else, I suggest you create a write up on your blog/wiki/etc Jun 19 06:30:26 a table of what pin and what function you are using it for Jun 19 06:30:57 yes so then the command will be SET r31.t12 right Jun 19 06:31:19 for example the table would say OE - GPIOX_Y - PN_M - mode A - input Jun 19 06:31:28 and do that for all the pins Jun 19 06:31:36 after making changes to the .dts file Jun 19 06:31:50 prehaps even add a brief descript of what that is... so OE would be - Output enable, active high or low Jun 19 06:32:23 ok thanks for suggesting i will make that Jun 19 06:32:38 it is fine to change the dts and you can change it to whatever you want but organizing will help anyone looking at it make sense Jun 19 06:33:05 unless you have that information, it is hard to figure out if it si correct or not Jun 19 06:33:48 to make sense of that assembly file, I would pretty much create something like that but I still donno what is intended/correct hence you need to provide that Jun 19 06:34:11 am i write in this Jun 19 06:34:21 heh.... evals open next monday ! Jun 19 06:34:34 what are you writing in what? Jun 19 06:35:08 sry the code SET r30.t12 Jun 19 06:35:55 pranav_kumar[m]: yes but that only works if you set the pinmux to mode 5 Jun 19 06:36:43 the pinmux is literally a multiplexer... it has inputs from different parts of the SoC going into/out of it. the mode selects which one Jun 19 06:37:08 yes that the problem that i have faced when accesing the pin p8_11 in mode 6 and if was not working as expected Jun 19 06:37:22 so even if your code does everything right, it may not show up on the physical ball/pin until the mux is configure correctly Jun 19 06:37:34 pranav_kumar[m]: mode 5!!!!!!!!! Jun 19 06:37:57 input and output are different modes for the directly connected pins Jun 19 06:38:27 download the am3358 datasheet (not the TRM). There is a table that lists all the modes and their functionality Jun 19 06:38:45 from your point of view, search it by the mode7 name Jun 19 06:42:27 i was following the pin mux mapping from http://exploringbeaglebone.com/wp-content/uploads/resources/BBBP8Header.png in which it mode 6 for pr1_pru0_pru_r30_15 for the gpio 1_13 pin no .p8_11 Jun 19 06:46:35 ok i will try that again and follow up with the documentation/blog part Jun 19 07:39:18 try not to blindly follow other people's blogs/articles Jun 19 07:51:24 * embden[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/MZIIhUVIKtcQdkPUrryxQWaa > Jun 19 07:52:18 all symbols are defined Jun 19 08:42:42 embden[m]: Can you push your code somewhere? Jun 19 08:45:58 embden[m]: I think the wait loop will not work correctly on Xen. But it should not be necessary for testing purpose here. The following 3 lines should be enough: Jun 19 08:46:00 ldr r12, =API_HYP_ENTRY Jun 19 08:46:02 adr r0, hyp Jun 19 08:46:04 smc #0 Jun 19 09:57:15 julieng: yes, I tried it before and it didn't work. But I'll definitely push my code to somewhere. By it didn't work I mean that the was no output from the PRINT instruction right after smc, so, maybe the instruction did work but it just wasn't able to continue the execution after the smc handler. So shouldn't we store the context first? Jun 19 10:05:45 embden_[m]: The earlyprintk code relies on r11 to point to the UART base address. This is set before smc #0. My guess is the smc will clobber all the registers. Jun 19 10:06:07 embden_[m]: You could quickly try to do ldr r11, =EARLY_UART_BASE_ADDRESS /* r11 := UART base address */ Jun 19 10:06:20 just after the label hyp. Jun 19 10:07:17 ok, I'll be back with the results in an hour or two Jun 19 10:08:29 the Linux code clearly saves and restores r2-r12 around the smc call, so yeah: the handler will clobber those Jun 19 11:21:46 julieng: apritzel yes, after writing back to r11 the uart address I get the output up to Setting up control registers Jun 19 11:27:24 embden_[m]: Youhou! Now that we know it works, I would create a separate entry point for omap5. The entry point would switch the CPU to hyp mode and then jump to the normal entry point (i.e init_secondary). Jun 19 11:35:34 apritzel: could you point me to the place where r2-r12 are saved and stored aroung smc - I do not completely understand the code. Jun 19 12:05:11 julieng: I am not completely understand the execution flow before init_secondary, but I have some great news - the debugger and power supplys have just arrived Jun 19 12:21:54 embden_[m]: I think apritzel meant in omap-smc.S. So he inferred that the smc done in omap5_secondary_hyp_startup may also clobber registers r2-r12. Jun 19 12:22:19 In general as we don't have a clear understanding of how the smc works on TI platform, it would be best to assume the "worst". Jun 19 12:22:48 embden_[m]: That's a good news! Jun 19 12:23:20 embden_[m]: What do you mean by the "execution flow before init_secondary"? Jun 19 12:31:06 julieng: I can't see from where init_secondary is called Jun 19 12:32:28 I can see that address of the procedure is copied to..wufen_base+offset? Jun 19 12:33:33 a wake up generator Jun 19 12:33:33 embden_[m]: init_secondary is called from the ROM. Jun 19 12:34:17 embden_[m]: This is the entry point for secondary CPUs in Xen. Basically, we tell the ROM to start the secondary CPU and then jump into the init_secondary. Jun 19 12:34:45 You probably will probably be able to see the flow with the debugger. Jun 19 12:44:42 julieng: so, we are writing the address of the init procedure for CPU1 into a wkupgen region on an offset correspondent to wake-up of CPU1 and then we tell ROM to start CPU1 and it executes the procedure? Jun 19 12:53:41 embden_[m]: That's correct. Jun 19 13:52:41 julieng: https://pastebin.com/3JBw6S4K Jun 19 13:53:33 https://github.com/embeddedden/xen/commit/2d76ae7aacb7c0ea7312eaddb91c3eb1e1963cc9 Jun 19 14:33:52 embden[m]: don't forget to set up CNTFRQ, that's another smc call Jun 19 14:34:04 (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 0 KHz Jun 19 14:34:15 this will not end up well, I guess ... Jun 19 14:46:44 embden[m]: Looking at the code, you can't use sp to save/restore register because the value in sp is not known. At worst, you may overwrite part of Xen. Jun 19 14:47:27 embden[m]: In this case, I think it is unecessary to save/restore the registers as we don't care about any here. Jun 19 14:47:41 apritzel: Should it be done on every CPU? Or just the boot CPU? Jun 19 14:47:54 julieng: good question Jun 19 14:48:17 I would *assume* that it's correctly set up on CPU0 already, and you just copy this value to CPU1 Jun 19 14:48:38 embden[m]: Other than that, would you mind to submit the patch on xen-devel? I will have a closer look on the ML. Jun 19 14:48:39 but then again this would make sense, so I don't hold my breath on it :-D Jun 19 14:49:14 apritzel: The message is coming from CPU0, so I think it is not correctly setup :). Jun 19 14:49:54 julieng: ah, I see Jun 19 14:50:47 pranav_kumar: Tell me what's the last thing you did, what kind of guidance are you looking for right now. Jun 19 14:51:51 I am unnble to use gpio in other mode which is other than mode 7 Jun 19 14:52:24 I had followed the steps guided by @ds2 Jun 19 14:52:39 julieng: apritzel I'll try to fix it after the meeting Jun 19 14:53:01 embden_[m]: Thank you. I will reply on the ML as well to keep record of the progress. Jun 19 14:58:08 pratimugale: How's it going? Any blockers? Jun 19 14:58:42 I will have to leave early today, want to make sure you are covered. Jun 19 14:58:48 Evals are coming up next week. Jun 19 14:59:06 abhishek_: Yes, Do I need a seperate kernel driver for read/write to PRU data memory from ARM? Or should I directly do it through /dev/mem Jun 19 14:59:52 pratimugale: I think /dev/mem is OK as long as you know what you are doing - remember we don't want to go in the kernel unless absolutely required. Jun 19 15:00:36 i am sharing the code in a moment Jun 19 15:01:08 pratimugale: Make sure you implement address space checking so that user cannot do anything beyond the PRU shared memory for now. Jun 19 15:01:12 abhishek_: Okay, and what all should I complete up before the first evaluations Jun 19 15:01:38 No changes to the data memory? Jun 19 15:02:15 There is IRAM, DRAM and shared RAM. Just control access to DRAM and Shared RAM Jun 19 15:02:51 Okay Jun 19 15:02:53 pratimugale: Besides, if you use RPMsg correctly - you shouldn't need to manipulate memory directly Jun 19 15:03:37 RPMsg is supposed to provide a bidir data transmission channel where the memory is taken care of by the kernel driver. Jun 19 15:04:18 That's why I am stressing on providing good example code Jun 19 15:04:59 That demonstrates how RPMsg can be used. Sure, you have basic loopback but we need more examples. Jun 19 15:05:30 What kind of examples did you have in mind for using /dev/mem? Jun 19 15:05:34 understood, how should I start with the examples? Jun 19 15:05:43 Is it something that could have done with RPMsg instead? Jun 19 15:07:03 pratimugale: Do you have something in mind as to how you would start with the examples? What is your starting point there/ Jun 19 15:07:05 *? Jun 19 15:07:56 abhishek_: was thinking of starting with PWM Jun 19 15:08:04 and then building up on that Jun 19 15:08:38 How many channels? Jun 19 15:10:33 abhishek_: What does channel exactly mean over here? Jun 19 15:10:59 I haven't thought of it yet Jun 19 15:11:02 Number of simultaneous PWM signals you can generate. Jun 19 15:11:21 Each independent of the other Jun 19 15:12:19 Start with 1 channel and then build up multiple channels. Jun 19 15:12:42 okay Jun 19 15:13:17 pratimugale: When creating the example, think about how you want to define your application, the communication structure and create a well-commented, with proper Makefile usage both on PC-side app as well as PRU side firmware. Think about the "experience" or "journey" of someone who would start with your code. Document as much as you can, both code and communication scheme, spec. Jun 19 15:14:44 https://gist.github.com/pranav083/37b2ddc424edf99ebbcf7724ce8948d9 please have a look on the code Jun 19 15:16:36 pranav_kumar: Using r30 is correct. Jun 19 15:16:50 Sounds like you need to correct your device tree overlay Jun 19 15:17:10 abhishek_: Okay, also the analog wave generation can also be multiple channel right? Jun 19 15:17:49 pranav_kumar: Try P8_45 or P8_46 they are bit 0 and 1 if I remember correctly Jun 19 15:18:15 i also seen in all the place like this only but how to make the device tree overlay right .Please suggest me for that pin p8_11 Jun 19 15:18:48 ok just i will try and update it to you soon Jun 19 15:18:53 pranav_kumar: Looking at the device tree - I see that you have configured P8_11 as Mode 6. Jun 19 15:19:04 pranav_kumar: Go to TI Pinmux utility (google it) Jun 19 15:19:05 yes Jun 19 15:19:43 pranav_kumar: Look at the BeagleBone Black schematic - which pin of AM335x is P8_11 on header Jun 19 15:19:49 refernce from here http://exploringbeaglebone.com/wp-content/uploads/resources/BBBP8Header.png Jun 19 15:20:31 pranav_kumar: Hmm Jun 19 15:20:46 pranav_kumar: You're running this code on PRU0 right? Jun 19 15:21:01 yes Jun 19 15:23:12 pranav_kumar: Try http://pinmux.tking.org Jun 19 15:23:45 pranav_kumar: You shouldn't be configuring the pin as input. Jun 19 15:24:26 so instead as output ok then Jun 19 15:24:52 pranav_kumar: Yes, correct but mode 6 only Jun 19 15:25:41 pranav_kumar: These sources can be right or wrong (like images) but the authoritative source on what the pinmuxing should be is the TI Pinmux utility Jun 19 15:26:02 pranav_kumar: I highly recommend you learn how to use it. Jun 19 15:26:16 thanks Jun 19 15:26:52 Yes, it can be. Jun 19 15:32:06 abhishek_: thanks, I'll start with the example after I finish the memory functions Jun 19 15:33:20 Okay, remember the memory access function requires root Jun 19 15:33:57 abhishek_: So I'll have to modify the daemon right Jun 19 15:34:43 pratimugale: Yes, but remember this is a potential security hole, so you want to implement restrictions on what addresses you can read or write. Jun 19 15:37:06 abhishek_: okay Jun 19 15:39:21 Actually this whole daemon thing is a security hole in itself, so ultimately we want to restrict access to the socket itself to trusted users only but that's a whole big project in itself, in how do you implement security. Jun 19 15:41:13 [not important for this project but something to think about] remember that the PRU has unrestricted access to the entire address space of the AM335x SoC, so any adverse firmware on the PRUs loaded has the potential to harm stuff. Jun 19 15:42:36 abhishek_: I'll search and see what I can do about this too Jun 19 15:42:43 pratimugale: Another good example could be precise control of stepper motors, this is something that has already been implemented on the PRUs, you could port it to RPMsg. Jun 19 15:43:36 abhishek_: Yes, I'll implement it as a second example Jun 19 15:44:26 This is something extra that'll ultimately be useful but keep your attention on the main tasks at hand. Jun 19 15:45:04 yes Jun 19 15:45:04 You'll have to prioritize. Jun 19 15:45:17 Alright Jun 19 16:05:03 pranav_kumar[m]: Are you here? Jun 19 16:05:14 yes Jun 19 16:05:44 I have been horribly busy at work and have about 400 mails that I need to answer, including yours. Jun 19 16:05:54 gm all Jun 19 16:06:19 i getting bit worried about these device tree things Jun 19 16:06:19 gm all Jun 19 16:06:19 The quick answers for you are that you should be using mode 7 GPIOs, not the PRU-muxed pins. Jun 19 16:06:28 jkridner: Morning. Jun 19 16:06:37 gm jkridner hendersa Jun 19 16:06:38 vaishnav98_[m]: how's life going with SPI? feeling better physically? Jun 19 16:06:53 gm everyone Jun 19 16:07:12 then i have already made video and working code for that Jun 19 16:07:24 yesterday Jun 19 16:08:31 Is the video up on YouTube? Jun 19 16:08:40 yes Jun 19 16:08:56 jkridner: Hi I tried to debug the issue by adding printk statements to the CSD check part of mmc driver to print out all CSD structure , however after install , no messages are visible :( , am I doing something wrong? Jun 19 16:09:06 What is the URL? Is it listed on your wiki page? Jun 19 16:09:16 https://www.youtube.com/watch?v=yTIs10-VrbM Jun 19 16:09:31 vaishnav98_[m]: which code repo? Jun 19 16:10:04 jkridner: physically I'm alright:) , I could get the OLEDC click working on pocketbeagle slot 1, MicroSD Click still doesn't load Jun 19 16:10:17 yes Jun 19 16:10:52 OLEDC is a nice accomplishment! Jun 19 16:11:10 so, SPI must be working in some fashion. Jun 19 16:11:14 try other microSD cards? Jun 19 16:11:17 pranav_kumar[m]: Have your 74HC194 ICs arrived yet? Jun 19 16:11:45 * jkridner wishes some students had picked up BeagleBone AI projects. Jun 19 16:14:06 jkridner: I didn't upload the code, only change I made was to add some printk calls to print the entire CSD structure here https://github.com/beagleboard/linux/blob/36fe81261dbfc1f751f7c1844e6ec5a36b594953/drivers/mmc/core/mmc.c#L149 , compiled and installed the module still no logs visible, log levels are correctly set Jun 19 16:14:07 No it had been shipped not get deliver it will take some time of but its 74hc299 Jun 19 16:14:52 OK. So you did get the 8-bit version, rather than the 4-bit version. That is fine. Jun 19 16:14:55 jkridner: :) will generalise the implementation and upload a demo video soon Jun 19 16:15:04 the error still prints? Jun 19 16:15:38 i am currently working with the available ic for now Jun 19 16:18:14 pranav_kumar[m]: One thing that I recommend that you add into the wiki is a timing diagram. You can generate these easily online using WaveDrom: https://wavedrom.com/ Jun 19 16:18:19 yes i was currently working with 8 bit version ic 74hc595 as for now as ic 74hc299 was not get deliver till now Jun 19 16:20:21 jkridner: yes , SPI is working https://vaishnav98.github.io/GSoC19/oledc.html I have made a small blog post here , the transfers are happening through greybus, the gbsim verbose mode shows the transfers Jun 19 16:21:13 jkridner: yes I tried other cards too no success:( the same is card is working when a corresponding overlay is loaded Jun 19 16:21:28 jkridner: still the error prints Jun 19 16:22:11 ok i will learn that and generate it for the code Jun 19 16:29:16 hendersa: i want to ask that Is it possible to change pinmux settings from PRU itself or not? through the assembly code Jun 19 16:30:35 jkridner: I tried out commenting out the error line, recompile and installed, still error shows up : https://pastebin.com/R5eaz9Yy , this is the compile and install output Jun 19 16:31:09 is the original module a built-in? Jun 19 16:31:59 jkridner: yes it's a built-in/default module Jun 19 16:33:29 hello students and mentors! Jun 19 16:33:41 hi Jun 19 16:33:46 hello Jun 19 16:33:46 hello everyone Jun 19 16:33:49 Hi all Jun 19 16:36:58 hello all Jun 19 16:37:50 I see jkridner and ravikp7 are here - so vaishnav98_ can you go first today ? major accomplishment, current status - blockers?? Jun 19 16:38:19 vaishnav98_[m]: I think you might need to create some kind of new name for the module and disable the old one. Jun 19 16:38:27 cwicks : sure Jun 19 16:38:41 vaishnav98_[m]: https://stackoverflow.com/questions/51369669/replace-kernel-builtin-module-with-a-loadable-one Jun 19 16:42:41 jkridner ravikp7 cwicks : the last week I was able to work on fixing issues with gbsim SPI and tried adding support for OLED C click via greybus, with the microSD click while loading a manifest I get an unrecognised CSD structure error , I am working on debugging the issue with the help of jkridner and ds2 , I hope to fix the issue and generalise the gbsim SPI click Jun 19 16:42:42 support and provide documentation for the supported clicks this week, blockers: fixing issues with MicroSD Click, doesn't have much idea on how to add support for I2C based clicks like mpu9dof click which has interrupt and muxed I2C (i2cgate) requirements Jun 19 16:43:27 vaishnav98_[m]: can you start by simply adding GPIO to Greybus? Jun 19 16:43:47 jkridner: sure I will do that and update today itself Jun 19 16:43:52 vaishnav98_[m]: turn on an LED or something.... then add a button to generate an interrupt. Jun 19 16:44:23 vaishnav98_[m]: once you can do GPIOs and interrupts, I believe the manifest format can specify those.... I will look. Jun 19 16:47:05 jkridner: sure , I will do that, during installation part I did something like that , the user LEDs are linked to new gpios gpio506-9 when a gpio manifest is loaded and controlled, will provide the manifest and sufficient documentation for it Jun 19 16:47:38 jkridner: sure I'll do it Jun 19 16:47:56 * ravikp7[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/JydIeBeYkDrGVOfnaKJOfuSC > Jun 19 16:49:20 hmmm Jun 19 16:49:53 pratimugale: are you mentors on line? Jun 19 16:50:59 vaishnav98_[m]: can you provide some step-by-step guide with PocketBeagle? I'd like to try with TechLab. Jun 19 16:51:43 cwicks: I talked with Abhishek about the next steps before the meeting Jun 19 16:52:20 He said he'll to leave early today Jun 19 16:52:22 ravikp7 : does i2cdetect detect the device at the correct address?, (0x76) , is the device having the default address , I did test both the clicks on pocketbeagle and Beaglebone with mikrobus cape all slots and didn't experience any issues with those clicks Jun 19 16:53:15 jkridner: sure, shall I post it in the blog? Jun 19 16:55:14 vaishnav_: the dmesg log for i2c shows "new_device: Instantiated device bme280 at 0x76", that confirms, right? Jun 19 16:55:41 I'm testing on PB with the techlab cape Jun 19 16:59:59 vaishnav_: please update the insclick command in the weather click blog post as you seem to have updated the command now, will save time for others Jun 19 17:00:48 ravikp7: I'm not sure if that confirms it, the insclick cli uses stored values for the device address to instantiate the device , but depending on the position of the address header/jump on the click the address could be different from default, maybe we'll have to handle this case also in the cli , I think this is same with dt overlay based support also I have Jun 19 17:00:49 experienced the it with mpu9dof click, so can you perform an i2cdetect -y -r 1 and confirm Jun 19 17:03:12 and one more tip, use a code formatter or a linting tool if not already Jun 19 17:03:24 ravikp7 I just now tried with the same setup, I got both the clicks working, can you report an issue in the repo I'll work on finding out the issue Jun 19 17:03:50 ravikp7: sure I'll do that today itself Jun 19 17:04:15 cwicks: I'm not sure about others Jun 19 17:04:40 * jkridner is confused that https://github.com/MotorolaMobilityLLC/nuttx/blob/master/apps/greybus-utils/manifests/hdk-sensehat.mnfs seems to contain almost no driver information. Jun 19 17:06:54 mdp: I see https://github.com/vaishnav98/manifesto/blob/master/manifests/oledc_spi1.mnfs#L24 provides a string descriptor, but where do you specify other parameters like backlights? Jun 19 17:10:50 jkridner: I was planning to modify the structure of manifest to include more relevant parameters and remove some entries that aren't very important for click board support like : version major,minor, can also add more entries and modify gbsim manifest parser for the same , will that work? Jun 19 17:12:17 vaishnav98_[m]: working with base manifests as templates is fine. Jun 19 17:18:31 * embden[m] waiting... Jun 19 17:18:48 jkridner: will update to you once I make the changes Jun 19 17:19:16 hmmmmmm Jun 19 17:19:27 isn't next week eval week? Jun 19 17:19:41 ds2: Yes it is. Jun 19 17:24:36 Yes, it's not even getting detected :/ Jun 19 17:28:59 cwicks: can I go next - I need to go to the grocery store in a half of an hour Jun 19 17:30:23 yes please - sorry for the delay - embden please advise your blockers Jun 19 17:30:27 ravikp7: :( , is config-pin working, can you confirm the modes on pins P2_09 and P2_11 are i2c , when connected to the Techlab cape Mikrobus slot, the click should be loaded : sudo ./insclick weather p1 , I can't understand where the issue is occurring, the CLI uses config-pin to set the pin modes Jun 19 17:31:11 * embden[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/GiEDRvNNAIZFCRmjyaHUEDmN > Jun 19 17:33:12 embden[m]: Thank you for the update! Jun 19 17:36:01 thanks embden apologies for the delay - Jun 19 17:38:31 pranav_kumar: Have you had a chance yet? update and blockers? Jun 19 17:41:18 ravikp7 : I have updated it. Jun 19 17:42:48 Yes, the modes are i2c, and on subsequent insclick command, here's the dmesg log Jun 19 17:43:02 last week i was able to program pins using the assembly code and then made its working video for that with the shift register . Then discussed with mentor about the problem that i was facing regarding the mode of the pinmux . I had discussed my issue with @ds2 and abhishek_ regarding the issue . but i had reflect the changes on my code as suggested by abhishek_ and was unable to get any results on the pins . Jun 19 17:43:02 I will study the links suggested by them today .And again try it with the code . But hendersa said for the time being move forward with the mode7 of the pinmux and have to discuss further plans with the mentors . Blocker : I have to discuss further about the approach of the kernel module development and pinmux mode . As hendersa was busy last week so discuss my problem today with other other mentor and working Jun 19 17:43:03 on that for now after waiting for few days for the reply by @hendersa. Jun 19 17:44:03 today i had talked to him earlier quite before the meeting had started Jun 19 17:46:39 pratimugale: please clarify for me. What are your next steps? Jun 19 17:46:58 This week I generated c-bindings that use the python daemon service that was written last year. Right now I'm working on writing the memory functions to the daemon. After this I'll start working on the examples(starting with PWM) as discussed with mentor Abhishek. My working repository now is https://github.com/pratimugale/PRUSS-Bindings. I wrote a simple python userspace program today(Mainly to check the Jun 19 17:46:59 generated swig files.) Blockers: haven't entirely understood /dev/mem, working on that. Jun 19 17:48:22 cwicks: The next steps being working on the examples Jun 19 17:51:47 thank you pratimugale Jun 19 17:52:03 okay - then I think each student updated? Jun 19 17:55:02 embden: pratimugale pranav_kumar vaishnav98_ thank you for making your updates. Here is my admin update for this week: Your first eval is due from the mentors next week. The eval form will open on 6/24 for them to put inputs and then close on 6/28. We like to have ours in early so a goal of 6/26 for the completion. It's really very important that between now and 6/26 you have very clearly aligned with your mentors Jun 19 17:55:03 on how you are doing and work very hard to maintain the schedule agreed. if you need any help at all - please reach out to the mentors on the channel or email or the forum. it's critical if you can't get a response from a particular mentor that you reach out to alternates. Jun 19 17:57:22 embden: pratimugale pranav_kumar vaishnav98_ Please remember that GSoC is a volunteer program for the mentors. It is the students responsibility to be assertive with the project and drive the communication and problem solving. The mentors are eager and excited to help you. They all want you to do well. Jun 19 17:57:42 will try that out and update you tomorrow, also will test with BBB Jun 19 17:58:27 If anyone has any challenges communicating or getting assistance, please let your mentors and also jkridner and myself know. Jun 19 17:59:18 pratimugale: Hey ! Still in here ? Jun 19 17:59:21 ravikp7: Thanks :) Jun 19 17:59:31 embden: pratimugale pranav_kumar vaishnav98_ thank you again for being on time to the meeting and making your updates. It is exciting to see the projects progress! Jun 19 17:59:31 zeekhuge: yes Jun 19 17:59:42 thank you cwicks Jun 19 17:59:42 Thanks Jun 19 18:00:17 thanks cwicks Jun 19 18:00:19 cwicks : Thank you for the update, will follow the instructions Jun 19 18:00:41 I was going through the above chat, and the memory access thing confuses me. Why do we want complete access to the PRU memory ? Jun 19 18:03:22 zeekhuge: I was actually exploring how to read the pru memory Jun 19 18:03:26 from ARM Jun 19 18:04:07 zeekhuge: Should it not be in the api? Jun 19 18:04:49 zeekhuge: Also are there any other functions required?'''''''' Jun 19 18:05:10 *? Jun 19 18:06:05 We already have a project which uses DMA to access the PRU memory space and read from there. Jun 19 18:07:06 https://github.com/maciejjo/beaglebone-pru-dma/ Jun 19 18:08:41 btw, I also see this by the previous student : https://github.com/maciejjo/beaglebone-pru-dma/issues/2 Jun 19 18:08:42 zeekhuge: Okay so I won't continue with that Jun 19 18:09:49 zeekhuge: Yes, I saw that Mohammed Muneeb was also working on DMA project Jun 19 18:10:20 * /dev/mem Jun 19 18:11:04 So, the thing is, if the idea is to first develop the APIs using the /dev/mem file first and then shifting it to the EDMA, then I think thats okay. And will also give you some understanding of how the PRU memory space works. Jun 19 18:11:44 or just setup a simple char device Jun 19 18:13:06 Also, if someone is using RPMsg, then the user will mostly be using C/C++, in which case, accessing the memory space is not a good idea. If the firmware is itself is in assembly, only then direct/complete memory access should be done. Jun 19 18:14:16 mostly be using C/C++ = to develop PRU firmware Jun 19 18:15:12 Should I follow this path for now? Jun 19 18:15:18 Okay Jun 19 18:16:25 Or as ds2 said. setup a simple char-dev. Manipulating the memory space directly from a user-space program seems, just somewhat incorrect. Jun 19 18:16:59 btw, to setup the char-dev, you will have to create a simple kernel-driver. Jun 19 18:19:17 zeekhuge: I have learn't to create simple kernel drivers and char device files, but haven't been able to figure out how to use it here Jun 19 18:30:31 So, inside the module, you get the actual physical address from the virtual address and try to read/write to that. The exposed char device is just an interface to user-space. Jun 19 18:30:45 You can look up into the rproc source code Jun 19 18:31:21 https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/remoteproc_virtio.c#L364 Jun 19 18:31:42 https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/remoteproc_core.c#L152 Jun 19 18:31:43 something like that. Jun 19 18:33:28 Thanks Jun 19 18:33:54 Will look into these and get back to you Jun 19 18:35:49 pratimugale: Probably more easy to understand would be from here https://github.com/abhishek-kakkar/BeagleLogic/blob/master/kernel/beaglelogic.c#L1227 Jun 19 18:37:00 https://github.com/beagleboard/linux/blob/4.14/drivers/remoteproc/pruss.c#L167 Jun 19 18:37:05 pratimugale: ^ Jun 19 18:37:50 So, PRUSS exposes these APIs, inside the kernel space, using this EXPORT statement : https://github.com/beagleboard/linux/blob/4.14/drivers/remoteproc/pruss.c#L190 Jun 19 18:38:15