**** BEGIN LOGGING AT Mon Mar 09 02:59:57 2020
Mar 09 08:33:18 * pradan[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/rQuckrfZdmVbvnzDruHVmXoO >
Mar 09 08:34:26 * pradan[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/BpUsKnlmXZlmbvwNgOwNdcAG >
Mar 09 08:34:50 * pradan[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/YEIjJlHVreRVnMfKyGsfHMDN >
Mar 09 16:04:06 <jkridner[m]> Don't think I'd ver seen redactions before.
Mar 09 16:42:54 <ymdatta> <jkridner[m] "hmmm.... https://github.com/beag"> Hi jkridner : Thanks for the link, i was able to understand the big picture. Now, i am able to understand what do you mean by an identifier.
Mar 09 16:47:46 <ymdatta> Since in cape bus we are identifying dt overlay, we just need a name and use that name to get appropriate data from firmware. Similarly, in our mikroBus case, the identifier would contain all the platform data  elements (say names), and we get the data for that elements from firmware. Is that line of thought correct?
Mar 09 16:48:30 <ymdatta> (Though there were few comments, the code was really good, props to the author.)
Mar 09 16:55:39 <jkridner[m]> For mikrobus, I'd want to leverage the strings used for driver definition today.
Mar 09 16:55:57 <jkridner[m]> I'm not sure of the specifics here, but I want to avoid a maintanence nightmare.
Mar 09 16:56:34 <jkridner[m]> ymdatta: for greybus, there is a manifest.... certainly no information beyond what would go in a manifest should be required.
Mar 09 16:57:13 <jkridner[m]> assumptions should be possible based on the gpio typically used for reset and interrupt so that they don't need to be specified explicitly.
Mar 09 16:58:25 <jkridner[m]> any quirks should be patched-up in the kernel, but there shouldn't be a massive table for all the different click boards such that maintainers get irritated with patches coming in for every new click when drivers already exist.
Mar 09 16:59:05 <jkridner[m]> take a look at last year's Click boards via Greybus project that used the Greybus simulator.
Mar 09 17:00:52 <jkridner[m]> we want to specifically start by fixing the problem that there wasn't an implicit definition of resources for the platform data outside the bus-specific driver by creating a slightly higher-level bus.
Mar 09 17:01:43 <jkridner[m]> for typical I2C device drivers, the platform data is often required to provide a gpio for an interrupt signal.
Mar 09 17:05:33 * jkridner[m] does some driver reading.
Mar 09 17:07:11 * jkridner[m] wonders if ADXL345 (very common accelerometer) is a good proxy to understand the mikrobus bus driver requirements.
Mar 09 17:07:33 <jkridner[m]> probably over half the drivers would fall under IIO....
Mar 09 17:08:06 <jkridner[m]> a number of the Click devices would be auxdisplay, drm, network or others.
Mar 09 17:09:03 <jkridner[m]> being able to successfully generate probes/registers for those 4 would be a great start--without requiring any Click-specific device tree entries.
Mar 09 17:09:27 * jkridner[m] reads https://www.kernel.org/doc/html/v4.12/driver-api/iio/core.html again.
Mar 09 17:10:41 * jkridner[m] is suprised how clean the regmap interface is.
Mar 09 17:33:58 * ymdatta looking at last year's click boards via greybus project
Mar 09 18:18:16 <jkridner[m]> ymdatta: got a feel for a next question? Start your project proposal?
Mar 09 18:20:57 * jkridner[m] is not finding much at https://elinux.org/Category:GSoCProposal2020
Mar 09 18:22:30 <ymdatta> jkridner: That's a lot of information to understand (your replies before). I will start with the proposal in 1-2 days.
Mar 09 18:22:37 <ymdatta> :)
Mar 09 18:35:11 * pradan[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/wpyRBhTjPlmeVercttZrevnq >
Mar 09 18:36:44 <jkridner[m]> what do you mean by "tag selection"
Mar 09 18:36:47 <jkridner[m]> ?
Mar 09 18:37:01 <jkridner[m]> that is a really long IRC message.
Mar 09 18:39:51 <pradan[m]> I meant that I have mentioned the mentors who may be helpful/related here...
Mar 09 18:41:00 <pradan[m]> I will try and keep the messages short next time
Mar 09 18:46:27 <jkridner[m]> I don't know much about the various models and training frameworks....
Mar 09 18:46:40 <jkridner[m]> ...it seems like you are convolving the two a bit, but I could be wrong.
Mar 09 18:46:52 <jkridner[m]> I thought Caffe was more of a training framework.
Mar 09 18:47:15 <jkridner[m]> Whereas YOLO was a set of trained models.
Mar 09 18:47:25 * jkridner[m] googles.
Mar 09 18:49:17 <jkridner[m]> it looks like YOLO uses the "COCO" dataset.
Mar 09 18:50:14 <jkridner[m]> seems like YOLO is more of a "complete system", not just the model.
Mar 09 18:50:42 <jkridner[m]> darknet seems to be the code and must incorporate the models.
Mar 09 18:54:58 <jkridner[m]> ds2: do you think pradan would need to update https://git.ti.com/cgit/tidl/tidl-utils/tree/src/importTool/modules/ti_dl/utils/tidlModelImport to import the models from darknet?
Mar 09 19:03:16 <ds2> jkridner[m]: probally not.... there been conversions of darknet to TF...IIRC, the tidlModelImport can take TF models
Mar 09 19:03:34 <ds2> problem is sorting out the config file
Mar 09 19:03:45 <ds2> that's where I stalled and started looking elsewhere
Mar 09 19:04:12 <jkridner[m]> k, that makes it a bit easier.
Mar 09 19:04:44 <ds2> judging from context, I am guessing there were long messages sent using matrix that I don't see (my client ignores the ACTIONs used to point to a URL)
Mar 09 19:06:45 <pradan[m]> The last messages I sent on Saturday were about 4-5 lines long. I fear if even that's not permitted by IRC.
Mar 09 19:07:21 <ds2> I checked my logs and nothing from you in the last few days, pardan[m]
Mar 09 19:08:05 <ds2> usually, I check my logs at least once daily if not more often
Mar 09 19:09:52 <pradan[m]> That's very strange. I am new to IRC and didn't know of these issues. I thought you were busy for the last 4-5 days and didn't get time to see the messages....
Mar 09 19:09:52 <pradan[m]> Is my last message visible (the first one I sent today ? )
Mar 09 19:11:48 <pradan[m]> I ran a benchmark test on the FeatherCNN  using one of the ports for ARM CPUs and it gives an avg inference time of 130ms when using a pre-converted Caffe model of size 16.2MB on an image of shape 3x224x224.
Mar 09 19:12:02 <ds2> pradan[m]: nope
Mar 09 19:12:27 <ds2> paradan[m]: what hardware?
Mar 09 19:12:40 <pradan[m]> How should I make sure that my messages are even sent successfully?
Mar 09 19:12:51 <ds2> keep them short like you are doing now :)
Mar 09 19:13:16 <ds2> let me make up an example of what long message show up as (and get ignored as I don't log ACTIONs):
Mar 09 19:13:50 * ds2 sent a long message: MMETHOD://ADDRESS/URI
Mar 09 19:13:58 <ds2> replace METHOD.... with an actual URL
Mar 09 19:14:32 <ds2> that's sent as an action in the IRC prootocol (PRIVMSG CTRL-AACTION ......)
Mar 09 19:14:42 <ds2> vs normal messages being sent as PRIVMSG ....
Mar 09 19:20:34 <pradan[m]> It was on an AWS EC2 virtual machine : ARM Server (1 vCPU, ARM architecture, 1 Core, 2.3GGz, 2GB memory)
Mar 09 19:21:30 <ds2> do you know what ARM core? (32 or 64 bit, etc)?
Mar 09 19:21:51 * pradan[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/DxdogcsENwobfVFEhYYYWxnX >
Mar 09 19:22:05 <ds2> you did that again:
Mar 09 19:22:08 <pradan[m]> 64 bit
Mar 09 19:22:12 <ds2> * pradan[m] sent a long message:  <
Mar 09 19:22:17 <ds2> +https://matrix.org/_matrix/media/r0/download/matrix.org/DxdogcsENwobfVFEhYYYWxnX >
Mar 09 19:22:47 <ds2> hmmm so that is not directly applicable... the BBAI and BBone are both 32bit
Mar 09 19:26:38 <ds2> have you tried running YOLO through feathercnn? there are caffe versions of YOLO floating around on githib
Mar 09 19:26:43 <ds2> or tools to generate it
Mar 09 19:30:14 <pradan[m]> The developers have published results on tests on 64 bit systems like the RPi 3 and 32 bit devices like the RK3399... I just google it but still unsure.
Mar 09 19:32:05 <pradan[m]> Yeah I found some resources on converting Darknet models to Caffe on GitHub but not tested it yet
Mar 09 19:38:58 <pradan[m]> If we go with FeatherCNN, it eventually replaces the need for TIDL, outperforming it. Does that violate the project guidelines ?
Mar 09 19:58:48 <ds2> it may be okay but I suspect the performance will not be as good
Mar 09 19:58:56 <ds2> you talk about featherCNN but not hte model
Mar 09 19:59:20 <ds2> hence those numbers are not hte most meaningful... when you can generate the same sort output (object classification and location) as the YOLOs....
Mar 09 20:23:03 <pradan[m]> I will try and replicate YOLO's results now. I am not sure but I think the current infernces are made on a MobileNet model.
Mar 09 22:45:24 <ds2> mobilenet is part of TIDL, IIRC...that's a different approach and may be a bit simplier as all it does is predicts a single item
Mar 10 02:58:19 <go_cool[m]> <Pac23 "cool,tag me if you have any prob"> Hi, now that I have completed all the basic requirements, could you please  guide me onto the next step for the project.
**** ENDING LOGGING AT Tue Mar 10 02:59:57 2020