**** BEGIN LOGGING AT Fri Jun 14 02:59:58 2019 Jun 14 03:12:50 pratimugale (@pratimugale:matrix.org): try cleaning up your original code. Jun 14 08:41:40 I will just use for the highest reveision (revC). Jun 14 08:50:08 embden (@embden:matrix.org): why don't you use the DT provided with the board? Jun 14 08:56:48 embden[m]: I mean the goal of Device-Tree is to describe the platform and should not depend to your Linux kernel. I would hope that on the x15, this is the case. Jun 14 08:57:23 julieng: revc one is working. Jun 14 08:57:36 it was just easier to get Jun 14 08:58:22 julieng: right now, I don't know what bootargs to pass to the kernel Jun 14 08:58:54 this is what I can see when booting without any; Jun 14 08:58:55 Kernel command line: androidboot.serialno=0c0090136d0c0002 console=ttyS2,115200 androidboot.console=ttyS2 d... Jun 14 09:00:35 embden[m]: the androidboot.* parameters should not be necessary in your cases. A typical command line "console=<...> root=<...> earlycon=<...>" is usually enough Jun 14 09:03:15 embden[m]: You can copy the value from the default command line. I guess the command line is embed in U-boot environment. Jun 14 09:06:12 julieng: ok, right now I was able to boot and there is a kernel failure when it tries to mount rootfs Jun 14 09:07:10 embden[m]: Can you post your the log on pastebin and copy the link here? Jun 14 09:09:23 https://pastebin.com/a9kXjdbq Jun 14 09:09:23 julieng I also don't understand what size to write in initrd. I wrote 32M, but my compressed image is 22.9M Jun 14 09:15:11 embden[m]: If you are download the size from tftp, you can use $filesize to know the correct size. In general, in testing environment, any size that is bigger than your initrd is OK. Jun 14 09:15:35 Xen will copy as is the 32MB to Dom0 memory. Jun 14 09:31:06 embden[m]: pastebin -> It looks like the problem is root=<...> is not configured correctly. Where is your root? Is it in the initrd or on the mmc? Jun 14 09:31:06 julieng: it is in the initrd **** BEGIN LOGGING AT Fri Jun 14 09:32:19 2019 Jun 14 09:33:20 julieng: the same result. Jun 14 09:35:49 embden[m]: I don't use the initrd very often. I tend to directly use the rootfs from the mmc. Maybe ds2 or sstabellini can help here? Jun 14 09:54:57 julieng: I think I was able to boot it to a promt..but...I rebuilt the busybox and now I get those lines appearing all the time : can't open /dev/tty2: No such file or directory Jun 14 09:57:05 I think it is something related to mdev Jun 14 09:57:17 I will ask it in busybox irc Jun 14 10:42:47 julieng: so, now it works to some extent. Jun 14 10:55:18 embden[m]: Some extent? out of curiousity, what was the problem? Jun 14 10:58:47 julieng: I mean that it works but I don't know how well it works. Jun 14 10:58:48 And the problem was that /dev wasn't populated, so, I add the line to rcS: mount -t devtmpfs -o rw,dev,nosuid,noexec,noatime,size=0 devtmpfs /dev Jun 14 11:00:59 zeekhuge: I did some cleanup, what should I work on now? Jun 14 11:01:25 embden[m]: That should be enough for bringing up Xen on the x15 (at least just Dom0). Jun 14 13:39:30 abhishek_: How is work to be continued from https://github.com/MuneebMohammed/PRUSS-Bindings Jun 14 13:43:30 pratimugale: there was a lot of basic stuff done there that you had to pick up - for example look at https://github.com/MuneebMohammed/PRUSS-Bindings/tree/master/prussd Jun 14 13:44:13 You've practically recreated it in C. Jun 14 13:44:22 Yes, I will be using the daemon service now Jun 14 13:48:28 The advantage of having a daemon is that userspace apps don't need to deal with root permissions, although restricting access to the socket is necessary - but that will come at a later stage. Jun 14 13:49:11 Yes, because the rpmsg module can't be probed from the c program directly Jun 14 13:49:58 Correct, it's invoked by the PRU kernel driver that probes rpmsg if there's an entry in the resource table of the PRU firmware. Jun 14 13:51:41 I assume that you are familiar with what the resource table is and how to customize it. If you're not, you need to go back and understand it - it should have ideally happened in the community bonding period. Jun 14 13:53:55 I did read read about resource tables Jun 14 13:56:28 But I didn't understand exactly how to modify it Jun 14 13:56:29 Have you tried creating a small rpmsg application on the PRU side and established communication between your API and the PRU Jun 14 13:56:45 and resource tables were available with the examples Jun 14 13:56:57 Yes Jun 14 13:58:16 hmm, you have copied the example as-is Jun 14 13:58:36 Try customizing it and play around with it Jun 14 13:59:34 Okay, Jun 14 14:00:11 How familiar are you with embedded electronics? Have you worked with protocols like UART, SPI etc? Jun 14 14:04:23 I haven't used the protocols, although I went through them while applying https://www.bits-pilani.ac.in/pilani/deveshsamaiya/eeeg547 Jun 14 14:05:25 This is related to the Linux kernel. The project is about PRU userspace so kernel is out of scope here. Jun 14 14:06:44 The PRU is designed for handling I/O tasks efficiently Jun 14 14:09:54 When I was doing my GSoC with BeagleBoard 5 years ago, I thought a logic analyzer would be a really good use of them and that became my SoC project. I'd suggest that you try something that appeals to you and find a way to involve PRUs there. Figure it out, you don't have to come up with an answer right away. But you should meet your targets for the first evaluation period. Jun 14 14:11:30 So like using the SPI, UART protocols with the PRU? Jun 14 14:13:02 That's just an example. Try and come up with more use-cases yourself. Jun 14 14:13:44 But this will be like an example right? Jun 14 14:14:16 Yes, creating an API without examples on how to use it would be dry. Jun 14 14:14:17 which will use the api functions Jun 14 14:14:32 Got it Jun 14 14:14:57 API is a simple thing, but there should be ample examples available so that others can pick up and use it Jun 14 14:15:39 You've gotten so far, ask yourself, what kind of examples would you like to see that would have made your job easier? Jun 14 14:15:42 Can I try something like a standardized PID controller Jun 14 14:15:53 which will be ready to use Jun 14 14:15:59 Why not? Jun 14 14:17:16 okay, I will also go through the logic analyzer and think about other examples Jun 14 14:18:58 There is a silo of PRU knowledge sitting in only a few people's heads (including yours). The idea is to pour out the knowledge so that no more silos form - no one who has to start using the PRUs should have start from zero and figure it out every summer. Jun 14 14:20:23 hmm, so writing real world examples would be much better than the test demonstration examples for better understanding Jun 14 14:21:50 Come up with ideas on how you would like to proceed next, and let's discuss again with zeekhuge . Jun 14 14:23:17 Also talk to pranav_kumar - if he's stuck with PRUs, help him out. Jun 14 14:24:48 Okay, I'll get started right away Jun 14 14:25:27 Sure, we have been communicating over email Jun 14 14:25:59 Good to know :) Jun 14 15:04:30 pratimugale: When would you like to discuss the ideas that you come up with? Jun 14 15:39:43 embden[m]: that's normal, it's probably because somewhere it's set to open tty2 but actually it is not present on the system Jun 14 15:44:21 sstabellini: Jun 14 15:44:21 ogrh, sorry Jun 14 15:45:29 sstabellini: the problem is the default boot order in busybox. it tries to access ttys by default and fails because the /dev is not populated. So, I mounted /dev and changes the default behavior. Now, it works Jun 14 15:45:54 embden_[m]: good to hear Jun 14 16:45:22 abhishek_: Tomorrow ? **** ENDING LOGGING AT Sat Jun 15 02:59:57 2019