**** BEGIN LOGGING AT Mon Jun 25 03:00:04 2018 Jun 25 06:41:32 muneeb17[m]: was afk on weekend. I can look later on my bbb if it works, but I do not guarantee that it does, the wip stuff I did just for testing and did not foucs on it too much, the actual implementation of the project is different (dma configured on PRU via resource table and transfers managed by PRU, as descirbed in Documentation) Jun 25 07:07:14 muneeb17: you reported that you tried DMA project before GSoC started. What was the configuration used then ? What has changed since ? Jun 25 07:13:43 maciejjo: Ok, please update me when you try it. Jun 25 07:16:30 zeekhuge: I didn't actually try out the transfers with the examples, just made sure that the dma driver is up and running. Anyways, In this example the transfers need to be managed on the Linux side, so it is independent of the DMA project (in which PRU configures the eDMA). Jun 25 07:20:34 muneeb17 : I didn't get it. Jun 25 07:20:34 First, What is "this example" ? The WIP work in the DMA repo ? Jun 25 07:20:35 Second, what do you mean by "managed on Linux side" ? Is it like completely independent of PRU ? I don't think that it's or should be possible. Jun 25 07:21:43 zeekhuge: We decided to implement the Data Memory/Shared memory functions in the API using DMA instead of mmap() as discussed before. Jun 25 07:22:22 Btw .. on a different note, how is " didn't actually try out the transfer with examples" supposed to be reported as "I successfully tried it" ? Jun 25 07:24:58 zeekhuge: Sorry about that.. I thought you wanted me to compile and load kernel onto BBB with the DMA patches. Jun 25 07:30:41 zeekhuge: I am talking about this example specifically - https://github.com/maciejjo/beaglebone-pru-dma/tree/master/wip/pru_dma_test which can be implemented instead of mmap() Jun 25 07:37:08 muneeb17: you have modified the PRU code to work with DMA . Right ? Jun 25 07:38:05 PRU needs to raise signals to DMA. You are raising those ? Right ? Maybe that's what the "Timeout" error is ? Jun 25 07:39:26 Like this : Jun 25 07:39:26 https://github.com/maciejjo/beaglebone-pru-dma/blob/master/examples/01_leds/firmware/pru1_fw.c Jun 25 07:41:26 Which will require patches from pru-swpkg-patch, and using the code from 'firmware' dir Jun 25 07:41:38 zeekhuge: That's a different thing. What I'm doing is configuring the eDMA to do memory transfer from the kernel buffer to the PRU Data Memory directly.. this is not related to the DMA project. Remember the discussion we had to use DMA instead of mmap() for writeDataMem() and readDataMem() functions in our API. This should just be a trivial use case of the eDMA. Jun 25 07:43:37 Got it. Jun 25 07:44:06 Seems like there is delay in messages. Sometimes .. matrix just sucks . Jun 25 07:44:23 zeekhuge: yeah, it's seriously annoying Jun 25 07:50:07 zeekhuge: everything happens properly, the DMA channel is acquired and configured but just the actual transfer doesn't happen. Can you try running the module once on your board when you are free? Jun 25 10:09:52 muneeb17: there ? Jun 25 10:10:15 to run it on the board, will take time for me .. I will have to do a complete setup .. Jun 25 10:10:23 uhm .. I was looking at the code ... Jun 25 10:10:33 zeekhuge: here Jun 25 10:10:51 can you just try to use `devm_kzalloc` to allocate an extra memory and use it as the destination ? Jun 25 10:11:05 and let all other things in the code be same .. Jun 25 10:11:07 including the channels Jun 25 10:11:46 that would be a Ram to Ram transfer ... but will test if the things are wrong in the dma setup or in the PRUSS part Jun 25 10:12:24 I would need to change MEM_TO_DEV to MEM_TO_MEM too i guess. Jun 25 10:13:04 zeekhuge: I tried this too: https://github.com/maciejjo/beaglebone-pru-dma/tree/master/wip/dma_test and its not working too Jun 25 10:13:16 oh yes ! that too ! Jun 25 10:13:16 RAM to RAM transfer Jun 25 10:13:34 what was the error with next one ? Jun 25 10:14:14 next one is RAM to RAM transfer Jun 25 10:14:17 Same thing, the DMA transfer is not happening Jun 25 10:14:21 yeah .. Jun 25 10:14:40 gets timed out and no callback output Jun 25 10:15:41 abhishek_: any idea why this is happening? Jun 25 10:16:59 zeekhuge: can something be wrong with the dts Jun 25 10:17:00 what is the edma's highest priority ? Jun 25 10:17:26 change <&edma 20 > in the dtc Jun 25 10:17:33 *dts Jun 25 10:17:52 2. I tried putting dmas = <&edma 2> also but its not happening Jun 25 10:18:08 *20 2 Jun 25 10:18:14 just to clarify that should be prority number there Jun 25 10:18:22 zeekhuge: ^ Jun 25 10:18:46 no ! Jun 25 10:18:54 the first is the channel number, next is the priority Jun 25 10:19:00 oh ! okay Jun 25 10:19:00 got it Jun 25 10:19:16 * zeekhuge agrrr ! message delays Jun 25 10:19:56 yeah.. Jun 25 15:34:05 jkridner, abhishek_: As, I was using the same rndis header for this cdc-ecm interface. I thought that's the cause for the device not responding to dhcp, arp. But, I can't find header structure for the same anywhere. I looked into usb cdc ecm specs document as well Jun 25 15:35:13 the header size is same though as I can parse the payload from received packet by setting offset for rndis size Jun 25 15:35:59 I'm still not sure if this is the real issue here Jun 25 15:36:26 I tried dhcp directed as well as broadcast, no success Jun 25 15:47:30 Is the packet checksum being computed? Jun 25 15:49:00 Also, is it CDC ECM only? You mentioned that there is also CDC EEM and other standards Jun 25 15:53:13 abhishek_: the ipv4 packet checksum is correct and since udp checksum over ipv4 is optional, it's set to zero Jun 25 15:54:42 abhishek_: yes, read bunch of usb cdc spec documents, and figured out from interface descriptors that there's only ecm Jun 25 16:54:55 vaishnav98_: 2 great pull requests.... gave some comments. Jun 25 16:55:37 vaishnav98_: big question to me is if express sessions should be used or just do some authentication in socket.io..... for the Buster images, I don't expect we'll server any of the static content. Jun 25 16:56:27 vaishnav98_: ....so, the Express stuff is largely redundant there... in general, I want to move away from BoneScript from being a web server and simply make it an RPC server. Jun 25 16:56:50 ....but we should have authentication around that RPC server. Jun 25 16:57:43 Are we sending passwords as open-text right now? I'd like to eliminate that. Jun 25 16:58:17 For Buster, nginx is running the HTTP server and I expect we'll enable HTTPS at some point. Jun 25 17:08:42 jkridner: I have been going through your comments , will reply to each of them soon, if none of the static content will be served in future , then authentication in socket.io seems the best for the purpose, I will change the current implementation for that, currently the passwords are send as basic authentication headers , how should I modify it for better security ? Jun 25 17:25:38 abhishek_, jkridner: is it possible to debug this on debian end on beaglebone, why it's not responding to requests? Jun 25 17:26:06 I'd think wireshark would work on BeagleBone too. Jun 25 17:39:11 trying this https://www.elinux.org/ECE497_Project_WireShark Jun 25 20:13:52 jkridner, abhishek_: I used tcpdump on debian (beaglebone) to confirm that it's receiving the dhcp request on usb0, no there's no issue with the rndis header used Jun 25 20:13:58 * ravikp7 sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/eZpnIIWCUnOzarcaIjQTpYqu > Jun 25 20:15:12 *so there's no issue with the rndis header **** ENDING LOGGING AT Tue Jun 26 03:00:02 2018