**** BEGIN LOGGING AT Tue Jun 30 02:59:57 2020
Jun 30 05:07:05 <Abhishek[m]_> Lorforlinux: continue without me in today’s meeting afternoon
Jun 30 06:06:19 <lorforlinux[m]> Okiee :)
Jun 30 07:11:22 <pratimugale[m]> vedant16: nice
Jun 30 07:13:59 <pratimugale[m]> Couldn't attend the meeting yesterday, got busy with work; catching up on the logs
Jun 30 08:00:40 <ds2> me0w
Jun 30 08:00:48 <lorforlinux[m]> jkridner ds2 pdp7: Hi :)
Jun 30 08:01:24 <ds2> lorforlinux[m]: I tried to look at that PR, not sure what is the goal so I can't really comment on it :/
Jun 30 08:02:38 <lorforlinux[m]> The goal is to provide a common set of DT nodes that can be used to create unified DT overlays that work on both the boards.
Jun 30 08:03:01 <ds2> kind of like a library ?
Jun 30 08:03:34 <lorforlinux[m]> maybe, I am not sure if we call it a library.
Jun 30 08:04:03 <lorforlinux[m]> see this recent work for /bone/spi -> https://github.com/beagleboard/bb.org-overlays/pull/183
Jun 30 08:04:31 <lorforlinux[m]> these overlays has been tested on BBB and BBAI.
Jun 30 08:05:30 <ds2> would a abstraction layer be a better description?
Jun 30 08:05:31 <lorforlinux[m]> for BBAI the nodes are in bbai-bone-buses.dtsi -> https://github.com/beagleboard/BeagleBoard-DeviceTrees/pull/17/commits/d4caaff2cf855ebde0dbf2e319220c7767c6b9c8
Jun 30 08:06:01 <lorforlinux[m]> for BBB they are in bbb-bone-buses.dtsi -> https://github.com/beagleboard/BeagleBoard-DeviceTrees/pull/17/commits/325f881dc6196442e0d31ae158f62fcad868980c
Jun 30 08:06:22 <lorforlinux[m]> <ds2 "would a abstraction layer be a b"> yes definitely this is a better description.
Jun 30 08:06:32 <ds2> not necessarily trying to send you to a different direction but I think all this is a bad idea
Jun 30 08:07:41 <lorforlinux[m]> maybe, please guide what could be a better approach here. everything i learnt till now suggested this is the best thing to do.
Jun 30 08:07:49 <ds2> IMO (and emphasis on MO part) - wouldn't a macro in the .dts plus having U-boot and other loaders load different names be more in the spirit of DT's
Jun 30 08:08:44 <ds2> I am picturing having to debug this and I donno where the nightmare would end
Jun 30 08:09:37 <ds2> what this seems to be creating is a very beagle specific setup that unless someone knows this is happening is going to have to spend endless hours chasing the indirections to figure out what the DT is really doing
Jun 30 08:11:24 <lorforlinux[m]> yes that's definitely a possibility if don't pitch the idea clearly. but, how do we create a unified overlay by using your method?
Jun 30 08:11:36 <lorforlinux[m]>  * yes that's definitely a possibility if we don't pitch the idea clearly. but, how do we create a unified overlay by using your method?
Jun 30 08:11:51 <ds2> I'd do it as an include in the .dts
Jun 30 08:12:01 <ds2> so dtc does the mapping
Jun 30 08:12:40 <ds2> with this, at least I can uncompile the .dtb and have a chance of figuring out what it is doing (I in the context of someone who knows dt but not beagle stuff)
Jun 30 08:13:58 <lorforlinux[m]> okay, the dts file here is the overlay right?
Jun 30 08:14:08 <ds2> yes
Jun 30 08:14:21 <ds2> tell me if I am misunderstanding it -
Jun 30 08:14:35 <ds2> you are creating a mapping/abstraction layer in a .dtb file
Jun 30 08:14:47 <ds2> so other dtb can be used on both AI and BBB
Jun 30 08:16:20 <lorforlinux[m]> there is a problem here, how to we create an include file to make things work out on two boards? in short how do we handle the clash for peripheral nodes, let me give an example.
Jun 30 08:18:27 * lorforlinux[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/wlSJoXarnximuCATvJTYCQpI >
Jun 30 08:19:00 <lorforlinux[m]> Please correct me if this not what you are talking about ^
Jun 30 08:19:39 <ds2> please use pastebin or something more standard for long messages!!!
Jun 30 08:20:07 <ds2> this time I manage to dig it out
Jun 30 08:20:13 <ds2> here's what I would suggest doing:
Jun 30 08:20:23 <lorforlinux[m]> <ds2 "you are creating a mapping/abstr"> yea, I have created  separate include files for base dts that generates the dtb file with the symbols so that we can call them on both boards.
Jun 30 08:20:30 <ds2> in the beaglecompat.dtsi file:
Jun 30 08:21:24 <ds2> #ifdef BBAI; #define UART_P8_99 uart1; #else #define UART_P8_99 uart10; #endif
Jun 30 08:21:38 <ds2> then in the overlay & UART_P8_99 { ...... }
Jun 30 08:21:59 <ds2> that way you name it based on the pin it is connected (which is what the problem is, capes are connected to pins)
Jun 30 08:22:23 <ds2> and the dtsi would map it at build time. then build over-bbai.dtb and overlay-bbb.dtb
Jun 30 08:22:49 <ds2> have the loader search for *-bbai.dtb or *-bbb.dtb; if it iexists use that version instead of the normal one
Jun 30 08:23:51 <lorforlinux[m]> that's what rcn-ee suggested but jkridner suggest the way i have implemented it now.
Jun 30 08:24:05 <ds2> that way the main work is to figure out which dtb is loaded and proceed to decompile it for further debugging
Jun 30 08:24:16 <ds2> heh, thought I was alone in that opinion ;)
Jun 30 08:24:52 <lorforlinux[m]> <ds2 "have the loader search for *-bba"> but, we don't want two dtb files only one for both boards.
Jun 30 08:25:28 <ds2> figuring out the loaded dtb is relatively easy. figuring out someone's abstractions is not and in any case.... what if there is another BeagleUberBone next year?
Jun 30 08:25:33 <ds2> what's wrong with 2 dtb's?
Jun 30 08:25:59 <ds2> we have that idea all over the place... dtb's are equivalent to .o's
Jun 30 08:26:16 <ds2> what I hate to do is send you in circles
Jun 30 08:28:10 <lorforlinux[m]> It was said to me from starting that we want same DT and userpace binary to work on both the boards, taking that into account and following what jkridner instructed i came up with this.
Jun 30 08:28:56 <ds2> not really blaming you for it
Jun 30 08:29:14 <lorforlinux[m]> <ds2 "what I hate to do is send you in"> Yeah, i have to start all over again for implementing the two dtbs idea :(
Jun 30 08:29:20 <ds2> but like I said, that's MO... I find it not very debuggable and I am usually at the debugging end
Jun 30 08:29:39 <lorforlinux[m]> one more thing
Jun 30 08:30:05 <ds2> I can aways resort to ripping out all the overlays and regenerating a full dtb
Jun 30 08:31:35 <lorforlinux[m]> why are we not using bone-pinmux-helper for doing pinmuxing? we are using the that code on pocket beagle only!
Jun 30 08:32:38 <ds2> that I donno
Jun 30 08:33:22 <lorforlinux[m]> on BBB we have that but we are defining everything again instead of just doing  this -> &ocp{ P9_28_pinmux { status = "gpio"; };} after disabling the pin.
Jun 30 08:34:10 <ds2> the pinout of the pocket beale is a little different
Jun 30 08:35:30 <lorforlinux[m]> yes, and we have separate code for BBB. on pocket we are using &ocp{ P2_#_pinmux { status = "gpio"; };}  on BBB we can use &ocp{ P9_#_pinmux { status = "gpio"; };}
Jun 30 08:36:16 <ds2> I think things are a mess and that mess is part of the reason for this being a GSoC project
Jun 30 08:37:06 <lorforlinux[m]> we are already using the bone-pinmux-helper to diable pin any way, IMO we could just use it for pinmuxing also.
Jun 30 08:38:19 <lorforlinux[m]> jkridner pdp7 Abhishek_ if there is something I don't know which is blocking us to use tha bone-pinmux-helper for pinmuxing please let me know. It will be very helpful for my project if i can use them.
Jun 30 08:39:33 <ds2> I rarely use overlays
Jun 30 08:39:49 <pdp7> I think there is concern over modifying am5729 at run time
Jun 30 08:40:06 <ds2> that doesn't explain the BBB case
Jun 30 08:40:41 <lorforlinux[m]> ds2: do you have some resources on uboot, I want to enable cape manager on BBAI and for doing that I have to work on uboot SPL. rcn-ee told me that I2C is not functional at this moment that's why we can't have the cape-manager on the BBAI at this moment.
Jun 30 08:41:24 <ds2> lorforlinux[m]: does RCN have a repo for it? for the BBB heas a repo that wraps up the build process
Jun 30 08:42:29 <lorforlinux[m]> yes, I guess there is a repo to build uboot. he told me that the i2c read was not finished in SPL.
Jun 30 08:43:14 <ds2> you can still test the code w/o I2C
Jun 30 08:43:32 <ds2> could always fake capes in the code w/o using I2C.
Jun 30 08:43:33 <lorforlinux[m]> yes i am using the uEnv.txt for now.
Jun 30 08:43:56 <ds2> no, Imean compile it in. IIRC, SPL doesn't readl uEnv.txt
Jun 30 08:46:07 <lorforlinux[m]> ohh okay, but that would make things bit difficult as i can include them without compiling anything just by including the dtbo file name into uEnv.txt
Jun 30 08:46:29 <ds2> compile is easy
Jun 30 08:48:04 <lorforlinux[m]> if it would be efficient i would love to try it, how do i do it?
Jun 30 08:48:34 <ds2> his repo has a script that will download and run the compile. Once that is done, you can go into the sources and run make yourself
Jun 30 08:48:57 <lorforlinux[m]> okay i will try that.
Jun 30 08:48:59 <ds2> the reason i suggest his repo is it takes care of patching things and gets you close to what he has
Jun 30 08:50:49 <lorforlinux[m]> okay, I have to start doing uboot stuff anyway. I will start with this.
Jun 30 08:51:39 <ds2> sorry to through out yet another idea
Jun 30 08:52:36 <lorforlinux[m]> ds2: we can do one thing that will make things in between of both the ideas of implementing the compatibility layer, but it involves using on bone-pinmux-helper.
Jun 30 08:52:56 <vedant16[m]> > Couldn't attend the meeting yesterday, got busy with work; catching up on the logs
Jun 30 08:52:57 <vedant16[m]> Ohhk
Jun 30 08:53:27 <lorforlinux[m]> <ds2 "sorry to through out yet another"> noo way, that's an opportunity for me to learn more things.
Jun 30 08:54:15 <ds2> bone-pinmux-helper has similar problems but at least that is limited to GPIOs
Jun 30 08:54:32 <ds2> all this would be less of an issue with board files IMO
Jun 30 08:55:15 <lorforlinux[m]> <lorforlinux[m] "ds2: we can do one thing that wi"> instead of defining pinmux and nodes onto the bbai/bbb-bone-buses.dtsi file we can hust have empty bone_bus_#: &bus {} nodes there and stick with the older pinmuxing method we used for overlays.
Jun 30 08:57:01 <lorforlinux[m]> <ds2 "bone-pinmux-helper has similar p"> okay i will stick to the current method for now, and test things out. If time serves i will try this idea also.
Jun 30 08:58:10 <ds2> lorforlinux[m]: I'd suggest making sure it is okay with everyone. My feedback is based on debugging things which sometimes people don't see til they have to debug it
Jun 30 08:59:29 <lorforlinux[m]> rcn-ee doesn't have the problem with the work as long as it's not breaking old kernels.
Jun 30 09:00:21 <ds2> *shrug*
Jun 30 09:00:41 <lorforlinux[m]> pdp7 Abhishek_ can you please review my code https://github.com/beagleboard/BeagleBoard-DeviceTrees/pull/17 :)
Jun 30 09:01:53 <lorforlinux[m]> ds2: I have tested it on 4.14 and 4.19, how old (kernel) do you think we have to make things work out?
Jun 30 09:02:29 <ds2> is that 4.14 plain, TI, RT or?
Jun 30 09:04:04 <lorforlinux[m]> I used the beaglebone official IoT image, what do we have there?
Jun 30 09:04:23 <ds2> do uname -a and paste that
Jun 30 09:04:43 <ds2> I suspect bone is mainline and ai may be TI
Jun 30 09:04:45 <lorforlinux[m]> yes booting the board
Jun 30 09:05:24 <ds2> actually, ask RCN how far back he wants
Jun 30 09:05:32 <ds2> I sometimes use 3.2 ;)
Jun 30 09:05:46 <lorforlinux[m]> okay, I will do that.
Jun 30 09:05:59 <lorforlinux[m]> <ds2 "I sometimes use 3.2 ;)"> do you have any specific use case or something?
Jun 30 09:06:12 <ds2> I use 3.2 due to the lack of DT
Jun 30 09:06:59 <lorforlinux[m]> let me guess, you really hate DT.
Jun 30 09:07:03 <lorforlinux[m]> BBAI -> Linux beaglebone 4.19.94-ti-r45 #1buster SMP PREEMPT Thu Jun 18 19:18:41 UTC 2020 armv7l GNU/Linux
Jun 30 09:07:32 <ds2> :)
Jun 30 09:07:41 <ds2> that's a TI kernel (note the -ti part)
Jun 30 09:08:36 <ds2> IMO - DT's creates debugging issues... it adds yet another piece besides source code
Jun 30 09:10:07 <lorforlinux[m]> if what we are doing is just creating a node would that make things difficult to debug?
Jun 30 09:10:33 <lorforlinux[m]> BBB -> Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux
Jun 30 09:10:40 <ds2> let's say you are trying to get a new cape to work
Jun 30 09:10:41 <lorforlinux[m]> *BBBWL ^
Jun 30 09:11:02 <lorforlinux[m]> yes
Jun 30 09:11:02 <ds2> and all you have is a schematic plus the datasheet for the chips on the cape
Jun 30 09:11:23 <ds2> you can get the DT's in memory by reading it out of proc/sys
Jun 30 09:11:32 <ds2> proc or sys depending on versions
Jun 30 09:12:09 <ds2> if you don't know about all these abstraction layers, attempts t decompile that DTB from memory is going to result in yet another mystery to chase down - what is that node
Jun 30 09:17:01 <lorforlinux[m]> if we are looking it in that way, the new code will not limit anybody to use these nodes. you can use the more suitable way of doing things as you expect it to be done. If a person creates a overlay he/she must know that the overlay is made for BBAI or BBB board as they have used peripheral reference for that board and it will be differnet on other one, that will lead them to use those nodes else you don't have
Jun 30 09:17:01 <lorforlinux[m]> work about any of that if that's not your thing.
Jun 30 09:18:52 <ds2> it isn't about creating it. it is about using it
Jun 30 09:22:22 <lorforlinux[m]> maybe your idea is superior, don't know what might limit things there.
Jun 30 09:23:54 <lorforlinux[m]> let's see what others have say on this.
Jun 30 09:25:23 <lorforlinux[m]> ds2: I think it's pretty late for you now, thank you so much for your time It was really very nice talking to you :)
Jun 30 09:25:58 <ds2> =)
Jun 30 11:38:24 <jkridner[m]> oh, right, tuesday. :-(. sorry
Jun 30 13:28:58 <deepankarmaithan> updated my codes on the repo. https://github.com/deebot/Beaglebone-BidirectionBus
Jun 30 15:21:24 <jkridner[m]> lorforlinux: ds2 , it'll be tough to go back further than 4.14. I don't know this compatibility stuff needs to go back any further than 4.19.
Jun 30 15:41:35 <sakethr98[m]> deepankarmaithani: you here?
Jun 30 16:06:39 <Abhishek[m]_> Students - please make sure to complete your evaluations before Friday!
Jun 30 17:07:25 <nwan[m]> > Students - please make sure to complete your evaluations before Friday!
Jun 30 17:07:25 <nwan[m]> Thanks for the reminder. Just submitted mine :)
Jun 30 17:44:48 <vedant16[m]> @abhishek_:matrix.org: I added led blink, button controlled led examples, any more that i should add in IO section?
Jun 30 17:45:22 <vedant16[m]> And one more doubt, how do i use C macros to find out which Beaglebone board i am using?
Jun 30 17:47:40 <vedant16[m]> Or is there any way i can find exactly which model of BB i have
Jun 30 17:48:00 <vedant16[m]> I want to automate config-pin, rather than doing it manually everytime.
Jun 30 17:48:18 <vedant16[m]> <vedant16[m] "@abhishek_:matrix.org: I added l"> @pratimugale:matrix.org
Jun 30 18:29:08 <Abhishek[m]_> vedant: cat /proc/machinename or something
Jun 30 18:30:06 <vedant16[m]> <Abhishek[m]_ "vedant: cat /proc/machinename or"> machinename is not there
Jun 30 18:30:13 <vedant16[m]> I found out a way
Jun 30 18:30:41 <lorforlinux[m]> jkridner: hey, can you please review new code and merge the PR?
Jun 30 18:30:47 <vedant16[m]> in `/sys/firmware/devicetree/base` model file has model name
Jun 30 18:32:48 <vedant16[m]> Abhishek: I was thinking of automating pru binary loading step. Like say i generate out.pru binary. generally if i do `./out.pru` I get a exec error. Is it possible that when i do `./out.pru` a different binary is called which loads out.pru onto /lib/firmware and starts the PRU ?
Jun 30 18:33:06 <vedant16[m]>  * Abhishek: I was thinking of automating pru binary loading step. Like say i generate out.pru binary. generally if i do `./out.pru` I get a exec format error. Is it possible that when i do `./out.pru` a different binary is called which loads out.pru onto /lib/firmware and starts the PRU ?
Jun 30 19:01:44 <deepankarmaithan> <sakethr98[m] "deepankarmaithani: you here?"> sorry i was not there
Jun 30 19:42:19 <deepankarmaithan> sakethr98:  I have figured out the reason that is causing the issue that i have mentioned in the blocker.
Jun 30 19:43:06 <deepankarmaithan> When i try to compile  the code using resource table for pru0  it  throws error
Jun 30 19:59:26 <jkridner[m]> <lorforlinux[m] "jkridner: hey, can you please re"> k
**** ENDING LOGGING AT Wed Jul 01 03:01:14 2020