**** BEGIN LOGGING AT Wed Jun 27 03:00:02 2018
Jun 27 14:34:02 <zeekhuge> muneeb17: there ?
Jun 27 14:39:20 <muneeb17[m]> zeekhuge:  here
Jun 27 14:40:40 <muneeb17[m]> did you see the mail?
Jun 27 14:41:32 <zeekhuge> muneeb17: I'd suggest to use RPMsg for now.
Jun 27 14:42:01 <zeekhuge> Actually .. I was thinking .. that ARM to PRU can be done using RPMsg and PRU to ARM using DMA
Jun 27 14:42:10 <zeekhuge> But that will be too much ....
Jun 27 14:42:20 <zeekhuge> And .. DMA is still not merged ..
Jun 27 14:42:47 <muneeb17[m]> yeah.. to many different parts
Jun 27 14:42:48 <zeekhuge> So it will make more sense to use RPMsg
Jun 27 14:42:49 <zeekhuge> Which is always present there ..
Jun 27 14:43:50 <zeekhuge> I'll try to get into DMA thing soon .. and let's see if we can fix that. But for now .. and since RPMsg is already in kernel, should use RPMsg
Jun 27 14:45:17 <muneeb17[m]> zeekhuge:  Ok. What about the PRU memory functions
Jun 27 14:48:02 <zeekhuge> First .. i don't think the ARM should be allowed to arbitrarily read any data part of the PRUs without PRU knowing and actually signalling to start this transfer
Jun 27 14:48:19 <zeekhuge> That won't make real sense .. since the data can be incomplete etc
Jun 27 14:48:41 <zeekhuge> So .. these memory read functions will always be dependent on the PRU code.
Jun 27 14:50:51 <zeekhuge> And .. I think there is already RPMsg based data read methods in the daemon . Right ?
Jun 27 14:51:44 <zeekhuge> abhishek_: ^
Jun 27 14:52:32 <muneeb17[m]> zeekhuge:  Yeah.
Jun 27 14:54:27 <muneeb17[m]> zeekhuge:  abhishek_ :  So should I pause DMA for now and move on to the LOG_printf() thing?
Jun 27 14:55:15 <muneeb17[m]> Meanwhile you can look into the DMA issues
Jun 27 15:27:59 <abhishek_[m]> Okay
Jun 27 15:49:11 <muneeb17[m]> zeekhuge: abhishek_ : Not very sure about the implementation of the LOG_printf() as it is there in the CCS. Any insight on how to use it for RPMsg?
Jun 27 15:50:27 <abhishek_[m]> Maybe jkridner has some comments on Log_printf?
Jun 27 15:51:06 <jkridner> yup.... it is a pretty cool feature of CCS.
Jun 27 15:52:02 <jkridner> it is done via a circular buffer with fixed-sized writes...
Jun 27 15:52:36 <jkridner> you always have 32-bit data values, if they are floating point, pointers, integers, whatever, they are always cast into a 32-bit field.
Jun 27 15:55:04 <jkridner> The format strings are extracted from the binaries and presented as pointers in the circular log.
Jun 27 15:55:31 <abhishek_[m]> And where is the output of log_printf printed?
Jun 27 15:57:12 <jkridner> I'd expect you to print it in the kernel log.
Jun 27 15:57:39 * jkridner doesn't know a lot about how RPMsg works.
Jun 27 15:57:54 <jkridner> Where do the message handlers typically reside?
Jun 27 15:58:44 <abhishek_[m]> I wonder if putting log levels in the log_printf makes sense and them being matched with the kernel log levels
Jun 27 15:59:28 <abhishek_[m]> RPMsg is typically handled as an incoming interrupt in the pruss module
Jun 27 15:59:46 <jkridner> see http://www.ti.com/lit/ug/spruhd4m/spruhd4m.pdf "Using Log Events"
Jun 27 16:00:59 <jkridner> abhishek_[m]: I mean for messages going from ICSS (PRU) to the host.
Jun 27 16:04:39 * jkridner looks at https://www.kernel.org/doc/Documentation/rpmsg.txt
Jun 27 16:04:57 <jkridner> seems "rpmsg_endpoint" can be called to add a handler.
Jun 27 16:06:30 <zeekhuge> The rpmg client driver handles the messages
Jun 27 16:06:46 <jkridner> a big question would be if that handler could see the ELF of the PRU binary. If so, it could translate the pointers into messages written to the kernel log via printk
Jun 27 16:07:07 <zeekhuge> Maybe the log messages can prefixed with some decided symbol to differentiate it from the normal messages
Jun 27 16:07:08 <jkridner> zeekhuge: is there a default client driver for the PRUs?
Jun 27 16:07:30 <jkridner> zeekhuge: why would it be different than normal messages? it seems the messages already have channel ids.
Jun 27 16:08:06 <zeekhuge> jkridner : For RPMsg, yes
Jun 27 16:08:55 <zeekhuge> And client drivers can be easily written to handle these messages
Jun 27 16:09:11 <zeekhuge> https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31+/beaglescope/beaglescope_driver.c
Jun 27 16:09:43 <zeekhuge> Line 335
Jun 27 16:10:13 <zeekhuge> Callback set by line 450
Jun 27 16:10:21 <zeekhuge> muneeb17:  ^
Jun 27 16:11:34 <abhishek_[m]> Should require a custom RPMsg driver, yes
Jun 27 16:12:01 <abhishek_[m]> But I am not sure if the Rpmsg driver can access the elf file
Jun 27 16:12:33 <jkridner> zeekhuge, abhishek_[m], muneeb17[m]: doesn't it seem useful to have a "LOG_printf" style function in a standard library for the PRU that will send RPMsg's for debugging PRU code? Wouldn't the kernel driver be nearly trivial and be something we could load all the time?
Jun 27 16:12:59 <jkridner> abhishek_[m]: since the kernel loads the ELF, I'd expect it can read it at other times.
Jun 27 16:14:12 <abhishek_[m]> Since rpmsg's are being used anyway, I think it should be possible to have a small kernel module for this
Jun 27 16:14:23 <zeekhuge> Why do we want the RPMsg to be able to read ELF ? And I think, rproc driver can read ELFs
Jun 27 16:14:55 <abhishek_[m]> The module will simply write whatever the PRUs send to the kernel right?
Jun 27 16:15:44 <abhishek_[m]> ZeekHuge: if it can read ELFs, one can extract the format string and parameters from the ELF itself
Jun 27 16:16:38 <zeekhuge> jkridner: yes. Maybe we can use channels. Probably will have to look into how that will be handled (more interrupt mappings etc)
Jun 27 16:17:35 <zeekhuge> abhishek_: parameters ? Regarding the message channel and all ?
Jun 27 16:18:11 <abhishek_[m]> Args to printf
Jun 27 16:23:22 <jkridner> zeekhuge: we want to minimize the time the PRU spends on logging. It should just dump some values in a circular buffer... because we may want to use RPMsg, it might also need to set an interrupt flag, but I'd love to see even that eliminated.
Jun 27 16:23:40 <jkridner> zeekhuge: reading the ELF would avoid needing to put the strings into the buffer....
Jun 27 16:23:52 <jkridner> zeekhuge: you'd just put a pointer to the format strings.
Jun 27 16:24:16 <jkridner> zeekhuge: also, we'd always fix the number of arguments and cast each value to 32 bits.
Jun 27 16:24:26 <jkridner> zeekhuge: makes the logging trivial.
Jun 27 16:24:30 <jkridner> ...for the PRU.
Jun 27 16:25:00 <zeekhuge> Got it.
Jun 27 16:30:10 <vaishnav98_> Hi all
Jun 27 16:30:53 <abhishek_[m]> Hi all
Jun 27 16:31:19 <muneeb17[m]> Hello everyone
Jun 27 16:31:23 <ravikp7> Hi everyone
Jun 27 16:31:24 <cwicks[m]> Hello everyone!
Jun 27 16:32:48 <anirban1998[m]> Hi everyone!
Jun 27 16:36:27 <jkridner> hi all
Jun 27 16:36:43 <jkridner> can we start by discussing the issues anirban1998[m] was having last week?
Jun 27 16:37:21 <anirban1998[m]> jkridner: Yeah Sure!
Jun 27 16:37:38 <jkridner> ds2, welsh[m]: around?
Jun 27 16:37:45 <jkridner> anyone seen hendersa recently?
Jun 27 16:38:23 <jkridner> aside: 2nd evaluations start July 9th.
Jun 27 16:41:04 <anirban1998[m]> hendersa ds2 discussed some tasks to perform on the circuit to check if the USB breakout board was giving any problems
Jun 27 16:41:33 <jkridner> anirban1998[m]: did you perform those tasks?
Jun 27 16:41:44 <jkridner> anirban1998[m]: reach a conclusion?
Jun 27 16:42:05 <zeekhuge> Hello everyone !
Jun 27 16:43:36 <anirban1998[m]> The pocketbeagle is not still enumerating the hub...so maybe the USB breakout board is faulty...hendersa suggested a pocketbeagle cape
Jun 27 16:43:37 <anirban1998[m]> https://www.tindie.com/products/microwavemont/24-port-usb-20-hub-cape-for-pocketbeagle/
Jun 27 16:43:37 <anirban1998[m]> Will it be okay? Need some suggestions...
Jun 27 16:43:40 <cwicks[m]> hi welsh had to be on a plane at this time, but sent anirban1998 an email last night
Jun 27 16:43:59 <anirban1998[m]> cwicks: yeah got the mail
Jun 27 16:44:41 <jkridner> anirban1998[m]: kernel logs show no acknowledgement? share circuit diagram and a picture of the assembly?
Jun 27 16:45:01 <jkridner> that cape is fine, but the breakout should be fine too.
Jun 27 16:45:17 <cwicks[m]> jkridner: welsh : any power challenges with the USB pocketcape?
Jun 27 16:45:31 <jkridner> cwicks[m]: well, isn't this a powered hub?
Jun 27 16:46:02 <jkridner> cwicks[m]: which "pocketcape"? The cape from microwavemont?
Jun 27 16:46:22 <anirban1998[m]> jkridner the kernel logs give a VBUS error
Jun 27 16:46:22 <cwicks[m]> Yes cape from Microwavemont
Jun 27 16:47:52 <anirban1998[m]> https://i.imgur.com/idVYH8D.png
Jun 27 16:47:52 <anirban1998[m]> The circuit assembly
Jun 27 16:48:35 <jkridner> are you really going through a breadboard?
Jun 27 16:49:22 <jkridner> you should avoid running loose wire for D+/D-... the pin header spacing is bad enough! :-)
Jun 27 16:49:51 <anirban1998[m]> jkridner Yeah...all the circuit has been done on the breadboard
Jun 27 16:50:07 <jkridner> how do you power the PocketBeagle? microUSB? (if so, that should be fine, but the battery won't provide USB host power)
Jun 27 16:50:25 <jkridner> anirban1998[m]: USB probably won't work on a breadboard.
Jun 27 16:50:55 <jkridner> a picture of the assembly might be of use. Did hendersa put it together and test?
Jun 27 16:51:21 <anirban1998[m]> jkridner: yeah I power the pocketbeagle using microusb
Jun 27 16:52:02 <anirban1998[m]> jkridner: yeah...hendersa tested it
Jun 27 16:52:03 <anirban1998[m]> https://i.imgur.com/idVYH8D.png
Jun 27 16:52:04 <jkridner> ds2: around?
Jun 27 16:52:04 <anirban1998[m]> The circuit assembly
Jun 27 16:52:20 <jkridner> anirban1998[m]: that's just a drawing, not a picture.
Jun 27 16:52:26 <jkridner> er, photograph.
Jun 27 16:52:54 <anirban1998[m]> jkridner: hendersa tested it and it was working fine
Jun 27 16:53:09 <jkridner> k. :(
Jun 27 16:53:11 <anirban1998[m]> jkridner: okay...I am sending the pic
Jun 27 16:53:13 <jkridner> are the wires twisted?
Jun 27 16:54:42 <jkridner> ravikp7: can we check in with you? can you send the weekly reports on Monday?
Jun 27 16:55:29 * anirban1998[m] uploaded an image: 20180623_131736.jpg (2932KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/DbjxfnqXuFwIVxjOeWqjQMON >
Jun 27 16:55:30 <anirban1998[m]> jkridner: you mean the d+- wires?
Jun 27 16:55:42 <jkridner> anirban1998[m]: yes.
Jun 27 16:56:31 <ravikp7> jkridner: sure, I'll make sure to send it by monday from next time
Jun 27 16:56:31 <anirban1998[m]> jkridner: In this pic I have not twisted the d+- wires...but on ds2  's suggestion...I tried it...but still no result
Jun 27 16:59:05 <ravikp7> jkridner: as I reported I checked with tcpdump on the board, the board is indeed receiving the dhcp request, but I can't understand why there's no response
Jun 27 16:59:53 <jkridner> https://imgur.com/a/Uu9e3Xd
Jun 27 17:00:12 <ravikp7> I'm blocked here on this, so, I've started work on terminal ui for uboot console in beagleboot
Jun 27 17:00:13 <jkridner> my hook-up for comparison ^^^^
Jun 27 17:01:48 <jkridner> ravikp7: had the DHCP server started already? I'm also still confused why the request is necessary given that you know the information the app should use (self = 192.168.7.1/255.255.255.252 and no gateway/dns)
Jun 27 17:02:19 <jkridner> ravikp7: have you tried repeated sends of the request the same as a typical DHCP client would?
Jun 27 17:04:01 <jkridner> https://i.imgur.com/DpvZxMX.jpg <--- what I should have pasted, direct link
Jun 27 17:04:15 <anirban1998[m]> jkridner: So you mean that the USB breakout is giving problems due to not being connected to the pocketbeagle directly...rather via the breadboard?
Jun 27 17:04:20 <ravikp7> jkridner: the board typically sends igmp, icmpv6 and 2-3 mdns requests, I tried sending dhcp request each time a request is received. Also, the board further doesn't sends any request
Jun 27 17:04:46 <ravikp7> and I also tried to ping 192.168.7.1 from board, and it's unreachable
Jun 27 17:04:57 <jkridner> anirban1998[m]: I'd expect it to. Proper design of a USB layout means minimizing the loop area between D+ and D-.
Jun 27 17:05:13 <jkridner> the traces should be matched length as well.
Jun 27 17:05:37 <jkridner> the fact that the USB is brought to a 100mil header as some very obvious limitations.... but we shouldn't exacerbate them.
Jun 27 17:05:50 <jkridner> s/as/has/
Jun 27 17:06:30 <jkridner> ravikp7: how could you ping it (from the OS) if the app is holding the interface? or do you mean you issued a ping from the app?
Jun 27 17:07:58 <ravikp7> jkridner: ping from debain on board
Jun 27 17:08:01 <ravikp7> *debian
Jun 27 17:08:01 <anirban1998[m]> jkridner Okay I will try this and report accordingly. Don't know how hendersa got it correct with that configuration
Jun 27 17:09:12 <ravikp7> jkridner: how the board knows that we've assigned 192.168.7.1 to self?
Jun 27 17:09:22 <jkridner> ravikp7: oh? that doesn't make sense. it should be "reachable" even if the USB cable isn't connected.
Jun 27 17:09:23 <ravikp7> I mean to the app
Jun 27 17:09:46 <jkridner> ravikp7: because the Debian images *always* provide the RNDIS host with 192.168.7.1.
Jun 27 17:09:54 <jkridner> just part of am335x_evm.sh
Jun 27 17:11:09 <jkridner> what does 'ifconfig' tell you about usb0/usb1?
Jun 27 17:12:11 <jkridner> vaishnav98_: we will send out a newsletter tomorrow that mentions the 0.6.4-beta3 release. hopefully that'll start getting some feedback.
Jun 27 17:12:12 <ravikp7> jkridner: let me check and report
Jun 27 17:14:09 <ravikp7> jkridner: I just checked right now, after the app claims the interface, the device can't ping 192.168.7.1
Jun 27 17:14:19 * ravikp7 sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/nBYGdritAaajaJOknHbuRxXS >
Jun 27 17:14:37 <jkridner> vaishnav98_: how is the BBUI update going? get any users to try it out?
Jun 27 17:14:51 <vaishnav98_> jkridner: glad to hear that :) , was not well last week and could not finish all the tasks planned , will put in more time this week to make up for the lost time.
Jun 27 17:15:11 <ravikp7> ifconfig output:
Jun 27 17:15:14 * ravikp7 sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/VbCeFzoaLtgVzBbMlqLffULR >
Jun 27 17:17:04 <jkridner> ravikp7: what distro image?
Jun 27 17:17:24 <jkridner> https://beagleboard.org/latest-images ?
Jun 27 17:17:37 <ravikp7> jkridner: debain latest
Jun 27 17:17:37 <vaishnav98_> jkridner: I haven't got the rewrite ready for review yet, hopes to get it ready for testing this week itself, meanwhile I have made some changes to the secure-rpc and removed the authentication at the express level to socket.io, needs to add more test-cases.
Jun 27 17:17:47 <jkridner> 2018-06-17 then?
Jun 27 17:17:53 <ravikp7> flashed last month with etcher
Jun 27 17:18:16 <jkridner> hmmm.... what does ifconfig say again?
Jun 27 17:18:39 <jkridner> oh, wait... it was just in the other link
Jun 27 17:19:22 <jkridner> guess without an ARP or DHCP, it might not know how to associate the MAC ID.
Jun 27 17:19:50 <ravikp7> jkridner: it's 2018-03-05
Jun 27 17:20:58 <ravikp7> yes, that's why I'm trying for arp or dhcp acknowledgement from board
Jun 27 17:21:00 <jkridner> maybe try sending an ARP announcement instead of DHCP request?
Jun 27 17:22:23 <jkridner> vaishnav98_: great! any RPC security stuff to review?
Jun 27 17:22:39 <ravikp7> tried arp too, but i don't think I tried that sending it multiple times like dhcp
Jun 27 17:22:45 <jkridner> muneeb17[m]: before we wrap, should we get back to any blockers you are having?
Jun 27 17:23:27 <jkridner> ravikp7: I think you could just send an announcement too, without needing to send a probe, but I'm not sure.
Jun 27 17:25:06 <vaishnav98_> jkridner: it would be great if you could have a look at this : https://github.com/jadonk/bonescript/commit/dc9f1e973703b0a05109d97b30ea3ff8921c9415 and suggest the modifications needs to be made , also I have submitted the typescript definitions here : https://github.com/jadonk/bonescript/pull/176
Jun 27 17:25:14 <ravikp7> jkridner: I just want to make sure that we don't need to send mdns requests to the board? like the linux host is sending to the board
Jun 27 17:29:46 <jkridner> ravikp7: don't think so. we should parse the broadcasts to see what services the image is hosting as a way to offer the up to the user.
Jun 27 17:31:31 <ravikp7> jkridner: ok, I've implemented code for parsing as well as encoding mdns in case we need it
Jun 27 17:31:41 <Wormo> muneeb17[m] zeekhuge : thinking about the question of reading an elf file for pru to resolve buffer messages to actual strings, seems like the strings could be extracted and cached kernel-side as a part of loading firmware to PRU
Jun 27 17:32:41 <Wormo> would be a kernel change but that seems the straight-forward approach
Jun 27 17:34:08 <jkridner> vaishnav98_: I don't think the express sessionStore is needed. There should be a unique environment for each socket.io connection. a hash challenge upon getting the socket.io connection should be sufficient.
Jun 27 17:35:03 * jkridner has to run... and will check the pull requests and commits from vaishnav98_ later tonight.
Jun 27 17:39:43 <muneeb17[m]> Sorry... internet connectivity was gone..
Jun 27 17:40:39 <Wormo> the main issue would be getting something general enough to eventually be upstreamed
Jun 27 17:43:22 <muneeb17[m]> abhishek_: zeekhuge : Wormo : So, can we arrive at a goal for next week
Jun 27 17:45:11 <muneeb17[m]> From what I understand, we pass pointers to strings in the Elf and the PRU will parse it and get it... or is it the other way round
Jun 27 17:49:32 <jkridner> muneeb17[m]: PRU should do no parsing!!!! direction of the messages in your mind is wrong. LOG_printf is for debugging PRU code. It sends a message to the ARM who parses the ELF to find the string associated with the pointer to format messages going to the kernel log.
Jun 27 17:50:04 <Wormo> yes the kernel is what will do all the reporting, PRU is not made for that kind of work
Jun 27 17:50:29 <jkridner> vaishnav98_: https://github.com/jadonk/bonescript/blob/master/src/socket_handlers.js#L42 should provide a unique session socket. You can use a variable in that scope to limit access to functions until authentication.
Jun 27 17:50:37 <jkridner> Wormo: ++
Jun 27 17:51:03 <muneeb17[m]> Yeah.. makes sense
Jun 27 17:52:50 <Wormo> since remoteproc driver is what puts specific fw into pru in the first place, it makes sense for remoteproc to also collect the fw-specific format strings that can be generated so that PRU log events will be decodeable
Jun 27 17:54:11 <cwicks[m]> anirban1998: please let me know us you need mentoring through the HW change - I can help find help
Jun 27 17:55:45 <vaishnav98_> jkridner: okay , so would a simple socket.io middleware that listens to each socket connection and then performing authentication suffice? , I sort of misinterpreted your comment on the initial draft for this and went on with the express-session and all.
Jun 27 17:56:38 <muneeb17[m]> Wormo:  I see the discussion of jkridner with abhishek_  and zeekhuge  now. Things became a lot more clearer.
Jun 27 17:57:01 <muneeb17[m]> Wormo:  zeekhuge  suggested we use rpmsg channels for that
Jun 27 18:14:42 <anirban1998[m]> cwicks Sure ! Would be really glad...I will first try the configuration jkridner mentioned...then if it doesn't work...would possibly require some changes in HW
Jun 27 18:22:23 <jkridner> vaishnav98_: yes, I think a simple hash-challenge at the socket.io level could be enough, adding a couple of functions like setPassword() and login(). I don't think a username is required.
Jun 27 18:25:51 <vaishnav98_> jkridner: I understand it now, will make the modifications soon.
**** ENDING LOGGING AT Thu Jun 28 03:00:02 2018