**** BEGIN LOGGING AT Tue Jul 02 02:59:56 2019 Jul 02 11:13:15 sstabellini: could you give me a link where to learn more about how to write xen drivers? Jul 02 13:04:52 embden[m]: what do you mean with "Xen drivers", exactly? Hardware drivers to be used inside the Xen hypervisor? Jul 02 13:05:19 embden[m]: and for what device? this secondary IRQ controller in the SoC? Jul 02 13:15:46 sstabellini: wrote : "it could be that we need a crossbar driver in Xen" Jul 02 13:19:42 embden[m]: I am afraid there are not many "drivers" in the classical sense in Xen - by design. So there is also not much documentation or frameworks Jul 02 13:20:09 apritzel: I understand Jul 02 13:21:15 embden[m]: from what I understand the problem with the BB is that Xen needs to deal with the secondary interrupt controller, is that the crossbar that sstabellini is talking about? Jul 02 13:22:14 if yes, then you should look at the GIC driver, as this has some kind of interface you could implement Jul 02 13:25:08 apritzel: I am also trying to understand how crossbar works Jul 02 13:25:47 so this is about this "ti,irq-crossbar", I guess, which is the interrupt parent for uart3, which is the console? Jul 02 13:26:43 afaik crossbar maps external interrupts to on-core interrupt controllers. For arm-a15 core it maps interrupts to arm's GIC Jul 02 13:27:38 embden[m]: so maybe you should have a look at struct gic_hw_operations Jul 02 13:28:12 this is used to abstract GICv2 and GICv3, but maybe you could pretend this crossbar is some kind of GIC, and use that interface Jul 02 13:30:36 apritzel: hard to understand for me. Maybe dom0 will need to manage interrupts via the crossbar. But, probably, not. But I'll take a look on that struct Jul 02 13:32:04 dom0 will most likely want to deal with the crossbar, and this is fine. Xen actually doesn't want to deal with it, but has to due to the UART using this crossbar Jul 02 13:38:00 embden[m]: maybe you should find out what Xen exactly needs from that interrupt controller, if it's just a device triggering an IRQ Jul 02 13:38:26 chances are it's just some acknowledge IRQ and EOI operation Jul 02 14:30:13 pranav_kumar[m]: Are you here? Jul 02 14:31:09 Yes Jul 02 14:31:44 I had made progress on the shift register i have to update it on the progress page Jul 02 14:31:50 I'm back from travel and will be around far more often to help out. Jul 02 14:32:07 Did you get your evaluation feedback? Jul 02 14:32:27 Done the bidirectional communication with 74hc299 Jul 02 14:32:30 Yes Jul 02 14:32:33 https://gist.github.com/pranav083/40c711cbc86782a777ff3208182f72ac Jul 02 14:33:55 Good deal. What have you been using to test the PRU code (both hardware and software)? Jul 02 14:34:54 Yes both Jul 02 14:35:11 But what are you using to test? Jul 02 14:35:24 I understand you can use LEDs for output, but what about input? Jul 02 14:35:26 And both as an input and ouput using 4 gpio available Jul 02 14:36:06 Today i will do all the documentation and uplpad the few video that i have made while working on this Jul 02 14:36:48 Toggle switch connncted in the cascade mode to the next shift register Jul 02 14:38:02 Do you have a most recent device tree with mode 7 GPIO pins I can look at? Jul 02 14:38:25 yeds Jul 02 14:38:48 yes plz wait as my device boot up Jul 02 14:39:40 Be sure to keep your github projects up to date with your code. It doesn't matter if it is "broken" at the moment, as the mentors need to see daily activity so that we can help you as you get stuck. Jul 02 14:41:38 i have a problem with this register as it work only to the max frequency of 50Mhz(as in datasheet of 74hc299) and it also does not support latch functionality as it was in 74hc595 Jul 02 14:43:25 yes i was busy working so i was not able to communicate and update my total work , as my shift register start to work as expected .Today i will document all the things Jul 02 14:44:21 Please do. I want to get caught up with your work now that I am back and sync up with you daily to keep things moving forward. Jul 02 14:44:58 What's the next task for you? Is it the kernel driver? Jul 02 14:45:10 yes as i am already behind the schedule .Thanks for the update Jul 02 14:46:19 i have update the device tree file here Jul 02 14:47:19 Please include an updated Fritzing circuit and timing diagrams (wavedrom is fine) in your documentation. That will allow me to spot any potential problems that aren't being seen right now. Jul 02 14:49:04 yes tonight i will do all the documentation work that is left as it will also be difficult for me to make you understand the circuit. Jul 02 14:50:06 I understand. Hopefully, the documentation won't change much on the hardware side from here forward. Jul 02 14:52:24 Has the PRU firmware development been difficult for you? Have you tried using a PRU debugger to help? Jul 02 14:53:02 yes , as i have to make it more transparent to other user also . the only thing that is not their in 74hc299 is the latch functionality. I will make the documentation for that also Jul 02 14:55:13 no i had used pru debugger yet but i use the logic analyzer and small hardware knowledge of checking the circuit to get most thing done . Writing assembly code is slow but it is fine for me Jul 02 14:55:41 as i have to specific with the controller(pru) Jul 02 14:57:01 but which debugger are you talking about the one that is available with the ccs Jul 02 14:57:57 I was thinking of prudebug, but there might be other, more modern ones that are more useful. Jul 02 14:58:07 https://sourceforge.net/p/prudebug/wiki/User%27s%20guide/ Jul 02 14:58:59 prudebug hasn't been updated for a few years, though. Jul 02 15:01:07 thanks , i will look into that But what about the next step that i have to take Jul 02 15:01:38 Your immediate next step is your documentation. After that, we'll worry about the kernel driver. Jul 02 15:02:20 I can work with you to adapt the beaglelogic kernel driver for this project. Jul 02 15:02:34 ok it will get updated by today Jul 02 15:03:46 few days earlier i tried to understand it but i have bad time with that Jul 02 15:03:53 I am going to get back to work, but I need you to update your wiki page with the latest documentation prior to our update meeting tomorrow, OK? Jul 02 15:04:25 Also, I'd like you to come up with a list of any questions you have and mail those over to me so that I can work on getting answers for you. Jul 02 15:04:38 Today will be a busy day for you, I think. Jul 02 15:05:01 ok Jul 02 15:09:31 yes from the last few days when i got the shift register delivered Jul 02 15:14:12 zeekhuge abhishek_ : I am now able use rpmsg to tell the PRU what hexadecimal value needs to be written into the Data/SRAM using something like https://github.com/ZeekHuge/BeagleScope/blob/0afb7d98df2eb18dca3ffd3a943b3100a24191b6/firmware/main_pru0.c#L291. The msg_from_kernel array consists of ascii values of the characters being sent which need to be properly converted to 8 bit integer to write to the memory Jul 02 15:14:13 location. Then the other PRU will read from the same location and adjust its inputs accordingly. Is this method right? Jul 02 15:35:21 pratimugale : You can also send a 4-byte raw integer directly Jul 02 15:41:11 abhishek_: How do you do that ? Jul 02 15:43:34 pratimugale : You might want to read about serialization/deserialization Jul 02 15:44:54 For example, Int is 4 bytes, you send the 4 bytes that composes the integer and reconstruct it on the other side. Jul 02 15:49:06 abhishek_: Okay, I'll read about serialization. Jul 02 15:49:48 Will the message then consist of binary data? Jul 02 15:53:46 Yup Jul 02 15:56:14 abhishek_: ok, I'll try it now and get back to you Jul 02 16:04:43 jkridner ravikp7: specifying the MMC controller no. still doesn't fix the problem, the Pocketbeagle stopped booting up, https://gist.github.com/vaishnav98/592ee185e30e0d11e29a3bb456eeeaf7 **** ENDING LOGGING AT Wed Jul 03 03:00:28 2019