**** BEGIN LOGGING AT Wed Jul 31 02:59:56 2019 Jul 31 06:18:31 pratimugale: creating a dpkg - good idea ! Look into `checkinstall` utility. Jul 31 06:19:06 Also, we have to integrate or at least test that GUI PRU debugger and work on documentation. Jul 31 06:20:21 Moreover, about that dedicated kernel driver, its not just the module-key, but the sysfs bindings ie the rpmsg files you write into. The prussd should have dedicated files, so that other applications using rpmsg should not produce undesirable effects. Jul 31 06:20:40 * Moreover, about that dedicated kernel driver, its not just the module-key, but the sysfs bindings as well ie the rpmsg files you write into. The prussd should have dedicated files, so that other applications using rpmsg should not produce undesirable effects. Jul 31 06:44:13 yes Jul 31 06:45:27 zeekhuge: I think that the problem was in the order that the 'pru_rproc' and 'rpmsg_pru' modules are loaded into the kernel Jul 31 06:46:26 I've mentioned the lsmod here https://pratimugale.github.io/gsoc/2019/07/30/KernelOOPS.html Jul 31 06:47:23 the daemon currently was probing only the pru_rproc driver, and at some time during the execution, 'rpmsg_pru' is probed Jul 31 06:52:36 the rpmsg_pru driver is probed by the key, the channel name in the PRU Jul 31 06:52:52 It does not need to be probed explicitly. Jul 31 06:53:47 Its like - when you plug in a new device onto to the system. The kernel recognizes it, and tries to load the correct module. The channel-name in the PRU is the key that tells the kernel, which module to load. Jul 31 06:55:01 But how does the kernel is able to read the channel-name from PRU firmware ? Jul 31 06:56:12 The pru_rproc driver does that. When it starts the PRU, it "goes through" the firmware code (it parse the ELF format) and finds for the channel key, and then tells the kernel - "this is the driver key that need to be invoked". Jul 31 06:57:24 So, rpmsg_pru driver does not need to be probed as per say. But to control the prus, pru_rproc needs to be loaded, if not already present. Jul 31 06:58:01 Ideally, the device-tree should have already probed the pru_rproc (by the same mechanism of keys), but if it hasn't, then it need to be loaded explicitly. Jul 31 07:00:33 understood, but the sequence of the lines "rpmsg host is online" and "new rpmsg_pru device: /dev/rpmsg_pru31" are flipped in the dmesg logs Jul 31 07:00:45 between which the NULL pointer dereference happens Jul 31 07:00:59 It does probe it Jul 31 07:03:47 Did you try executing each step of the Makefile manually ? Jul 31 07:03:51 pratimugale: ^ Jul 31 07:04:09 yes Jul 31 07:04:19 And ? any insight from that ? Jul 31 07:04:30 it occurs while executing the object filee Jul 31 07:05:10 *file userspace.o Jul 31 07:05:18 You mean when you compile it ? Jul 31 07:05:30 or link it Jul 31 07:05:58 no, while running the final userspace program, no error during compilation occurs Jul 31 07:06:48 Did you try to start prus with the firmware, manually ? Jul 31 07:07:57 As in? Jul 31 07:08:20 Okay. My bad, Makefile is not "starting" the PRUs. The prussd does that. But that is what I meant by "did you try executing each step of the Makefile manually". Jul 31 07:08:37 pratimugale: You can start PRU manually. right ? Jul 31 07:08:48 yes Jul 31 07:09:04 like, copy the firmware to a specific location and then echo some magic words in some specific sysfs. right ? Jul 31 07:09:14 did you try that with this firmware ? Jul 31 07:10:29 for this firmware, I haven't tested it manually because the daemon again restarts it Jul 31 07:10:32 will try it Jul 31 07:11:08 * zeekhuge[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/KxsOEFQuRSfUWKaxIblnSRnt > Jul 31 07:11:21 right ? this is what this program is doing. Jul 31 07:11:40 yes Jul 31 07:11:49 Try to dive in. Jul 31 07:12:17 manually. Try to do each step. Jul 31 07:12:19 And see what happens. Jul 31 07:12:22 You NEED to pin-point where the error is actually. Jul 31 07:12:34 Is it in loading the firwares ? Jul 31 07:12:45 is it when sending messages over the rpmsg channels ? Jul 31 07:12:54 is it in loading the rpmsg_pru driver ? Jul 31 07:12:55 where ? Jul 31 07:12:59 that is the question. Jul 31 07:13:48 understood, doing the same Jul 31 07:13:51 For you, the error is "when running the userspace program". This is completely vague. That program is doing a lot of things. Jul 31 07:14:49 It appears while writing to the rpmsg channels, because the firmware does its job of writing to the PRU SRAM correctly Jul 31 07:15:12 "appears" ? guessing ? Jul 31 07:16:04 no, the kernel oops message appears (shows up) Jul 31 07:16:34 if that is the case, try writing to rpmsg channel manually. The same data that the prussd "should" write. Jul 31 07:18:02 okay Jul 31 15:20:16 Hello Jul 31 15:20:57 hi abhishek_ Jul 31 15:22:05 Will be afk during the meeting today. Jul 31 16:00:21 Will be late for the meeting. Jul 31 16:03:26 julieng: could you explain the interrupt extended property of serial node: Jul 31 16:03:27 interrupts-extended = <0x00000001 0x00000000 0x00000045 0x00000004 0x00000092 0x000003f8>; Jul 31 16:19:25 interrupts-extended allows to specify interrupts that are routed to difference interrupt controller. Jul 31 16:20:32 embden_new[m]: Have a look at linux/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for more details Jul 31 16:20:46 julieng: yes, I have seen the description but the format is different from the documentation in Linux Jul 31 16:21:51 embden_new[m]: How so? Jul 31 16:23:03 * embden_new[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/uKheTvVdWcseMfMOijEbcLGX > Jul 31 16:25:46 jkridner: I tried out setting greybus gpios as reset/dc for OLED clicks and it fails with a lot of warnings, https://github.com/vaishnav98/mikrobus_device/issues/2 , Greybus SPI bus+ physical gpios works Jul 31 16:31:52 embden_new[m]: The <... ...>, <... ..> is syntatic sugar of <... ... ... ...>. So it is easier to read. Jul 31 16:32:29 hi all Jul 31 16:32:41 cwicks: hi Jul 31 16:33:07 cwicks: hi Jul 31 16:33:23 Hi all Jul 31 16:34:03 julieng: ok, though I still can't decypher it Jul 31 16:36:02 gm all Jul 31 16:36:37 embden_new[m]: It works in triplet here. The first 3 cells correspond to one interrupt. The second 3 cells to the other one. Jul 31 16:37:08 The first cells points to the interrupt controller. This is the value of the phandle. Jul 31 16:37:49 jkridner: greybus gpio + greybus spi works for OLED clicks when not using the Mikrobus module I wrote, looks like some issue with the driver, trying to fix it Jul 31 16:38:04 jkridner: hi Jul 31 16:39:53 vaishnav98_[m]: looks like that might be a warning: https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpiolib.c#L3321 Jul 31 16:40:20 seems it wants you to use the gpiod_set_raw_value_cansleep() function instead. Jul 31 16:41:09 julieng: no. The first cell is for interrupt controller (phandle), the second cell is for don't know, the 3 is int number, the third is the int type and I don't know about two others Jul 31 16:41:32 s/third/fourth/ Jul 31 16:42:05 embden_new[m]: Actually I am talking rubish. It is one quadruplet and a pair Jul 31 16:42:07 interrupts-extended = <&crossbar_mpu GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>, Jul 31 16:42:09 <&dra7_pmx_core 0x3f8>; Jul 31 16:42:40 Can we get a Mentor roll call please? Jul 31 16:44:03 julieng: how did you find out that? Jul 31 16:44:05 jkridner: thanks for pointing out will try to fix it Jul 31 16:44:57 embden_new[m]: By looking at the original Device-Tree in Linux. am57xx-beagle-x15-common.dtsi Jul 31 16:45:39 julieng: ok, thanks, but does xen utilize interrupts-extended? Jul 31 16:47:09 pratimugale: do you have a mentor active in the meeting right now? Jul 31 16:49:21 cwicks: zeekhuge is here I think Jul 31 16:49:31 he informed that he would be a bit late Jul 31 16:49:32 I am present. But limited availability. Jul 31 16:49:36 Please ping me if theirs anything. Jul 31 16:49:44 awesome - thanks Jul 31 16:49:55 I will go first in reporting in this week. Jul 31 16:50:21 Thank you to everyone for filling out the 2nd evals on time. Both students and mentors were timely in their reporting to GSoC and we really appreciate it. Jul 31 16:51:14 The channel has been really busy this week - and cwicks loves a noisy IRC room - :) Jul 31 16:52:59 As some are aware, we have decided to discontinue the "Reference Design For A GPIO-based Parallel Bi-Directional Bus" as a GSOC 2019 project. This was a well thought out decision with inputs received from Pranav and the mentoring team as well as the admins. Jul 31 16:54:35 embden_new[m]: Which version of Xen are you using? This was added in May 2019 see commit 2e9f5f7262 "xen/device-tree: Add ability to handle nodes with interrupts-extended prop" Jul 31 16:55:35 julieng: I'll answer after the meeting Jul 31 16:56:13 to not interrupt others Jul 31 16:57:18 The discontinuation of a project is something that happens to GSoC mentoring organizations at times and should not be something we feel discouraged about as everyone learned in the process. Jul 31 16:58:24 If anyone has specific questions or concerns, please feel free to drop me a email at cathy@beagleboard.org Jul 31 16:59:55 Thank you to hendersa for joining in for the remainder of GSoC and helping the other 3 projects Jul 31 17:01:08 With that, pratimugale would you please provide this week's update? Jul 31 17:03:40 sure Jul 31 17:04:44 This week I worked on solving a kernel oops message(https://pastebin.com/CbjqZbEG) that shows up when writing data values to the rpmsg_pru31 channel. It shows up only when userspace.o is run for the first time after booting the BB. After the first time, the userspace.cpp program runs without any issues. Jul 31 17:04:57 dmesg logs for both cases: https://gist.github.com/pratimugale/40ea6dbeee1a505a49b0b8b701a5a0fe#file-dnesg_samples-log-L15 Jul 31 17:09:54 The bug can be reproduced by 'rmmod'ing the "rpmsg_pru" driver before writing the data values to the rpmsg_pru channel again. Manually probing the rpmsg_pru driver after booting does not cause any error and the example (https://github.com/pratimugale/PRUSS-Bindings/tree/master/examples/firmware_examples/example9-multichannel-waveform-gen) runs correctly Jul 31 17:10:24 zeekhuge: ^ Jul 31 17:11:09 After this I have to complete the documentation, implement a dedicated driver as discussed with the mentors and do debian packaging. Jul 31 17:15:33 sorry for my typing delays today - any blockers pratimugale ? Jul 31 17:15:43 embden_new: would you like to provide your update? Jul 31 17:16:00 ok Jul 31 17:16:36 During the last week, I was able to boot till the console prompt "Please press Enter to activate this console". The bad thing is that the virtual machine doesn't receive events (doesn't receive interrupts, after Linux start booting). So, probably there is a problem in the crossbar given to Linux as is. And my task is to virtualise the crossbar some way. Jul 31 17:18:09 cwicks: the above is the blocker that I'm working on Jul 31 17:18:32 thanks pratimugale Jul 31 17:18:32 It is not really clear what does happen, julieng probably, I was wrong that the crossbar is reconfigured and that's why interrupts doesn't go though. Because I've added the uart's crossbar line into irqs-reserved and Linux shouldn't touch it, but interrupts still doesn't work Jul 31 17:19:30 julieng: embden_new anything other members of the community can contribute on this blocker? Jul 31 17:20:20 cwicks: it's not like a hard blocker - just requires some time to be resolved Jul 31 17:20:20 zeekhuge: I couldn't pin point where the error was occuring as I had to go to college after we spoke, I'm working on it now Jul 31 17:21:50 cwicks[m]: I think input from ds2, sstabellini and drhunter[m] would be helpful. My knowledge on the crossbar is somewhat limited so I can only provide input from my other experiences on Xen. Jul 31 17:24:41 julieng: https://pastebin.com/NGhykvHW do you know why this is happenning? Jul 31 17:26:00 I wouldn't say it's a blocker. It's more of an error that need to worked in side by side. Jul 31 17:26:18 It's not "block"ing anything. Jul 31 17:28:26 embden_new[m]: "d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER4" & similar are expected. Jul 31 17:28:30 right, cwicks so there aren't any major blockers right now Jul 31 17:29:06 embden_new[m]: " d0v0 Unhandled SMC/HVC: 00000031" it looks like Dom0 is trying to access the firmware which it is not allowed to access. Jul 31 17:29:53 and at that point 3 CTRL+A doesn't work already Jul 31 17:30:18 embden_new[m]: Was it working before "*** Serial input to DOM0 (type 'CTRL-a' three times to switch input)" ? Jul 31 17:30:30 yes Jul 31 17:31:25 I'll check it again Jul 31 17:32:24 embden_new[m]: Hmmm Looking at your log, you don't have earlycon enabled in Linux. So the output is getting delayed until the console is effectively setup. If you had earlycon, you should see all the "Unhandled" message interleaved with Dom0 logs. Jul 31 17:34:26 julieng: I just removed recently Jul 31 17:34:54 Hi vaishnav98_ sorry for the delay - can you give your update Jul 31 17:35:18 cwicks: Sure Jul 31 17:36:15 * vaishnav98_[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/svymCaYxirjtjQevtHahGxja > Jul 31 17:41:38 mdp: do you know if there is anything particularly odd about IRQs over greybus? the GPIOs support IRQ by the best of your understanding? Jul 31 17:41:43 jkridner : also when trying out the clicks via the greybus spi/i2c the transfers seems to be very slow, it can be directly observed when trying out the oled clicks on the Techlab cape Mikrobus port via greybus, the reset line(also connected to the Cape rgb led) resets at a very slow rate when tried via greybus, but this currently doesn't affect the performance , i.e displaying text/images works on both cases Jul 31 17:43:40 jkridner : so would it feasible (and faster) if the transfers between the physical and virtual SPI bus be handled via the Mikrobus driver? Currently it is done on gbsim side via ioctl calls, also the simulator currently doesn't support multiple physical SPI/i2C buses at the same time Jul 31 17:44:44 Have you looked at the contents of the crossbar registers to see if what you have now is what you expect? They are located at 0x4A00 2A48 (starting at table 18-736 in the TRM) and also Table 17-2 for the default mapping. I'm looking at Jan2018 version of TRM (rev J) Jul 31 17:47:56 jkridner: I was able to figure out issue with irq over greybus, the issue was with the Mikrobus_gpio driver I wrote, manually exporting the gpios and passing it via i2c_new_device call works, I tried out mpu9dof click on physical i2c bus and a greybus gpio as interrupt and it works without issues, the issue is when passing the greybus irq to a greybus spi/i2c bus Jul 31 17:50:23 julieng: hm, I also find out that it works (3 CTRL+a ) for some time: https://pastebin.com/SermvJRR Jul 31 17:50:56 jkridner: from the kernel side I know of no issues. if the remote greybus endpoint responds to the greybus gpio mask/unmask/type operations and sends he events then it should work fine. Jul 31 17:53:34 vaishnav98_[m]: well, I'm wanting to use greybus to be able to abstract the location. it could be on any of the ports on the board (through gbsim), but could also be transported over TCP/IP (per cfriedt's project) Jul 31 17:54:09 mdp: think there could be a lack of irq implementation in gbsim? Jul 31 17:54:41 I know capturing gpio interrupts from userspace is a complex endeavor.... Jul 31 17:55:05 jkridner: definitely, I don't know if anybody implemented it after I left Jul 31 17:55:07 I believe it requires creating threads with relatively complex select operators. Jul 31 17:55:28 mdp: but it wasn't there when you stopped working on it? Jul 31 17:55:34 jkridner: correct Jul 31 17:56:18 mdp : was a spi/i2c device with interrupt requirement tried via greybus ? I am able to successfully try these combinations : greybus gpio irq + physical SPI/I2C bus what fails is greybus gpio irq + greybus SPI/I2C bus Jul 31 17:56:24 jkridner: there's lots of examples for handling userspace gpio irqs via both the legacy gpio api and the libgpiod api though..totally doable. Jul 31 17:58:17 vaishnav98_[m]: not while I was there...the core protocol + SVC + I2C was my initial focus..if you can imagine early bringup these were what I was trying to mock so we could provide the kernel implementation actually worked (and debug i2c operation with a simple part, which was an at24* eeprom fwiw) Jul 31 17:59:45 mdp: agree it is totally doable, but it would take development of some threads and selects.... and if you hadn't done userspace irqs before, you have to read the examples carefully. Jul 31 18:00:48 * jkridner wishes gbsim was a kernel module. :-) Jul 31 18:01:09 ChanServ: I don't want to slow down the technical mentoring that is ongoing on the channel - but need to end the formal meeting - thank you for the extra time. Can we please close with one comment from vaishnav98_ embden_new and pratimugale on the key things you will be doing this next week. Jul 31 18:02:55 cwicks: I am going to set up the crossbar to make interrupts go through it. Jul 31 18:03:20 mdp : thanks, will try to somehow figured out the issue Jul 31 18:03:43 jkridner: indeed, anything asynchronous usually requires threads..fwiw, using libgpiod makes life a lot easier..and gpiomon is a good example and useful to poke during devel Jul 31 18:05:33 jkridner: yeah, pros/cons to userspace...it was quick and dirty as I expected it to be used for ~4 weeks max until our firmware was "done"..long story but you can probably see that it was never envisioned to be a useful tool years later ;) I'm not even sure it's so useful in incomplete form. Jul 31 18:05:37 thanks embden_new Jul 31 18:06:51 cwicks: For me, work on the documentation, study about the required driver and implement it Jul 31 18:07:56 jkridner: mdp: I was able to try out mpu9dof click which requires interrupt : by passing a greybus gpio irq to the driver and it works well on a physical i2c bus, it also shows up in /proc/interrupts , if gbsim doesn't handle gpio irq would it have worked? Jul 31 18:08:07 jkridner: I'm starting to realize that your goal is to use gbsim as the "firmware" for a linux based endpoint...I guess, yes, if I were starting from scratch, I'd implement an in-kernel consumer like you suggest Jul 31 18:09:10 mdp: I think Alexandre Bailon did the same for his TCP/IP transport demo. not sure. Jul 31 18:09:29 vaishnav98_[m]: did you have an answer for cwicks[m]? Jul 31 18:09:56 thanks pratimugale Jul 31 18:10:19 cwicks: sorry for the delay, this week I will try to work on fixing the issue with instantiating clicks with interrupt requirements via greybus Jul 31 18:10:32 thanks vaishnav98_ Jul 31 18:10:32 jkridner: sorry for the delay Jul 31 18:11:31 I want to thank everyone again for this week's check in meeting - please do not hesitate to let mentors know where you need help - we are all excited to see the projects moving forward and the rest of the summer will go by very quickly ! Jul 31 18:14:09 vaishnav98_[m]: I think what we are finding is that interrupts work fine over greybus, but gbsim isn't listening for them and generating the events back. so, you'd probably need to add interrupt listening threads on each gpio to generate those interrupts. Jul 31 18:16:05 julieng: how Linux works with hvc0? regarding a node in DT? I mean hvc0 should present somewhere as a device Jul 31 18:17:17 jkridner: yeah, so what can be happening is that however you instantiate the mpu device it's been given an irq value..otherwise the driver would fail probe every time. and the irq has a valid descriptor so the kernel side created the appropriate gpiochip with irq support. and yeah, just gbsim is not hooking interrupts for the physical device and sending the events. Jul 31 18:22:22 sstabellini: ^ Jul 31 18:22:24 jkridner mdp: thanks for explaining, I think I understand now what was happening, I will look into libgpiod as mdp suggested Jul 31 18:22:48 sstabellini: (the question about hvc0) Jul 31 19:15:42 embden_new[m]: hvc0 is not described in the DT per se. It is instantiated by default when Linux is running on Xen. Jul 31 19:42:15 embden_new[m]: yes, give a look at drivers/tty/hvc/hvc_xen.c Jul 31 20:53:14 sstabellini: and what is the difference with the xenboot? Jul 31 20:55:22 embden_new[m]: that's meant to be used for early printks at boot only Jul 31 21:04:58 sstabellini: I mean what is the difference? why is there a need for a distinct device? Jul 31 21:08:02 embden_new[m]: sstabellini: earlyprintk have to work before everything is setup. So they have to be basic. Jul 31 21:09:13 By everything, I also include the console. So you can debug without the complexity of the console subsystem. Jul 31 21:10:41 Also, while for dom0 the earlyprintk and normal console will go in the same place (i.e xen console) Jul 31 21:11:09 For guest, earlyprintk will go on Xen console (if the hypervisor allows it) and the normal console will use the PV console interface. Jul 31 21:12:59 julieng: is it possible that xenboot works and hvc0 doesn't? **** ENDING LOGGING AT Thu Aug 01 03:00:25 2019