**** BEGIN LOGGING AT Tue Jun 16 03:06:38 2020
Jun 16 03:55:17 <jkridner[m]> <lorforlinux[m]1 "Also, there is no /proc/device-t"> Do you have any overlays enabled? The eMMC and HDMI overlays aren't required as they no longer interfere with cape pins.
Jun 16 03:57:06 <jkridner[m]> <lorforlinux[m]1 "For BBBWL i think the problem is"> But that is why I had you give the output of version.sh. It shows that the overlays don't have a conflict and the HDMI overlay is selected.
Jun 16 03:57:31 <jkridner[m]> <jkridner[m] "But that is why I had you give t"> output from dmesg might help.
Jun 16 04:04:43 <jkridner[m]> <lorforlinux[m]1 "they seem to change the device n"> OK, but I think these are SoC-specified, rather than board-level.
Jun 16 07:22:13 <lorforlinux[m]1> <jkridner[m] "Do you have any overlays enabled"> yes they are enabled, will try to remove them and load the overlay again!
Jun 16 07:22:48 <lorforlinux[m]1> <jkridner[m] "But that is why I had you give t"> okay thanks, trying it now.
Jun 16 08:02:20 <lorforlinux[m]1> jkridner ds2 Abhishek_ pdp7 Hi :)
Jun 16 08:03:27 <ds2> hi
Jun 16 08:04:16 <lorforlinux[m]1> Hey ds2 how are doing?
Jun 16 08:04:42 <lorforlinux[m]1> Thanks to nwan I can load the overlays on BBAI now.
Jun 16 08:05:03 <ds2> cool
Jun 16 08:05:09 <ds2> is the BBAI fully stable for you?
Jun 16 08:06:01 <lorforlinux[m]1> Yes, i guess it's stable.
Jun 16 08:06:19 <ds2> did you get the fan?
Jun 16 08:06:52 <lorforlinux[m]1> yes i have the fan installed.
Jun 16 08:07:05 <lorforlinux[m]1> it's not flamin hot without the fan either.
Jun 16 08:07:22 <ds2> if you did anything on the CPU, it'd be
Jun 16 08:07:40 <ds2> trying to compile on there did not go well
Jun 16 08:08:11 <lorforlinux[m]1> yes, yet to do something heavy load stuff there.
Jun 16 08:09:34 <lorforlinux[m]1> I am trying to load the virtual cape overlay I wrote for BBAI yesterday.
Jun 16 08:10:29 <ds2> are you using tabs or spaces in the DT's?
Jun 16 08:11:58 <lorforlinux[m]1> tabs, should i be using spaces?
Jun 16 08:12:11 <ds2> no, tabs are good
Jun 16 08:12:17 <ds2> just noticed the diff looked a bit odd
Jun 16 08:12:33 <ds2> w/o pulling it down, I can't tell from the GH interface if it is tabs or spaces
Jun 16 08:12:43 <ds2> also noticed you had trailing white space
Jun 16 08:13:14 <lorforlinux[m]1> yes it was good on my pc but not when pushed on github
Jun 16 08:13:30 <ds2> hmm? how is it possible?
Jun 16 08:13:45 <ds2> git should be able to transfer htings verbatium
Jun 16 08:14:15 <lorforlinux[m]1> no idea
Jun 16 08:14:34 <ds2> are you using the commandline?
Jun 16 08:14:52 <lorforlinux[m]1> I am using vscode
Jun 16 08:15:08 <ds2> oh... *shrug*
Jun 16 08:15:27 <ds2> any questions?
Jun 16 08:16:55 <lorforlinux[m]1> yes, can you suggest what should be done for the aliases for the buses
Jun 16 08:17:15 <lorforlinux[m]1> <lorforlinux[m]1 "jkridner: I was working on virtu"> please see these messages
Jun 16 08:18:07 <ds2> not sure what the problem is?
Jun 16 08:18:20 <ds2> can you explain
Jun 16 08:20:34 <lorforlinux[m]1> the problem here is that we are providing different names to the buses like if you want to access the i2c5 of BBAI you will find it as i2c-4 and also as /bone/i2c/1
Jun 16 08:21:15 <ds2> you mean /dev/i2c-4 vs /bone/i2c/1?
Jun 16 08:22:19 <lorforlinux[m]1> I want to say that i2c5 should be i2c-5 nooh?
Jun 16 08:23:02 <lorforlinux[m]1> I am not sure, is there any reason to create aliases for those buses?
Jun 16 08:23:12 <ds2> I don't see the problem... those are just names. are there userland utilities that wants to access it ?
Jun 16 08:23:31 <ds2> I personally don't see any reason for that. /dev/i2c-4 is the standard name
Jun 16 08:23:52 <lorforlinux[m]1> <ds2 "you mean /dev/i2c-4 vs /bone/i2c"> we can not argue with the /bone/i2c/1 as this will provide common reference ground between BBB and BBAI
Jun 16 08:23:59 <ds2> userland shouldn;t be touching them unless they are debugging and if they are debugging, they should walk /sys to figure out what is the physical bus
Jun 16 08:24:10 <ds2>  /bone/i2c/1 is nonstandard.
Jun 16 08:24:24 <ds2> I am a Linux user first. Bone is secondary
Jun 16 08:24:44 <ds2> but those are my opinions. but since no one else is here... :D
Jun 16 08:25:22 <lorforlinux[m]1> <ds2 "I personally don't see any reaso"> okay so we should stick to the aliases we have?
Jun 16 08:25:45 <ds2> I would go as far as say why even have /bone/....
Jun 16 08:26:35 <lorforlinux[m]1> yes that makes sense, we can change aliases to make things compatible with BBAI
Jun 16 08:27:07 <ds2> the aliases in the DT shouldn't impact this as this userland stuff
Jun 16 08:27:19 <ds2> as long as the DT's are self consistent, it should be fine
Jun 16 08:28:27 <lorforlinux[m]1> Okay what do you suggest we should do?
Jun 16 08:28:52 <ds2> I still don't understand why something needs to be done?
Jun 16 08:29:35 <lorforlinux[m]1> okay the thing is we want same header pins to show up as a device with same name on both the boards.
Jun 16 08:29:51 <lorforlinux[m]1> one way is to use /bone/<bus>/<#>
Jun 16 08:30:07 <ds2> why do you want to do that?
Jun 16 08:30:31 <ds2> i2c-5 is i2c-5, i2c-1 is i2c-1... there are i2c-1's on both boards
Jun 16 08:30:59 <lorforlinux[m]1> other one might be aliases, which we once dropped before in favor of symlinks (/bone stuff).
Jun 16 08:31:51 <ds2> I'd fine it very confusing and probally go write who ever wrote code to call i2c-5 on the BBAI i2c-1 a very long and nasty email
Jun 16 08:32:02 <lorforlinux[m]1> <ds2 "i2c-5 is i2c-5, i2c-1 is i2c-1.."> but same pins provide i2c-5 on BBAI but i2c-1 on BBB
Jun 16 08:32:09 <ds2> that's the kind of things that has waste hours and hours of my time debugging
Jun 16 08:32:40 <ds2> if you must use a name - how about call it i2c-P8-XX or i2c-P9-XX?
Jun 16 08:33:09 <lorforlinux[m]1> yes that's true, people will miss the fact and waste there time debugging
Jun 16 08:33:37 <lorforlinux[m]1> <ds2 "if you must use a name - how abo"> yes that's a good idea.
Jun 16 08:34:28 <ds2> not sure if your background... but consider this - I send you a .c file with code in there - 1 function:int read_addr(int ptr) but the implementation is just 1 line return ptr+1
Jun 16 08:35:08 <ds2> if all you saw was that prototype and name, you would form expectations... calling it i2c-N has the same effect.
Jun 16 08:35:50 <ds2> just imagine you get a core dump with a fault in that function... you can spend hours on it before you look at the implementation :D
Jun 16 08:36:40 <lorforlinux[m]1> totally makes sense.
Jun 16 08:36:56 <ds2> all the CS classes teach people to use descriptive names but I'd argue... use varibles like x to force people to read the code instead of form expectations... I know that would have saved me a lot time!
Jun 16 08:37:13 <ds2> anyways :D
Jun 16 08:38:42 <ds2> hey jkridner
Jun 16 08:38:51 <lorforlinux[m]1> I would have wasted my day looking for i2c1 on my board it was my first day with it, using those aliases it's i2c-0 on the board but uboot calls it I2C1 same with I2C4 :(
Jun 16 08:39:11 <ds2> yep
Jun 16 08:39:11 <lorforlinux[m]1>  * I would have wasted my day looking for i2c1 on my board if it was my first day with it, using those aliases it's i2c-0 on the board but uboot calls it I2C1 same with I2C4 :(
Jun 16 08:40:05 <lorforlinux[m]1> I am in favour of dropping those aliases if everybody agrees. makes things more understandable.
Jun 16 08:40:07 <ds2> would have been nice if they called it i2c-sw1 (SW numbering 1)... I dbg both HW and SW and almost always forced to verify the mapping with a scope :(
Jun 16 08:41:22 <lorforlinux[m]1> that's painful :(
Jun 16 08:43:17 <ds2> you might run in the same thing if you have UARTs
Jun 16 08:43:37 <lorforlinux[m]1> yes dealing with it right now.
Jun 16 08:48:03 <lorforlinux[m]1> I think you should go sleep, I don't have anything else to ask. thank you so much for your support :)
Jun 16 08:48:35 <ds2> =) if you thinking of anything, just put it on the channel
Jun 16 08:49:14 <lorforlinux[m]1> sure thing ;)
Jun 16 12:06:08 <jkridner[m]> lorforlinux I am so sorry
Jun 16 12:13:25 <jkridner[m]> ds2: there’s no way to search for a port based on header pins. that is the point of the exercise.
Jun 16 12:13:58 <jkridner[m]> i had a late night, but not late enough.
Jun 16 12:15:18 <jkridner[m]> the aliases seem counterproductive to me as they are.
Jun 16 12:18:22 <jkridner[m]> I don’t know why sw numbering can’t match hw numbering. the /dev/bone numbering is yet another as it is meant to cover header-level, not soc-level.
Jun 16 14:21:00 <lorforlinux[m]1> <jkridner[m] "lorforlinux I am so sorry"> please don't be, it's okay you can answer my questions anytime you get free.
Jun 16 14:22:29 <lorforlinux[m]1> <jkridner[m] "i had a late night, but not late"> I had 3 hour sleep just before the meeting 😂
Jun 16 14:22:30 <jkridner[m]> What questions are outstanding?
Jun 16 14:23:20 <lorforlinux[m]1> Should I remove the aliases? what is the real purpose of their existence? how do i find out if it's okay to remove them?
Jun 16 14:25:43 <lorforlinux[m]1> BTW you agree that there non alignment with hardware is a problem for users right?
Jun 16 17:20:39 <jkridner[m]> <lorforlinux[m]1 "Should I remove the aliases? wha"> I don't know why they are there. Seems like a question for linux-omap. I think they are to create the indexes desired by mainline sw developers.
Jun 16 17:21:23 <jkridner[m]> <lorforlinux[m]1 "BTW you agree that there non ali"> yes and no. I don't like the sw indexes, but we do need separate entries to align on header position, vs soc.
Jun 16 17:27:46 <lorforlinux[m]1> Okiee no problemo, we can ignore them for now and work on what's necessary 👍 if you find anything interesting please let me know.
Jun 16 17:28:18 <lorforlinux[m]1> Got the i2c5 virtual cape working on BBAI.
Jun 16 17:55:10 <jkridner[m]> what is a "virtual cape"?
Jun 16 17:55:59 <lorforlinux[m]1> It's just to configure one bus with one overlay.
Jun 16 17:57:27 <lorforlinux[m]1> Needed for easy boot time pinmuxing ^
Jun 16 18:17:06 <ds2> i wonder if we can create a connector entity that does the mapping. so these overlays just ask for the connectors and not things like I2C
Jun 16 18:42:13 <lorforlinux[m]1> maybe, but I am not sure i can do that.
Jun 17 01:13:03 <lorforlinux[m]1> jkridner ds2 Abhishek_ pdp7 I have created virtual capes for all 4 UARTs of BBAI but only 2 are working correctly.
Jun 17 01:13:44 <lorforlinux[m]1> For UART10 and UART3 both RX and TX is working
Jun 17 01:14:20 <lorforlinux[m]1> For UART5 and UART8 only TX is working and i get gibberish on RX.
Jun 17 01:18:59 <jkridner[m]> <lorforlinux[m]1 "It's just to configure one bus w"> ah, yes, the interface overlays that aren't capes at all.
Jun 17 01:19:15 <lorforlinux[m]1> yes
Jun 17 01:19:31 <jkridner[m]> <lorforlinux[m]1 "jkridner ds2 Abhishek_ pdp7 I ha"> do these overlays produce common binaries between Black and AI?
Jun 17 01:19:57 <lorforlinux[m]1> <lorforlinux[m]1 "For UART5 and UART8 only TX is w"> I noticed that for both these RX pins there is also a UART TX pin (AB pins)
Jun 17 01:19:58 <jkridner[m]> just getting working overlays is certainly a nice start.
Jun 17 01:21:36 <lorforlinux[m]1> <jkridner[m] "do these overlays produce common"> no they do not I have created separate BBAI_ DT files, I have make some heavy changes to create one DT for both boards
Jun 17 01:22:27 <jkridner[m]> sure, just trying to make sure you are keeping the end goal in mind.
Jun 17 01:22:27 <lorforlinux[m]1> <jkridner[m] "just getting working overlays is"> What should i do to compile two dtbo files one for BBAI and BBB from single DT file?
Jun 17 01:22:48 <jkridner[m]> <lorforlinux[m]1 "What should i do to compile two "> don't do that.
Jun 17 01:23:38 <jkridner[m]> I think the big risk is figuring out how to map to the same peripheral names within the base dt files such that the overlay binaries can be the same.
Jun 17 01:25:31 <lorforlinux[m]1> <lorforlinux[m]1 "I noticed that for both these RX"> for example uart8_rxd is on P8.37B and uart6_txd on P8.37A, do you thing this might be causing the problem?
Jun 17 01:29:01 <lorforlinux[m]1> <jkridner[m] "I think the big risk is figuring"> how do i switch between {AM33xx and DRA7xx}IOPAD functions used for pinmuxing for the BBB and BBAI board?
Jun 17 01:29:18 <jkridner[m]> Make sure to double-check the https://dev.ti.com/sysconfig pinmux configuration, just to make sure pairs are valid.
Jun 17 01:29:56 <jkridner[m]> Certainly if 2 both buses are enabled and the alternate pin isn't in GPIO input-only mode, then there could be issues.
Jun 17 01:30:21 <jkridner[m]> I've seen the Driver-off mode on tied pins cause problems as the pull-ups/downs seem to be pretty strong.
Jun 17 01:30:53 <lorforlinux[m]1> the alternate pin is a GPIO and i also tried Driver-off :(
Jun 17 01:32:39 <jkridner[m]> double-check everything with show-pins.pl?
Jun 17 01:33:22 <lorforlinux[m]1> yes did that every time I rebooted.
Jun 17 01:34:03 <lorforlinux[m]1> I have set driver off and it's showing this
Jun 17 01:34:04 <lorforlinux[m]1> P9.11b                   136   B8 0 slow         vout1_d17
Jun 17 01:34:04 <lorforlinux[m]1> P9.11a                   203  B19 4 fast rx      uart5_rxd        serial@48066000 (pinmux_bb_uart5_pins)
Jun 17 01:34:41 <lorforlinux[m]1> should vout1_d17 be Driver-off ? I see that for some pins
Jun 17 01:35:08 <jkridner[m]> I'd set it to gpio mode, input only.
Jun 17 01:35:18 <jkridner[m]> the vout1_d17 mode isn't good to have.
Jun 17 01:35:59 <lorforlinux[m]1> Okay I tried to set Driver-off on that pin but i will try again
**** ENDING LOGGING AT Wed Jun 17 02:59:57 2020