**** BEGIN LOGGING AT Wed Jun 26 02:59:57 2019
Jun 26 04:32:33 <pranav_kumar[m]> <ds2 "pranav_kumar: thanks for the doc"> Its not fully completed but i will complete the most of it while in the mean while
Jun 26 04:33:31 <pranav_kumar[m]> <ds2 "pranav_kumar: thanks for the doc"> https://github.com/pranav083/pocket_beagle-work all my code is in here
Jun 26 04:48:28 <zeekhuge[m]> pratimugale: Why not implement the stall method in assembly ? In case of Assembly, you can calculate the exactly delay that the operations with incur.
Jun 26 04:48:40 <zeekhuge[m]> stall method : https://github.com/pratimugale/PRUSS-Bindings/blob/master/examples/firmware_examples/example3-pwm/pwm_test.c#L9
Jun 26 04:50:57 <zeekhuge[m]> In fact, for your example (in which the PWM can be started only once, and will go on for ever) the entire infinite-while loop should be implemented in assembly. That will give it perfect precision.
Jun 26 04:51:05 <zeekhuge[m]> while loop : https://github.com/pratimugale/PRUSS-Bindings/blob/master/examples/firmware_examples/example3-pwm/pwm_test.c#L45
Jun 26 05:06:58 <pratimugale[m]> zeekhuge: I will try using assembly today for this example
Jun 26 05:10:26 <pratimugale[m]> <zeekhuge[m] "pratimugale: Why not implement t"> I did have difficulty calculating the delay
Jun 26 05:11:54 <ds2> delay on the PRU should be simple.. most instructions (except ones that leave the PRUSS) are 1 cycle
Jun 26 05:12:04 <ds2> it runs at a fixed 200MHz clock
Jun 26 05:18:29 <pratimugale[m]> ds2: even memory access?
Jun 26 05:19:57 <ds2> pratimugale[m]: what kind of memory?
Jun 26 05:20:13 <pratimugale[m]> the PRU memory
Jun 26 05:20:15 <ds2> PRUSS memory has a specific but defined timing
Jun 26 05:20:48 <ds2> it is like 1 + bytes/4 cycles or something similar
Jun 26 05:21:02 <ds2> ceil(1+ bytes/4)
Jun 26 05:21:20 <pratimugale[m]> <ds2 "ceil(1+ bytes/4)"> thanks
Jun 26 05:21:32 <ds2> check the TRM to be sure... I am going by memory
Jun 26 05:21:49 <ds2> it has been a few years since I last had to do really tight timing
Jun 26 05:22:17 <pratimugale[m]> ds2: Yes I will check it
Jun 26 05:22:31 <ds2> outside of PRUSS is a dice roll
Jun 26 05:22:58 <ds2> should add the caveat - that assumes no conflicts with the other PRU
Jun 26 05:23:32 <pratimugale[m]> <ds2 "should add the caveat - that ass"> this is for the PRU memory itself right?
Jun 26 05:24:52 <ds2> okay, let's be clear - PRUSS is the entire subsystem, this includes 2 PRUs and 3 banks of memory (PRU0 mem, PRU1 mem, and the shared mem)
Jun 26 05:25:12 <ds2> if PRU0 and PRU1 both it the same memory, say PRU0 mem; it could cause a delay
Jun 26 05:26:06 <ds2> does that clarify PRU vs PRUSS?
Jun 26 05:26:40 <pranav_kumar[m]> @ds2 should i go with this https://github.com/abhishek-kakkar/BeagleLogic/tree/master/kernel and made the .dts file which include all the pins of the beaglebone
Jun 26 05:26:45 <pratimugale[m]> <ds2 "does that clarify PRU vs PRUSS?"> Yes, thank you
Jun 26 05:27:49 <zeekhuge[m]> pratimugale: So basically, if you are trying to access anything over the L3 or L4 bus, then it cannot be predicted.
Jun 26 05:27:53 <ds2> pranav_kumar[m]: I'd not do ALL the pins. Just the pins you are using
Jun 26 05:28:01 <zeekhuge[m]> L4 and L3 in the firgure 2 : https://zeekhuge.me/post/working_with_prus_beagleboneblack_introduction_to_prus/
Jun 26 05:29:41 <pranav_kumar[m]> Ok, so the dts file that i had made will be fine for now
Jun 26 05:29:52 <ds2> I wonder if the PRU can be used for a side channel attack (a la spectre et al)
Jun 26 05:30:23 <ds2> I suspect the L3/L4 isn't completely unpredictable... the delays there could be revealing
Jun 26 05:39:57 <pranav_kumar[m]> @ds2 https://gist.github.com/pranav083/fe3916cd4a97e8b9a823d82c82458d82 i have tried this on different pins to access the pins in mode 5 and mode 6 but it not seems to access the r30 register
Jun 26 05:40:59 <pranav_kumar[m]> As @abhishek_:matrix.org  said that my program seems to be fine but there is a problem in my .dts file
Jun 26 05:52:12 <pratimugale[m]> <ds2 "I suspect the L3/L4 isn't comple"> Will study further about this
Jun 26 06:03:25 <zeekhuge[m]> pratimugale: Its not something immediately required.
Jun 26 06:03:34 <zeekhuge[m]> about the L4/L3 thing
Jun 26 06:03:53 <zeekhuge[m]> so, maybe for now, focus on more firmware and API examples.
Jun 26 06:03:58 <pratimugale[m]> Sure
Jun 26 06:05:29 <ds2> pranav_kumar[m]: let's put the mode 5/mode 6 stuff toward end as hendersa suggested.... GSoC is short and we need to keep focus
Jun 26 06:23:47 <pranav_kumar[m]> <ds2 "pranav_kumar: let's put the mode"> Ok can you guide me how can i read or write the data directly to gpio pins by using the program(other than .asm file). And what should probably be my next step further . I had checked  https://github.com/RobertCNelson/dtb-rebuilder as suggested.
Jun 26 06:25:26 <pranav_kumar[m]> Bascially how to wrap up asm code that can be use further
Jun 26 06:26:07 <pranav_kumar[m]> In code
Jun 26 06:37:55 <ds2> pranav_kumar[m]: .asm is my recommended lang for doing PRU work
Jun 26 06:44:07 <pranav_kumar[m]> <ds2 "pranav_kumar: .asm is my recomme"> Yes, but not able to understand to which aspect you referring it
Jun 26 07:34:21 <zeekhuge[m]> pranav_kumar: What is that you want to achieve using PRU-ASM ?
Jun 26 08:12:50 <pranav_kumar[m]> <zeekhuge[m] "pranav_kumar: What is that you w"> thanks for asking zeekhuge  as i have to provide a bus interface mechanism out to the user so that user can be able to do bidirectional communication any free gpio available to them . And can also able to extend no. of the input /output pins available to them.
Jun 26 08:14:48 <pranav_kumar[m]> So as suggested the best way around it was using the assembly code and then wrap it further
Jun 26 08:15:26 <zeekhuge[m]> pranav_kumar:  okay. So do you have the asm code ?
Jun 26 08:17:40 <pranav_kumar[m]> yes i have the asm code for using the pins as output or say using few pins and extend the no. of output using shift register
Jun 26 08:18:42 <zeekhuge[m]> Cool. I thought you were stuck somewhere.
Jun 26 08:22:00 <pranav_kumar[m]> i have not done the input part yet or say how to store the input from the shift register to the internal memory of the PRU or ARM and use it further in my program(kernel space or user space program ). That were i am stuck
Jun 26 08:23:21 <pranav_kumar[m]> I am not able to understand what should i do with the assembly code in the long run and how to use assembly code further
Jun 26 08:23:35 <pranav_kumar[m]> in the main program
Jun 26 08:30:03 <zeekhuge[m]> pranav_kumar: That has been a problem for a long time. There are following ways out of it :
Jun 26 08:30:49 <zeekhuge[m]> The traditional way has been, use one of the the PRUs for IO, save data into some memory inside the PRUSS and use the  other PRU to transfer that data from PRUSS to the ARM
Jun 26 08:31:37 <zeekhuge[m]> Now, note that the data has to be transfered from PRUSS to ARM by a PRU itself. Using the CPU for that will be an extreme over-kill and waste.
Jun 26 08:32:30 <zeekhuge[m]> We had a project, in which we added support to use DMA for the data trasnfer from PRUSS to ARM, but as far as I know, the project is not in a working state on the latest kernel version.
Jun 26 08:32:57 <zeekhuge[m]> Using DMA would have allowed to use the other PRU for some other operations.
Jun 26 08:33:46 <pranav_kumar[m]> can you refer me any resource from where i can see it how to make use of it.
Jun 26 08:34:22 <zeekhuge[m]> So right now, the best/ideal working approach would be to use one PRU for IO and other to transer data.
Jun 26 08:34:50 <pranav_kumar[m]> <zeekhuge[m] "We had a project, in which we ad"> yes i had also came over a lot of resources that got either outdated or not working in the latest kernel
Jun 26 08:34:53 <zeekhuge[m]> Note : You can use read PRUSS memory space directly from /dev/mem, but is not really recommended.
Jun 26 08:35:38 <zeekhuge[m]> pratimugale: Have used /dev/mem for now. So if you decide to go that way, he might be able to help.
Jun 26 08:36:21 <zeekhuge[m]> Now, if you decide to use one PRU for IO and the other to transer data, then their is a mechanism : called RPMsg, which can be used for this.
Jun 26 08:37:00 <embden[m]> apritzel:  https://pastebin.com/xdxkw6TP Also, I have a question why  in https://github.com/torvalds/linux/blob/master/arch/arm/mach-omap2/timer.c#L697 first the value is read and then ORed with a new value? Is it possible that there a garbage in those read values so by adding new bits we make the situation even worse?
Jun 26 08:37:10 <zeekhuge[m]> basically beaglelogic and beaglescope both use this approach : Use one PRU for IO and the other to transfer data. Although both of them use different mechanism (sofware) to achieve that.
Jun 26 08:37:16 <pranav_kumar[m]> <zeekhuge[m] "Note : You can use read PRUSS me"> i need a solution that have regular access pru and that is also not process consumming to the system as i have to provide an alternate solution for extending the functionality of the gpio
Jun 26 08:39:29 <apritzel> embden[m]: ORing: it's masking bits off in the readl line, then ORing the new ones in
Jun 26 08:39:38 <apritzel> so it's about preserving other bits in this register
Jun 26 08:41:42 <embden[m]> apritzel: hm, ok. I thought it would be more proper to AND with ~MASK to nullify the required bits in the read value and then OR with a new one
Jun 26 08:42:17 <apritzel> yeah, that's against normal practise, the mask is defines somewhat the other way around
Jun 26 08:42:46 <apritzel> it's 0xfffff000, where the name suggests it should be 0x00000fff
Jun 26 08:43:03 <pranav_kumar[m]> <zeekhuge[m] "basically beaglelogic and beagle"> ok i will contact pratimugale  for that thanks for suggestion
Jun 26 08:44:56 <embden[m]> apritzel:  I mean what will happen if the reg already has some value that was read from the register?
Jun 26 08:45:53 <embden[m]> and then we OR it with a desired value, wouln't we have some mess in the result?
Jun 26 08:46:14 <apritzel> embden[m]: from just looking at the code I assume that the values live in the lower 12 bits
Jun 26 08:48:23 <zeekhuge[m]> pranav_kumar: If you directly access through /dev/mem, that will actually consume CPU I think. The best approach would be to implement a ring-buffer kind of thing using PRU memory space, where one of the PRUs will write, and then use another PRU to write that data to the ARM space.
Jun 26 08:49:02 <zeekhuge[m]> We have enough documentation to get you started if you decide to go with this approach. Maybe discuss it with mentors.
Jun 26 08:49:03 <embden[m]> apritzel:  basically, I don't understand why it is "|=" instead of "=". It seems that we shouldn't care about previous values of numerator or denumerator registers, so why to keep existing bits.
Jun 26 08:49:13 <julieng> embden[m]: Did you firgure out the clock frequency to use?
Jun 26 08:49:13 <apritzel> embden[m]: btw, have you checked what Linux prints as the arch timer frequency?
Jun 26 08:49:53 <apritzel> embden[m]: I guess the upper bits in those registers contain other information, and we must not change them
Jun 26 08:50:47 <pranav_kumar[m]> <zeekhuge[m] "pranav_kumar: If you directly ac"> yes you are right that why they said to use  the minimalist approach of accessing the pru as it will consume  less resources from the cpu
Jun 26 08:53:07 <embden[m]> julieng:  almost, the last question was how to inform xen about the clock-frequency. But I am going to solve it today.
Jun 26 08:53:34 <embden[m]> apritzel: arch_timer_frequency was 6.144 I believe
Jun 26 08:53:50 <apritzel> embden[m]: yes, that's the one
Jun 26 08:54:02 <apritzel> just realised that the Linux code always results in that frequency
Jun 26 08:54:32 <apritzel> if you multiply the rates in the switch/case statement with their num/denum pairs, you will always get 6.144 MHz
Jun 26 08:54:59 <apritzel> so the purpose of the code is to program the clock, not to calculate the arch timer frequency
Jun 26 08:55:27 <apritzel> that is fixed at 6144000 Hz, and that is the value you should write into the DT
Jun 26 08:55:35 <embden[m]> apritzel: oh, now I understand how it works
Jun 26 08:56:27 <julieng> embden[m]: Xen is able to deal with "clock-frequency" property. So writing in the DT should be sufficient. Alternatively we can replicate Linux code in Xen.
Jun 26 08:56:58 <julieng> apritzel: Such a great way to waste time computing a fixed value ;)
Jun 26 08:57:42 <embden[m]> julieng:  apritzel  my confusion was that: "it's 0xfffff000, where the name suggests it should be 0x00000fff" -_-
Jun 26 08:58:00 <apritzel> julieng: this sysclk_in is system wide, I believe, so this num/denum programming has only to be done once, not per core
Jun 26 08:58:54 <embden[m]> I wasn't able to understand why they take only lower bits and then OR them with a new bits
Jun 26 09:00:44 <embden[m]> Ok, so, I putted the value into the DT and get to the mistake: https://pastebin.com/MskyW7ym
Jun 26 09:01:29 <embden[m]> I will try to deal with it a bit later today
Jun 26 09:04:08 <julieng> embden[m]: This is because the guest is trying to access a region that has not been mapped in stage-2.
Jun 26 09:04:26 <julieng> embden[m]: I would recommend to enable earlyprintk in your kernel so you can see where exactly it crashes.
Jun 26 09:05:13 <embden[m]> ok
Jun 26 09:05:27 <julieng> embden[m]: Also, your dom0 command line looks suspicious. "initrd=0x84000000,32M" -> it is up to Xen to decide where the initrd will be loaded. So this address may be wrong.
Jun 26 09:06:04 <julieng> I think you should remove this parameter and let the kernel loading the initrd from the address specified in the DT.
Jun 26 09:06:15 <embden[m]> ok, yes, that's true
Jun 26 09:09:01 <julieng> embden[m]: For early printk, look at the option DEBUG_LL and EARLYPRINTK in linux.
Jun 26 09:09:51 <embden[m]> ok
Jun 26 10:16:32 <pratimugale[m]> zeekhuge: Is controlling multiple pwm pins actually possible using the pru?
Jun 26 10:18:58 <zeekhuge[m]> pratimugale: it is. But you cannot generate arbritrarily any duty-cycle, but it has to be based on calculations, and tge fact that executing each instruction (GPIO) takes 5ns.
Jun 26 10:19:43 <pratimugale[m]> I am accurately able to control one pin
Jun 26 10:19:46 <zeekhuge[m]> And i would suspect the code has to be very clever to be able to do that.
Jun 26 10:31:11 <pratimugale[m]> For two channels or more the accuracy is lost, but relative to each other the brightness(voltage) of the LEDs is correct.
Jun 26 10:40:57 <zeekhuge[m]> What is the frequency you are using?
Jun 26 10:43:01 <zeekhuge[m]> pratimugale: ^
Jun 26 10:43:51 <pratimugale[m]> zeekhuge: I am controlling it using oncycles and offcycles
Jun 26 10:45:36 <pratimugale[m]> and then delaying for that amount of time
Jun 26 10:46:50 <zeekhuge[m]> Wheres the code?
Jun 26 10:46:56 <zeekhuge[m]> Okay. I see it now.
Jun 26 10:47:04 <zeekhuge[m]> You are using voltage as the parameter
Jun 26 10:47:36 <pratimugale[m]> yes
Jun 26 10:48:57 <zeekhuge[m]> Typically, for the pwm, you set the frequency and then the dutycycle.
Jun 26 10:49:13 <pratimugale[m]> <zeekhuge[m] "Wheres the code?"> I'll upload the rest of the code today(in which input is take from the ARM)
Jun 26 10:49:58 <zeekhuge[m]> I just skimmed over you code, and it looks like your frequency will change based on the voltage. ie, the offcycle is constant but oncycles will change, and the total determines the frequency
Jun 26 10:50:51 <pratimugale[m]> yes I hadn't set the frequency for now, but will also take that as an input
Jun 26 10:51:02 <zeekhuge[m]> Nevertheless, as long as you are using C code, and that too a for loop (which will try to store the value of i and then read and increment it each time) predicting things can be tricky
Jun 26 10:52:14 <pratimugale[m]> I'll try using assembly now using your reference
Jun 26 16:02:18 <Abhishek_1> Meeting in 30mins
Jun 26 16:06:37 <pranav_kumar[m]> <pranav_kumar[m] "i have not done the input part y"> Hello abhishek_  plz suggest resources me regarding this. It was a little chat that i have with zeekhuge  early today
Jun 26 16:12:00 <Abhishek_1> pranav_kumar : designate a PRU pin as input and other as clock
Jun 26 16:12:59 <pranav_kumar[m]> <Abhishek_1 "pranav_kumar : designate a PRU p"> other as clock means
Jun 26 16:13:46 <pranav_kumar[m]> like as clk that is required in the shift register to function or something else
Jun 26 16:13:46 <cwicks[m]> ChanServ: Good morning mentors and students - meeting in 15 mins.  All student and mentor reviews have been turned in on time - thank you!
Jun 26 16:13:51 <Abhishek_1> For a shift register you need clk and data pins
Jun 26 16:14:15 <pranav_kumar[m]> <cwicks[m] "ChanServ: Good morning mentors a"> hello cwicks
Jun 26 16:14:15 <Abhishek_1> clk = clock
Jun 26 16:16:13 <pranav_kumar[m]> <Abhishek_1 "For a shift register you need cl"> ok . and how to access those data that is stored in the register(data from input pins) to my program(other than aseesmbly program
Jun 26 16:16:17 <pranav_kumar[m]> <Abhishek_1 "clk = clock"> yes
Jun 26 16:18:48 <Abhishek_1> <pranav_kumar[m] "ok . and how to access those dat"> First get it into assembly code and then into PRU RAM
Jun 26 16:19:45 <Abhishek_1> Then we'll see
Jun 26 16:22:15 <pranav_kumar[m]> <Abhishek_1 "First get it into assembly code "> ok
Jun 26 16:25:17 <ds2> or just toss it in a register
Jun 26 16:30:23 <pranav_kumar[m]> <ds2 "or just toss it in a register"> ok as my shipment(shift register) will arrive on around 29 june -1 july. I will test the code using simple input toggle switch on pins for now
Jun 26 16:30:37 <zeekhuge[m]> pranav_kumar: i have a few examples in my repo that might help you understand assembly and pru code. Feel free to ask if you need help with them.
Jun 26 16:31:10 <cwicks[m]> Hello ChanServ Welcome to our 6/26 Wednesday GSoC check-in meeting!
Jun 26 16:31:14 <vaishnav98_[m]> Hi all
Jun 26 16:31:26 <cwicks[m]> Student roll call please
Jun 26 16:31:33 <embden[m]> hi
Jun 26 16:31:39 <pranav_kumar[m]> hello all
Jun 26 16:31:48 <pratimugale[m]> hi
Jun 26 16:33:14 <jkridner[m]> gm all
Jun 26 16:33:25 <jkridner[m]> I have limited access today.
Jun 26 16:33:44 <cwicks[m]> Okay jkridner we'll do your team first
Jun 26 16:33:45 <jkridner[m]> big thing is first evaluation!
Jun 26 16:34:10 <cwicks[m]> All accomplished!!
Jun 26 16:34:38 <cwicks[m]> ChanServ: Mentors can you please roll call?
Jun 26 16:35:04 <cwicks[m]> vaishnav98_: Please prepare to go first w/ your update and detail your blockers.
Jun 26 16:35:14 <ds2> Here
Jun 26 16:35:17 <zeekhuge[m]> cwicks: +1
Jun 26 16:36:04 <vaishnav98_[m]> <cwicks[m] "vaishnav98_: Please prepare to g"> cwicks: Sure
Jun 26 16:37:08 <julieng> cwicks[m]: Here
Jun 26 16:37:32 * vaishnav98_[m] sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/rEXDjyOzqlnsTsBtZZzWQhoD >
Jun 26 16:44:37 <cwicks[m]> vaishnav98_: thank you for posting an update video!  *cwicks loves videos*
Jun 26 16:44:47 <cwicks[m]> Are your mentors helping with the issue?
Jun 26 16:46:11 <vaishnav98_[m]> <cwicks[m] "vaishnav98_: thank you for posti"> :)
Jun 26 16:48:26 <vaishnav98_[m]> <cwicks[m] "Are your mentors helping with th"> cwicks : yes , jkridner suggested disabling the built-in driver and changing its name and then installing it as a loadable module, I couldn't figure out , how exactly to disable the built-in mmc driver
Jun 26 16:48:58 <cwicks[m]> vaishnav98_: stay on - jkridner may jump back in during the meeting
Jun 26 16:49:16 <cwicks[m]> embden: Would you like to go next - ?
Jun 26 16:49:32 <embden[m]> yes
Jun 26 16:49:44 <jkridner[m]> set ‘status = “disabled”;’ in the device tree.
Jun 26 16:49:53 <embden[m]> During the last week, I was able to switch bb-x15 secondary core to non-secure HYP mode and figure out what is happening with clocks.
Jun 26 16:50:00 <embden[m]> The main blocker for now is that Linux hangs when trying to boot and I need to find out why.
Jun 26 16:50:09 <jkridner[m]> then, create a new driver name for your new driver.
Jun 26 16:50:16 <embden[m]> I am also going to investigate how to use the hardware debugger.
Jun 26 16:50:54 <embden[m]> mentors helped me a lot
Jun 26 16:51:14 <vaishnav98_[m]> <jkridner[m] "then, create a new driver name f"> jkridner: I did this
Jun 26 16:52:04 <vaishnav98_[m]> <jkridner[m] "set ‘status = “disabled”;’ in th"> jkridner but couldn't figure out how to do this, will try it
Jun 26 16:55:19 <cwicks[m]> embden: that's good you are getting the support you need.
Jun 26 16:55:50 <cwicks[m]> we have julieng online right now and other mentors if you want to chat about the Linux hanging.
Jun 26 16:56:30 <embden[m]> thanks, thought I got the feeling that julieng  is always reachable.
Jun 26 16:56:39 <cwicks[m]> Also ds2  online
Jun 26 16:56:49 <julieng> cwicks[m]: I have suggested a few possibility to debug it today. Happy to discuss with embden[m] if there are any misunderstanding :).
Jun 26 16:57:04 <cwicks[m]> *gsoc mentors never sleep :) *
Jun 26 16:57:25 <ds2> embden[m]: nothing to add beyond the early_printk thing
Jun 26 16:57:41 * embden[m] is compiling Linux
Jun 26 16:59:09 <cwicks[m]> pratimugale: would you like to go next ?  quick update in the last week and blockers?
Jun 26 16:59:28 <pratimugale[m]> cwicks: yes
Jun 26 17:00:48 <pratimugale[m]> This week I was able to write to the PRU SRAM, DRAM memory to give input to the PRU and create a simple PWM example using this. I am currently working on making the PWM example multi-channel (and taking frequency also as input).
Jun 26 17:00:48 <pratimugale[m]> Blocker: The output for the multi-channel PWM is not accurate and I still am figuring out how to do it. After this I will provide an interface using RPMsg for the user to read/write data to the PRU SRAM, DRAM.
Jun 26 17:02:06 <pratimugale[m]> <cwicks[m] "*gsoc mentors never sleep :) *"> Mentors are very helpful :)
Jun 26 17:03:08 <zeekhuge[m]> pratimugale: The only reason why PWM is working for single channle, that I can think of, is because you have based it on on/off-cycles, and that the frequency is not constant.
Jun 26 17:03:32 <zeekhuge[m]> Typically, the frequency and the duty-cycle should define a PWM
Jun 26 17:03:50 <zeekhuge[m]> and to achieve that, their is no other way but to use assembly
Jun 26 17:05:21 <zeekhuge[m]> And if the example allows the freqency and DC to be set only once, before the PWM actually starts, then the assembly code should not be very complex.
Jun 26 17:05:23 <ds2> RPMsg? calling the RPMsg services will likely add jitter. make sure to run rpmsg on 1 PRU core and PWM on the other (if you have the resources....)
Jun 26 17:05:44 <pratimugale[m]> zeekhuge: I will use assembly to do it now, taking both frequency and duty cycle as input
Jun 26 17:06:40 <zeekhuge[m]> ds2: As for the current example, the idea is to initially just take the parameters for the PWM as input and then start the PWM and un-subscribe from PWM
Jun 26 17:06:48 <zeekhuge[m]> *from RPMsg
Jun 26 17:07:23 <ds2> zeekhuge[m]: unsubscribe or just not call the rpmsg stuff?
Jun 26 17:09:30 <pratimugale[m]> <ds2 "RPMsg? calling the RPMsg service"> Yes, I have am referencing the beaglescope project
Jun 26 17:09:53 <pratimugale[m]> 1 PRU for rpmsg
Jun 26 17:10:47 <vaishnav98_[m]> jkridner ravikp7 : also Greybus doesn't provide any provision to pass additional information regarding the device to the driver : https://github.com/beagleboard/linux/blob/36fe81261dbfc1f751f7c1844e6ec5a36b594953/drivers/staging/greybus/spilib.c#L438 , how to pass these parameters once fetched from the manifest
Jun 26 17:11:20 <zeekhuge[m]> ds2: yeah. I mean, its just one time rpmsg message before actual pwm. So no jitter while pwm-ing.
Jun 26 17:12:17 <pratimugale[m]> <zeekhuge[m] "ds2: yeah. I mean, its just one "> We can change the parameters when its running
Jun 26 17:13:16 <zeekhuge[m]> pratimugale: let the first example be simple, and involve one time setup
Jun 26 17:13:16 <jkridner[m]> mdp: do you have an idea how greybus was meant to be used with arbitrary SPI and I2C devices that include other resources, like interrupts?
Jun 26 17:13:32 <pratimugale[m]> <zeekhuge[m] "pratimugale: let the first examp"> okay
Jun 26 17:14:14 <zeekhuge[m]> pratimugale : Once you have the understanding of the PRU cycles and assembly, we will look into dynamic changes using RPMsg
Jun 26 17:16:41 <embden[m]> julieng:  what platform to use with DEBUG_LL? Will kernel be able to communicate via a onboard uart device? I would suggest that hvc0 should be used as the uart. But I can't see it in the list
Jun 26 17:17:34 <pratimugale[m]> <zeekhuge[m] "pratimugale : Once you have the "> understood; just to be clear, the RPMsg will take input from ARM, write it into SRAM/DRAM and then the other PRU will start; right?
Jun 26 17:18:48 <julieng> embden[m]: I am not entirely sure which one. Maybe ds2 know?
Jun 26 17:19:47 <zeekhuge[m]> RPMsg is an entire framework. When there is a message, pru is interrupted (its kind a tricky) and given the DRAM location to read from, and the message size. It then read it from there.
Jun 26 17:19:50 <julieng> embden[m]: Xen is partially emulating the UART so platform specific earlyprintk can work. However, you will not be able to use it for read character from the onboard UART.
Jun 26 17:19:54 <zeekhuge[m]> pratimugale: ^
Jun 26 17:22:54 <pratimugale[m]> <zeekhuge[m] "RPMsg is an entire framework. Wh"> The message is already written in the DRAM?
Jun 26 17:23:28 <pratimugale[m]> <pratimugale[m] "The message is already written i"> When the PRU reads it
Jun 26 17:23:49 <ds2> embden[m]: normally it is just hte regular console
Jun 26 17:25:20 <zeekhuge[m]> DRAM is basically the system RAM. Right? And everything there is, is on the system RAM. Having said that, the RPMSG maintains a buffer, and the data is written to that buffer. Now this buffer (like every memory space their is) is on the DRAM
Jun 26 17:26:38 <zeekhuge[m]> Makes some sense?
Jun 26 17:26:50 <pratimugale[m]> Yes, it does
Jun 26 17:28:16 <pratimugale[m]> zeekhuge: Thanks
Jun 26 17:28:17 <cwicks[m]> pranav_kumar: did you get a chance to update and give blocker status yet?
Jun 26 17:28:51 <pranav_kumar[m]> no cwicks
Jun 26 17:29:04 <pranav_kumar[m]> <cwicks[m] "pranav_kumar: did you get a chan"> i was further running the resources provided by @hendersa over the last week make up some documentation as asked and guided by @ds2 so that to have better understanding of the pin mapping that is being used in the shift register and beaglebone.The main blocker that i have was to how to use the data provided to or by the pins to the program that i was discussing
Jun 26 17:29:05 <pranav_kumar[m]> earlier today with @ds2 and @zekhuge and its seems that their need of a efficient technique that has to be in place. as @zeekhuge told the rpmsg technique will might be slower and have to use one pru with other for good response.
Jun 26 17:30:07 <pranav_kumar[m]> as @hendersa said that he will be quite busy over these time so i am seeking most my help from ds2  and abhishek_
Jun 26 17:35:02 <cwicks[m]> pranav_kumar: are you able to communicate more often on what various things you are trying on each blocker?
Jun 26 17:35:18 <ds2> pranav_kumar[m]: use the data?
Jun 26 17:36:02 <pranav_kumar[m]> <ds2 "pranav_kumar: use the data?"> provided in the datasheet
Jun 26 17:37:33 <pranav_kumar[m]> <cwicks[m] "pranav_kumar: are you able to co"> yes mostly over the irc and  figuring out what should i do next after doing the assembly part thing
Jun 26 17:37:55 <ds2> what datasheet? the 74xx datasheet or the am335x datasheet?
Jun 26 17:39:13 <pranav_kumar[m]> <ds2 "pranav_kumar: use the data?"> am335xx datasheet
Jun 26 17:43:27 <pratimugale[m]> zeekhuge: I'll start with the rpmsg thing and update you tomorrow
Jun 26 17:44:19 <pratimugale[m]> Also writing the assembly code
Jun 26 17:45:09 <pranav_kumar[m]> i will update about the input assembly code .But which register will be good to store these information
Jun 26 17:46:56 <cwicks[m]> pranav_kumar: pratimugale embden vaishnav98_   and Mentors:  Here is my admin update for the week:  Thank you to everyone for getting the evaluations in on time to GSoC.
Jun 26 17:47:29 <cwicks[m]> I want to make sure we continue to have good communication especially from the students on the progress of the projects.
Jun 26 17:49:42 <ds2> pranav_kumar[m]: that's up to  you... there are plenty of general purpose ones on the PRU
Jun 26 17:49:55 <cwicks[m]> pranav_kumar: pratimugale embden_ vaishnav98_   Please take the time to update the mentors on the progress you are making on the project, especially blockers on a daily or twice a day basis.  Be trying things on your own when you don't have a mentor online on the IRC to work through and report it on the progress via email/IRC.  While we only require a written report on a weekly basis, more often updates is needed at
Jun 26 17:49:55 <cwicks[m]> this point especially if you are behind in your milestones.
Jun 26 17:51:30 <zeekhuge[m]> <pranav_kumar[m] "i will update about the input as"> pranav_kumar: did you try to go through the pru basics? The memory segments available and associated latency. If not, try do that, thoroughly, and make then decide what would be best for the usecase
Jun 26 17:52:51 <cwicks[m]> If anything is not clear from mentors, please ask and make sure you are clearly communicating next steps and what you have tried, etc when debugging.
Jun 26 17:53:41 <pranav_kumar[m]> <zeekhuge[m] "pranav_kumar: did you try to go "> i have gone through the material given in the datasheet of am335xx .Their i have section dedicated to pru and its programming (topic 4.5)
Jun 26 17:54:13 <cwicks[m]> I'd like to encourage all the students to keep their energy level and problem solving high at this point in the project - You can do it!  Let us know what support you need/questions you have.
Jun 26 17:55:14 <cwicks[m]> Next GSOC deadline for us to give review is July 22.  Thank you also to the mentors for being available and guiding students to help them succeed.
Jun 26 17:59:22 <cwicks[m]> I have to officially sign off the weekly meeting - however, please students stay online while you have mentors now so that you can get great interactions on your blockers while you have the mentors online.
Jun 26 18:00:36 <pranav_kumar[m]> i have a question as we are in the college making the  the opensource version provided by nasa jpl  (to be use in the agriculture related research)  : https://opensourcerover.jpl.nasa.gov/#!/explore   https://github.com/nasa-jpl/open-source-rover using beaglebone blue any resources that you might point to will be better for them(team)  to start with. as, I am trying to encourge people in community to use
Jun 26 18:00:36 <pranav_kumar[m]> Beaglebone blue over rpi as it have many advantages.
Jun 26 18:03:00 <ds2> just remember - if you use the blue, burning out drivers will require a new blue
Jun 26 18:04:48 <pranav_kumar[m]> <ds2 "just remember - if you use the b"> yes we have two that we won from mouser electronics contest but very less idea about its limitation on driving different components
Jun 26 18:08:29 <zeekhuge[m]> <pranav_kumar[m] "i have gone through the material"> So do you have the understanding of what the physical layout of the pru memory and the associated latency is?
Jun 26 18:09:54 <zeekhuge[m]> pranav_kumar: whats your work timing?
Jun 26 18:11:41 <pranav_kumar[m]> <zeekhuge[m] "So do you have the understanding"> i have little understanding of how the register are distributed over the pru and what these register mainly work for
Jun 26 18:12:24 <zeekhuge[m]> <pranav_kumar[m] "i have little understanding of h"> Yes. Work on that.
Jun 26 18:12:32 <pranav_kumar[m]> <zeekhuge[m] "pranav_kumar: whats your work ti"> i mainly work from evening time here from 5pm to 2am ist
Jun 26 18:14:11 <pranav_kumar[m]> <zeekhuge[m] "Yes. Work on that."> yes will update soon
Jun 26 18:14:55 <zeekhuge[m]> Cool
Jun 26 18:15:08 <pranav_kumar[m]> <ds2 "just remember - if you use the b"> thanks for the advice ds2  we will use it more carefully
Jun 26 18:15:10 <zeekhuge[m]> I will be up till late today.
Jun 26 18:15:43 <zeekhuge[m]> So, try to find out resources which actually describe the pru memory things and their usage etc
Jun 26 18:16:10 <zeekhuge[m]> And ask me if you find something confusing.
Jun 26 18:19:35 <pranav_kumar[m]> <zeekhuge[m] "So, try to find out resources wh"> yes i had already go through that from table to table (or register table) and  write down the topic that seems to be important to me especially which are related to the pru from the datasheet few days ago . I will go through it again to revise the things .
Jun 26 18:19:47 <pranav_kumar[m]> <zeekhuge[m] "And ask me if you find something"> ok
Jun 26 19:00:55 <embden[m]> ds2:  could you remind me what config file to use in Linux for bb-x15?
Jun 26 19:18:03 <embden[m]> I found it
**** BEGIN LOGGING AT Wed Jun 26 20:04:53 2019
Jun 26 20:09:53 <pranav_kumar[m]> zeekhuge: i am following the SPRUH73C datasheeet page no.237 their is topic of memory mapping which seems to same for both local and global memory map and can be accessed via PMAO register
Jun 26 20:11:43 <pranav_kumar[m]> i think i should store the value in local memory register once and then transfer it to the global memory or i should go with the shared memory for this
Jun 26 20:13:43 <zeekhuge[m]> Each transaction incurs some latency.
Jun 26 20:13:57 <zeekhuge[m]> Calculate the latency you can afford
Jun 26 20:14:25 <zeekhuge[m]> it should require simple math to do that.
Jun 26 20:14:46 <zeekhuge[m]> Also, do you know, or can you pin point the exact problem/doubts/questions you have ?
Jun 26 20:15:16 <zeekhuge[m]> I mean, in order to get the project in pace ?
Jun 26 20:17:18 <pranav_kumar[m]> <zeekhuge[m] "Calculate the latency you can af"> are you talking about instruction cycle
Jun 26 20:20:21 <pranav_kumar[m]> <zeekhuge[m] "Also, do you know, or can you pi"> i was basically asking as to make a assembly code that can take input and i can able to show the output of it on the terminal. that why i am asking about how to use the global memory map for this.
Jun 26 20:21:23 <pranav_kumar[m]> or i should store the input and reflect it through the led connected to shift register
Jun 26 20:22:09 <embden[m]> julieng:  now, I can investigate: https://pastebin.com/BBAFPkVU
Jun 26 20:26:00 <julieng> embden[m]: Looks like not all devices are described in the Device-Tree. It would be interested to find out where exactly the address is coming from.
Jun 26 20:31:24 <embden[m]> julieng:  from where can you see it?
Jun 26 20:38:36 <embden[m]> also, it is interesting why most of the lines are putted twice.
Jun 26 20:40:55 <julieng> embden[m]: I think this is because you have DEBUG_LL enabled and also earlyprintk. I would not worry too much though.
Jun 26 20:41:56 <julieng> embden[m]: Regarding your question, I can see two way to answer:
Jun 26 20:42:10 <julieng>   1) Go through the call stack and see if you find an ioremap related to it
Jun 26 20:42:25 <julieng> 2) Get the variable accessed and grep for it in the code.
Jun 26 20:42:44 <julieng> Mostly likely, you will find an ioremap that has an hardcoded value rather than looked up from the Device-Tree.
Jun 26 20:43:26 <embden[m]> I mean "Looks like not all devices are described in the Device-Tree. " how did you get to that conclusion?
Jun 26 20:43:27 <julieng> Note that, as MMIO are direct map, "traps.c:1998:d0v0 HSR=0x93800007 pc=0xc012bd5c gva=0xfa243404 gpa=0x00000048243404" gives you a hint that Linux is trying to access the physical address gpa.
Jun 26 20:44:11 <julieng> embden[m]: Oh, because Xen will go through the Device-Tree and map all the MMIO regions to Dom0. So it is most likely that the device was not described in the Device-Tree.
Jun 26 20:44:31 <julieng> I know that some arm32 boards still don't have everything in the DT.
Jun 26 20:44:49 <julieng> It could also be an error in Xen when parsing the DT, but I doubt it.
Jun 26 20:45:14 <embden[m]> it is possible since I have am5729 processor and the dt is for am5728
Jun 26 20:45:24 <embden[m]> they are essentially equal though
Jun 26 20:45:36 <embden[m]> am572x
Jun 26 20:46:32 <embden[m]> maybe I also should use dt which is provided with the pre-installed linux
Jun 26 20:49:22 <julieng> embden[m]: I would recommend to use the correct DT for your platform. pre-installed one would be a first step.
Jun 26 20:57:48 <embden[m]> julieng: hm, it uses the same device tree
Jun 26 21:26:17 <embden[m]> julieng:  so, the error occurred when linux tried to read PM_CPU0_PWRSTST register, to obtain a status on CPU domain current power state
Jun 26 21:28:54 <julieng[m]> Where is the ioremap done?
Jun 26 21:29:18 <julieng[m]> embden ^
Jun 26 21:32:58 <embden[m]> julieng: should it happen in one of the functions of call stack?
Jun 26 21:33:33 <julieng[m]> embden possibly. Or you can try to find out where the variable used is set.
Jun 26 21:37:08 <embden[m]> julieng:  what variable?
Jun 26 21:39:35 <julieng> embden[m]: You said that Linux was trying to read PM_CPU0_PWRSTST register. I guess this is an offset from a variable.
Jun 26 21:40:37 <julieng> The variable likely points to the beginning of the MMIO region mapped. If you track the variable, then you should be able to find out where the region was mapped (via ioremap, devm_ioremap & similar).
Jun 26 21:57:40 <embden[m]> julieng:  I think I found the function for initialization: omap2_prm_base_init, it initializes prm_base values based on dt
Jun 26 22:12:59 <embden[m]> julieng:  but is this a problem in xen or in linux?
Jun 26 22:16:17 <embden[m]> For me, the problem might be in Xen, since, Linux uses the value from Dt
Jun 26 22:56:17 <julieng[m]> embden I don't know yet where the problem lies. Can you please post on the xen-devel your findings?
Jun 26 22:57:18 <julieng[m]> I am interested to know where the ioremap is done, which DT node (i.e path) it uses. A pointer to the DT.
Jun 26 23:00:19 <julieng[m]> Ideally the Xen log with CONFIG_DEVICE_TREE_DEBUG enabled would be useful.
Jun 26 23:54:23 <jkridner[m]> can I get some kind of accomplishments on https://elinux.org/BeagleBoard/GSoC/2019_Projects to document on-going progress?
**** ENDING LOGGING AT Thu Jun 27 02:59:57 2019