**** BEGIN LOGGING AT Wed Jul 03 03:00:28 2019 Jul 03 05:02:47 pranav_kumar: How's it going? Jul 03 05:04:30 Just finished up interfacing the shift register with beaglebone black and working on completing the documentation part ,video ,waveform Jul 03 05:05:06 Using the PRUs for this, or just normal SPI? Jul 03 05:06:24 For now using the pru Jul 03 05:06:42 Nice. Jul 03 05:06:57 Fixed the device tree issues? Jul 03 05:09:50 Accessing the mode 7 was possible to me from very early but what i was getting the problem is in accessing the modes 6 and 5 . But @hedersa said it will not be much of the issue now and it will complicate thing up for the user perspective Jul 03 05:13:33 @pratimugale:matrix.org: i heard in the news that their are flood warning issused in mumbai region duebto heavy rainfall Jul 03 05:20:10 There is a warning but the rains have now subsided Jul 03 05:23:43 Nice to hear that Jul 03 05:36:10 pranav_kumar[m]: did you send out a status update yet? Jul 03 05:53:17 No i will send by today Jul 03 13:34:39 sstabellini: is it possible to obtain xen device tree generated for dom0? Jul 03 15:58:25 embden[m]: the easiest way, if you could reach a dom0 prompt, would be to look at /proc/device-tree Jul 03 15:58:36 embden[m]: otherwise you'll have to add printks in Xen Jul 03 16:02:18 embden[m]: give a look at prepare_dtb_hwdom Jul 03 16:02:24 embden[m]: in xen/arch/arm/domain_build.c Jul 03 16:02:37 embden[m]: and all the following recursive calls to handle_node Jul 03 16:06:33 ok Jul 03 16:15:36 Hi all Jul 03 16:15:57 hello Jul 03 16:17:28 Hi all Jul 03 16:20:41 abhishek_: Hi, does the raw integer need to be written into the rpmsg_pru3x file directly? The "data" that the PRU firmware receives is a void pointer Jul 03 16:22:10 I still don't understand exactly how to do it Jul 03 16:24:55 Good morning, all. Or afternoon. Or whatever. Jul 03 16:28:06 HELLO hendersa Jul 03 16:28:23 pranav_kumar[m]: Hello! Jul 03 16:29:00 on the road yet again. very sad i have not been helpful to vasihnav98_ on getting unstuck on the driver namespace issue to help with driver debug. Jul 03 16:29:24 hope you are safe. Jul 03 16:30:12 I am, thanks :) Jul 03 16:31:46 cwicks running the meeting today? Jul 03 16:32:06 she might be on travel for the US holiday tomorrow. Jul 03 16:32:26 jkridner: I'm sort of stuck with that issue, I have figured out some way to pass parameters to SPI based drivers so that clicks like oledc and OLEDB can be supported without the separate fbtft_device calls, but with i2c based clicks I don't have much Idea, also I have ordered for some more clicks as I didn't have all the clicks outlined in the proposal Jul 03 16:33:20 mdp: ping. Not sure of other Greybus experts who might be responsive on IRC. Jul 03 16:33:31 Hello all! Roll call students ? Jul 03 16:33:32 consider asking the greybus list. Jul 03 16:33:44 the updated work in the circuit branch https://github.com/pranav083/pocket_beagle-work/tree/circuit/2.shift_74hc299/BB_Black hendersa Jul 03 16:33:45 Here I am jkridner :) Jul 03 16:33:47 hi Jul 03 16:34:11 hi Jul 03 16:34:12 hello cwicks jkridner Jul 03 16:34:23 pranav_kumar[m]: Got it. When you have updated videos, code, etc., just add links into your wiki page under your daily update. Jul 03 16:35:34 jkridner: Sure , I'll send a mail today itself to the mailing list Jul 03 16:35:41 ... Jul 03 16:35:45 I see we have all 4 students today - and can I get roll call from mentors? I see hendersa and jkridner Jul 03 16:36:06 ok i am just finished up making the circuit now editing the video Jul 03 16:36:13 hi ds2 Jul 03 16:37:18 julieng: is on vacation, sstabellini was around here Jul 03 16:37:29 I am here Jul 03 16:37:50 thanks embden Jul 03 16:37:59 pranav_kumar: will you please go first this week - quick update, blockers? Jul 03 16:38:05 Hi sstabellini Jul 03 16:38:12 hi cwicks[m] Jul 03 16:41:19 ... Jul 03 16:41:41 Did we lose connection with pranav_kumar ? Jul 03 16:41:59 He's probably typing a huge paragraph. Jul 03 16:42:03 pratimugale : You type cast the void pointer into whatever data type you are expecting Jul 03 16:42:44 one that turns into a link so it can't be logged properly? :( Jul 03 16:42:54 gotcha - cwicks excited for updates this week Jul 03 16:43:22 thanks for the chance , last week i got the Ic delivered 74hc299 .So I first started with the interfacing of switches to take the input .then 1.interfaced the shift register 2. interfaced the shift registers in cascade. then using those shift register to use as input and output using pru assembly code. Here is some of the work and rest about video will be updated by Jul 03 16:43:23 today . Done the documentation of the project. https://github.com/pranav083/pocket_beagle-work/tree/circuit/2.shift_74hc299/BB_Black Jul 03 16:44:54 yes i skipped some of the part as it not possible to update to fast for me :) Jul 03 16:45:17 no i am here cwicks Jul 03 16:46:34 thank you for the highlight pranav_kumar Please summarize any blocks you are having right now and your approach? Jul 03 16:48:14 abhishek_: yes, I'm trying it, it kinda becomes difficult to debug (on the PRU side) once stuck Jul 03 16:48:47 i have some issue with the IC as it doest not support latch feature and it update data bit by bit . I am discussing that with hendersa Jul 03 16:50:23 i had also made a small to do guide of prussdrv technique of uploading the assembly code in pru for the latest kernel 4.14.xx https://elinux.org/Beagleboard_gsoc_2019_bi-directional_progress#Basic_Guide_on_how_to_upload_code_to_PRU_in_BeagleBone Jul 03 16:50:24 do you have prudebug working? Jul 03 16:50:51 jkridner: no Jul 03 16:51:22 I mean I haven't used it yet Jul 03 16:52:52 Will install it now Jul 03 17:02:30 Hi embden would you like to give your update now? Jul 03 17:02:43 yes, thanks Jul 03 17:03:02 Last week, I was able to overcome issues with memory mapping and stuck in interrupt controller issue (the main issue). So, the blocker is I need to figure out how to deal with IRQ mapper (or secondary interrupt controller) in Xen. That's what I am doing now asking questing questions here and on the xen mailing list, looking into the xen code and reading manuals. Jul 03 17:06:45 thanks embden glad to see you are well connected with mentors and the xen group Jul 03 17:07:03 pratimugale: your turn - how is it going? what blocks are you facing? Jul 03 17:08:49 cwicks: This week I was able to use assembly instead of C to generate PWM with adjustable frequency (from 1 MHz to 1Hz). I was also able to take inputs using RPMsg, but had to convert the ascii values to hexadecimal data and then write to the PRU SRAM. Now I'm working on passing raw integers and reconstructing it on the firmware side. Jul 03 17:08:49 Blocker/Currently Working on: Passing raw integers as the "message" to the PRU. Jul 03 17:11:14 The blocker is also that I have less understanding of rpmsg than I thought, so I'm going through its documentation again Jul 03 17:12:50 Ok, let us know your progress and if there's any specific thing you need to understand there. Jul 03 17:14:16 thanks pratimugale glad to know you have some good resources Jul 03 17:14:37 OKay now time for vaishnav98_ how is your project going - what blocks are you facing - where do you need help? Jul 03 17:14:48 abhishek_: yes, I will let you know, I have made detailed updates on the github pages too Jul 03 17:15:02 jkridner cwicks ravikp7: last week I was working on debugging the issue with microSD click support through gbsim and was not able to disable the MMC driver using a dt overlay, due to some mistake in the overlay dts, after loading the overlay the Pocketbeagle stopped booting up, I have updated the project documentation last week and got a pull request to libsoc merged , Jul 03 17:15:03 since I was stuck with debugging the microSD click issue , I tried out interfacing the click support with Beaglebone Makecode project and hope to get it done this week, I have also ordered for some extra click Boards as I didn't have all the click boards outlined in the proposal, I wasn't able to order all of them but was able to order the important ones, I will initiate the discussion on the Greybus mailing list Jul 03 17:15:03 today itself and hope to fix the issues with MicroSD click support soon. Jul 03 17:19:06 Remember that the Click board uses the SPI interface of MMC cards. Your issue might be as simple as which driver loads. Jul 03 17:22:16 Note how mmc-spi-slot is loaded on top of spi, not mmc: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/PB-SPI0-MICROSD-CLICK.dts Jul 03 17:22:31 jkridner: I tried the microSD click through the dt overlay and monitored the messages and found that first mmc-spi driver is being loaded which in turn creates a new new MMC device, through gbsim also the same order is being followed, the mmc-spi driver doesn't throw any errors but the mmc1 (or the new mmc driver) throws the unsupported CSD structure error and fails Jul 03 17:23:10 my assumption was that this was part of the mmc driver, but I should check. Jul 03 17:24:09 so, the same drivers are loading? Jul 03 17:24:28 jkridner: yes I understand that and tried the same method, but the mmc-spi driver loads the MMC driver and the particular error is thrown by mmc driver Jul 03 17:25:06 mmc-spi is a part of thc driver itself Jul 03 17:26:35 how does it select the driver to load? for the mmc controllers, the platform data is provided by device tree. i don’t know how this works with greybus. Jul 03 17:26:44 jkridner I believe so, this was the error message I was getting when loading the microSD click, https://github.com/vaishnav98/gbsim/issues/6 here the mmc-spi driver is first probed Jul 03 17:29:47 * jkridner[m] looks at https://github.com/beagleboard/linux/blob/4.14/drivers/mmc/host/mmc_spi.c Jul 03 17:30:28 jkridner: greybus doesn't allow to pass additional platform data to the driver, it allows only to pass the driver name as far as I understand, I will confirm after communicating through the Greybus mailing list Jul 03 17:33:02 jkridner: after going through the MMC driver sources I suspect that the error was thrown from here https://github.com/beagleboard/linux/blob/36fe81261dbfc1f751f7c1844e6ec5a36b594953/drivers/mmc/core/mmc.c#L148 , that's the reason I was talking about disabling the MMC driver for printing out the CSD data received Jul 03 17:40:58 Thank you embden vaishnav98_ pratimugale pranav_kumar and all the mentors for joining the meeting this week. here is my admin update: Jul 03 17:40:59 you might be able to adjust the pocketbeagle dt to use SPI, I think. not sure. Jul 03 17:42:20 the next evaluations are due to GSoC on 7/22. please provide a clear update in your weekly reports on where you are regarding milestones. If you are behind, you need to include a plan to catch up and how you are going to catch up on the schedule. Please let me know anyone who is not on schedule. Jul 03 17:45:15 pratimugale : Lot of traveling last . Will be more active in upcoming days. If something urgent, please email. Jul 03 17:46:25 jkridner: I'm sorry I didn't understand what you meant :( , other clicks like oled are working via the gbsim virtual SPI driver Jul 03 17:46:27 zeekhuge: okay, thanks Jul 03 17:48:16 embden: pratimugale pranav_kumar vaishnav98_ By now in the project, the mentors should be receiving daily updates from you on the IRC. If you hare not checking in and advising daily your progress and blockers, the mentors cannot know how to assist. If you are behind, you can be checking in two times per day minimum. Jul 03 17:48:52 thank you cwicks Jul 03 17:49:13 cwicks: Thank you, will do that Jul 03 17:49:22 thanks Jul 03 17:49:50 Is everyone pushing code on regular basis? Jul 03 17:50:16 Also, are all the reports done? Jul 03 17:50:29 sstabellini: just get to mind that I can't switch the console since probably interrupts from uart are not routed via the crossbar. Jul 03 17:51:10 pranav_kumar: can you please give me the link of your reports thread? Also, can you please cc me the future reports? Jul 03 17:51:13 Should be pushing code every day at this point correct? Jul 03 17:51:13 Thank you to all the mentor volunteers. Please remember students that the mentors are volunteers they want to see you succeed. You the students need to drive the communication and lead the projects. If you feel discouraged in any way, let the mentors know, they have been stuck coding in their own lives plenty of times. They will know things to help. - signing off - Jul 03 17:52:47 zeekhuge cwicks : as I was stuck with the microSD click , last week I couldn't push any useful Code, will do as soon as I am able to solve the issue Jul 03 17:54:05 embden pratimugale vaishnav98_ pranav_kumar : it is almost a requirement that you push code regularly, and that their should be some coding done on daily basis (some exceptions exist). Also, all reports done? Jul 03 17:54:43 zeekhuge: what kind of reports? Jul 03 17:54:57 Weekly reports. Jul 03 17:56:50 embden[m]: You might try asking on #beagle regarding the interrupt controller...they might not know about xen but any info could help. I personally haven't looked at that part of the SoC Jul 03 17:57:55 ds2: yeah, that's a decent idea Jul 03 17:58:24 cwicks: Thank you. zeekhuge I will push the rpmsg code into the repo asap. Jul 03 17:58:41 zeekhuge : yes, I had submitted the report Jul 03 17:59:23 zeekhuge: I have submitted the report Jul 03 18:01:40 pranav_kumar : ? Jul 03 18:02:26 Yes i had submitted all my previous work week work to my repo Jul 03 18:03:03 zeekhuge: in defense of those who haven't done a weekly report - it's quite cumbersome to maintain both weekly email Monday reports and weekly IRC reports. Every time on the weekly IRC meeting I forget what was my state at the last IRC meeting. Jul 03 18:04:42 Done testing on the 74hc299 ,input storing input manipulating it etc. As said earlier by you i was get late @ZeekHuge_:matrix.org Jul 03 18:05:46 @students : Students should take their respective projects seriously and should really dedicate it the time the project deserves. No side projects. No other commitments. We do understand that their can be some circumstances not under control, but they should be conveyed to the mentors. Jul 03 18:07:30 embden: the reports should be basically a diff between last monday, and current monday. To get that diff, look at the last report, and you should know the current state. Or you can use 'git log --oneline' on your repo. And even can add more filters. Jul 03 18:07:54 Once you know the diff, you just need to summarize (mostly the blockers) in the irc report. Jul 03 18:09:38 This irc report is basically to allow the "other" Mentors and admins to get a quick view of your project. And then then, they might have something to tell you. Jul 03 18:10:57 Anyhow, this "report" thing takes only a little more than an hour and little mental effort, but can be very helpful at times. Jul 03 18:11:37 zeekhuge: the problem appears due to time lag. For example, On one Monday I have task 1 as a blocker. But I resolved it till Wednesday. So, I report about it on Wednesday. But next Wednesday, I don't remember exactly, whether I have discussed it with mentors last time. Jul 03 18:12:46 it is not important, it's just question of power-saving - why to make to weekly-reports in different days Jul 03 18:12:57 two* Jul 03 18:13:45 I understand the motivation why, it's just a bit of annoying Jul 03 18:15:45 The logic is, mentors should have enough time to be able to read your report before the meeting. You just need to maintain that. You can delay the report sending as long as above condition is satisfied. Further more, if your report sending on monday helps solve a blocker, I'd say its worth it. If its mostly you who solve that monday-blocker by yourself, just make sure the mentors know about the blocker, and delay the Jul 03 18:15:46 reports (it should still satisfy the above condition) Jul 03 18:17:36 zeekhuge: yes, as I said, I understand the motivation. Jul 03 18:26:45 Students. I apologize I just assumed all the reports were in this week. Please as @zeekhuge recommends report on time and summarize Jul 03 20:56:16 embden[m]: yes, it looks like it is the case Jul 03 20:56:23 about the uart interrupts Jul 03 20:56:57 I don't know exactly would be the best next step on top of my head Jul 03 20:57:17 I think you'd need to read about the crossbar and figure out if it is easier to configure it in Xen completely Jul 03 20:57:26 then forward interrupts via GIC to dom0 Jul 03 20:57:36 or if it is easier/better to try to assign the crossbar to dom0 Jul 03 20:57:45 most probably it is best to keep in Xen only Jul 03 20:58:01 I want to try the latter first Jul 03 20:58:02 but I don't know for sure -- it also depedends how on the interrupts are routed Jul 03 20:58:33 embden[m]: that's OK, it might work as long as the interrupts configuration is exactly the same virtual-physical Jul 03 20:58:54 embden[m]: when interrupts come in, Xen will inject them as usual in dom0, even if the come via the crossbar Jul 03 20:59:03 I also believe that crossbar is a quite common thing Jul 03 20:59:12 embden[m]: however, be careful that Xen needs to know about those IRQs Jul 03 20:59:21 embden[m]: if it doesn't know, Xen will discard them Jul 03 21:00:12 what I am saying that even if you assign crossbar to dom0, which could be a good first step, the IRQs coming to the GIC need to be advertised to Xen via device tree as usual, otherwise will drop them instead of forwarding them to dom0 Jul 03 21:01:03 sstabellini: hm, ok. I need to read the gic implementation Jul 03 21:02:17 embden[m]: give a look at xen/arch/arm/irq.c, in do_IRQ if _IRQ_GUEST is set, it will be injected to the guest as a virtual interrupt Jul 03 21:02:25 using vgic_inject_irq Jul 03 21:02:37 I believe that in DT many interrupts are routed to the crossbar Jul 03 21:02:51 ok Jul 03 21:03:07 IRQ_GUEST is set by gic_route_irq_to_guest Jul 03 21:03:23 called by route_irq_to_guest Jul 03 21:03:40 called by map_irq_to_domain Jul 03 21:04:11 called by handle_device Jul 03 21:04:24 called by handle_node Jul 03 21:04:38 in xen/arch/arm/domain_build.c, when parsing the device tree at boot Jul 03 21:05:01 I would add a printk to check that that flow works correctly for crossbar IRQs Jul 03 21:05:03 embden[m]: ^ Jul 03 21:05:18 yes, ok Jul 03 21:07:10 embden[m]: I'll be off for the rest of the week (4th of July here) Jul 03 21:07:24 embden[m]: one more suggestion Jul 03 21:07:57 embden[m]: if remapping the crossbar to dom0 doesn't work properly, I would read what Linux does to set it up correctly and try to replicate it in Xen entirely, taking crossbar away from dom0 Jul 03 21:09:41 sstabellini: ok, thought it might be a bit strange, since, the gic is arm-specific and the crossbar is for the whole SoC Jul 03 21:11:10 embden[m]: the crossbar driver would have to be in a platform specific location, such as under xen/arch/arm/platforms Jul 03 21:12:18 embden[m]: do you know which IRQs are routed via crossbar? Jul 03 21:12:59 sstabellini: all the IRQs except of local interrupts Jul 03 21:13:20 embden[m]: do you know if the IRQ *numbers* change due to crossbar? Jul 03 21:14:19 also do you know if the "interrupts" property works differently when crossbar is present? Jul 03 21:14:27 Hm, I don't understand the question. I believe that crossbar is needed to be able to remap interrupts Jul 03 21:16:14 Don't know about the second question Jul 03 21:17:03 there is something here: https://www.kernel.org/doc/Documentation/IRQ-domain.txt in Hierarchy IRQ domain section Jul 03 21:17:09 sstabellini: ^ Jul 03 21:19:44 "The IRQ_CROSSBAR is able to map any of its input signals to any of its outputs." Jul 03 21:22:35 embden[m]: basically Xen will look at the interrupt property and figure out the interrupt number from there. It does that by interpreting the interrupt property using the way it is expressed with a GIC Jul 03 21:23:11 embden[m]: see Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml Jul 03 21:23:39 embden[m]: specifically the second cell is the interrupt number Jul 03 21:24:06 theoretically, with interrupts are routed to crossbar first, all the IRQ mappings could be different and the interrupt property could be different too Jul 03 21:24:32 looking at the device tree it doesn't seem to be the case: for instance interrupts = <0x0 0xe1 0x4>; Jul 03 21:24:32 Where can I get the docs? Jul 03 21:24:49 it is a three cells property and 0xe1 is very plausibly the interrupt number Jul 03 21:25:10 so maybe everything we have for the GIC will apply as is for when crossbar is present Jul 03 21:25:27 embden[m]: it should be somewhere in the beagleboards docs? Jul 03 21:25:49 ok Jul 03 21:26:28 so, it's Linux'es Jul 03 21:26:49 look at the am5 docs Jul 03 21:26:59 not bb docs Jul 03 21:28:48 ds2: I found the required docs Jul 03 21:29:32 embden[m]: So, in Xen, we need to call gic_route_irq_to_guest appropriately, even for IRQs that go via crossbar. It doesn't matter too much whether the crossbar is configured in dom0, by remapping it to dom0, or whether it is configured it directly in Xen. But Xen needs to know which IRQs go to Dom0, and to do that gic_route_irq_to_guest needs to be called. And today, that is done based on the "interrupts" property in Jul 03 21:29:34 device tree Jul 03 21:31:09 embden[m]: does it make sense? Jul 03 21:31:10 sstabellini: ok Jul 03 21:32:25 sstabellini: it odes, though I don't understand how it is detected automatically. For example, if IRQ has a number 0x5 before the crossbar, then after it it can become 0x8, so, how xen will follow that... Jul 03 21:33:35 embden[m]: Yes, I don't know that either. If the remapping works the way you describe, with IRQ numbers changing dynamically, then it is very likely that the only option is to have a crossbar driver in Xen itself Jul 03 21:33:58 embden[m]: so that the crossbar driver in Xen will configure the 0x5->0x8 mapping and call gic_route_irq_to_guest(0x8) Jul 03 21:35:44 But to configure the crossbar it is needed to write to a special CTRL_CORE_xx...xx register Jul 03 21:36:28 sstabellini: So, maybe xen can control those writes. Jul 03 21:36:45 embden[m]: yes Jul 03 21:38:37 sstabellini: ok, then I will try to follow your advice tomorrow Jul 03 21:39:13 embden[m]: 1. write a small driver in Xen for crossbar that configure the interrupt mappings and calls route_irq_to_guest Jul 03 21:39:37 embden[m]: 2. you might have to modify the device tree for dom0 so that crossbar is "hidden", otherwise dom0 will try to configure crossbar again Jul 03 21:39:53 embden[m]: 2a. hide crossbar itself Jul 03 21:40:29 embden[m]: 2b. change interrupt numbers exposed to dom0 to match the final mapping done by Xen (0x5->0x8, then in device tree only 0x8 is present) Jul 03 21:42:22 alternatively: Jul 03 21:42:40 1. remap crossbar to dom0, and let it configure the IRQ mappings Jul 03 21:43:03 2. in Xen find out what the mappings are and call route_irq_to_guest appropriately Jul 03 21:43:33 this second strategy looks more like a "hack" but it could be a way to get things running quickly for a testy Jul 03 21:43:38 *test Jul 03 21:44:07 also, I don't know in Xen how to find out what the crossbar mappings are. Maybe we could read them from crossbar itself. Jul 03 21:44:20 it is a bit awkward though Jul 03 21:44:23 embden[m]: ^ Jul 03 21:44:27 hm, for me the second way looks better, since, Linux is ready to deal with crossbars Jul 03 21:45:41 embden[m]: I know what you are referring to, but in practice a guarantee it is more awkward. Let me explain. Jul 03 21:46:00 embden[m]: how does Xen know that Linux is "finished" configuring crossbar, so that it can finally read the configuration from it? Jul 03 21:46:20 embden[m]: there is no clear way. and what if Linux changes the configuration? Xen will never know Jul 03 21:46:32 no way, probably Jul 03 21:46:48 I agree Jul 03 21:46:55 embden[m]: unless we change linux to make a hypercall to let Xen know about it, but it would require changes in Linux deep in the crossbar driver nobody will be happy about Jul 03 21:47:10 embden[m]: I know this because we try this all before :-) Jul 03 21:47:16 embden[m]: it never comes out all right :-) Jul 03 21:47:40 embden[m]: the first strategy is more code, but it is a better abstraction and a clear separation of responsibilities: Jul 03 21:47:41 I mean, if Linux wants to change the crossbar it would want to make a call to the special register Jul 03 21:48:04 embden[m]: there one more way Jul 03 21:48:20 though, there is no easy way to find out when the Linux set up the crossbar Jul 03 21:48:38 embden[m]: if Xen exposed a "fake" crossbar to Linux, every read/write made by Linux will be trapped into Xen Jul 03 21:49:01 embden[m]: Xen will replicate the read/write to the real crossbar, but it will also set up route_irq_to_guest correctly Jul 03 21:49:16 so basically: xen configure the real crossbar, but it does so upon instructions from Linux Jul 03 21:49:44 to get an idea out to trap things in Xen give a look at xen/arch/arm/vgic-v2.c Jul 03 21:50:19 embden[m]: OK, let's recap :-) Jul 03 21:50:46 embden[m]: 1. expose crossbar to dom0 in device tree (no device tree changes) without remapping crossbar to Linux Jul 03 21:51:14 embden[m]: 2. implement a skelethon emulated crossbar that captures the configuration reads and writes from Linux for crossbar Jul 03 21:51:48 embden[m]: 3. Xen replicates the reads and writes on real hardware and sets up things internally as appropriate, i.e. route_irq_to_guest Jul 03 21:52:11 basically the "fake" crossbar is the simplest possible crossbar driver in Xen, one that does only what Linux tells it to do Jul 03 21:52:45 I see it Jul 03 21:53:46 this is easier than the first strategy we discussed because it doesn't need device tree modifications, and it doesn't need a proper crossbar driver in Xen Jul 03 21:54:18 but it still has similar advantages: only Xen programs the real crossbar Jul 03 21:54:49 it looks complicated - I don't understand the second step Jul 03 21:55:04 oh, you gave an example in gic-v2 Jul 03 21:55:08 ok Jul 03 21:57:33 embden[m]: yes, step 2 is a driver that figure out what Linux wrote and acts accordingly Jul 03 21:57:41 embden[m]: see vgic_v2_distr_mmio_read Jul 03 21:57:52 embden[m]: and vgic_v2_distr_mmio_write Jul 03 21:58:14 ok Jul 03 23:23:56 https://www.youtube.com/playlist?list=PLttoix_9Us2yHM4zNr08ynm4iwXZTgxam updated the video from progress video 2 to 5 **** ENDING LOGGING AT Thu Jul 04 02:59:57 2019