**** BEGIN LOGGING AT Mon Aug 05 03:02:02 2019
Aug 05 05:07:31 <Abhishek_1> CI would be great, especially if you can integrate it with rcn-ee 's package distribution system.
Aug 05 05:08:56 <Abhishek_1> pratimugale : My documentation effort wasn't that great at my time, zeekhuge did better.
Aug 05 05:09:52 <Abhishek_1> Think about what kind of documentation you would have wanted when you were getting started with this project, and write it that way.
Aug 05 05:10:55 <Abhishek_1> You should definitely talk to Dr. Mark Yoder who has created the PRU cookbook.
Aug 05 05:26:18 <pratimugale[m]> abhishek_[m]: ok, thanks; I'll send an email to Dr. Mark Yoder today.
Aug 05 10:02:21 <embden_new[m]> julieng:  am I right that handlers installed on physical address?
Aug 05 10:21:17 <julieng> embden_new[m]: guest physical address
Aug 05 10:24:38 <embden_new[m]> julieng:  I can't fing the description of gfn, pfn, mfn and others. I thing I need to obtain gaddr?
Aug 05 10:29:24 <embden_new[m]> julieng:  should I use something like gfn_to_gaddr(pfn_to_gfn(paddr_to_pfn(PHYS_ADDR)))  in register_mmio_handler?
Aug 05 10:31:28 <embden_new[m]>  * @freenode_julieng:matrix.org:  should I use something like gfn_to_gaddr(gfn_to_pfn(paddr_to_pfn(PHYS_ADDR)))  in register_mmio_handler?
Aug 05 10:31:50 <embden_new[m]>  * @freenode_julieng:matrix.org:  should I use something like gfn_to_gaddr(pfn_to_gfn(paddr_to_pfn(PHYS_ADDR)))  in register_mmio_handler?
Aug 05 10:33:28 <julieng> embden_new[m]: The description of gfn, mfn, pfn can be found in xen/include/xen/mm.h
Aug 05 10:38:13 <julieng> In the case of Dom0. MFN == GFN == PFN.
Aug 05 10:38:25 <julieng> So you can use gfn_to_gaddr(...) directly
Aug 05 10:39:18 <julieng> All the *addr are not typesafe, but *fn are. What matters is you get the correct *fn.
Aug 05 10:39:52 <julieng> register_mmio_handler() is taking a guest physical address directly, so you can use PHYS_ADDR
Aug 05 10:40:05 <julieng> without having to go through the conversion.
Aug 05 10:40:32 <embden_new[m]> julieng:  but why I can't see the output then?
Aug 05 10:41:39 <embden_new[m]> in here https://github.com/xen-project/xen/commit/8b152404e6621b5beef484030f57dc9ff3ba877e
Aug 05 10:46:16 <julieng> embden_new[m]: On Friday, I suggested the region may have been mapped by the special mappings callback. Did you check whether this was the case or not?
Aug 05 10:47:24 <embden_new[m]> julieng:  I can see that there is no mapping in .specific_mapping, how can I check it other way?
Aug 05 10:48:27 <julieng> embden_new[m]: You can walk the guest P2M and check whether there are a mapping. See dump_p2m_lookup() in arch/arm/p2m.c
Aug 05 10:48:45 <embden_new[m]> ok
Aug 05 11:03:02 <embden_new[m]> julieng: https://pastebin.com/AKyfwzKY
Aug 05 11:04:06 <embden_new[m]> also, there are others
Aug 05 11:08:14 <embden_new[m]> here all of them are: https://pastebin.com/9YAdZSRJ
Aug 05 11:09:43 <embden_new[m]> So, I think I should unmap the page somehow and make a handler that allows to write to the mentioned addresses and does corressponding actions for writes to the crossbar? julieng
Aug 05 11:15:22 <julieng> embden_new[m]: The best would be to prevent the mapping at first.
Aug 05 11:15:53 <julieng> If you want to quickly try unmapping, you can use unmap_mmio_regions
Aug 05 11:17:30 <embden_new[m]> julieng:  hm, to prevent mappingm I think there should at least two ways. First, is to map it to somewhere else, and the second is to not map at all (I think it is not a good way). Right?
Aug 05 11:22:06 <julieng> map it to somewhere else is not an option.
Aug 05 11:22:35 <julieng> you don't know how Dom0 is going to use it. So all MMIOs should be map at the correct place.
Aug 05 11:23:11 <julieng> Furthermore, keeping map means that Linux has still access to the crossbar. We don't want that as this also Dom0 to do the wrong things on the hardware.
Aug 05 11:23:55 <julieng> If you keep unmap, then *all* the access will be trapped to Xen. You can then make a decision whether you want to emulate them as passthrough to the host.
Aug 05 11:26:58 <embden_new[m]> ok
Aug 05 11:29:07 <embden_new[m]> julieng:  so, I want to try to unmap it but where to do it? It should be done after dt is read, right?
Aug 05 11:41:31 <embden_new[m]> also, does unmap_mmio_regions take a number of bytes to unmap as nr but a page number as a start of unmap region?
Aug 05 11:44:38 <julieng> embden_new[m]: Towards the end of the domain construction should be ok.
Aug 05 11:45:33 <julieng> embden_new[m]: A page number. It would make very confusing to the using if there are not any sort of cohesion between the parameters.
Aug 05 11:47:43 <embden_new[m]> julieng:  a page number or number of pages?
Aug 05 12:08:39 <embden_new[m]> julieng:  I unmapped the page but I stll got messages from dump_p2m_lookup.
Aug 05 12:08:39 <embden_new[m]> And now I have the following Liunux output: https://pastebin.com/aRcmdKCU
Aug 05 12:09:10 <julieng> number of pages.
Aug 05 12:09:36 <julieng> Well, dump_p2m_lookup will walk the page table. So while you unmapped the block entry, the table may still be there.
Aug 05 12:10:21 <julieng> embden_new[m]: "(XEN) traps.c:1998:d0v0 HSR=0x93440047 pc=0xc04e5848 gva=0xfc002a48 gpa=0x0000004a002a48" this is a good news, this means the mapping is not anymore in the P2M.
Aug 05 12:10:38 <julieng> Now the "interesting" work of virtualizing the crossbar can start.
Aug 05 12:13:28 <embden_new[m]> julieng:  why mmio_handler hasn't handled this? or returning is not sufficient for allowing the operation?
Aug 05 12:18:34 <julieng> embden_new[m]: I would add debug print in your IO handler and see if it is called. If not, then you can look at try_handle_mmio() to see what's wrong.
Aug 05 12:18:40 <embden_new[m]> oh, I did a small mistake - wrote 1000 instead of 0x1000 in register_mmio_handler, so not the whole page was covered
Aug 05 12:27:16 <embden_new[m]> julieng:  ok, now it works as predicted (handler is called): https://pastebin.com/4RRMi38W
Aug 05 13:15:13 <pratimugale[m]> <Abhishek_1 "CI would be great, especially if"> abhishek_[m]: what do you exactly mean by integrating with Robert Nelson's package distribution system and how should I go about doing it?
Aug 05 13:16:01 <Abhishek_1> Every time you make a change, it is pushed upstream into his package repositories.
Aug 05 13:16:19 <Abhishek_1> After the debian package is rebuilt
Aug 05 13:24:38 <pratimugale[m]> abhishek_[m]: I don't understand, will it be on that debian image that the changes be tested?
Aug 05 13:27:32 <Abhishek_1> Your changes get integrated into the Debian image, yes
Aug 05 13:34:56 <pratimugale[m]> abhishek_[m]: Could you point me to something similar or some reference, I've not used CI a lot, and I don't know how the integration would be done
Aug 05 13:48:41 <Abhishek_1> Travis CI is popular, there's also GitLab's CI
Aug 05 14:13:09 <pratimugale[m]> abhishek_[m]: https://github.com/pratimugale/PRUSS-Bindings/blob/sandbox/.travis.yml I made this and am checking it right now; the build correctly 'fails' for any syntax errors in cpp-bindings, but errors in prussd.py go undetected-> https://travis-ci.org/pratimugale/PRUSS-Bindings/builds/567897638. What I don't understand is how the integration would be done with his Debian image, I'm looking into this.
Aug 05 15:14:38 <embden_new[m]> julieng:  Linux maintains the crossbar state, should we also do it?
Aug 05 18:30:28 <vaishnav98_[m]> jkridner: I could get mpu9dof click with greybus gpio as irq + greybus i2c bus working :) , the problem was with setting the wrong value for functionality for the greybus i2c-adapter in gbsim, I will push the code soon
Aug 05 18:37:13 <mdp> vaishnav98_[m]: cool!
Aug 05 18:41:07 <vaishnav98_[m]> mdp :-)), thanks a lot for the support I was really stuck with greybus interrupts for many days
Aug 05 22:58:01 <embden_new[m]> julieng:  some time ago, I find that interrupts don't pass the crossbar even if I mark the uart3's interrupt as skip-irqs in dt
Aug 05 23:03:58 <embden_new[m]> and now I can see from dom0 output that it starts to change crossbar starting not from the fourth (uart3's) slot in crossbar but from the seventh. But I didn't think that I should also overwrite the base address of crossbar and now I have found out that though I've hidden fourth slot of the crossbar dom0 still overwrites it but now it thinks that it's the seventh. So, by hiding the fourth slot I shifted all slots
Aug 05 23:03:58 <embden_new[m]> and have created a supermess. Now it's not surprising that it didn't work.
**** ENDING LOGGING AT Tue Aug 06 02:59:57 2019