**** BEGIN LOGGING AT Mon Aug 12 02:59:58 2019 Aug 12 08:58:07 julieng: sstabellini I don't understand how to rework the crossbar. Could you answer my question? (few messages above) Aug 12 10:12:30 embden_new[m]: The vgic code should be able to cope with virtual GIC interrupt != host GIC interrupt. In the case of the crossbar, it might be easier to think the two are equals. Aug 12 10:12:58 Looking the DT bindings, you should be able to tell Linux which IRQs are available. Aug 12 10:14:49 embden_new[m]: Did you implement the registers trapping? If so, did you see a case where the GIC interrupt may alrady be reserved? Aug 12 11:15:38 julieng: I did implement it, but as far as I can see Linux doesn't change much in the crossbar (just few writes occur) Aug 12 11:20:57 embden_new[m]: What are those write from? You should see some to initialize the crossbar (crossbar_of_init). And then when IRQs are allocated using allocate_gic_irq(). Aug 12 11:26:13 julieng: I believe that it initialize all register with zero and then write some values into some registers, e.g. into timer1 Aug 12 11:42:56 embden_new[m]: I am not expecting to see a lot of write from the crossbar. After all it is mostly for setting up routing. If you can try to focus on one specific device and see if it is working. Aug 12 11:43:13 For instance, is any of the network/block device going through the crossbar? Aug 12 11:43:32 The timer is also an option. Although, I am not entirely sure what is "timer1". Aug 12 11:47:24 julieng: could you tell me then what my tasks are for the next few days? My code now is a total mess. Should I make it be more appropriate? And regarding the crossbar should I look whether one device is working properly? I mean if I assume that gic==vgic it might lead to some consequences. But is it ok for now? Aug 12 11:59:47 drhunter[m]: ^ Aug 12 12:04:44 I need to leave for 2-3 hours, after that I will be back to work on the issue Aug 12 12:31:11 zeekhuge: Regarding the previous issue, for some reason, the device file "pruss_api_pru1" was not being created on the debian image that I was then working on. After that, I tested the driver on 3 different debian images, and the device file gets created properly (pruss_api is probed) on loading the firmware and starting the PRU. Aug 12 12:49:21 zeekhuge Abhishek_ For installation of this module, should the source file "pruss_api.c" be compiled on the user's side? Because installing the linux headers consumes 78MB of space. Aug 12 13:09:04 pratimugale : You can submit module source to rcn-ee and he'll include it in the beagleboard kernels Aug 12 13:24:06 Abhishek_: I don't know if the module should be included in all of the beagleboard kernels because it is specific to this project. The module is derived from rpmsg_pru and it creates a device file called "pruss_api_pru1" instead of "rpmsg_pru31" Aug 12 13:24:44 Well you do want to put out a debian package right? Maybe you can add it there. Aug 12 13:25:47 Abhishek_: Okay Aug 12 13:26:00 vaishnav98_: soooooo sorry for being completely unavailable the last 10 days or so. Aug 12 13:26:31 ravikp7: have you had any interactions while I've been out-of-touch? Aug 12 13:26:44 I lost my phone on Aug 4 and was out of the country. Aug 12 13:26:52 I should be getting a replacement today. Aug 12 13:34:03 I am drawing a picture of what I think we are trying to achieve as I'm not entirely sure what bit is missing at the moment. Hopefully it will help us decide that. Aug 12 13:37:36 jkridner : sorry to hear that :( , I have so far added support for clicks with interrupt requirements on greybus i2c bus, currently I am writing some simple tests to include in gbsim to verify the functionality (greybus gpios, interrupts,SPI..) Aug 12 13:54:56 cool. did you just add interrupt support to gbsim as a solution? Aug 12 13:55:24 * jkridner[m] wishes cfriedt and others doing greybus work were all either here or #beagle Aug 12 13:58:11 vaishnav98_: cfriedt has been fixing some bugs and getting some networking bridge stuff working that is really interesting. Aug 12 13:59:12 jkridner: yes, I used libsoc methods to do it, when a greybus gpio is configured as interrupt , the corresponding attached physical gpio will also be configured the same interrupt type and in the interrupt callback a greybus irq_event message will be sent, I verified it with button+led example as you suggested and it was working well Aug 12 13:59:28 jkridner: great, I'll look into it Aug 12 13:59:50 vaishnav98_: where are the latest instructions? I think if you have any milestones to check off, you should try to get them checked and then focus on user experience for a nice demo. I think significant code structure fix-ups might be too much to take on. Aug 12 14:00:55 it would have been nice to have a solid metadata structure for the Clicks.... and that was certainly the goal of the exercise, but it seems we don't have a straight-forward direction for that as of now, unless you've worked something out. Aug 12 14:02:21 jkridner: One thing I am confused with is to how to integrate the Mikrobus driver to instantiate devices (clicks) on greybus buses, for now it takes parameters click name and port and instantiates the device in the corresponding bus, is adding a call to the Mikrobus driver from greybus a good method? Aug 12 14:03:47 jkridner: https://vaishnav98.github.io/GSoC19/ I am posting the instructions for trying out new clicks here Aug 12 14:06:03 jkridner: I am stuck with adding support for ultrasonic distance click based on the pga460 signal processor, I couldn't find any Linux based support for it, I am confused on how to proceed with it in the short period of time Aug 12 14:07:25 I guess that's really a matter where the abstraction exists. In my mind, I think mikroBus is really on both sides. Aug 12 14:08:49 jkridner: could something like this work? manifest contains the click name and the port it is attached , the additional platform data will be supplied through a dynamically loaded device tree overlay , which will be parsed by the Mikrobus driver and the device instantiation takes place (gbsim+greybus handles setting up the buses, dynamic overlay+ Mikrobus driver Aug 12 14:08:49 handles device instantiation on the bus)? Aug 12 14:11:30 do you mean that the manifest describes the bus as mikroBus instead of I2C/UART/SPI/etc.? I think that could make a lot of sense if I understand. Aug 12 14:14:44 by "both sides", I mean I think of greybus as "just a transport".... Aug 12 14:15:04 but now, what we are transporting is a certain collection of I2C/SPI/GPIO/UART/etc...... Aug 12 14:15:20 such that in the transport, the particular port is now abstracted... Aug 12 14:15:35 the transport is on a per-mikroBus basis. Aug 12 14:16:46 so, you still have to instantiate the drivers for Clicks on the greybus host side, but you will use the same interrupt, reset, etc. that would normally be used for mikroBus.... and not need to worry about the exact pin details. Aug 12 14:17:11 then, on the gbsim-side, you'd just to think about mapping the resource requests to the right ports/pins. Aug 12 14:17:35 so, it still knows something about the physical side of mikroBus... how it is wired up on the board. Aug 12 14:17:46 does that make sense? Aug 12 14:18:11 you might need to break things down for me a bit to explain where the challenges are right now. Aug 12 14:19:55 jkridner: manifest currently describes the greybus peripherals required in terms of cports and protocol as far as I understand, for example what I was suggesting is : consider an example for an mpu9dof click , this click requires a greybus i2c bus and a greybus gpio interrupt , so the manifest will have a i2c protocol on cport1 and gpio protocol on cport2 , loading Aug 12 14:19:56 the manifest will set up the corresponding peripherals (greybus gpio, greybus i2c bus) , also the manifest will have the click name and port , which will be passed to the Mikrobus driver for device instantiation Aug 12 14:20:56 oh. yeah, that's actually more what I had in the mind before we started running into the interrupt issues. Aug 12 14:21:42 I was thinking you were looking to combine them, but if you can make these multiple cports work together in a bundle and get the device instantiated properly, that'd be ideal as it'd require no new abstractions in greybus. Aug 12 14:23:43 jkridner: getting multiple cports working together in a bundle is working, I have tried it , but I am not sure how to pass that details to the corresponding device driver, the confusion is with the instantiation part Aug 12 14:25:49 vaishnav98_: cfriedt just sent you an e-mail. Aug 12 14:26:27 ahoy! Aug 12 14:26:37 welcome! Aug 12 14:27:11 jkridner: I was going through it, thank you cfriedt Aug 12 14:27:47 vaishnav98_ - if you have some questions, please ask away. Aug 12 14:28:15 we were just discussing if, for mikroBus, vaishnav98_ should indeed use a cport per peripheral, like an mpu9dof where you'd have cport1 with i2c and cport2 with a gpio for the interrupt. Aug 12 14:29:27 I think there was further some question if there would be a mikrobus driver still in the loop to intercept the mikroBus name and still put together the platform data and probe. Aug 12 14:30:30 I was a little more confused on the statment of the port number coming across in the manifest. Aug 12 14:30:34 hmm... that would be a good approach. Aug 12 14:31:36 cfriedt: is there an alternate we aren't considering? I mean is this the way usage was intended? Aug 12 14:31:54 cfriedt jkridner: my doubt is how to properly Instantiate a click device , as of now setting up the greybus interfaces (SPI/i2c/gpio) is working and the interaction between greybus buses with physical buses is working (userspace tests like SPI loopback works) , I am confused with how to instantiate the devices properly (if it's a simple device with no additional platform data it's straightforward ) Aug 12 14:33:03 cfriedt: how are the manifest events typically handled? Aug 12 14:33:37 I guess if no additional platform data is required, they "just work" via the bus driver? Aug 12 14:34:04 but, lots of these drivers need extra little bits of gpio, etc. Aug 12 14:34:10 for GPIO, there is a device-side message that is sent to the AP over greybus Aug 12 14:34:22 that would be an interrupt event Aug 12 14:34:36 * jkridner[m] wonders if gregkh is in #beagle, but knows mdp lerks here every now and again. Aug 12 14:35:22 jkridner cfriedt: yes , I was able to try this with greybus spi device (by changing the spi_new_device call to a mikrobus_new_device call , but for greybus i2c there is no particular device setup related methods in greybus/i2c.c so how could we trigger the mikrobus_new_device call for an i2c device Aug 12 14:35:25 cfriedt: but, you are talking about particular device event there, not the discovery process. The manifests themselves have a mechanism to bubbling up to drivers, no? Aug 12 14:35:29 in terms of associating platform data with information from the greybus manifest, i am not quite sure if that's supported yet in terms of the manifest spec, or the kernel side for manifest processing Aug 12 14:36:08 *but* there is a "name" feature in the manifest, and two cports can be in the same bundle, soooooo Aug 12 14:36:41 jkridner: if that data isn't supplied how could gbsim know which Mikrobus port the device is connected to Aug 12 14:37:12 vaishnav98_: that'd have to be supplied to gbsim by the userspace initiated probe. Aug 12 14:37:24 ie, the 'insclick'. Aug 12 14:40:19 jkridner: the manifest likely gets exported through sysfs and is attached to a particular module (and module-id is synonymous with primary-interface-id) Aug 12 14:40:34 jkridner: but I have not yet validated that. Aug 12 14:41:54 it would be kind of roundabout, but a userspace app could pass the critical manifest data back to a mkroBus driver. I'm sure there must be a way to get a driver to listen to it directly. Aug 12 14:43:06 maybe we need a new bundle class for our mikroBus driver? Aug 12 14:44:05 jkdridner: https://github.com/torvalds/linux/blob/master/drivers/staging/greybus/interface.c#L439 Aug 12 14:44:46 jkdridner Aug 12 14:44:58 jkdridner: no manifest in the interface sysfs data Aug 12 14:45:08 jkridner: okay then port information is not required in the manifest, I was thinking of obtaining it from the manifest Aug 12 14:46:19 really, the manifest should have a mechanism for supplying platform data though, and it should be symbolic, and localized to the bundle of the cport in question Aug 12 14:47:04 well, but I think they handle that with bundle classes right now.... but I'm probably wrong. Aug 12 14:47:55 or maybe not localized to the bundle, but certainly the module Aug 12 14:48:05 there is a "Sensor" bundle class. Aug 12 14:51:33 * jkridner[m] wonders if there is something similar for sensors: https://elixir.bootlin.com/linux/latest/ident/gbaudio_register_module Aug 12 14:52:56 are we all trying to look at documentation to figure out what to say? Aug 12 14:53:37 should really be as simple as specifying another pair of string descriptors in the manifest, that are of the form: driver-specific-gpio-name=manifest-specific-gpio-name, and manifest-specific-gpio-name=manifest-specific-gpio-number, but that entity really needs to be defined in the manifest spec Aug 12 14:54:27 i.e. Aug 12 14:54:33 there are uevents on bundles.... so many hacks are available to us. :-) Aug 12 14:55:13 question 1: should that be done on a cportX or bundle level? Aug 12 14:55:36 i.e. [string-descriptor 2]string = driver-specific-gpio-name=manifest-specific-gpio-name Aug 12 14:55:45 probably should go with that question back on the greybus-dev list, though the discussion as died? Aug 12 14:56:13 I did not realize there was a list.. maybe I should be on it! Aug 12 14:56:27 cfriedt: can that be done in a driver generic way? Aug 12 14:56:45 cfriedt: https://lists.linaro.org/pipermail/greybus-dev/2019-July/000804.html Aug 12 14:56:47 jkridner: I believe so, yes Aug 12 15:01:24 jkridner: just joined the list. Can you reply on the original thread an CC me? That way I can chime in with my 2c Aug 12 15:03:07 vaishnav98_: if you're interested in the python code, try running it at some point and see if you can spot the bug. It would be nice to get a second pair of eyes on it Aug 12 15:06:13 cfriedt: sure I'll have a look at it today Aug 12 15:23:03 I just made another embarrassing attempt at getting some clarity on the list. Aug 12 15:23:16 maybe if we discuss it out ourselves on-list, we'll finally figure it out? Aug 12 15:31:01 hi drhunter ! Aug 12 15:31:45 I am here drhunter Aug 12 15:33:44 Denis, I sent you an email with my current understanding of what you are trying to do. It left me with big gaps in how the virtual GIC is working. For the crossbar itself can I check you have looked at Table 17-2 in http://www.ti.com/lit/ug/spruhz6k/spruhz6k.pdf. Looking at UART3 for the terminal it is cross bar element 69, routed to MPU_IRQ74 which goes to GICv2 106. On the virtual GIC can you explain how you think Aug 12 15:33:45 MPU_IRQ74 should be handled so that interrupt could be routed to virtual CPU? This seems to me to be what is next step. Aug 12 15:34:04 * drhunter[m] posted a file: virtual GIC.pptx (52KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/MtbCyXQunIQuAdrdjzmRmCRy > Aug 12 15:34:29 and as I've just seen RIOT has an upload option I have just added ppt. Aug 12 15:43:02 drhunter: first of all, we have uart3 working. it is deleted from xen automatically and we add its irq to irqs-skip list in DT Aug 12 15:43:38 I think we can't just left uart3 in DT because xen needs it Aug 12 15:44:15 Secondly, where can I find this mapping from MPU_IRQ to GICv2 irq? Aug 12 15:47:17 And in general my question is: if we have gic irq N mapped to vgic irq M, what should we do if something is written in the crossbar register M or N? Or should we just assume for now that gic==vgic? julieng drhunter Aug 12 16:03:31 its that table 17-2 that gives the mapping to gic in column 1 Aug 12 16:05:01 oh, ok Aug 12 16:05:16 for now i would assume M=N as at the moment you can't route the interrupts. once you are able to route interrupts to a guest then second step would be to handle M!=N as the guest DT might try and reconfigure. Aug 12 16:08:49 drhunter: what do you mean by "can't route interrupts"? Aug 12 16:12:54 my understanding is that at the moment if a hw interrupt occurs then it is not routed to the virtual cpu to handle (timer interrupts dont count as they are inside the A15 core). Is that not correct? or do you have the PV drivers working on dom0? Aug 12 16:13:34 drhunter[m]: embden_new[m]: I would consider a the vGIC as a black box. The main function is vgic_inject_irq() which is used to raise the interrupt vIRQx to the guest. Aug 12 16:14:22 A vIRQx can either be fully virtual or mapped to an HW IRQs. Aug 12 16:15:02 For HW IRQs, they will still first be received by Xen and then injected to the guest (see do_IRQ). Aug 12 16:16:51 In general all PPIs (per-CPU interrupts) are virtualized. This includes the arch timer one. Aug 12 16:17:17 For dom0 all virtual SPIs are mapped to HW SPIs. Aug 12 16:18:25 The only para-virtualized bit of Dom0 is the console. All the rest is using the virtualization extensions in the hardware or direct access to a device. Aug 12 16:20:19 The general process for an HW IRQs routed to Xen is: Aug 12 16:20:24 s/Xen/the guest/ Aug 12 16:20:35 1) Xen receives the interrupt Aug 12 16:21:09 2) The interrupt priority is dropped (the HW IRQ is still active but would not block other interrupts) Aug 12 16:21:31 3) Xen figures out the vCPU to inject the interrupt and the vIRQ Aug 12 16:23:52 4) The vGIC will configure the virtual GIC CPU Interface via the LRs (List Register) to inject the interrupt when the vCPU runs Aug 12 16:24:04 5) The guest is receiving the interrupt and handling it Aug 12 16:24:29 6) The guest deactivate the interrupt -> This will also deactivate the HW IRQs. Aug 12 16:53:54 Thanks Julian. So for now the best way at the moment would be to consider the crossbar as a static configuration (M=N). Does a PV driver use the vIRQ and so it could be tested with mounting an SD card in a domU? If not what would be best way to test vIRQ? Aug 12 17:01:02 drhunter[m]: Is the SD card interrupt going through the crossbar? If so, then testing Dom0 can actually mount the SDCard should be sufficient Aug 12 17:02:46 It would be best if DomU is left out of the equation for now. This is only adding more complexity and potentially more bug (we don't know whether the crossbar is enough to make the rest working). Aug 12 17:25:15 Basically all peripheral interrupts go through the crossbar. Device has 420 potential interrupt sources which are mapped as required to 152 crossbar inputs. Aug 12 17:26:12 Thinking about it, using one of the GP Timers (ie not core timers) would be easiest way to generate a crossbar IRQ for testing. Aug 12 17:35:20 julieng: drhunter there will be a final evaluation soon. Can we decide in what direction should I work? Regarding omap5 hyp patch, current state of the code (it's a mess) and testing the crossbar? Aug 12 18:42:25 My thought is that getting fundamental code to work and in a state to commit - such as omap5 hyp is #1 priority. Tidying up code would be #2 and testing crossbar #3. Aug 12 18:53:19 drhunter: ok Aug 13 01:27:41 Abhishek_: There is a problem of kernel oops: Unable to handle kernel NULL pointer dereference at virtual address 000001dc that occurs when rpmsg_pru is probed for the first time by the firmware. Subsequent use of the firmware code works correctly until rpmsg_pru module is removed from the kernel or the beaglebone is rebooted. What could be causing this? Aug 13 01:49:34 the dmesg logs are here: https://github.com/pratimugale/pratimugale.github.io/blob/master/_posts/2019-07-30-KernelOOPS.md Aug 13 02:44:41 From what I can see in the logs, it occurs somewhere inside rpmsg_pru_write Aug 13 02:45:05 There is a null pointer dereference happening Aug 13 02:46:59 pratimugale : Do you want to try https://www.kernel.org/doc/html/v4.14/dev-tools/kgdb.html Aug 13 02:46:59 Kgdb? Aug 13 02:52:11 @abhishek_:matrix.org: I will try to use the debugger, haven't used it before **** ENDING LOGGING AT Tue Aug 13 02:59:56 2019