**** BEGIN LOGGING AT Mon Jul 15 03:01:15 2019 Jul 15 04:10:11 Try using putty on windows, serial connect the second bb by checking which COM port it is connected to Jul 15 04:49:07 @pratimugale:matrix.org: i use linux and all my files is in their Jul 15 07:24:47 zeekhuge abhishek_ I started writing code for stepper motor control: https://github.com/pratimugale/PRUSS-Bindings/tree/wip/examples/firmware_examples/example7-stepper-control. I am currently writing a seperate library for the driver - started yesterday. Jul 15 07:27:04 The problem I'm facing is while having two or more commands to be sent to the stepper motor i.e how to figure out if the motor is finished with its previous job. One way to get around this is to use usleep() which I'm using at the moment, but I'm not sure if its the right approach for proper precision. Jul 15 07:27:33 So I was thinking waiting on the rpmsg channel on the Linux side, the PRU will send a message back once the assembly code is done executing. There will have to be an interrupt from PRU0 to PRU1 too as PRU0 runs the assembly code and PRU1 has the rpmsg firmware. Is this method correct? Jul 15 07:27:45 The main function is in user_test.cpp Jul 15 07:30:52 Yup, rpmsg would disturb the real time aspect of the timing loop so different PRUs is fine. PRU-PRU communication through interrupts is also OK Jul 15 07:36:17 abhishek_: I'll should finish it up and post a demostration video before Wednesday's meeting Jul 15 07:44:47 Looking forward to it Jul 15 07:46:42 Ok, thanks Jul 15 09:01:19 zeekhuge: i had solved the problem of getting high freqency signal while uploading the code . Its came out that the pin (i/o pins ) gives 2.56v in high state and 0.25v in low state when checked using the multimeter. Jul 15 09:01:45 https://youtu.be/R3kSgY7nwpk Jul 15 09:41:19 embden[m]: I would only focus to give crossbar access to Dom0. I am not entirely sure DomUs interrupt remapping is worth it. It is only require for device passthrough and it is not entirely clear whether this could be used on the BeagleBoard x15 Jul 15 09:42:53 embden[m]: I don't really follow the rest of your message. Could you give an update on your current state? Jul 15 09:43:41 julieng: the state is that I am trying to understand how to map the interrupts Jul 15 09:44:28 I believe that the gic supports 192 interrupts and the crossbar has more input lines Jul 15 09:44:47 embden[m]: That's correct. Jul 15 09:47:24 embden[m]: AFAICT, x15 has more interrupts thant what the GIC supports (Note that theoritically the GIC can support up to 1020 interrupts but the hardware may support less). The crossbar is here to workaround that limitations. Jul 15 09:48:21 yes, so, I am looking for the place where to make the translation Jul 15 09:58:59 embden[m]: The translation is done by dt_irq_xlate Jul 15 10:07:19 embden[m]: The interrupt subsystem in Xen is quite simplistic (compare to Linux). Jul 15 10:09:16 julieng: I can see that multiple interrupt controllers are not supported, so, some logic for kind of a chain of interrupt translation should be added probably Jul 15 10:10:10 embden[m]: Yes, although I think a fully-fledge hierarchy is probably to overkill for Xen. Jul 15 10:10:30 What we probably want is only two-level Jul 15 10:10:34 one-level is Xen Jul 15 10:11:15 Sorry, one level is the GIC and handled by the common code Jul 15 10:11:38 the second level is handled by the platform code. Jul 15 10:13:18 I agree Jul 15 10:14:56 embden[m]: I don't have a particular preference how this could be done so far. Could you come up with a suggestion? Jul 15 10:15:24 julieng: I am interested in from where to get the right interrupt number as input for gic_irq_xlate Jul 15 10:18:29 I would think about filling a crossbar representing structure from the crossbar's control registers Jul 15 10:21:10 embden[m]: I don't think you would need to call gic_irq_xlate when the interrupt is going through the crossbar. Jul 15 10:22:07 The crossbar will do the allocation of the GIC interrupt ID Jul 15 10:22:42 You will actually need to provide another *_irq_xlate that match the bindings for the crossbar. Jul 15 10:27:22 I mean that we have interrupt number in the device tree. And those interrupt numbers are input lines to the crossbar. But we don't know the GIC interrupt numbers. Those values are stored in the crossbar control register after reset. So, should we in crossbar_irq_xlate, for example, read those values into some binding structure? And then call gic_irq_xlate with those interrupt values? Jul 15 10:27:26 julieng: ^ Jul 15 10:31:54 embden[m]: *_irq_xlate are just here to translate the DT information into something usuable for Xen. Jul 15 10:32:29 You know the GIC interrupt numbers as soon as you configure the crossbar. Jul 15 10:35:03 Basically what you want to do is something like: Jul 15 10:35:14 Though, there is no need in the distinct structure mirroring the crossbar control register since the crossbar control register already keeps the required information, is that right? Jul 15 10:36:05 1) Find out the crossbar interrupt ID from the DT Jul 15 10:36:15 2) Allocate the GIC interrupt ID Jul 15 10:36:28 3) Configure the crossbar to route the interrupt Jul 15 10:36:44 4) Initialize the GIC interrupt ID Jul 15 10:37:00 The steps does not have to be done in the same function. Jul 15 10:37:53 embden[m]: mirroring -> You don't really care about the crossbar interrupt ID after the configuration has been done. You only need to have the GIC interrupt ID in hand. Jul 15 10:38:40 Sometimes mirroring can be useful as reading device register has a cost. Jul 15 10:43:10 julieng: that looks reasonable. Jul 15 10:45:15 julieng: but will then in that case crossbar_irq_xlate replace gic_irq_xlate? Jul 15 10:48:41 embden[m]: If all the interrupts are going through the crossbar, then it would be fine to just replace gic_irq_xlate by crossbar_irq_xlate. Jul 15 10:49:02 If not, then we would need to call the correct _xlate Jul 15 10:49:19 all SPIs Jul 15 10:54:31 can anyone point out the problem what is the problem in the second video . where i am running the same code . But deriving two led which are connected to npn transistor base pins and the output get currupted . while this is not the case in the first video . All the circuit is powdered by beagle bone only : 1. https://youtu.be/R3kSgY7nwpk 2. https://youtu.be/fG5O7ty_u3c Jul 15 10:55:51 julieng: wouldn't it be easier to just change specifier and size fields in dt_raw_irq structure to the appropriate gic values right before dt_irq_xlate? Jul 15 11:00:05 embden[m]: Sorry, I don't understand your suggestion. Jul 15 11:00:19 Could you expand it? Jul 15 11:01:50 pratimugale: i had figured out the way to communicate multiple beaglebone . Thanks for the reply, i had used earlier the guide from http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/#Static_IP_Address_under_Debian but the only problem that i faced is that ,I have to use address 192.168.*.* (which should be other than .7.*) as it was not getting connected to the system or i was not able to Jul 15 11:01:51 get the ip address. Jul 15 11:06:52 julieng: I mean in xen/common/device_tree.c in dt_irq_translate there is a call to dt_irq_xlate. And we pass as a parameter dt_raw_irq which describes the interrupts from DT. The mentioned function transform irq from DT into internal representation of IRQ I believe. So, before call to the dt_irq_xlate can we call platform_irq_xlate which will substitute input crossbar's values in dt_raw_irq with output crossbar Jul 15 11:06:52 values. Jul 15 11:09:28 embden[m]: There are probably some rework to do around this code. Jul 15 11:12:17 embden[m]: Most likely we want to extend dt_irq to take the interrupt-controller parent Jul 15 11:13:26 This would allow us more freedom in the code to decide what to do. Jul 15 11:19:46 I think at the moment we consider the internal representation to be the same as the GIC ID. Jul 15 11:21:04 dt_translate_irq is probably not meant to return the internal representation but the direct information from the device-tree. This can then be consumed by the caller to route interrupt or decide whether the interrupt can be assigned to the guest.= Jul 15 11:23:55 julieng: am I understand right that in the "interrupts" propery the first value is SGI number, the second is SPI number and the third is the type of value (EDGE, LEVEL,..)? And what are other fields about? Jul 15 11:24:33 embden[m]: For which bindings? Jul 15 11:25:11 The interpretation of the "interrupts" property depends on the interrupt controller. Jul 15 11:25:47 julieng: ok, so, for gic every interrupts should have three fields? Jul 15 11:26:26 embden[m]: That's correct. Jul 15 11:27:05 embden[m]: The first field tells you whether this is a SPI or PPI. Jul 15 11:28:12 The second field tells you the interrupt number of the interrupt type (SPI/PPI) Jul 15 11:29:06 The third field contains the flags. In Xen, we only deal with the first 4 bits which contain the trigger type and level. Jul 15 11:33:13 julieng: ok, I then will try to make a quick translation as I proposed - it should be relatively quick, and see how far I can boot, and then start implementing you suggestion Jul 15 12:05:33 julieng: hm, the mistake I have is: (XEN) the vIRQ number 253 is too high for domain 0 (max = 192) Jul 15 12:06:10 So, the interrupt number is 221 Jul 15 12:07:54 everything is ok Jul 15 12:09:18 embden[m]: The vIRQ is based on the maximum number of interrupted supported by the GIC. Jul 15 12:10:16 See route_irq_to_guest() Jul 15 12:13:21 embden[m]: I can see two way here: Jul 15 12:13:48 1) route_irq_to_guest() initialize the crossbar to route the interrupt to a specific GIC ID. Jul 15 12:14:50 2) route_irq_to_guest() only log that the guest will be allowed to configure the crossbar interrupt ID foo. Jul 15 12:15:06 julieng: it seems that it is really not the best possible solution that I propose. I am still trying to allocate the right interrupt numbers as you proposed Jul 15 12:16:24 sstabellini: Do you have a view how we should deal with hierarchy interrupt controller in Xen? Jul 15 12:27:05 julieng: how to accomplish this: 2) Allocate the GIC interrupt ID Jul 15 12:55:54 embden[m]: The crossbar driver will have to allocate the GIC interrupt ID. Jul 15 12:56:48 embden[m]: For now, I think you should only focus on getting the UART driver working. This does not need to have the guest booting. So you could avoid routing everything to Dom0 for now. Jul 15 12:56:53 could you give me an example? Jul 15 12:57:54 embden[m]: Have a look at linux/drivers/irqchip/irq-crossbar.c. Specifically the function allocate_gic_irq.c Jul 15 12:58:05 *allocate_gic_irq. Jul 15 12:59:05 ok Jul 15 12:59:07 will have a look Jul 15 13:17:39 julieng: I have a build error : Error: size of domain_build.o:.data is 0x04 Jul 15 13:18:38 embden[m]: This is because anything in domain build should be in the init section. Jul 15 13:19:35 embden[m]: I guess you try to add a new global variable. Right? If so, you would need to add the attributes __initdata. Jul 15 13:19:58 yes, that's right Jul 15 13:20:15 I will just make it static local Jul 15 13:22:52 embden[m]: static local will have the exact same issue. Jul 15 13:23:44 I mean static in the file where I use it Jul 15 13:24:04 embden[m]: Ok Jul 15 13:57:18 julieng: I tried to write to the control register it seems that I can't do it from xen right now. I got a data abort Jul 15 13:57:48 embden[m]: How did you map the control register to Xen? Jul 15 13:58:21 julieng: I just tried to write to physical address Jul 15 14:02:20 I am a bit confused why xen should allocate memory to itself Jul 15 14:06:46 embden[m]: Xen is running with MMU enabled and therefore use its own virtual address space. Jul 15 14:08:19 For accessing the physical address, you need to map it into a specific virtual address. This can be done using ioremap_nocache(...). Jul 15 14:08:50 The function takes a base physical address and the size to map in parameters and will return the base virtual address Jul 15 14:08:53 ok Jul 15 14:09:48 you can then use the IO helpers to access the regions (see xen/include/asm-arm/arm64/io.h). Jul 15 14:26:31 julieng: so, I got to the newer error: (XEN) Unable to get irq 1 for /ocp/interconnect@48000000/segment@0/target-module@60000/i2c@0/rtc@6f Jul 15 14:27:26 node looks like this: https://pastebin.com/tihswi8n Jul 15 14:29:33 and it seems that it has another interrupt-controller before the crossbar Jul 15 14:32:26 embden[m]: And you get the error even if you take dom0 out of the equation? Jul 15 14:34:51 julieng: I thought I haven't started to deal with dom0 Jul 15 14:37:11 embden[m]: Are you suggesting this is called while dealing with the UART? Jul 15 14:37:24 I mean the error happen Jul 15 14:38:41 julieng: I tried to implement the simplest mapping : https://github.com/embeddedden/xen/commit/e7fb11250911732c5d717096dbacb80a66df5898 Jul 15 14:38:57 the code is really bad but I wanted to see whether the approach will work Jul 15 14:42:22 embden[m]: What's the verdict? Jul 15 14:44:33 julieng: I think that I need to utilize tegra approach for revealing the crossbar. Because it seems that there is some interrupt-controller before the crossbar but my code tries to use the same logic for it and fails. Jul 15 15:21:47 julieng: how platform structs are used in the platform.c if they are defined as static in platform-specific files? Jul 15 15:56:04 embden[m]: All the platform structures will reside in the section .arch.info. Jul 15 15:57:08 If you look to the linker scripts (arch/arm/xen.lds.S), we defined _splatform/_eplatform as the begin/end of the section. Jul 15 15:57:25 The two variables are then used to iterate over all the platforms Jul 15 16:35:16 ok Jul 15 17:30:23 embden[m]: What the state of the patch "xen/arm: Switch OMAP5 secondary cores into hyp mode"? Jul 15 17:31:08 julieng: haven't worked further on it Jul 15 17:31:12 yet Jul 15 17:35:01 embden[m]: Thanks for the update. It would be good to get the discussion going on the thread. Jul 15 17:38:01 julieng: ok, I will continue on it tomorrow Jul 15 17:41:39 embden[m]: thanks Jul 15 17:43:25 julieng: so, I changed the code a bit https://github.com/embeddedden/xen/commit/5a4f3d488a38f70bc9f63886f33ce7a00c03c5e6 Jul 15 17:43:46 and now I got the error: Jul 15 17:43:47 (XEN) the vIRQ number 192 is too high for domain 0 (max = 192) Jul 15 17:55:01 julieng: Am I right that there to many interrupts in DT? What should I do? **** ENDING LOGGING AT Tue Jul 16 03:02:17 2019