**** BEGIN LOGGING AT Mon Aug 19 02:59:57 2019 Aug 19 05:17:34 pratimugale: was looking at the project link. What are the other things you planning to complete before 26 ? Aug 19 05:18:07 Also, make a release (on githib -> release) and add the deb their. Aug 19 05:18:21 Maybe v1.0.0 ? Aug 19 05:18:32 As this would be the first release. Aug 19 05:41:47 @ZeekHuge_:matrix.org: I was planning to see if we can integrate 'prudebug' with this; and the kernel oops is left Aug 19 05:42:09 I will make the release on githuv Aug 19 05:42:26 Does the code contain inline documentation comments? Aug 19 05:46:22 @ZeekHuge_:matrix.org: For some of the examples, I still have to write proper comments and do their documentation Aug 19 05:46:43 No. Not the examples. The apis Aug 19 05:46:58 Do they have inline documentation comments? Aug 19 05:47:33 I see. They dont. Aug 19 05:47:42 No Aug 19 05:48:05 https://github.com/ZeekHuge/BeagleScope/blob/master/beaglescope/beaglescope_driver.c#L69 Aug 19 05:48:12 These are inline documentation comments Aug 19 05:48:20 Once you have them in your code Aug 19 05:48:43 You can then use doxygen to create web-pages explaining all the APIs Aug 19 05:49:03 All the functions, their purpose, their return type and all the arguments. Aug 19 05:49:22 The kind of documentation that you find in a "good famous" Project Aug 19 05:49:45 @ZeekHuge_:matrix.org: Ok, I will make sure to add the these as well Aug 19 05:50:28 Do you think this + oops finxing can be done before 26 ? Aug 19 05:50:38 pratimugale: ^ Aug 19 05:54:43 @ZeekHuge_:matrix.org: I will do my best to do and fix it, I don't exactly know how much time it will take but it should be done. Aug 19 05:55:12 Did you try discussing about oops with ds2? Aug 19 05:56:39 Not yet, I will discuss it with him asap Aug 19 05:56:53 If not, try putting it on the mailing list, with as much detailed analysis as you can (code, logs, instructions etc) and cc me, Abhishek_ and ds2 with that. Aug 19 05:57:34 @ZeekHuge_:matrix.org: Ok, will do that Aug 19 05:57:57 He is very experienced with kernel. We might be able to find the error if we'll dive deeper. But he might find it just by looking at the logs. Aug 19 05:58:15 And the code of course. Aug 19 06:56:02 great, will put it out on the mailing list today Aug 19 13:16:45 julieng: drhunter any thoughts on my question above? Aug 19 13:28:05 embden_new[m]: Supporting a second interrupt controller is always going to be nasty without a full rework. Tegra's implementation is one the best I have seen so far. Aug 19 13:28:34 What matters is all the platform specific code is a platform specific file and hooks are provided. Aug 19 13:30:47 So here what I suggest: Aug 19 13:31:20 1) Split the code to avoid platform specific code in common code Aug 19 13:31:39 2) Document the approach (as pointed by drhunter[m]) Aug 19 13:31:50 3) Provide a branch with all the work. Aug 19 14:52:32 julieng: am I right that tegra's approach is not upstreamed yet? Aug 19 15:22:38 embden_new[m]: You are correct. Aug 19 15:41:59 julieng: hm, if it is not supported how other boards deal with interrupts amount greater that number of irq lines? Aug 19 15:53:42 embden_new[m]: The GIC spec allows up to 1019 interrupts... For any normal board, this is quite a lot. If you want more then there are the ITS extension for MSI. Aug 19 15:54:12 But here the problem is TI decided to ship with a GIC supporting only 200ish interrupts. Aug 19 15:55:05 Any sensible hardware would have shipped with a GIC supporting more interrupts than that. I don't know why TI decided against it. Aug 19 15:57:03 julieng: I believe I have heard they also stopped to manufacture socs Aug 19 15:57:47 embden_new[m]: This was mentioned on the mailing list. But I can't confirm neither deny it. Aug 19 15:59:00 32-bit Arm virtualization is mostly for hobbyist. Any decent production projects are using 64-bit nowadays. But that may shift again with the IoT story. Aug 19 16:07:14 julieng: people in our lab work with security in for devices, the worst thing they don't know much about virtualization but this is not the best university in the world. Aug 19 16:07:15 Then, I will implement something similar to tegra's thing. Aug 19 16:09:58 embden_new[m]: I would suggest to focus on the documentation first. This is more important than having nice split code. Someone needs to be able to understand what was done in the project and what is missing. Aug 19 16:13:39 julieng: what kind of documentation - is the blog entry ok? Aug 19 16:21:23 For the documentation I would like. Aug 19 16:22:07 1. System overview of how uboot, Xen and Dom0 fit together Aug 19 16:22:55 drhunter[m]: 1. already exists on a few place on the web... Aug 19 16:23:18 2. Detailed explanation of the problem with current situation and why the crossbar didn't fit into that architecture Aug 19 16:24:56 3. Details on changes you made to fit the crossbar into Xen. Focus should be on what Xen wants/needs and how you provided that functionality. It should describe the changes you made from a Xen point of view and not a silicon/Linux point of view Aug 19 16:25:25 drhunter[m]: So can you explain what exactly you want on 1.? Aug 19 16:25:44 Aim is that someone else would be able to start from where you left off without having to call you. Aug 19 16:26:30 embden_new[m]: A blog entry is fine with me. Aug 19 16:27:41 I'm thinking that the next person to look at this is probably not going to be a Xen expert. So a brief overview is required. No point cutting and pasting from other websites. So it could just be short with links and an explanation about what pieces of the puzzle each link provides. Aug 19 16:28:00 ok Aug 19 16:52:35 julieng: I just thought that IO handlers might also be not required for handling crossbar register reads and writes. Maybe we can use them only to block access to console's irq line (which we added to skip-irqs) otherwise, they are probably not needed, since, we already mapped all the lines and in the current version just allow everything. Aug 19 16:57:27 embden_new[m]: As the device is shared between Xen and Dom0, we need to trap and sanitize it. Aug 19 16:59:53 Technically dom0 is trusted, so here this is mostly for preventing dom0 doing the wrong thing or concurrent access problem. Aug 19 17:00:09 Looking at the Linux code, I think the later would not be such an issue. Aug 19 17:01:02 julieng: should some spinlock be taken in mmio handlers? Aug 19 17:02:04 embden_new[m]: If you keep an internal state then definitely yes. Aug 19 17:02:21 If it is just access the crossbar, then I think this should be ok. Aug 19 17:03:00 ok Aug 19 17:03:55 We should have this discussion on the ML once the series has been sent. Aug 19 17:04:42 julieng: I also haven't understood what to do with the last HYP realted patch Aug 19 17:07:55 drhunter[m]: ^ Aug 19 18:04:16 embden_new[m], julieng - do we have a snapshot to submit for GSoC purposes? Aug 19 18:07:58 ds2: right now, the documentation is in an initial state with a linke to the code: https://medium.com/@denisobrezkov/xen-on-beagleboard-x15-a517ea7d9bb Aug 19 19:07:09 embden_new[m]: nice... glad to see you are on top of it... I had to dro poff for some personal stuff... do you plan to make a tag like GSOC2019_FINAL? Aug 19 19:22:51 ds2: it's not hard after all. I think everything will be ready for submission on 25th. Aug 19 19:33:28 I mean adding a tag is not hard Aug 19 19:44:47 *nod* Aug 19 20:53:11 0201 LEDs? Aug 19 21:44:35 ds2: Hi, could you please have a look at this kernel oops problem I'm facing while using rpmsg. I have described it on the mailing list here: https://groups.google.com/d/msg/beagleboard-gsoc/711XmP7jFMc/sE0PvoScAwAJ. zeekhuge said you might be able to help me regarding this. The code involves sending large amount 1-byte values to the PRU through rpmsg_pru31 and writing them to the PRU SRAM for further use. Aug 19 22:55:52 julieng: I am also interested whether I need make_crossbar_node or it should be created automatically? Aug 20 02:42:25 @ZeekHuge_:matrix.org: I couldn't find ds2's email. Do you know it so I can forward the mail to him as well **** ENDING LOGGING AT Tue Aug 20 03:01:37 2019