<zmatt>
jkridner: I do wonder why TI chose to put lpddr4 on the j721 instead of something with better availability like ddr3 or ddr4... I can't imagine that saving a bit of power consumption on ram is that important in automotive applications
starblue1 has quit [Ping timeout: 268 seconds]
starblue1 has joined #beagle
GenTooMan has quit [Ping timeout: 268 seconds]
GenTooMan has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
vagrantc has quit [Quit: leaving]
Shadyman has quit [Remote host closed the connection]
otisolsen70 has joined #beagle
CrazyEddy has joined #beagle
ikarso has joined #beagle
giort has joined #beagle
giort has quit [Ping timeout: 252 seconds]
blech has quit [Ping timeout: 240 seconds]
blech has joined #beagle
starblue1 has quit [Ping timeout: 252 seconds]
starblue1 has joined #beagle
florian has joined #beagle
starblue1 has quit [Ping timeout: 260 seconds]
starblue1 has joined #beagle
otisolsen70_ has joined #beagle
otisolsen70_ has quit [Remote host closed the connection]
otisolsen70 has quit [Ping timeout: 268 seconds]
<kveremitz>
probably availability of cheap dram for other users
<kveremitz>
or .. not.
<kveremitz>
I mean,, "normal" availability, not "covid-availability"
<kveremitz>
stupid virus :D
<kveremitz>
really screwed with us
otisolsen70 has joined #beagle
<zmatt>
*shrug* there's undoubtedly reasons
buzzmarshall has joined #beagle
<zmatt>
it does support quite high clock speeds compared to ddr4 on am64xx/am65xx
Shadyman has joined #beagle
otisolsen70 has quit [Read error: Connection reset by peer]
<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
<zmatt>
the_person48: use either the bb.org-overlays repo or my overlay-utils repo, they have macros and constants for pin configuration
Shadyman has quit [Remote host closed the connection]
Shadyman has joined #beagle
<the_person48>
ok, I think I might have actually installed the former yesterday
<the_person48>
is the usage similar?
<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
<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:
<the_person48>
yeah that looks like the one I used!
<the_person48>
ok, so I clone the overlay-utils
<the_person48>
put in my .dtsi file, then I think there's a way to compile it?
<zmatt>
and most things you might do in overlays are not highly sensitive to exact kernel version
<zmatt>
make whatever.dtbo
<the_person48>
then load it /boot/uEnv.txt?
<the_person48>
cool
buzzmarshall has quit [Quit: Konversation terminated!]
<the_person48>
does it matter where I put the .dtbo file?
<the_person48>
or just any directory as long as I point to it with the /boot/uEnv.txt file?
<zmatt>
yep
<rcn-ee>
the_person48, you can specify full path.. .otherwise it looks under /lib/firmware/ and /boot/dtbs/<uname0r>/overlays/
<the_person48>
ok cool, thanks
florian has quit [Quit: Ex-Chat]
<rcn-ee>
the_person48, err wait... how old was your u-boot... those "other" directories might not be supported..
<rcn-ee>
we needed it for GSOC last summer, so the build must be last August 2020..
<zmatt>
absolute path is generally fine anyway
<rcn-ee>
i had /lib/firmware/ hard-coded for a few years in u-boot... (before the change last year..)
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #beagle
<the_person48>
I'm not sure how old it is
<the_person48>
but I tried /lib/firmware and the overlay appears to have loaded
<rcn-ee>
no matter how old, /lib/firwmare/ will work..
<the_person48>
ok, I'll just keep using that then
<zmatt>
and if you use an absolute path then which directory you use doesn't matter at all
<the_person48>
oh I see
<the_person48>
yeah I'm doing that as well, haha
<the_person48>
yay for redundancy!
<rcn-ee>
Things got interesting when we got "kernel" specific overlays...
<rcn-ee>
(or just EOL older kernels faster..)
<the_person48>
yeah that sounds difficult
<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
<the_person48>
ok, maybe I'll just make a new folder then, and use the absolute path
<zmatt>
ultimately though it's up to you, put it whereever you think is convenient
<the_person48>
ok, so it looks like my old overlay is working, the show-pins | sort now has, for example "lo >> dcdc_pwr_on"
<the_person48>
dcdc_pwr_on is my custom name
<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/
<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?
<zmatt>
no
<the_person48>
ah, that makes sense
<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)
<the_person48>
for example
<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
<the_person48>
ok I see
<zmatt>
internal pull is not handled by the gpio module but by pinmux, specifically PIN_NOPULL vs PIN_PULLUP vs PIN_PULLDN
<zmatt>
the primary purpose is to ensure input pins don't float
<zmatt>
whenever the output driver is active on a pin the configured internal pull-up/down is ignored
<the_person48>
gotcha
<the_person48>
ok I see
<zmatt>
(so having internal pull on an output-only pin does not increase power consumption)
<the_person48>
and does any of this control the "slew control"
<the_person48>
?
<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
<rcn-ee>
slew control is special pin mode on top of everything else.. i2c seems ot be the only user... (sometimes)
<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?
<vd>
what are led0 and led1 on the beaglebone black?
<the_person48>
looks like they are in /sys/class/leds
<the_person48>
not sure which is which but there are only four in there for me: beaglebone:green:usr0
<the_person48>
(through 3)
Guest95 has joined #beagle
Guest95 has quit [Client Quit]
<the_person48>
also, I'm running into an issue configuring pin 9_15 using the overlay-utils overlay I've made
<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:
<zmatt>
it's unfortunate dtc gives such a terrible and uninformative error message
<the_person48>
oh, so I have to use P9_15a or b?
<the_person48>
and yeah it is confusing, I just change things one at a time so I know what breaks stuff
<the_person48>
I tried changing it P9_15a and it compiles now!
<the_person48>
what's the difference? not sure if I should be using 9_15a or b
<the_person48>
I see now that there are two entries in show-pins, P9_15a changed the first one
<the_person48>
but still curious if I should be changing both, or just one, or how to choose
M-blaise has quit [Ping timeout: 240 seconds]
M-blaise has joined #beagle
<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
<the_person48>
should I just change the macro definition in this file?
<the_person48>
or is there a way to manually change it per-pin in the dtsi overlay?
<zmatt>
why exactly do you need to?
<the_person48>
I'm not sure, but my electrical engineering coworker asked me to
<the_person48>
he said it will reduce "ringing", or something like that
<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"
<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."
<zmatt>
"We do not recommend using slow mode and there is no data for slow mode because of the reasons mentioned above."
<zmatt>
-- TI support
<the_person48>
ok interesting
<the_person48>
I'll give that to him and only change it if we prove that we have to
<the_person48>
if I do end up needing to change it though, what's the best way?
<zmatt>
e.g. PIN_PULLUP( P9_26, 3 | SLEW_SLOW ) would work
<the_person48>
ok got it
<the_person48>
thanks
<the_person48>
another issue I'm having: my overlays don't work when I put them in a custom folder, ~/boot_overlays
<the_person48>
but they do work when I put them in /lib/firmware
<zmatt>
while specifying the full path to the .dtbo in /boot/uEnv.txt ?
<the_person48>
in both cases I'm using the full absolute path to load them in /boot/uEnv.txt
<the_person48>
any idea why that might be?
<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
<the_person48>
ok
<the_person48>
fortunately it's not that big of a deal
<the_person48>
ok, another question: I'm trying to configure P9.11,13,21,22,24, and 26 as UARTs
<the_person48>
is this just done by specifying the correct mode in the pinmux?
<the_person48>
like I see P9.11 is support to be a UART in mode 6, so I can just:
<zmatt>
(you can optionally omit the "USES_PIN" declarations if you cape-universal globally disabled anyway)
<the_person48>
I did
<zmatt>
I know, that's why I mentioned it
<the_person48>
ok, so I declare it as a separate group from the GPIO pins then
<the_person48>
awesome
<zmatt>
you should have a pinmux block per device that needs pinmux
<the_person48>
and then I assume I2C is similar? trying to do those on P19/20
<the_person48>
and my memory is that the analog pins are not configurable, so they should be good by default?
<zmatt>
the i2c bus on P9.19/20 is setup in the base dts
<the_person48>
ok, so if I do nothing then the i2c should be right by default?
<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
<zmatt>
yeah, &i2c2 will be enabled by default
<the_person48>
ok, so good on i2c's
<the_person48>
is enabling adc done in the /boot/uEnv.txt?
<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
<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
<the_person48>
ok, it sounds like it's probably already good, but is there a way to check?
<zmatt>
check if the adc shows up as device?
<zmatt>
as iio device
<the_person48>
i.e. check if the adc pins are already the way we want them
<the_person48>
yeah
<zmatt>
there's nothing to configure about the pins, just the adc itself
<the_person48>
I don't think we're trying to do anything weird with them, just want to make sure they work
<the_person48>
ok, so just add that udev rule then to access the adc pins?
<zmatt>
what udev rule?
<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
<the_person48>
I'll look for the rule, one sec
<zmatt>
no but I did make one that makes a symlink for the adc itself
<the_person48>
ah yeah I'm pretty sure that was it
<the_person48>
so just add that? and then there was a similar one for gpios I was using
<the_person48>
that let us access them via /dev/gpio/P9_27, etc.
<the_person48>
is that compatible with overlay-utils or does the overlay change things?
blech has quit [Ping timeout: 260 seconds]
<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
<zmatt>
also you have already observed that it works
<the_person48>
gotcha
<the_person48>
ok, so I'll add that on top then
<zmatt>
or maybe I misremembered? didn't you already access it that way?
<the_person48>
I just thought it might conflict with the names that the overlay gives it, or something like that
<the_person48>
I did, but I'm redoing stuff on a new OS so I haven't done the udev rules yet
<the_person48>
I will add it soon
<zmatt>
no it _depends_ on the gpios being given names via DT
<the_person48>
ok
<zmatt>
that's the whole purpose of the rule, to make gpios accessible using their DT-declared name
<the_person48>
ah
<zmatt>
also, the rule is explicitly shown in the comments in overlay-utils gpio-demo.dtsi
<the_person48>
so if I want to refer to them by number, like P9_27, P8_28, etc.
<zmatt>
those aren't numbers, those are the names given to them by cape-universal
<zmatt>
(since it has no better way to name gpios)
<the_person48>
then I should just have those as the names in the top grouping section?
<the_person48>
ok
<the_person48>
right now I have names like test_name_1
<the_person48>
but I think I just want to refer to them by their physical pin location, like P9_27
<zmatt>
I'd suggest using names that actually reflect the function of the gpio, not the physical location
<the_person48>
We intend to do that in a higher level in our code
<the_person48>
cause then it'll more accessible
<the_person48>
ideally would like to get the boot configuration right and then not have to mess with it again
<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
<zmatt>
I mean, that's up to you I guess, I personally prefer not having to hardcode such details into the software
<the_person48>
gotcha
<zmatt>
and that choice has already paid off for me
<the_person48>
yeah, I get where you're coming from
<the_person48>
but I think we would rather make the naming change in our software rather than in the DT overlay
<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
<zmatt>
it unfortunately still needed some logic to differentiate between the two, but most of it is agnostic
<the_person48>
gotcha
<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)
rcn-ee has joined #beagle
<the_person48>
yeah that makes sense
<the_person48>
ok, so I'm trying to make P9_11 and P9_13 UART4, just like in this example:
<the_person48>
I removed all other references to them, and then just copy/pasted the code from the example
<the_person48>
the uart4_pins: uart4 part inside the pinmux
<the_person48>
and the &uart4 bit at the end
<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
<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
<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
<the_person48>
that makes sense, for readability
<zmatt>
well then something is wrong :) maybe check kernel log
<the_person48>
but I already had a &am33xx_pinmux section, so I wasn't sure if I could have another one?
<the_person48>
ok
<the_person48>
is that the sudo /opt/scripts/tools/version.sh thing?
<the_person48>
was using that to troubleshoot /boot/uEnv.txt before
<zmatt>
journalctl -k
<zmatt>
or dmesg
<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)
<the_person48>
gotcha, there's only one P9.11 and P9.13 in show-pins
<the_person48>
checking the kernel log now
ikarso has quit [Quit: Connection closed for inactivity]
<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
<the_person48>
just like you said
<zmatt>
looks like you messed up the uart4 declaration somehow
<the_person48>
ok
<the_person48>
let me investigate
<zmatt>
specifically, looks like you put the pinmux node in / instead of in &am33xx_pinmux
<zmatt>
"could not find pctldev for node /uart4"
<the_person48>
oh yep you're right
<the_person48>
thanks
<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
<the_person48>
oh interesting
<the_person48>
maybe an issue with my /boot/uEnv.txt?
<zmatt>
dunno, no idea what could cause that
<the_person48>
ok
<zmatt>
but it's not good
<the_person48>
well I adjusted the first issue and am rebooting so we'll see if that works
<the_person48>
ok
<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
<the_person48>
ok they're showing up as UARTs now so that's good!
<the_person48>
weird
<the_person48>
I'll send my /boot/uEnv.txt just in case there's something obvious there
<zmatt>
oh, I do see why your attempt to use a custom directory didn't use: you can't abbreviate /home/debian to ~
<the_person48>
ahhh
<zmatt>
~ is the home directory of the current user... wtf would the "current user" be to a bootloader? :P
<the_person48>
gotcha, that makes sense
<the_person48>
didn't think about that
<the_person48>
but yeah I'm not seeing any reason for kernel weirdness here at least
<zmatt>
and I don't see anything here that explains the wrong kernel cmdline, unless it's just a broken/obsolete u-boot version
<the_person48>
got cape universal commented out
<the_person48>
that's possible
<the_person48>
I am on an old version of debian
<zmatt>
you haven't updated u-boot ?
<the_person48>
I don't think so
<the_person48>
should I?
<the_person48>
trying to figure out how to check u-boot version
<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
<zmatt>
that version.sh script includes u-boot version in its output
<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
<the_person48>
ok, I'll get that output
<the_person48>
ok, and what is the purpose of that?
<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
<the_person48>
gotcha
<the_person48>
and is the source of randomness "bad" otherwise?
<the_person48>
like seeded repeatably or something like that?
<zmatt>
yes and can lead to warnings or the system waiting until more entropy is available in some cases
<the_person48>
here's the output of the version.sh script
<zmatt>
2018.03-00002-gac9cce7c6a
<zmatt>
pretty old
<the_person48>
ok, what's the best way to update it?
<the_person48>
and will it mess up compatibility with debian 9.5?
<the_person48>
cause my coworkers want me to use that OS
giort has joined #beagle
<zmatt>
u-boot doesn't interact with userspace so your debian release isn't hugely important
<zmatt>
why exactly are you using an ancient version of debian anyway?
<the_person48>
my coworkers have used it succesfully for some other project before
<the_person48>
and they don't want to update cause they know it worked then
<the_person48>
so I'm stuck using it unless I show it can't work for some reason
<zmatt>
/o\
<the_person48>
but yeah, I'd rather use 10
<zmatt>
are they also still using Windows XP ?
<the_person48>
ahahaha
<the_person48>
it took a long time to update to windows 10 haha
<the_person48>
you joke but
<the_person48>
were on windows 7 for a while
<the_person48>
how do I update uboot? is it a sudo apt thing?
<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
<zmatt>
I think there's a script, though I've generally done it manually
<zmatt>
bbl, distracted
<the_person48>
ok, sounds good
<the_person48>
no rush
<the_person48>
also, I added the udev rules for pin names
<the_person48>
worked for gpio, but /dev/adc isn't showing up
<the_person48>
do you think it might be some issue with enabling adc in /boot/uEnv.txt?
<the_person48>
I think the rule I used is exactly the same as the one I used succesfully before on the newer OS
giort has quit [Quit: giort]
<the_person48>
I tried uncommenting disable_uboot_overlay_adc=1, but that didn't seem to work
vagrantc has quit [Quit: leaving]
<the_person48>
ok yeah something weird is definitely going on with the udev rules
<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.
<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.
<the_person48>
I get P8_3-6,P9_15,19,20
<the_person48>
and then don't have the right total number that I set either
<the_person48>
any idea what might be going wrong? not sure if it's a problem with my overlay or udev rule
<the_person48>
I used the same udev rule from before that seemed to be working then though, on the newer OS, with no overlay