**** BEGIN LOGGING AT Tue Jul 03 03:00:00 2018 Jul 03 05:03:28 abhishek_: jkridner Wormo : We need to discuss the *_LOG_* method for these PRUs. Jul 03 05:04:07 The ELF parsing is just technical complexity. I am still bit confused about the architecture/implimentation Jul 03 05:05:06 1st - How do we want the data to be transferred ? Do we want PRU to write it ? or the MPU to fetch it (maybe using DMA) Jul 03 05:06:23 2nd - I think we want the method to be blocking, right ? And if we use DMA to read it, then the PRU will issue an interrupt to the DMA, DMA will read it, and then issue flags to show that it has been served, and the PRU will return from the `LOG` method. Jul 03 05:06:26 Is that right ? Jul 03 05:06:56 I am not sure how CCS implemented how and how it use to work there .. Jul 03 05:08:39 muneeb17: yes. Basically, the constant parts of the log-message will be noted by the kernel module itself, and only the data elements of the message will then need to be fetched at runtime Jul 03 05:10:10 Also, I think those curcular buffers are in the kernel space. Jul 03 05:10:40 So, each time the PRU dumps something, its written over the last data Jul 03 05:11:41 zeekhuge: We could just print it to the kernel immediately, right? Jul 03 05:12:47 RPMsg can send them instantaneously - well, the implementation right now makes the PRU writes the data at some reserved location. So it consumes PRU cycles, and and the speed depends on the activity on the hardware-bus Jul 03 05:13:12 muneeb17: how ? Jul 03 05:14:57 zeekhuge: The PRU is much slower, so we could printk the message directly, no? Jul 03 05:15:49 zeekhuge: But it is better to store them, to be sure.. got it. Jul 03 05:16:45 how ? If its a constant message, why do we need to log them ? If its some data, then we need to fetch them from the PRUSS to show them in the kernel logs. Jul 03 05:18:06 I mean after formatting the message with the data Jul 03 05:18:38 *string with the data Jul 03 05:19:56 that is the thing. You do not need to fetch the whole string. If we are able to parse the ELF, we can get string from there, and then we just need the `data` part of it, which needs to be read from the PRUSS at run-time. Jul 03 05:22:15 btw, ELF parsing is better to be done in remoteproc driver. They already do it. They see if the ELF needs RPMsg support and the channel number etc, reserve buffers for them and then use all this data to probe the RPMsg driver. Jul 03 05:22:49 Am I making it bit more clear ? or more confusing ? Jul 03 05:23:29 zeekhuge: yeah.. I did get that. My question was the circular buffer. The buffer will store the pointer to the string and the runtime data, right? When the PRU sends a RPMsg we could just do the formatting instantaneously and print the message to the kernel log. Jul 03 05:24:38 The circular buffer makes sense to me, only if its there on the PRU side, which will save it some time... Jul 03 05:25:33 after recieving data at the kernel driver yeah. we can print it. Jul 03 05:29:05 zeekhuge: And I think Direct memory read will be better instead of RPMsg. These debug messages should not impact the PRU performance.. Jul 03 05:29:37 I think that will depend on the implementation. If DMA reads the data, then yeah. If PRU writes them .. the maybe no. Jul 03 05:30:01 Well, again. Do we want the method to be blocking ? if yes. Then PRU will have to wait before the data is read. Jul 03 05:30:08 even if its done using DMA Jul 03 05:30:59 And I am not sure which will be faster ... Jul 03 05:34:06 zeekhuge: Maybe we add some ordering info and make the method non-blocking? Jul 03 05:36:18 making it non-blocking might make it un-reliable .. and might lead into too many complications (for the user developing the fw, to make it reliable ) Jul 03 05:42:16 maybe we can use FIFO, but then , PRUs are also tight on memory and we will have to reserve some space and let user know that you dont have to use this space etc etc .. Jul 03 05:42:40 So .. I think this needs to be sorted out. Jul 03 05:43:05 like .. all of ^^^^^ this .. Jul 03 05:44:00 btw .. I think making it blocking makes more sense Jul 03 05:48:27 zeekhuge: Yeah.. once these things are finalised, I dont think implementation will take much time.. Jul 03 05:49:48 Can you parse ELF ? Jul 03 05:52:14 Yeah, I found some ways to do it. We need to get the .rodata part where the strings are stored.. we could get the offsets to the segments and access it. Found some code to do it but its not working. Jul 03 05:54:01 okay. look into remote proc driver Jul 03 05:55:38 https://github.com/beagleboard/linux/blob/4.1/drivers/remoteproc/pru_rproc.c Jul 03 05:55:55 https://github.com/beagleboard/linux/tree/4.1/drivers/remoteproc Jul 03 05:58:54 zeekhuge: I looked into this https://github.com/beagleboard/linux/blob/4.9-rt/drivers/remoteproc/remoteproc_elf_loader.c .. I guess we could put the format strings in a different section in the elf. It would make the retreival much easier? Jul 03 06:00:29 It would also separate the debug strings from other ones in the fw Jul 03 06:02:25 I'm confused about the pointers part, though ... could you explain how that would work? Jul 03 06:03:10 what about them ? Jul 03 06:04:40 You would pass a pointer to the string.. What address will that pointer store? Jul 03 06:05:45 The pointer to the string in the .rodata part? the PRU DRAM address where it is copied to? Jul 03 06:06:09 zeekhuge: ^ Jul 03 06:09:00 why do you need to do anything with the strings ?? they will be in the kernel space already. Jul 03 06:09:21 The pointers here are related to the data elements in that string. Jul 03 06:09:54 pointer passing from ARM to PRU?!? Jul 03 06:09:55 if the code is `Log_printf("Data1 is %d and data2 is %d", var1, var2);` Jul 03 06:10:28 then we are only concerned with the var1 and var2 pointers, not with the whole string Jul 03 06:10:44 where is that Log_printf() running? Jul 03 06:10:56 ds2: We are trying to implement the Log_printf() from CCS . Jul 03 06:11:07 zeekhuge: yes but where is it running? Jul 03 06:11:13 ds2: The PRU side Jul 03 06:11:13 like pru will do Log_printf() and print messages in the kenerl log Jul 03 06:11:53 that sounds painful to implement Jul 03 06:12:00 an exercise in MM Jul 03 06:12:04 ds2: your suggestions on it will really help. Jul 03 06:12:05 zeekhuge: We should have some way to tell that the data belongs to that string, no? Jul 03 06:12:38 who is parsing the %'s? Jul 03 06:12:51 The kernel side Jul 03 06:12:57 keep in mind the kernel is running in an MMU Jul 03 06:13:18 so addresses from the PRU will need to be manually xlated into MMU addresses Jul 03 06:13:57 ds2: we want the kernel to parse the string and use pointers to get the data from PRUs at runtime. Jul 03 06:14:26 zeekhuge: I get that part... just pointing out there is address xlation needed in SW Jul 03 06:15:34 implementing ("%s", str) cannot be done with while(*str != '\0'){putchar(*str); str++} in K-space if str is coming from Jul 03 06:15:39 PRU Jul 03 06:15:53 muneeb17: I think that can simply be sequenced. And kernel will have to remember these belong to those etc .. Not sure but I guess can be done that way . Jul 03 06:16:12 str will be either a P-address or an offset from one of the segments in the PRUSS Jul 03 06:16:32 and DRAM offsets change depending on which PRU it came from Jul 03 06:20:36 We probably should not even support str . Jul 03 06:20:44 in Log_printf() Jul 03 06:20:54 I dont see any use of it. Jul 03 06:20:54 zeekhuge: I dont understand why we need pointers if that can be sequenced. We could fix the arguments to a specific number(say 3) and make the PRU pass the data in the buffer in that order. Ther kernel side could simply read that and printk it Jul 03 06:21:11 PRUs dont read strings. They read data .. like 32 bit data .. Jul 03 06:21:37 what % formatters are you thinking of supporting? Jul 03 06:23:38 Whatever fits into the 32 bit data field. All types will be cast to 32-bit. Jul 03 06:24:18 sounds expensive on the PRU Jul 03 06:24:49 "%02x%02x%02x%02x" for one Jul 03 06:25:16 and does CCS support casting bitfields to 32bit data? Jul 03 06:30:32 muneeb17: wait ! can we use those debug features to do this ? Jul 03 06:31:24 zeekhuge: which debug features? Jul 03 06:33:30 the `regs` command Jul 03 06:33:37 from the remoteproc Jul 03 06:34:48 Will have to leave now ... Jul 03 06:34:49 later. Jul 03 06:36:30 the debug commands like `regs` and `single_step` Jul 03 06:36:31 etc Jul 03 06:37:50 zeekhuge: yeah, we could use that for casting bitfields, I guess Jul 03 06:48:06 zeekhuge: We have to do it on the PRU side only, so I don't think so Jul 03 08:02:52 abhishek_ zeekhuge : I dont understand why we need pointers if the format strings and the data can be sequenced. We could fix the arguments to a specific number(say 3) and make the PRU pass the data in the buffer in that order. Ther kernel side could simply read that and printk it Jul 03 08:05:51 I will be only able to give my comments after 6 pm IST today. Jul 03 08:07:01 abhishek_: ok, I will be here around 6 Jul 03 15:39:09 Hi, ping muneeb17 and zeekhuge Jul 03 15:39:12 Wormo: around? Jul 03 15:41:07 Here's what I think: Jul 03 15:41:29 (regarding the PRU printf implementation) Jul 03 15:44:11 We know that (i) it has to be fast and (ii) minimal impact on the runtime. Jul 03 15:46:02 The kernel could either read from a kernel space circular buffer (in DDR) or access the PRU memory directly. Jul 03 15:47:28 If it is to access PRU memory, it should know the location of the strings and all the variadic arguments Jul 03 15:48:26 We could get that information inside of the function call in the PRU and by reading about the PRU calling convention Jul 03 15:50:45 Another way of doing it will be to do a strcpy to the circular buffer and let the kernel handle the printing Jul 03 15:51:57 So we are looking at O(n) time to print the message, the larger the message, more time to perform the memory copy. Jul 03 15:56:12 (Questions to answer: How does the PRU compiler handle strings? Does it ever touch the PRU instruction memory? Or it is straightaway loaded into the Data SRAM of the PRU?) Jul 03 15:58:25 The shortest method, however, would be to reuse the existing RPMsg infrastructure to send messages on a different channel Jul 03 15:59:58 Send the format string, and the variadics as a RPMsg onto a separate channel that has its own kernel driver that receives messages and dumps it on the log Jul 03 16:03:11 Disadvantages of this approach: the use of RPMsg and you can't place printf's in the critical path of your code (for example, timing sensitive parts) Jul 03 16:04:41 But the second disadvantage applies to almost any printf implementation Jul 03 17:31:38 was not there yet, on a conf call now, will try to read over before I have to head out Jul 03 18:11:08 abhishek_: So, no kernel side parsing of elf? Jul 03 18:13:55 Also, regarding the PRU compiler string handling, the strings are stored in the .rodata section of the elf and that section is copied into the PRU DRAM as specicfied in the linker command file. **** ENDING LOGGING AT Wed Jul 04 03:00:04 2018