**** BEGIN LOGGING AT Wed Aug 09 03:00:00 2017 Aug 09 06:37:22 jkridner: I'm checking a byte (4th) of the packet received for requests, the byte for tftp request for file transfer depends upon the length of the file name, so just using that Aug 09 06:40:24 jkridner: just a random byte which is different for all requests, just observed that in that byte, it depends upon the file name length. I didn't refer the packet header format for that as things worked this way Aug 09 06:56:18 jkridner: the UDP packet received during TFTP request, is used for TFTP reply, so made global, infact other parsed packets like ether are also made global to be acccessible by other request handlers Aug 09 06:57:17 jkridner: I've got sudo-prompt working in my app with the help of etcher developer Aug 09 07:04:24 jkridner: is identify request clear to you now? and I don't understand what do you mean by "I need to parse the tftp request filename" ? Aug 09 07:05:57 ravikp7: random is not good. there are direct ways to parse the packets. Aug 09 07:07:06 ravikp7: for a task I'm doing, I would like to be able to have u-boot tftp multiple files.... Aug 09 07:07:13 that means parsing the name of the requested file. Aug 09 07:07:15 I added it. Aug 09 07:08:02 jkridner: the code take care of parsing the file name Aug 09 07:08:26 jkridner: you checked the api for multiple file transfer? Aug 09 07:09:32 jkridner: why you added that? I've all implemented in code Aug 09 07:10:15 the "multiple file transfer" relies on different VID/PID and isn't using the requested filename. Aug 09 07:10:32 the RRQ packet contains the TFTP requested filename. Aug 09 07:11:20 jkridner: the api requires vid, pid and file path, it extracts filename from filepath and parses it Aug 09 07:11:26 so, if I want the same client to perform multiple TFTPs (or use the same VID/PID for both SPL and u-boot, which it does in the case of tftp), then I need to check the filename requested. Aug 09 07:11:58 the filepath is just for the file to transfer, it doesn't have anything to do with the file REQUESTED by the client. Aug 09 07:12:22 you aren't looking at the requested file, except maybe at the length. I looked all over that. Aug 09 07:13:20 jkridner: yeah, not looking for a requested file, I just implemented the way it was for BBBlfs Aug 09 07:13:53 yeah, that code was too limiting for many use cases. Aug 09 07:14:39 btw, one nice feature of your code is we should be able to migrate it to https://developer.chrome.com/apps/app_usb Aug 09 07:15:09 jkridner: and I'm inexperienced to think of that cases, please guide me for that Aug 09 07:15:09 also, I was thinking that since we can do general control transfers, why can't we initiate a control transfer in windows to set the configuration? Aug 09 07:15:45 ravikp7: just try to make the routines as general and stateless as possible, then integration with other use cases is simple. Aug 09 07:15:46 jkridner: that was already in my mind, that web usb api :) Aug 09 07:16:17 ravikp7: see https://flash.getchip.com/ Aug 09 07:18:17 I've been playing with many scenarios, including netconsole. so there are protocols other than bootp/arp/tftp that are rather interesting. Aug 09 07:18:51 the FIT image thing is fine, but still a pain. Aug 09 07:19:05 jkridner: cool, we can get similar flash web app :) Aug 09 07:19:16 doing tftp of each of a device tree, kernel and ramdisk is easier if they are separate. Aug 09 07:19:24 ravikp7: if you make it. ;-) Aug 09 07:19:41 ravikp7: it isn't 'flash', it is a Chrome plug-in. Aug 09 07:19:51 using https://developer.chrome.com/apps/app_usb Aug 09 07:20:14 I noticed that doesn't have setConfiguration, so that'd have to be done on top of control transfers. Aug 09 07:20:17 jkridner: sure, yeah, I meant flashing app, not flash ;-) Aug 09 07:20:36 oh right. I understood that for a second before my mind went off. Aug 09 07:22:41 jkridner: I'm currently juggling between server integration with app and adding features in server code. And only 3 weeks left for gsoc coding period, if you can please guide me to priortize the tasks Aug 09 07:25:36 I'd say you want to make sure your code is clean and all bugs/limitations are well understood. Aug 09 07:25:56 it is more important that you preserve what you've already accomplished than to try to accomplish more. Aug 09 07:26:15 because when GSoC ends, your time on this will go way down. Aug 09 07:26:28 and having a good base folks in the community can build upon is critical. Aug 09 07:27:02 so, I'd focus on bugs, code clean-up and documentation. Aug 09 07:27:28 jkridner: sure, I understand. I also think same. Aug 09 07:27:35 desired features (such as handling compressed images and downloading images) should be documented well along with what stopped you from getting there. Aug 09 07:28:49 I think if you record a couple videos of the app in action, you might improve your understanding of user issues. Aug 09 07:29:01 plus, you'd be able to show off the app. Aug 09 07:29:17 jkridner: any additions/changes to server code for now? Aug 09 07:29:52 I'm trying to figure what of my changes I should share back. Aug 09 07:30:49 jkridner: can I add a tag like "Powered by etcher by Resin.io" to the app footer. I think that way we can expect more help from etcher community by promoting them Aug 09 07:32:54 I like that. Aug 09 07:53:02 Whoa, 4AM! must sleep Aug 09 15:38:27 pmezydlo: did you post your weekly report on the mailing list? Aug 09 15:44:27 m_w: yes, right now Aug 09 15:49:16 okay Aug 09 15:59:34 hi Aug 09 16:00:28 hi all Aug 09 16:00:40 hi Aug 09 16:01:00 hi Aug 09 16:01:23 hi everyone Aug 09 16:07:31 moin Aug 09 16:07:39 slow week? Aug 09 16:08:05 a bit... Aug 09 16:08:07 yeah for me :| Aug 09 16:10:01 hmmm Aug 09 16:12:36 who's running the mtg? Aug 09 16:13:20 nerdboy: since in absence of av500: Aug 09 16:13:37 you can.... Aug 09 16:14:08 again? Aug 09 16:14:19 nerdboy: he sent out a mail Aug 09 16:14:35 he will be out today Aug 09 16:14:41 then headcount! Aug 09 16:14:49 o/ Aug 09 16:15:01 +1 Aug 09 16:15:03 present Aug 09 16:15:08 hi I'm here Aug 09 16:15:16 +1 Aug 09 16:15:36 ee wrote in his report he will not be able to participate Aug 09 16:15:37 ee said he wont be here today Aug 09 16:15:52 then 5 it is... Aug 09 16:16:23 * nerdboy didn't memorize the agenda... Aug 09 16:16:35 ee? Aug 09 16:16:44 reports are in? Aug 09 16:16:51 pmezydlo: see above Aug 09 16:17:13 yeah sorry Aug 09 16:17:39 i see 6 it looks like Aug 09 16:19:20 who's on first? Aug 09 16:19:32 I can go first Aug 09 16:20:33 IIRC it will be me and indu this week giving reports Aug 09 16:21:35 yes Aug 09 16:22:00 maciejjo: you have the stick Aug 09 16:22:10 ok, lets go then ;) Aug 09 16:22:24 just to remind, my project is BeagleBone PRU DMA support. It has PRU firmware and kernel module for ARM side Aug 09 16:22:38 since last report most of my work has been done on kernel module side Aug 09 16:22:51 I refactored it so now it serves as a kind of framework for other modules Aug 09 16:23:03 it is located here: https://github.com/maciejjo/beaglebone-pru-dma/blob/master/kmod/pru_dma.c Aug 09 16:23:20 After loading it doesn't do anything except buffer allocation, but exports all functions to be used by modules for specific applications Aug 09 16:23:36 This is illustrated by examples, which now contain their own kernel modules making use of the main pru_dma module Aug 09 16:24:05 I added data aquisiton example, which reads measurements from an hcsr04 sensor connected to PRU pins to local buffer and transfers via DMA to main memory Aug 09 16:24:14 It is located here: https://github.com/maciejjo/beaglebone-pru-dma/tree/master/examples/02_sensor Aug 09 16:24:29 kernel module has a read-only sysfs parameter which blocks until tx is complete and calculates mean value of the measurements and presents it to user Aug 09 16:24:51 each example consists of 3 parts: kernel module which uses pru_dma framework; pru firmware which includes pru_dma_lib; dts file for pins configuration and pru-dma configuration parameters Aug 09 16:25:26 I will be adding some more examples in following weeks Aug 09 16:25:56 maciejjo: any plans to measure performance? i.e. does this slow the PRU in some way? Aug 09 16:27:20 it should not have much impact on PRU becasue I am only polling for INTC event in PRU when waiting for transfer completion Aug 09 16:27:28 and this should not be much overhead Aug 09 16:27:56 but performance measurement will be implemented Aug 09 16:28:04 as example application Aug 09 16:28:15 ds2: ^^^ Aug 09 16:28:17 the leds and resistors are pretty easy for someone to figure out but wiring example is always helpful... Aug 09 16:28:31 going to add more docs later? Aug 09 16:28:58 yes but the DMA engine reads from the PRU RAM... does that cause the PRU to stall if there is a collision? or is DMA guarantee to stall til the PRU is done? Aug 09 16:30:02 ds2: fair point, I must see in TRM if this is mentioned there... Aug 09 16:30:41 nerdboy: yes documentation will be added for building & incorporating in other projects Aug 09 16:33:28 non-trivial examples also? Aug 09 16:33:55 yes, I still have time for more advanced examples Aug 09 16:34:01 i guess we started kinda late; any more questions/issues? Aug 09 16:34:29 * nerdboy has mtg #2 coming up... Aug 09 16:34:51 *questions for maciejjo i mean Aug 09 16:35:49 yeah, if that is all then thank you for attention and I give the stick back :) Aug 09 16:36:07 going once? Aug 09 16:36:42 sold Aug 09 16:37:12 * nerdboy hands the stick to indu Aug 09 16:37:27 Thank you Aug 09 16:37:36 As mentioned in the weekly report, the implementation parts are almost done. Aug 09 16:37:55 I have started testing and bug fixing.The basic flow of the driver is tested in non real time using aplay and arecord ALSA utilities. Aug 09 16:38:35 The ALSA driver can be found here : https://github.com/induarun9086/beagleboard-linux/blob/4.4/sound/drivers/avb.c Aug 09 16:38:51 brain-fart.... missed most of the meeting. ping me if you need me. Aug 09 16:39:20 The further tasks are to create a test application and a test setup to test the real time sync audio playback. Aug 09 16:39:54 The test setup involves 1 bbb as a transmitter 1 bbb as a avb loopback device. The first bbb streams the original and the loopbacked stream to a test pc where time sync could be measured. Aug 09 16:40:23 With the testing I hope to fix the bugs and improve the software. Aug 09 16:40:51 In parallel I will start updating the detailed doc. Aug 09 16:40:53 l would test that... Aug 09 16:41:17 as long as i can replicate the setup from the docs Aug 09 16:41:42 Aug 09 16:41:53 i got tht Aug 09 16:41:57 ok I will complete the documentation with all the required steps to replicatethe setup Aug 09 16:42:25 thanks, I'd also try Aug 09 16:42:30 * nerdboy hopefully not being too subtle Aug 09 16:44:12 any other questions or suggestions? Aug 09 16:46:59 going once? Aug 09 16:47:57 i didn't see anything blocking you two; anyone else have blocking/other issues? Aug 09 16:48:18 all good here Aug 09 16:48:30 nope Aug 09 16:50:04 ravikp7: I tried your server as you said , I started server and connected the usb cable while pressing power button on bbb Aug 09 16:50:18 but it still showed waiting for device Aug 09 16:50:54 thetransformerr: you held down the s2 button? Aug 09 16:51:24 I thought boot button was pwr Aug 09 16:51:37 okk let me try with s2 Aug 09 16:51:48 yeah, no problem :) Aug 09 16:53:35 * nerdboy trying to remember _av500_ agenda items Aug 09 16:53:40 * thetransformerr[ uploaded an image: Screen Shot 2017-08-09 at 10.23.09 PM.png (217KB) Aug 09 16:54:03 the emmc should get mounted now Aug 09 16:54:09 who's on for reports next week? Aug 09 16:54:33 me and ee are up next week Aug 09 16:54:36 pmezydlo: and ravikp7 : i guess Aug 09 16:54:42 sorry Aug 09 16:55:43 thetransformerr: so, testing complete, it's working. thanks :) Aug 09 16:56:37 okay, don't forget to push early/often (coherent commits) Aug 09 16:56:55 okk and should emmc appear as usb storage drive because, I just had this message Aug 09 16:57:02 * thetransformerr[ uploaded an image: Screen Shot 2017-08-09 at 10.25.24 PM.png (45KB) Aug 09 16:57:13 * nerdboy rings the end-of-mtg gong Aug 09 16:57:19 yeah, it's all good Aug 09 16:57:28 may be no partitions is the reason Aug 09 16:57:31 okk Aug 09 16:57:46 as you say :) Aug 09 16:58:33 sorry, got back late toady. Will see tha logs. maciejjo - is your weekly report out there ? Aug 09 16:59:29 zeekhuge: yes, it is Aug 09 17:02:54 maciejjo: what about the configuration parameters we discussed about ? Are they still been separately sent to the PRUs ? Aug 09 17:04:39 zeekhuge: yes, this is still in progress, I have patched kernel to add custom resource parsing for DMA parameters but didn't yet got it to work Aug 09 17:05:19 okay, is the code somewhere in the wip dir ? Aug 09 17:05:23 maciejjo: ^ Aug 09 17:07:17 no I didn't commit it as it is not a part of project but changes to kernel, but I will push it to repo to show you Aug 09 17:08:08 I am not at my workstation atm, I will ping you when it will be available Aug 09 17:31:24 maciejjo: Okay, just add it as the patch Aug 09 17:31:43 and mention the reference in a README Aug 09 22:01:24 * nerdboy back from the dentist **** ENDING LOGGING AT Thu Aug 10 03:00:01 2017