**** BEGIN LOGGING AT Tue Jul 30 03:01:12 2019
Jul 30 09:03:11 <julieng> embden_new[m]: Xen will only remove the UART node itself (ti,dra742-uart). If you want to blacklist the parent as well, you would need to do it manually in the omap5 platform code.
Jul 30 10:04:09 <zeekhuge[m]> pratimugale: Can you point out where is the sendMsg_raw method handled in the prussd ?
Jul 30 10:05:52 <zeekhuge[m]> Also, it will help us if you'll restate the problem in terms of the prussd instead of the APIs. APIs are just messages to the prussd. right ? So, focusing on prussd is required.
Jul 30 10:09:41 <pratimugale[m]> <zeekhuge[m] "pratimugale: Can you point out w"> zeekhuge: here : https://github.com/pratimugale/PRUSS-Bindings/blob/7ecc655cfe12fb4db8261caa5209036123ba42e2/prussd/prussd.py#L183
Jul 30 10:23:19 <pratimugale[m]> the format (cmd) is "sendmsg r rpmsg_pru 31 1281"
Jul 30 10:46:32 <zeekhuge[m]> pratimugale: Keep a gist (not pastebin) of the error message obtained from dmesg.
Jul 30 10:46:38 <zeekhuge[m]> And share that as well
Jul 30 10:47:03 <pratimugale[m]> ok
Jul 30 10:53:07 <zeekhuge[m]> Also, just to be safe, try importing prussd directly into a python file and call send_msg method with the right command.
Jul 30 10:53:20 <zeekhuge[m]> pratimugale: So that we are sure that this is the point of error.
Jul 30 10:54:00 <pratimugale[m]> zeekhuge: https://gist.github.com/pratimugale/9820cf72065f4f0a01e01295c4459b57
Jul 30 10:54:19 <pratimugale[m]> <zeekhuge[m] "Also, just to be safe, try impor"> okay
Jul 30 10:55:59 <zeekhuge[m]> Also, then try to write the exact data that prussd writes, directly - manually to the rpmsg_dev file.
Jul 30 10:56:28 <zeekhuge[m]> pratimugale: Basically, try to pin-point, exactly, where the error is.
Jul 30 10:56:39 <zeekhuge[m]> by going one step deeper at a time.
Jul 30 10:58:47 <zeekhuge[m]> If writing the data manually, that prussd is supposed to write, does not produce the error, then prussd is doing something it is not supposed to do.
Jul 30 10:59:32 <zeekhuge[m]> if it produces the same error, then either their is something wrong with the format of the data or with the kernel/firmware.
Jul 30 11:00:24 <zeekhuge[m]> pratimugale:  makes sense ?
Jul 30 11:00:41 <pratimugale[m]> zeekhuge: yes, understood
Jul 30 11:05:13 <zeekhuge[m]> pratimugale:  And it's not an error as per say. It is just taint-ing the kernel. I think that's why its working (ie, not showing the error) the second time.
Jul 30 11:08:20 <pratimugale[m]> zeekhuge: I see, I didn't know what exactly to call it before
Jul 30 11:09:41 <zeekhuge[m]> I am still not sure tbh.
Jul 30 11:10:00 <zeekhuge[m]> Maybe ask @ds2 about it.
Jul 30 11:10:25 <zeekhuge[m]> Show him the dmesg : https://gist.github.com/pratimugale/9820cf72065f4f0a01e01295c4459b57#file-dmesg_example9-txt-L369
Jul 30 11:14:17 <pratimugale[m]> zeekhuge: will do, I found a similar article here: https://community.hiveeyes.org/t/problems-getting-ds18b20-running-on-beaglebone/1293/3
Jul 30 14:37:50 <embden_new[m]> julieng:  yes, that's what I've done yesterday also. And as I said it boots to the same place now but without deleting the whole node. But still doesn't respond
Jul 30 14:41:32 <julieng> embden_new[m]: Sorry if I already asked. Was it responsive before Dom0 is set up?
Jul 30 15:27:17 <embden_new[m]> julieng:  it seems it works only before loading the kernel
Jul 30 16:01:34 <julieng> embden_new[m]: Hmmm... I am wondering if this is because of the crossbar issue I mentioned yesterday.
Jul 30 16:02:08 <julieng> embden_new[m]: As the crossbar is directly accessible from Linux, it will modify the crossbar. So the routing will be different.
Jul 30 16:02:32 <julieng> embden_new[m]: You should look at getting the crossbar region trapped and print a message.
Jul 30 18:06:00 <embden_new[m]> julieng:  can you expain it - what should I do?
Jul 30 18:44:35 <embden_new[m]> julieng:  hm, I think, I know what is happening. Probably, Linux remaps irqs in the crossbar but Linux doesn't know about uart3 (it's deleted by xen) so uart3's irq is not mapped anymore after this
Jul 30 19:42:26 <julieng> embden_new[m]: I pointed out yesterday that the crossbar will still be mapped because it shares a page (4K) with other devices.
Jul 30 19:42:40 <julieng> So Linux will be accessing the host crossbar.
Jul 30 19:43:08 <julieng> This is not what we want because Xen needs to control some of the interrupts routed to the crossbar (for instance the UART).
Jul 30 19:43:19 <julieng> So we need to expose a virtual crossbar.
Jul 30 19:43:29 <embden_new[m]> julieng:  as a quick fix I want to try to add uart3 irq to "ti,skip-irqs"
Jul 30 19:45:49 <embden_new[m]> though, it is not that trivial, so, I think I will just work on virtual crossbar, could you give me some hint on where to start?
Jul 30 20:32:58 <jkridner[m]> vaishnav98_: any updates?
Jul 30 20:39:57 <vaishnav98_[m]> jkridner: tried out putting debug messages on gbsim and running on verbose mode, the pin state change(push button interrupt) does not trigger any greybus messages, the interrupt request suceeds , trying to debug it, couldn't try anything yesterday.morning as classes had started here is the kernel logs when running the button led interrupt example on a greybus gpio:
Jul 30 20:39:58 <vaishnav98_[m]> https://github.com/vaishnav98/mikrobus_device/issues/1
Jul 30 20:41:19 <vaishnav98_[m]> jkridner: I also added test to check whether the irq is valid in mikrobus_spi/i2c_device as you suggested which was missing previously
Jul 30 20:57:03 <julieng> embden_new[m]: I don't know how critical are they other devices sharing the page with the crossbar. So an approach would be to ensure in domain_build.c that any address related to the crossbar (even if it is coming from another device) is not mapped in the Dom0 P2m.
Jul 30 20:57:24 <julieng> This will likely means Xen will receive a data abort from Linux.
Jul 30 20:57:55 <julieng> From there, you can walk you way through adding IO helper for the region you care about.
Jul 30 20:58:22 <julieng> In this helper, you can decide whether this belongs to the crossbar and have to be emulated
Jul 30 20:58:56 <julieng> Or the access is on the other device and the replicate the access to the host hardware.
Jul 30 21:00:10 <embden_new[m]> ok
**** ENDING LOGGING AT Wed Jul 31 02:59:56 2019