**** BEGIN LOGGING AT Thu Sep 16 03:00:05 2021
Sep 16 13:41:17 <kveremitz> probably availability of cheap dram for other users
Sep 16 13:41:28 <kveremitz> or .. not.
Sep 16 13:41:52 <kveremitz> I mean,, "normal" availability, not "covid-availability"
Sep 16 13:42:20 <kveremitz> stupid virus :D
Sep 16 13:42:29 <kveremitz> really screwed with us
Sep 16 14:21:21 <zmatt> *shrug* there's undoubtedly reasons
Sep 16 14:40:32 <zmatt> it does support quite high clock speeds compared to ddr4 on am64xx/am65xx
Sep 16 16:48:14 <the_person48> hey guys, I am running debian 9.5 on a beaglebone black rev C. I am trying to change the configuration of one of the GPIO pins at boot using a device tree overlay. I followed this example: https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/compiling-an-overlay succesfully compiled it, and loaded it on boot by modifying
Sep 16 16:48:14 <the_person48> /boot/uEnv.txt
Sep 16 16:48:36 <the_person48> I confirmed that it is changing pin configurations with the show-pins utility, but am now trying to get one pin into the mode I want, and am having trouble
Sep 16 16:49:29 <zmatt> ughh, magic hex constants
Sep 16 16:49:34 <the_person48> the mode is a hex number representing 7 bits, each of which toggle a different mode: http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/
Sep 16 16:49:35 <the_person48> yup
Sep 16 16:50:02 <zmatt> the_person48: use either the bb.org-overlays repo or my overlay-utils repo, they have macros and constants for pin configuration
Sep 16 16:52:08 <the_person48> ok, I think I might have actually installed the former yesterday
Sep 16 16:53:08 <the_person48> is the usage similar?
Sep 16 16:53:29 <zmatt> you can clone either of those from git... bb.org-overlays uses mainline macros (mostly), my overlay-utils has different macros (for historical reasons) that are overall cleaner and less verbose
Sep 16 16:54:55 <zmatt> e.g. spi0 pinmux example in overlay-utils: https://github.com/mvduin/overlay-utils/blob/master/spi0.dtsi#L24-L27
Sep 16 16:55:38 <the_person48> ok, I think I might have actually used one of these a long time ago. I was previously running ubuntu and trying to do the same thing, and this forum pointed me to one of them. Here is a paste of the beginning of the .dtsi file I ended up with:
Sep 16 16:55:39 <the_person48> https://pastebin.com/rBUQfU2G
Sep 16 16:55:41 <zmatt> same pinmux in bb.org-overlays: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPIDEV0-00A0.dts#L36-L39
Sep 16 16:55:53 <the_person48> do you know which library that goes along with? or is it either?
Sep 16 16:55:55 <zmatt> that's definitely overlay-utils
Sep 16 16:56:01 <the_person48> ok, I'll use that one then
Sep 16 16:56:19 <the_person48> I just wasn't sure if this would still work on the different OS, do you think it's ok for debian 9.5?
Sep 16 16:56:21 <zmatt> it's not really a "library", mostly just a makefile and some include files containing macros
Sep 16 16:56:39 <zmatt> debian release is irrelevant, kernel is all that matters
Sep 16 16:57:18 <the_person48> gotcha
Sep 16 16:57:27 <zmatt> your paste is clearly derived from: https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi
Sep 16 16:57:30 <the_person48> 4.14
Sep 16 16:57:49 <the_person48> yeah that looks like the one I used!
Sep 16 16:58:06 <the_person48> ok, so I clone the overlay-utils
Sep 16 16:58:19 <the_person48> put in my .dtsi file, then I think there's a way to compile it?
Sep 16 16:58:20 <zmatt> and most things you might do in overlays are not highly sensitive to exact kernel version
Sep 16 16:58:27 <zmatt> make whatever.dtbo
Sep 16 16:58:28 <the_person48> then load it /boot/uEnv.txt?
Sep 16 16:58:35 <the_person48> cool
Sep 16 17:06:41 <the_person48> does it matter where I put the .dtbo file?
Sep 16 17:06:56 <the_person48> or just any directory as long as I point to it with the /boot/uEnv.txt file?
Sep 16 17:07:15 <zmatt> yep
Sep 16 17:07:30 <rcn-ee> the_person48, you can specify full path.. .otherwise it looks under /lib/firmware/ and /boot/dtbs/<uname0r>/overlays/
Sep 16 17:09:50 <the_person48> ok cool, thanks
Sep 16 17:13:47 <rcn-ee> the_person48, err wait... how old was your u-boot... those "other" directories might not be supported..
Sep 16 17:14:08 <rcn-ee> we needed it for GSOC last summer, so the build must be last August 2020..
Sep 16 17:14:26 <zmatt> absolute path is generally fine anyway
Sep 16 17:15:24 <rcn-ee> i had /lib/firmware/ hard-coded for a few years in u-boot... (before the change last year..)
Sep 16 17:25:20 <the_person48> I'm not sure how old it is
Sep 16 17:25:31 <the_person48> but I tried /lib/firmware and the overlay appears to have loaded
Sep 16 17:25:55 <rcn-ee> no matter how old, /lib/firwmare/ will work..
Sep 16 17:26:03 <the_person48> ok, I'll just keep using that then
Sep 16 17:26:11 <zmatt> and if you use an absolute path then which directory you use doesn't matter at all
Sep 16 17:26:18 <the_person48> oh I see
Sep 16 17:26:22 <the_person48> yeah I'm doing that as well, haha
Sep 16 17:26:26 <the_person48> yay for redundancy!
Sep 16 17:26:39 <rcn-ee> Things got interesting when we got "kernel" specific overlays...
Sep 16 17:26:52 <rcn-ee> (or just EOL older kernels faster..)
Sep 16 17:26:52 <the_person48> yeah that sounds difficult
Sep 16 17:27:03 <zmatt> I'd personally probably avoid /lib/firmware/ given that that's where standard overlays get installed, so putting custom overlays elsewhere avoids worrying about name conflicts
Sep 16 17:27:28 <the_person48> ok, maybe I'll just make a new folder then, and use the absolute path
Sep 16 17:28:22 <zmatt> ultimately though it's up to you, put it whereever you think is convenient
Sep 16 17:28:27 <the_person48> ok, so it looks like my old overlay is working, the show-pins | sort now has, for example "lo >> dcdc_pwr_on"
Sep 16 17:28:36 <the_person48> dcdc_pwr_on is my custom name
Sep 16 17:29:07 <zmatt> while testing I generally point the path straight into my overlay-utils dir so I only have to remake the dtbo after changing the source code and don't need to copy it anywhere... laziness \o/
Sep 16 17:29:09 <the_person48> so I'm able to control input or output, and if it starts low or high. is this second part analagous to the pull up/pull down?
Sep 16 17:29:18 <zmatt> no
Sep 16 17:29:19 <the_person48> ah, that makes sense
Sep 16 17:29:57 <the_person48> or is the pull part handled in the second half of the dtsi file where it says like PIN_NOPULL(P8_11,7)
Sep 16 17:29:58 <the_person48> for example
Sep 16 17:30:22 <zmatt> init-low/high configures the initial output level of a gpio that's configured to be output-only (or bidirectional but initially output), since you can't make a gpio an output without telling what to output
Sep 16 17:30:44 <the_person48> ok I see
Sep 16 17:30:57 <zmatt> internal pull is not handled by the gpio module but by pinmux, specifically PIN_NOPULL vs PIN_PULLUP vs PIN_PULLDN
Sep 16 17:31:14 <zmatt> the primary purpose is to ensure input pins don't float
Sep 16 17:32:12 <zmatt> whenever the output driver is active on a pin the configured internal pull-up/down is ignored
Sep 16 17:32:20 <the_person48> gotcha
Sep 16 17:32:31 <the_person48> ok I see
Sep 16 17:32:34 <zmatt> (so having internal pull on an output-only pin does not increase power consumption)
Sep 16 17:32:43 <the_person48> and does any of this control the "slew control"
Sep 16 17:32:44 <the_person48> ?
Sep 16 17:33:08 <the_person48> I'm not sure exactly what that is or if it matters but that's the only difference I see between the settings here and with the incovenient hex value
Sep 16 17:33:31 <rcn-ee> slew control is special pin mode on top of everything else.. i2c seems ot be the only user... (sometimes)
Sep 16 17:33:57 <zmatt> the_person48: https://github.com/mvduin/overlay-utils/blob/master/include/subarctic/pinctrl.h#L16-L18
Sep 16 17:34:15 <the_person48> ok got it
Sep 16 17:34:19 <the_person48> thanks
Sep 16 17:34:49 <zmatt> my current macros just always set INPUT_EN since the utility of disabling input on a pin is questionable
Sep 16 17:35:29 <rcn-ee> INPUT_EN is cool, it allows some of the crazy things config-pin does to work..
Sep 16 17:35:31 <the_person48> ok
Sep 16 17:35:39 <zmatt> (and some output-only pins actually require input to be enabled, e.g. spi sclk)
Sep 16 17:35:41 <zmatt> rcn-ee: what do you mean?
Sep 16 17:35:47 <the_person48> and what is the default for slew if I don't set anything explicitly?
Sep 16 17:35:58 <zmatt> fast, slew should almost always be fast
Sep 16 17:36:06 <the_person48> ok
Sep 16 17:36:36 <rcn-ee> zmatt, randonly changing from gpio, can, i2c, usart... stuff a normal person shouldn't do..
Sep 16 17:36:45 <zmatt> rcn-ee: what does that have to do with input_en ?
Sep 16 17:37:26 <rcn-ee> In a case you have it set as output, but then rx something on the same pin, that other perheripal, still gets it..
Sep 16 17:38:01 <zmatt> not afaik, if you configure a pin to non-gpio mode with input enabled you still can't monitor the pin via the gpio controller
Sep 16 17:38:04 <zmatt> annoyingly
Sep 16 17:38:11 <zmatt> that worked on the dm814x. but not on the am335x
Sep 16 17:41:50 <zmatt> the_person48: the am335x datasheet mentions that all timing values in the datasheet assume pins are configured to fast slew
Sep 16 17:44:53 <zmatt> rcn-ee: and pru definitely also just sees all-zeros on its input if no pins are muxed to pruin
Sep 16 17:45:16 <zmatt> so no, input_en is purely for the peripheral selected by the mux mode
Sep 16 17:45:45 <zmatt> and keeping it enabled for everything is just simpler, no need to think
Sep 16 18:36:04 <the_person48> notably, I tried making my own directory, ~/boot_overlays
Sep 16 18:36:11 <the_person48> and put the dtbo in there
Sep 16 18:36:23 <the_person48> adjusted the /boot/uEnv.txt file to point to the absolute path
Sep 16 18:36:35 <the_person48> but that made it so the overlay didn't load for some reason
Sep 16 18:36:42 <the_person48> still works when I have it in /lib/firmware though
Sep 16 19:05:22 <the_person48> any idea why that might be?
Sep 16 19:08:43 <the_person48> also, looks like I am trying to change the slew rate to slow after all
Sep 16 19:09:10 <the_person48> I see macros defined to basically set the default as SLEW_FAST here: https://github.com/mvduin/overlay-utils/blob/master/include/subarctic/pinctrl.h#L16-L18
Sep 16 19:10:14 <the_person48> what's the best way to change that to slow? should I actually modify the pinctrl.h file and change the macro itself, or is there a way to do it within the .dtsi overlay that will manually choose slew slow without using the macros?
Sep 16 19:43:31 <vd> what are led0 and led1 on the beaglebone black?
Sep 16 20:02:56 <the_person48> looks like they are in /sys/class/leds
Sep 16 20:03:17 <the_person48> not sure which is which but there are only four in there for me: beaglebone:green:usr0
Sep 16 20:03:20 <the_person48> (through 3)
Sep 16 20:13:05 <the_person48> also, I'm running into an issue configuring pin 9_15 using the overlay-utils overlay I've made
Sep 16 20:13:48 <the_person48> when I try to make it it tells me "unable to parse input tree". this error goes away when I comment out the line in the pinmux:
Sep 16 20:14:11 <the_person48> PIN_NOPULL( P9_15, 7 ) // gpio 1.16
Sep 16 20:14:32 <the_person48> but the weird thing is that almost exactly that same code is working and causing no errors for the pin right next to it:
Sep 16 20:14:53 <the_person48> PIN_NOPULL( P9_14, 7 ) // gpio 1.18
Sep 16 20:15:17 <the_person48> any idea what might be causing the issue with the  P9_15 line?
Sep 16 21:09:09 <zmatt> the_person48: P9_15 connects to two pins of the am335x: https://github.com/mvduin/overlay-utils/blob/master/include/bone/black.h#L77-L78
Sep 16 21:09:25 <zmatt> (same goes for P9_41 and P9_42)
Sep 16 21:09:48 <zmatt> it's unfortunate dtc gives such a terrible and uninformative error message
Sep 16 21:25:39 <the_person48> oh, so I have to use P9_15a or b?
Sep 16 21:28:15 <the_person48> and yeah it is confusing, I just change things one at a time so I know what breaks stuff
Sep 16 21:32:04 <the_person48> I tried changing it P9_15a and it compiles now!
Sep 16 21:32:23 <the_person48> what's the difference? not sure if I should be using 9_15a or b
Sep 16 21:38:48 <the_person48> I see now that there are two entries in show-pins, P9_15a changed the first one
Sep 16 21:39:03 <the_person48> but still curious if I should be changing both, or just one, or how to choose
Sep 16 21:54:45 <zmatt> they're different pins with different functionality, so you which one to configure is up to your needs.  I personally also prefer to always configure both processor pins in this case, just to make sure they're both claimed in the kernel's bookkeeping, e.g.: https://github.com/mvduin/overlay-utils/blob/master/spi1.dtsi#L36-L37
Sep 16 22:01:39 <the_person48> ok, I'll do both then, thanks!
Sep 16 22:02:20 <the_person48> what's the best way to adjust the slew control to slow? I'm looking at this file you linked earlier: https://github.com/mvduin/overlay-utils/blob/master/include/subarctic/pinctrl.h#L16-L18
Sep 16 22:02:32 <the_person48> should I just change the macro definition in this file?
Sep 16 22:02:43 <the_person48> or is there a way to manually change it per-pin in the dtsi overlay?
Sep 16 22:03:55 <zmatt> why exactly do you need to?
Sep 16 22:04:14 <the_person48> I'm not sure, but my electrical engineering coworker asked me to
Sep 16 22:04:21 <the_person48> he said it will reduce "ringing", or something like that
Sep 16 22:06:25 <zmatt> "the timing parameters provided in the data sheet were validated with slew rate set to fast and may not be valid when set to slow.  Since the device was not validated for slow slew rate, data related to this setting is not provided in the data sheet.  So yes, it is implying you should only use fast slew rate"
Sep 16 22:06:40 <zmatt> "We also determined the IO cells used in AM335x were not providing any significant change in slew rate. Therefore, there wasn't any value in characterizing the device while operating in slow mode."
Sep 16 22:06:57 <zmatt> "We do not recommend using slow mode and there is no data for slow mode because of the reasons mentioned above."
Sep 16 22:07:06 <zmatt> -- TI support
Sep 16 22:07:31 <the_person48> ok interesting
Sep 16 22:07:46 <the_person48> I'll give that to him and only change it if we prove that we have to
Sep 16 22:07:58 <the_person48> if I do end up needing to change it though, what's the best way?
Sep 16 22:10:00 <zmatt> e.g.  PIN_PULLUP( P9_26, 3 | SLEW_SLOW )  would work
Sep 16 22:10:13 <the_person48> ok got it
Sep 16 22:10:14 <the_person48> thanks
Sep 16 22:19:05 <the_person48> another issue I'm having: my overlays don't work when I put them in a custom folder, ~/boot_overlays
Sep 16 22:19:14 <the_person48> but they do work when I put them in /lib/firmware
Sep 16 22:19:28 <zmatt> while specifying the full path to the .dtbo in /boot/uEnv.txt ?
Sep 16 22:19:32 <the_person48> in both cases I'm using the full absolute path to load them in /boot/uEnv.txt
Sep 16 22:19:40 <the_person48> any idea why that might be?
Sep 16 22:20:43 <zmatt> none whatsoever, that sounds bizarre to me.  there's zero reason for u-boot to care where you put them when specifying the full path, and I've never had any problem using a custom location
Sep 16 22:22:18 <the_person48> ok
Sep 16 22:22:31 <the_person48> fortunately it's not that big of a deal
Sep 16 22:25:23 <the_person48> ok, another question: I'm trying to configure P9.11,13,21,22,24, and 26 as UARTs
Sep 16 22:25:39 <the_person48> is this just done by specifying the correct mode in the pinmux?
Sep 16 22:25:57 <the_person48> like I see P9.11 is support to be a UART in mode 6, so I can just:
Sep 16 22:26:35 <zmatt> https://github.com/mvduin/overlay-utils/blob/master/uart4.dtsi
Sep 16 22:27:23 <zmatt> (you can optionally omit the "USES_PIN" declarations if you cape-universal globally disabled anyway)
Sep 16 22:27:32 <the_person48> I did
Sep 16 22:27:45 <zmatt> I know, that's why I mentioned it
Sep 16 22:27:46 <the_person48> ok, so I declare it as a separate group from the GPIO pins then
Sep 16 22:27:49 <the_person48> awesome
Sep 16 22:28:12 <zmatt> you should have a pinmux block per device that needs pinmux
Sep 16 22:28:17 <the_person48> and then I assume I2C is similar? trying to do those on P19/20
Sep 16 22:28:33 <the_person48> and my memory is that the analog pins are not configurable, so they should be good by default?
Sep 16 22:28:35 <zmatt> the i2c bus on P9.19/20 is setup in the base dts
Sep 16 22:28:54 <the_person48> ok, so if I do nothing then the i2c should be right by default?
Sep 16 22:29:19 <zmatt> analog pins are indeed not configurable, though I don't think the adc is enabled by default if cape-universal is disabled so you do still need to do that
Sep 16 22:29:51 <zmatt> yeah, &i2c2 will be enabled by default
Sep 16 22:30:24 <the_person48> ok, so good on i2c's
Sep 16 22:30:39 <the_person48> is enabling adc done in the /boot/uEnv.txt?
Sep 16 22:32:21 <zmatt> so, I don't know for sure whether or not the adc is setup by cape-universal or by some other overlay, it might actually be some other overlay in which case you don't need to do anything unless you want to override whatever the default config is
Sep 16 22:33:00 <zmatt> now that I think of it, I do think it's enabled by a separate overlay since there's a setting for that in /boot/uEnv.txt
Sep 16 22:33:05 <the_person48> ok, it sounds like it's probably already good, but is there a way to check?
Sep 16 22:33:21 <zmatt> check if the adc shows up as device?
Sep 16 22:33:24 <zmatt> as iio device
Sep 16 22:33:27 <the_person48> i.e. check if the adc pins are already the way we want them
Sep 16 22:33:27 <the_person48> yeah
Sep 16 22:33:44 <zmatt> there's nothing to configure about the pins, just the adc itself
Sep 16 22:33:48 <the_person48> I don't think we're trying to do anything weird with them, just want to make sure they work
Sep 16 22:34:02 <the_person48> ok, so just add that udev rule then to access the adc pins?
Sep 16 22:34:09 <zmatt> what udev rule?
Sep 16 22:34:47 <the_person48> previously you suggested I add a udev rule to rename the adc pins as symlinks and make them accessible to read from the file tree
Sep 16 22:34:57 <the_person48> I'll look for the rule, one sec
Sep 16 22:35:11 <zmatt> no but I did make one that makes a symlink for the adc itself
Sep 16 22:35:23 <zmatt> https://pastebin.com/bE6YLNny   that
Sep 16 22:35:38 <the_person48> ah yeah I'm pretty sure that was it
Sep 16 22:36:05 <the_person48> so just add that? and then there was a similar one for gpios I was using
Sep 16 22:36:15 <the_person48> that let us access them via /dev/gpio/P9_27, etc.
Sep 16 22:36:34 <the_person48> is that compatible with overlay-utils or does the overlay change things?
Sep 16 22:37:43 <zmatt> why would an udev rule care about how exactly the device tree came about?  it looks at the final result, it doesn't know or care about the concept of overlays
Sep 16 22:38:03 <zmatt> also you have already observed that it works
Sep 16 22:38:30 <the_person48> gotcha
Sep 16 22:38:35 <the_person48> ok, so I'll add that on top then
Sep 16 22:38:58 <zmatt> or maybe I misremembered? didn't you already access it that way?
Sep 16 22:38:59 <the_person48> I just thought it might conflict with the names that the overlay gives it, or something like that
Sep 16 22:39:16 <the_person48> I did, but I'm redoing stuff on a new OS so I haven't done the udev rules yet
Sep 16 22:39:22 <the_person48> I will add it soon
Sep 16 22:39:25 <zmatt> no it _depends_ on the gpios being given names via DT
Sep 16 22:39:32 <the_person48> ok
Sep 16 22:39:47 <zmatt> that's the whole purpose of the rule, to make gpios accessible using their DT-declared name
Sep 16 22:40:01 <the_person48> ah
Sep 16 22:40:02 <zmatt> also, the rule is explicitly shown in the comments in overlay-utils gpio-demo.dtsi
Sep 16 22:40:20 <the_person48> interesting
Sep 16 22:40:29 <zmatt> https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi#L8-L14
Sep 16 22:40:40 <the_person48> so if I want to refer to them by number, like P9_27, P8_28, etc.
Sep 16 22:41:04 <zmatt> those aren't numbers, those are the names given to them by cape-universal
Sep 16 22:41:15 <zmatt> (since it has no better way to name gpios)
Sep 16 22:41:19 <the_person48> then I should just have those as the names in the top grouping section?
Sep 16 22:41:21 <the_person48> ok
Sep 16 22:41:28 <the_person48> right now I have names like test_name_1
Sep 16 22:41:42 <the_person48> but I think I just want to refer to them by their physical pin location, like P9_27
Sep 16 22:41:47 <zmatt> I'd suggest using names that actually reflect the function of the gpio, not the physical location
Sep 16 22:42:15 <the_person48> We intend to do that in a higher level in our code
Sep 16 22:42:26 <the_person48> cause then it'll more accessible
Sep 16 22:42:36 <the_person48> ideally would like to get the boot configuration right and then not have to mess with it again
Sep 16 22:43:01 <zmatt> that way you can easily move gpios around in a future hw revision (e.g. to free up pins which you need for other functionality) and you'd only need to update the DT while software doesn't need to know or care where exactly the gpio is connected
Sep 16 22:43:41 <zmatt> I mean, that's up to you I guess, I personally prefer not having to hardcode such details into the software
Sep 16 22:43:45 <the_person48> gotcha
Sep 16 22:43:49 <zmatt> and that choice has already paid off for me
Sep 16 22:43:51 <the_person48> yeah, I get where you're coming from
Sep 16 22:44:08 <the_person48> but I think we would rather make the naming change in our software rather than in the DT overlay
Sep 16 22:45:50 <zmatt> well we have both hardware revisions out there in the field so our software needs to support both, despite things having moved around significantly
Sep 16 22:46:18 <zmatt> it unfortunately still needed some logic to differentiate between the two, but most of it is agnostic
Sep 16 22:46:48 <the_person48> gotcha
Sep 16 22:47:58 <zmatt> (e.g. it opens the /dev/spi/dsp device, without having to know that was spi0 cs1 on the old revision versus spi1 cs0 on the new revision)
Sep 16 23:01:37 <the_person48> yeah that makes sense
Sep 16 23:11:58 <the_person48> ok, so I'm trying to make P9_11 and P9_13 UART4, just like in this example:
Sep 16 23:11:58 <the_person48> https://github.com/mvduin/overlay-utils/blob/master/uart4.dtsi
Sep 16 23:12:21 <the_person48> I removed all other references to them, and then just copy/pasted the code from the example
Sep 16 23:12:33 <the_person48> the uart4_pins: uart4 part inside the pinmux
Sep 16 23:12:38 <the_person48> and the &uart4 bit at the end
Sep 16 23:12:56 <the_person48> I left out the two lines about uses_pin at the top but thought they were unnecessary cause I've disabled cape universal
Sep 16 23:13:31 <zmatt> I generally prefer keeping the pinmux block for a peripheral together with the peripheral itself (it's fine to have multiple &am33xx_pinmux { .. }; sections), but that's just aesthetic preference
Sep 16 23:13:33 <the_person48> the new overlay compiles, but after referencing it, and rebooting, P9.11/13 still aren't showing up as UARt with show-pins
Sep 16 23:13:53 <the_person48> that makes sense, for readability
Sep 16 23:13:59 <zmatt> well then something is wrong :)  maybe check kernel log
Sep 16 23:14:13 <the_person48> but I already had a &am33xx_pinmux section, so I wasn't sure if I could have another one?
Sep 16 23:14:16 <the_person48> ok
Sep 16 23:14:44 <the_person48> is that the sudo /opt/scripts/tools/version.sh thing?
Sep 16 23:14:56 <the_person48> was using that to troubleshoot /boot/uEnv.txt before
Sep 16 23:14:56 <zmatt> journalctl -k
Sep 16 23:14:58 <zmatt> or dmesg
Sep 16 23:16:08 <zmatt> the typical reason pinmux might not apply is if there's conflicting pinmux, which would cause an error in the kernel log... though that can usually also be recognized by checking with show-pins (which would show one or more of the pins being in use)
Sep 16 23:16:44 <the_person48> gotcha, there's only one P9.11 and P9.13 in show-pins
Sep 16 23:16:49 <the_person48> checking the kernel log now
Sep 16 23:17:14 <zmatt> not sure what you mean by that
Sep 16 23:17:19 <the_person48> https://pastebin.com/hPdV5SPx
Sep 16 23:17:44 <the_person48> I thought you were saying that if that was the issue, P9.11 and P9.13 might show up twice in show-pins
Sep 16 23:17:48 <zmatt> no
Sep 16 23:17:49 <the_person48> like they're trying to be used by two things?
Sep 16 23:17:53 <the_person48> but maybe I misunderstood
Sep 16 23:17:56 <zmatt> you did
Sep 16 23:18:10 <zmatt> also the tiny fragment you pasted from your kernel log is not a useful fragment
Sep 16 23:18:32 <the_person48> oh oops
Sep 16 23:18:37 <the_person48> sorry I thought that was all
Sep 16 23:21:04 <zmatt> whether pins are used or not is recognized in show-pins output by the pin being in gpio mode, grayed out, with no info about anything using the pin in the rightmost columns, e.g. like P8.07-10 in https://github.com/mvduin/bbb-pin-utils/blob/master/doc/images/show-pins-sorted.png
Sep 16 23:21:35 <zmatt> those are unused pins, while if a pin is in use (according to the kernel's worldview) there will be info there
Sep 16 23:22:05 <the_person48> https://pastebin.com/S7ykrWaA
Sep 16 23:22:08 <the_person48> ok here's the full output
Sep 16 23:22:54 <the_person48> and ok, yeah P9.11/P9.13 are showing up as grayed out gpio mode, no info on the right, in show pins
Sep 16 23:22:56 <the_person48> just like you said
Sep 16 23:23:01 <zmatt> looks like you messed up the uart4 declaration somehow
Sep 16 23:23:06 <the_person48> ok
Sep 16 23:23:24 <the_person48> let me investigate
Sep 16 23:23:30 <zmatt> specifically, looks like you put the pinmux node in / instead of in &am33xx_pinmux
Sep 16 23:23:54 <zmatt> "could not find pctldev for node /uart4"
Sep 16 23:24:10 <the_person48> oh yep you're right
Sep 16 23:24:13 <the_person48> thanks
Sep 16 23:25:49 <zmatt> there's also something weird going on with your kernel parameter, u-boot is failing to inform the kernel that u-boot overlays are being used and the deprecated obsolete bone_camegr should be disabled
Sep 16 23:26:09 <the_person48> oh interesting
Sep 16 23:26:29 <the_person48> maybe an issue with my /boot/uEnv.txt?
Sep 16 23:26:58 <zmatt> dunno, no idea what could cause that
Sep 16 23:27:02 <the_person48> ok
Sep 16 23:27:11 <zmatt> but it's not good
Sep 16 23:27:14 <the_person48> well I adjusted the first issue and am rebooting so we'll see if that works
Sep 16 23:27:20 <the_person48> ok
Sep 16 23:28:16 <zmatt> my first thought was that maybe you disabled u-boot overlays and were actually using bone_capemgr, but it doesn't look like that's the case so dunno how u-boot overlays can be enabled yet "bone_capemgr.uboot_capemgr_enabled=1" be missing the kernel cmdline
Sep 16 23:28:44 <the_person48> ok they're showing up as UARTs now so that's good!
Sep 16 23:28:54 <the_person48> weird
Sep 16 23:29:07 <the_person48> I'll send my /boot/uEnv.txt just in case there's something obvious there
Sep 16 23:29:11 <the_person48> will reexamine as well
Sep 16 23:30:28 <the_person48> https://pastebin.com/KiEZJWPu
Sep 16 23:31:20 <zmatt> oh, I do see why your attempt to use a custom directory didn't use:  you can't abbreviate /home/debian to ~
Sep 16 23:31:36 <the_person48> ahhh
Sep 16 23:31:42 <zmatt> ~ is the home directory of the current user... wtf would the "current user" be to a bootloader? :P
Sep 16 23:32:09 <the_person48> gotcha, that makes sense
Sep 16 23:32:11 <the_person48> didn't think about that
Sep 16 23:32:40 <the_person48> but yeah I'm not seeing any reason for kernel weirdness here at least
Sep 16 23:32:53 <zmatt> and I don't see anything here that explains the wrong kernel cmdline, unless it's just a broken/obsolete u-boot version
Sep 16 23:32:58 <the_person48> got cape universal commented out
Sep 16 23:33:03 <the_person48> that's possible
Sep 16 23:33:08 <the_person48> I am on an old version of debian
Sep 16 23:33:24 <zmatt> you haven't updated u-boot ?
Sep 16 23:33:42 <the_person48> I don't think so
Sep 16 23:33:44 <the_person48> should I?
Sep 16 23:34:00 <the_person48> trying to figure out how to check u-boot version
Sep 16 23:34:27 <zmatt> I'm a bit surprised there's any version of u-boot that supports overlays yet doesn't add the bone_capemgr.uboot_capemgr_enabled=1 kernel parameter, makes me wonder if u-boot overlays was still in development/prototyping at the time of whatever u-boot release you have
Sep 16 23:34:38 <zmatt> that version.sh script includes u-boot version in its output
Sep 16 23:35:37 <zmatt> btw, unrelated to everything, I suggest adding  rng_core.default_quality=100  to the list of options in the 'cmdline' variable, that allows the system to use the hardware random number generator
Sep 16 23:36:10 <the_person48> ok, I'll get that output
Sep 16 23:36:28 <the_person48> ok, and what is the purpose of that?
Sep 16 23:37:08 <zmatt> random numbers are needed for lots of things both in the kernel and in userspace, and having the hw rng available means there's always a good source of randomness available
Sep 16 23:37:30 <the_person48> gotcha
Sep 16 23:37:50 <the_person48> and is the source of randomness "bad" otherwise?
Sep 16 23:37:59 <the_person48> like seeded repeatably or something like that?
Sep 16 23:38:22 <zmatt> yes and can lead to warnings or the system waiting until more entropy is available in some cases
Sep 16 23:38:29 <the_person48> ok gotcha
Sep 16 23:38:54 <the_person48> https://pastebin.com/FUbKC0CH
Sep 16 23:39:00 <the_person48> here's the output of the version.sh script
Sep 16 23:39:47 <zmatt> 2018.03-00002-gac9cce7c6a
Sep 16 23:39:49 <zmatt> pretty old
Sep 16 23:46:33 <the_person48> ok, what's the best way to update it?
Sep 16 23:46:45 <the_person48> and will it mess up compatibility with debian 9.5?
Sep 16 23:46:57 <the_person48> cause my coworkers want me to use that OS
Sep 16 23:57:09 <zmatt> u-boot doesn't interact with userspace so your debian release isn't hugely important
Sep 16 23:57:30 <zmatt> why exactly are you using an ancient version of debian anyway?
Sep 17 00:03:27 <the_person48> my coworkers have used it succesfully for some other project before
Sep 17 00:03:37 <the_person48> and they don't want to update cause they know it worked then
Sep 17 00:03:46 <the_person48> so I'm stuck using it unless I show it can't work for some reason
Sep 17 00:03:48 <zmatt> /o\
Sep 17 00:04:03 <the_person48> but yeah, I'd rather use 10
Sep 17 00:04:08 <zmatt> are they also still using Windows XP ?
Sep 17 00:04:12 <the_person48> ahahaha
Sep 17 00:04:21 <the_person48> it took a long time to update to windows 10 haha
Sep 17 00:04:23 <the_person48> you joke but
Sep 17 00:04:29 <the_person48> were on windows 7 for a while
Sep 17 00:04:43 <the_person48> how do I update uboot? is it a sudo apt thing?
Sep 17 00:05:27 <zmatt> like, starting with an uptodate system is always easier than updating later on in a project... starting out with something that's already obsolete during development just sounds like a future maintenance nightmare
Sep 17 00:06:10 <zmatt> I think there's a script, though I've generally done it manually
Sep 17 00:06:22 <zmatt> bbl, distracted
Sep 17 00:06:31 <the_person48> ok, sounds good
Sep 17 00:06:33 <the_person48> no rush
Sep 17 00:06:42 <the_person48> also, I added the udev rules for pin names
Sep 17 00:06:49 <the_person48> worked for gpio, but /dev/adc isn't showing up
Sep 17 00:07:03 <the_person48> do you think it might be some issue with enabling adc in /boot/uEnv.txt?
Sep 17 00:07:14 <the_person48> I think the rule I used is exactly the same as the one I used succesfully before on the newer OS
Sep 17 00:29:38 <the_person48> I tried uncommenting disable_uboot_overlay_adc=1, but that didn't seem to work
Sep 17 00:40:37 <the_person48> ok yeah something weird is definitely going on with the udev rules
Sep 17 00:41:00 <the_person48> I tried renaming the pins to their physical positions (cause this is still what I want to call them by), like P9_15, etc.
Sep 17 00:41:28 <the_person48> but when I got to /dev/gpio, I get a lot of pins that are just named number, like 0, 1, 10, 105, etc.
Sep 17 00:41:53 <the_person48> I get P8_3-6,P9_15,19,20
Sep 17 00:42:03 <the_person48> and then don't have the right total number that I set either
Sep 17 00:42:16 <the_person48> any idea what might be going wrong? not sure if it's a problem with my overlay or udev rule
Sep 17 00:42:36 <the_person48> I used the same udev rule from before that seemed to be working then though, on the newer OS, with no overlay
Sep 17 02:48:11 <vd> what is the &ldo3_reg device tree node?
**** ENDING LOGGING AT Fri Sep 17 02:59:56 2021