**** BEGIN LOGGING AT Tue Apr 20 02:59:56 2021
Apr 20 03:26:20 <MortyFell> Has anyone put together a .dbto for the IPC units on the BBAI yet?
Apr 20 03:28:02 <MortyFell> I will try but do not hold your breath.
Apr 20 03:28:19 <MortyFell> I am still trying to catch up to '15.
Apr 20 03:29:46 <zmatt> what do you mean by "IPC units" and why would you need a dtbo?
Apr 20 03:29:59 <MortyFell> The main reason I am asking is b/c the Arago Project/Linux SDK has some files, .xem4 types, and...oh.
Apr 20 03:30:40 <MortyFell> I am asking b/c I thought one would need a specific type of .dtbo to describe the hardware that is on the BBAI or would I need the .dtsi file instead?
Apr 20 03:31:06 <MortyFell> Oh. IPC.
Apr 20 03:31:11 <zmatt> arago doesn't support dtbos
Apr 20 03:31:15 <MortyFell> Let me make sure I am saying that correctly.
Apr 20 03:31:18 <MortyFell> No!
Apr 20 03:31:22 <zmatt> nothing you're saying makes sense
Apr 20 03:31:32 <MortyFell> As usual. Blah.
Apr 20 03:31:34 <zmatt> also firmware files just go into /lib/firmware, there's no DT involved
Apr 20 03:31:41 <MortyFell> Right.
Apr 20 03:31:45 <MortyFell> I got that part.
Apr 20 03:33:00 <MortyFell> @zmatt: I am trying to describe what is not in my vocabulary right now. Let me try again.
Apr 20 03:33:12 <zmatt> did you mean IPU instead of IPC ?
Apr 20 03:33:25 <MortyFell> Let me make sure.
Apr 20 03:33:49 <MortyFell> I think I just made some mistakes in typing. Please hold (if you have a couple of minutes).
Apr 20 03:34:42 <MortyFell> cough. Yes, IPU.
Apr 20 03:34:53 <MortyFell> Not the DSPs.
Apr 20 03:35:05 <MortyFell> the m4 processor(s)...
Apr 20 03:36:41 <MortyFell> So, would I need a specific file, not the user space programmed file, type to tell the main processor that I am about to use it?
Apr 20 03:38:28 <MortyFell> I know one of the IPU processors, from what you have told me in the past, is dedicated to the vision engines.
Apr 20 03:39:10 <MortyFell> So, I can use one of them, the first one, to handle specific tasks. Does this sound right? Although slower than the PRU processors, I would like to try.
Apr 20 03:43:45 <MortyFell> Oh. There are four of them...nice!
Apr 20 03:45:41 <MortyFell> well, dual core * 2.
Apr 20 03:50:38 <mattb00ne> does the ecap work with P9_22 and P9_21
Apr 20 03:54:57 <mattb00ne> nm it is pwm
Apr 20 03:55:04 <mattb00ne> that is what I was using it for
Apr 20 03:55:10 <MortyFell> PWM!
Apr 20 04:05:09 <MortyFell> @zmatt: I will read more about m4 processing before I call on you again for this circumstance. All I know is I have some .xem4 files that need linking and to be able to do this is a question I cannot ask yet.
Apr 20 04:05:58 <zmatt> why are you doing anything with the IPUs ?  They are probably the hardest cores to work with on the system with the least possible useful applications
Apr 20 04:09:50 <MortyFell> B/c...I want to learn terrific things! So, there is really no way to call these IPU source files w/out a correct toolchain and linker script?
Apr 20 04:10:25 <mattb00ne> zmatt should GPIO pins be pulled down or up for connecting to a stepper
Apr 20 04:10:35 <mattb00ne> i know you said doesnt really matter
Apr 20 04:10:38 <mattb00ne> but is there typically
Apr 20 04:10:56 <mattb00ne> a preference
Apr 20 04:10:59 <mattb00ne> or standard
Apr 20 04:11:54 <MortyFell> @zmatt: I know it is probably too complicated to describe in a couple of sentences. I will keep reading.
Apr 20 04:13:00 <zmatt> I have no idea what a stepper is expecting, though you want to have a specific default level before the output is enabled then what matters more than the pull you configure is the default pull after reset (before pins can be configured), which you can influence by either just using the right pin (some pins have default pull-up, some have default pull-down), or overriding internal pull with external ...
Apr 20 04:13:06 <zmatt> ...pull
Apr 20 04:13:22 <mattb00ne> i am going through an eazy driver module
Apr 20 04:13:35 <mattb00ne> https://learn.sparkfun.com/tutorials/easy-driver-hook-up-guide/all
Apr 20 04:14:05 <zmatt> that link doesn't work
Apr 20 04:14:10 <zmatt> oh never mind
Apr 20 04:14:14 <zmatt> I screwed up
Apr 20 04:15:46 <zmatt> mattb00ne: so you're talking about the STEP pin I assume?
Apr 20 04:15:55 <mattb00ne> yes
Apr 20 04:16:07 <mattb00ne> updating my overlay file
Apr 20 04:16:16 <zmatt> since it triggers on rising edge, presumably you'd want it to be default low
Apr 20 04:16:25 <mattb00ne> i lost my version that had P9_21 and P9_22 set to pwm
Apr 20 04:16:31 <mattb00ne> pl
Apr 20 04:16:32 <mattb00ne> ok
Apr 20 04:16:48 <zmatt> though if you ensure the SLP pin is low by default then obviously the default for the STEP pin won't matter
Apr 20 04:17:27 <zmatt> usually if I don't have a strong reason to configure pulls differently, I just use whatever was the reset-default pull for pin
Apr 20 04:17:44 <zmatt> the reasoning there is that this avoids a transition when going from reset pull to configured pull
Apr 20 04:18:23 <zmatt> and whatever the reset pull is for the pin, the external hardware already needs to deal with it during the time between power-on/reset and when pins are getting configured
Apr 20 04:20:24 <zmatt> generally speaking the only things you explicitly want to avoid (or minimize the duration of such situations if not easily avoidable) are:  1. having internal pull conflicting with external pull   2. having no pull (internal or external) on a pull that is not externally driven (at all times)
Apr 20 04:20:44 <zmatt> *on a pin
Apr 20 04:21:33 <mattb00ne> ok I will leave those alone
Apr 20 04:21:36 <zmatt> don't forget close the 3/5V select solder-jumper on this board
Apr 20 04:21:40 <zmatt> *to close
Apr 20 04:21:41 <mattb00ne> I did
Apr 20 04:21:59 <mattb00ne> is 5V logic more common
Apr 20 04:22:07 <mattb00ne> you figure you would default to the less harmful option
Apr 20 04:22:18 <mattb00ne> if it starts at 3V and you are in 5V no harm no foul
Apr 20 04:22:21 <zmatt> incorrect
Apr 20 04:22:33 <mattb00ne> the other way you fry the board
Apr 20 04:22:33 <mattb00ne> really?
Apr 20 04:23:03 <zmatt> since these are inputs, so if the board is configured for 3.3V (by default) and you then drive it with a microcontroller with 5V outputs, you'll fry the easy board
Apr 20 04:23:27 <zmatt> (and possibly the microcontroller, depending on the amount of clamping current)
Apr 20 04:23:34 <mattb00ne> right but the other way
Apr 20 04:23:47 <mattb00ne> board is for 5V and I drive with a 3.3V
Apr 20 04:23:57 <zmatt> then it might not work reliably
Apr 20 04:24:12 <mattb00ne> i would want that the default case so the worse case doesnt work but you dont fry the board
Apr 20 04:25:09 <zmatt> it looks like this thing has no logic outputs, so there's no risk of frying the board if you configure its VCC to 5V
Apr 20 04:25:25 <zmatt> no risk of frying anything I mean
Apr 20 04:25:32 <zmatt> so they chose the safe default
Apr 20 04:26:50 <mattb00ne> well I soddered to force the 3.3V
Apr 20 04:27:41 <zmatt> lol so this board has three different pins to effectively disable it: RST, ENABLE, and SLP
Apr 20 04:28:37 <zmatt> okay so they leave SLP and RST unconnected in their example
Apr 20 04:29:03 <mattb00ne> yeah I am trying to setup the pins for all these things
Apr 20 04:29:23 <mattb00ne> i want to default them to the positions so I just drive the step and direction in my program
Apr 20 04:29:26 <zmatt> so I guess RST is there just in case you have a reason to reset the board...
Apr 20 04:29:46 <zmatt> lemme see if the A3967 datasheet have anything important to say about them
Apr 20 04:31:22 <zmatt> ok so yeah, so the logic signals need to be above 70% of VCC to be "high" and below 30% of VCC to be low
Apr 20 04:31:58 <zmatt> so if VCC is 5V, the minimum input voltage to be guaranteed logic-high is 3.5V, so driving it with 3.3V in that case isn't guaranteed to work (it might, but it might not)
Apr 20 04:32:07 <zmatt> hence the need for the jumper
Apr 20 04:32:54 <mattb00ne> broke my dtbo file https://pastebin.com/9SNercZw
Apr 20 04:33:38 <mattb00ne> F3 on your sheet is mode 4 right
Apr 20 04:33:44 <mattb00ne> column F3
Apr 20 04:33:53 <zmatt> no, F3 is mode 3
Apr 20 04:34:39 <mattb00ne> but I must have another error killed my overlay
Apr 20 04:34:46 <mattb00ne> mode 4 is uart
Apr 20 04:35:28 <zmatt> why would mode numbering in my spreadsheet be off by one?  that makes no sense
Apr 20 04:36:22 <zmatt> also, if you're using uptodate overlay-utils, the preferred pin macros are PIN_PULLUP, PIN_PULLDN, PIN_NOPULL
Apr 20 04:37:07 <zmatt> also, pwm pinmux should be attached to the pwm controller, not to pruss
Apr 20 04:38:15 <zmatt> well, I guess if you don't enable the pwm controller and just use ti,no-idle; then you could configure its pins here, but then you should also have those declarations (for the pwm controller) in this overlay
Apr 20 04:39:26 <zmatt> but if you're reconfiguring the pwm controller to uio (to be able to configure and monitor it from userspace as well as from pru) you should attach the pinmux there, see e.g. https://github.com/mvduin/overlay-utils/blob/master/uio-pwm1.dtsi
Apr 20 04:39:31 <mattb00ne> let me repull the utility
Apr 20 04:40:17 <zmatt> hmm why do I use NOPULL there in violation of my default policy for pulls
Apr 20 04:40:35 <zmatt> see, apparently even I don't always know for sure what to do with pull configuration ;)
Apr 20 04:41:06 <mattb00ne> lol
Apr 20 04:41:51 <zmatt> but in principle it is possible for the ehrpwm outputs to go high-z (via the tripzone mechanism) so I ought to configure PULLDN on them just for safety
Apr 20 04:42:28 <mattb00ne> ok do I need this other stuff. This is a more complicated overlay than what I was using
Apr 20 04:42:47 <mattb00ne> did you do a substantial update to pi-uio
Apr 20 04:42:52 <mattb00ne> in the past 3months
Apr 20 04:43:51 <mattb00ne> I guess I could just have this in another slot
Apr 20 04:44:01 <mattb00ne> and my other overlay in the first slot
Apr 20 04:44:46 <mattb00ne> I am using P9_22 and P9_21 would I need to change anything
Apr 20 04:46:54 <denix> zmatt: arago is a distro and has nothing to do with dtbo. but the kernel used in arago does support dtbos - e.g. https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/conf/machine/include/am65xx.inc#n9
Apr 20 04:47:39 <zmatt> denix: beagleboard.org abandoned kernel overlays quite a while ago, they're now applied by u-boot
Apr 20 04:48:45 <zmatt> so what matters is whether u-boot has been built with a boot script that allows the user to configure, via some config file, overlays for u-boot to load and apply to the base dtb before passing it to the kernel
Apr 20 04:49:15 <zmatt> I'm pretty sure that part is beagleboard.org-custom stuff, hence I assumed it's not a thing in arago
Apr 20 04:49:16 <denix> zmatt: yes, they are applied by u-boot, but provided by the kernel. it's not bb specific, it's how mainline does it these days
Apr 20 04:49:32 <zmatt> the kernel is not involved here in any way whatsoever
Apr 20 04:50:42 <mattb00ne> zmatt: Do I need to modify that pwm overlay to use P9_21&22
Apr 20 04:51:30 <zmatt> denix: the kernel doesn't know or care how the bootloader produced the DT structure that the bootloader passes to the kernel (and even mainline u-boot performs minor modifications to it between loading it from a .dtb file and passing it to the kernel)
Apr 20 04:52:39 <zmatt> mattb00ne: obviously.. if those were merely different pins of the same pwm controller then you'd only need to change the pinmux block, but those pins are ehrpwm0 while this example is for ehrpwm1
Apr 20 04:54:14 <zmatt> so that additionally requires changing pwm1 -> pwm0 and pwmss1 -> pwmss0 throughout the entire file, and also the peripheral addresses that are in it
Apr 20 04:54:34 <mattb00ne> i can do the number swap but the addresses
Apr 20 04:54:38 <zmatt> 48302000 -> 48300000
Apr 20 04:54:48 <mattb00ne> =(
Apr 20 04:54:48 <mattb00ne> ok
Apr 20 04:55:52 <zmatt> I guess I could include examples for pwm0 and pwm2 in overlay-utils
Apr 20 04:57:10 <mattb00ne> yes please!
Apr 20 04:59:02 <zmatt> oh and the interrupt number
Apr 20 04:59:25 <mattb00ne> there is a lot for me to mess up
Apr 20 05:02:44 <mattb00ne> https://pastebin.com/kDTbd68K
Apr 20 05:02:51 <mattb00ne> probably wrong but I tried
Apr 20 05:10:53 <zmatt> okay, fixed pin pull, indentation (somehow it was a mix of tabs and spaces), and some comments in uio-pwm1.dtsi and added uio-pwm0.dtsi and uio-pwm2.dtsi
Apr 20 05:12:11 <zmatt> hey looks like you got pretty close
Apr 20 05:12:52 <zmatt> you got the two pins swapped (P9.22 is out A), the interrupt number, and the fact that P9.21/22 are default pull-up, not default pull-down
Apr 20 05:14:04 <zmatt> of course an argument could be made in favor of using pull-down instead of pull-up, but then at the very least the comment would be wrong.  (this is one case where pull-up, pull-down, and no-pull all have reasonable arguments in favor of them)
Apr 20 05:15:24 <zmatt> oh and missed some pwm1->0 and pwmss1->0 changes
Apr 20 05:15:37 <zmatt> quite a few actually
Apr 20 05:16:29 <zmatt> see this is a case where I would just use my text editor's search-and-replace-all to avoid missing one or more ;)  (which is in fact what I did)
Apr 20 05:23:43 <zmatt> oh he left
Apr 20 05:34:19 <mattb00ne> ok
Apr 20 05:34:52 <mattb00ne> thanks for the push
Apr 20 06:08:20 <zmatt> mattb00ne: and based on the EasyDriver schematic you can leave SLEEP, RESET, and ENABLE all unconnected, the EasyDriver board has 10K pull resistors that default in the direction that makes the driver functional (all three are active-low, hence pulldown for ENABLE and pull-up for SLEEP and RESET)
Apr 20 13:16:04 <anpra> Hi All,
Apr 20 13:16:05 <anpra> I am trying to integrate MCP2515 with beaglebone AI. I found the device tree related to this on Beaglebone black.
Apr 20 13:16:05 <anpra> https://github.com/battlesnake/beaglebone-spi0-mcp2515/blob/master/MCP2515.dts
Apr 20 13:16:05 <anpra> Can we port this on BBAI? I have already enabled the SPI interface using overlays on BBAI.
Apr 20 13:29:08 <TonyTheLion> this is a ti kernel, and I'm trying to boot it on a BBB, however it boots into initramfs shell, it says it doesn't find the /dev/mmcblk1p2 partition.  Is this not a supported kernel? https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-5.10.y
Apr 20 13:29:37 <TonyTheLion> I note the beagle images provided by beagle have 4.19.y kernels
Apr 20 14:32:00 <mattb00ne> I know there is a big lag on kernels for BBB
Apr 20 14:32:16 <mattb00ne> you are welcome to build your own though. Some guys have done that here
Apr 20 14:45:42 <TonyTheLion> @mattb00ne: yea I built my own, the one I linked, but it fails to boot.
Apr 20 14:46:09 <mattb00ne> yeah that is above my pay grade
Apr 20 14:46:12 <mattb00ne> sorry
Apr 20 14:46:48 <mattb00ne> there are a few people who have made their own kernals and got it working on here
Apr 20 14:46:54 <mattb00ne> they will pop on just be patient
Apr 20 14:47:02 <mattb00ne> why do you need the upgrade so bad
Apr 20 14:54:20 <TonyTheLion> mattb00ne: because we want to have an LTS kernel that can keep up with patches for production reasons
Apr 20 14:54:41 <TonyTheLion> and longterm maintenance
Apr 20 14:55:52 <mru> I'm somewhat amused by the insistence on choosing an LTS kernel for product deployment, and then insisting even more strongly that the kernel under no circumstances may be updated
Apr 20 14:56:41 <TonyTheLion> what about stability
Apr 20 14:57:01 <mru> if you actually update to newer releases on that lts branch, it's fine
Apr 20 14:57:15 <mru> but that's rare in my experience
Apr 20 14:57:34 <TonyTheLion> I can't claim to have a lot of experience with kernel stuffs
Apr 20 14:57:39 <TonyTheLion> so you're probably right
Apr 20 15:17:51 <zmatt> TonyTheLion: p2 ? you have a separate boot partition?
Apr 20 15:19:14 <zmatt> TonyTheLion: in that initramfs shell, what /dev/mmcblk*p* devices *do* exist?
Apr 20 15:22:29 <zmatt> anpra: I mean, enabling the spi controller (and its pins) is the only part that's specific, declaring a child device attached to that spi controller (e.g. an mcp251x) works the same way across all arm-based linux systems
Apr 20 15:22:56 <zmatt> well, okay, declaring the pinmux node for its interrupt line is still device-specific
Apr 20 15:23:25 <zmatt> also, that overlay you linked to is awful, it looks like someone decompiled a .dtbo
Apr 20 15:23:56 <zmatt> overlay source code should never contain a manually written __overrides__ block, that should be generated by dtc
Apr 20 15:25:48 <anpra> @zmatt: what about the fragments? Can I use similar fragments for creating the dts file for BBAI?
Apr 20 15:26:25 <zmatt> that's boilerplate for overlays (and with modern dtc also not needed)
Apr 20 15:27:17 <zmatt> if you choose to write overlays the old way (i.e. manually write the boilerplate) then the fragments must be uniquely numbered in your overlay, but nowadays it's better to let dtc auto-generate them for you
Apr 20 15:27:37 <zmatt> whichever approach you use, you need to stick to it for your entire overlay, you can't mix the two
Apr 20 15:28:26 <zmatt> what does your overlay look like currently?
Apr 20 15:28:51 <zmatt> (for enabling the spi)
Apr 20 15:31:27 <zmatt> I assume you're using an external can controller because you need a second CAN bus ?
Apr 20 15:31:54 <AnandPrakash[m]> zmatt:
Apr 20 15:32:04 <AnandPrakash[m]> It is not using fragments
Apr 20 15:32:05 <zmatt> (rev A2 of the BBAI will support a second can bus on P8.07/08 but unfortunately it's not available yet)
Apr 20 15:32:18 <anpra> https://pastebin.com/kVFPgb9X
Apr 20 15:32:30 <zmatt> yep that's modern syntax
Apr 20 15:32:57 <zmatt> this way of doing pinmux is terrible though
Apr 20 15:33:16 <zmatt> pinmux for a device should be attached to the device it's for
Apr 20 15:34:46 <anpra> So you mean pinmux should be defined within the device structure?
Apr 20 15:38:41 <zmatt> kinda like this I guess: https://pastebin.com/Sb8VzaSL
Apr 20 15:38:47 <zmatt> if you want to make use of the predefined pinmux nodes
Apr 20 15:39:19 <zmatt> (normally you'd have only a single pinmux node per state, but I *think* this is allowed)
Apr 20 15:40:02 <zmatt> oh actually, the #address-cells and #size-cells lines in &bone_spi_0 should be removed, they're inappropriate
Apr 20 15:40:12 <zmatt> those properties should not be overridden in existing DT nodes
Apr 20 15:41:51 <zmatt> oh right, they're doing that to silence stupid warnings... even though the warnings themselves are just bogus (hence modifying the source code to silence them is kinda bad, either dtc should be fixed or a flag should be used to suppress invalid warnings)
Apr 20 15:43:47 <zmatt> (of course you still need the boilerplate at the top of the file, I just omitted that because I'm lazy)
Apr 20 15:44:48 <anpra> when you say boilerplate you mean the overlay file declaration , right?
Apr 20 15:46:10 <zmatt> /dts-v1/; /plugin/; &{/chosen} { overlays { YOUR-FILENAME-HERE = __TIMESTAMP__; }; };
Apr 20 15:46:26 <anpra> yeah..got it
Apr 20 15:46:51 <zmatt> you'll also need some #include for the IRQ_TYPE_EDGE_FALLING macro
Apr 20 15:47:13 <zmatt> #include <dt-bindings/interrupt-controller/irq.h>
Apr 20 15:48:10 <zmatt> and the two FIXME lines should be changed to reference whatever gpio you're using as its interrupt line, and the associated pinmux for it
Apr 20 15:49:36 <zmatt> and the clock-frequency of the clock node needs to be set correctly
Apr 20 16:02:13 <AnandPrakash[m]> zmatt: Sure I will try it out..thanks for your help
Apr 20 16:12:44 <TonyTheLion> @zmatt: none
Apr 20 16:12:56 <TonyTheLion> there no sign of any /dev/mmcblk*
Apr 20 16:13:40 <zmatt> TonyTheLion: did you forget to include necessary drivers in your kernel config? :P
Apr 20 16:14:11 <zmatt> like, this sounds like either kernel config or dtb is broken
Apr 20 16:14:22 <TonyTheLion> I compiled the default, so I'm starting to wonder if that might be the case
Apr 20 16:14:32 <zmatt> also default dtb ?
Apr 20 16:15:29 <TonyTheLion> /boot/dtbs/5.10.21-ti-r1/am335x-boneblack.dtb
Apr 20 16:15:39 <TonyTheLion> that's what uboot is loading
Apr 20 16:17:24 <zmatt> dunno what's broken then... you could try locating the mmc platform devices
Apr 20 16:18:06 <TonyTheLion> ye I think I need to figure out what mmc drivers it requires and check if they are compiled in
Apr 20 16:18:09 <zmatt> like  ls -ld /sys/bus/platform/devices/*mmc*
Apr 20 16:19:23 <zmatt> if they're missing it's DT, if they're present but no have no driver symlink in them then the kernel is failing to probe a driver for them (not compiled-in (and if compiled as module that module isn't in initramfs) or driver probe failed)
Apr 20 16:20:27 <zmatt> grep MMC_OMAP_HS /boot/config-$(uname -r)
Apr 20 16:21:11 <TonyTheLion> so that ls in initramfs returs this
Apr 20 16:21:34 <TonyTheLion> lrwxrwxrwx    1 0        0                0 Jan  1 00:00 /sys/bus/platform/devices/48060000.mmc -> ../../../devices/platform/ocp/48000000.interconnect/48000000.interconnect:segment@0/480602fc.target-module/48060000.mmc
Apr 20 16:21:38 <TonyTheLion> lrwxrwxrwx    1 0        0                0 Jan  1 00:00 /sys/bus/platform/devices/481d8000.mmc -> ../../../devices/platform/ocp/48000000.interconnect/48000000.interconnect:segment@100000/481d82fc.target-module/481d8000.mmc
Apr 20 16:22:03 <TonyTheLion> doesn't look wrong
Apr 20 16:22:22 <zmatt> but no 'driver' symlink in those dirs?
Apr 20 16:23:07 <TonyTheLion> no
Apr 20 16:23:13 <TonyTheLion> those two lines are the only things I get
Apr 20 16:23:14 <zmatt> (also please use pastebin for multiline pastes... especially with lines that are this long :P )
Apr 20 16:23:20 <zmatt> yes but *in* those dirs
Apr 20 16:23:43 <zmatt> as in  ls -ld /sys/bus/platform/devices/*mmc*/driver
Apr 20 16:26:09 <TonyTheLion> https://pastebin.com/1LjhiwTF seems like it has those
Apr 20 16:26:24 <zmatt> huh
Apr 20 16:27:00 <TonyTheLion> could it be the wrong driver
Apr 20 16:27:36 <TonyTheLion> the 4.19.y kernel gives omap_hsmmc driver
Apr 20 16:27:50 <zmatt> yeah it is a bit odd, I wonder what the deal with that is
Apr 20 16:29:03 <TonyTheLion> that driver that it points to seems to be an SD card driver, and the other hsmmc is an omap MMC controller
Apr 20 16:29:44 <zmatt> that doesn't really say anything, since these controllers are always mmc/sd/sdio
Apr 20 16:29:58 <TonyTheLion> oh
Apr 20 16:30:16 <zmatt> ls -l /sys/bus/platform/devices/*mmc*/mmc_host/*
Apr 20 16:30:45 <zmatt> ls -l /sys/bus/platform/devices/*mmc*/mmc_host/*/*/block
Apr 20 16:33:05 <zmatt> hmm, sdhci-omap didn't exist in 4.14, but it does in 4.19 (and is enabled in its kernel config)
Apr 20 16:33:21 <TonyTheLion> https://pastebin.com/fJzY6cvg
Apr 20 16:34:02 <TonyTheLion> that host directory doesn't iexist
Apr 20 16:34:11 <TonyTheLion> I mean block
Apr 20 16:34:43 <zmatt> so it doesn't detect anything connected to the bus
Apr 20 16:34:47 <zmatt> check kernel log for errors?
Apr 20 16:36:29 <TonyTheLion> > No match for driver 'omap_hsmmc'
Apr 20 16:36:32 <TonyTheLion> there's this line
Apr 20 16:36:58 <zmatt> that's certainly odd
Apr 20 16:37:33 <zmatt> so is the documentation for the sdhci-omap driver config option: https://elixir.bootlin.com/linux/latest/source/drivers/mmc/host/Kconfig#L1066
Apr 20 16:38:20 <zmatt> like... the MMC/SD controller in DRA7 is the same one as on the am335x
Apr 20 16:38:40 <zmatt> i.e. the one for which the omap_hsmmc driver exists
Apr 20 16:39:17 <zmatt> maybe it's just a newer driver that uses common sdhci code, a situation a bit like omap-serial vs 8520-omap
Apr 20 16:39:45 <zmatt> 8250, whatever
Apr 20 16:40:21 <zmatt> anyway, it sounds like this kernel has never been tested on a beaglebone :P
Apr 20 16:40:41 <zmatt> my guess would be the .dts has simply been forward-ported but actually requires modifications
Apr 20 16:40:42 <TonyTheLion> it is sounding like that
Apr 20 16:41:10 <zmatt> or you could try to see if you can make it use the omap_hsmmc driver again
Apr 20 16:41:13 <zmatt> dunno
Apr 20 16:41:23 <zmatt> why are you trying to use this kernel?
Apr 20 16:43:42 <TonyTheLion> the latest 4.19.y ti that we are using breaks (kernel panics) on sleep. since I'm not a kernel guy, the obvious answer seemed to be to find a later LTS kernel that may not have these issues
Apr 20 16:43:50 <TonyTheLion> but clearly that isn't such an easy task
Apr 20 16:44:19 <TonyTheLion> you once told me to use TI kernels, so I tried to stick to that
Apr 20 16:44:39 <TonyTheLion> it seems like the 4.19.y's are supported and tested on BBB
Apr 20 16:44:54 <zmatt> so, since you're building custom kernels, does that include custom code?
Apr 20 16:45:09 <TonyTheLion> no but it may do in the future
Apr 20 16:45:15 <zmatt> hmm
Apr 20 17:36:36 <mattb0000ne> will dmesg let me know if there was a problem with my overlay
Apr 20 17:37:04 <mattb0000ne> zmatt: I added your uio-pwm0.dtbo to my uEnv.txt but it did not take
Apr 20 17:37:13 <mattb0000ne> does order matter?
Apr 20 19:18:24 <zmatt> no.  define "did not take" ?
Apr 20 19:20:57 <zmatt> hmm
Apr 20 19:28:06 <zmatt> mattb0000ne: it seems to work fine here, I just tested it (with and without cape-universal to be sure): https://pastebin.com/raw/wQcKxgWy
Apr 20 19:29:31 <zmatt> mattb0000ne: well, order doesn't matter unless you have two overlays that try to override the same DT property of course
Apr 20 19:30:33 <zmatt> or another way overlays can conflict is if they both try to claim the same pin using a pinmux declaration
Apr 20 20:42:21 <mattb0000ne> ok
Apr 20 20:42:33 <mattb0000ne> let me try i will remove my pru-pins overlay
Apr 20 20:42:42 <mattb0000ne> but initial pass it did not take
Apr 20 21:16:52 <zmatt> I mean, it should be pretty easy to check for conflicts... if you have conflicting pins then it would also be shown by show-pins
Apr 20 21:17:52 <zmatt> conflicting pinmux declarations I mean
Apr 20 21:25:32 <mattb0000ne> hmmm maybe it is my uEnv.txt
Apr 20 21:25:45 <mattb0000ne> i took everything out but that uio-pwm0.dtbo
Apr 20 21:25:51 <mattb0000ne> and i do not get the pwm
Apr 20 21:26:58 <zmatt> as in, the pins don't get configured? the uio devices don't appear? both?  is the overlay listed in /proc/device-tree/chosen/overlays ?
Apr 20 21:27:33 <mattb0000ne> https://pastebin.com/b5LwdRP3
Apr 20 21:27:59 <mattb0000ne> i did a fresh pull of your overlay utilities project
Apr 20 21:28:05 <mattb0000ne> my uEnv.txt is the following
Apr 20 21:28:56 <zmatt> ah wait I think I know
Apr 20 21:28:58 <mattb0000ne> https://pastebin.com/CQdE6GB2
Apr 20 21:29:16 <mattb0000ne> need to update my kernel?
Apr 20 21:29:52 <zmatt> I thought you had used an uio_pdrv_genirq device before on your system but maybe not...  install this file: https://github.com/mvduin/py-uio/blob/master/etc/modprobe.d/uio.conf  (as /etc/modprobe.d/uio.conf )
Apr 20 21:30:24 <zmatt> and update your initramfs with  sudo update-initramfs -u
Apr 20 21:32:50 <mattb0000ne> ok restarting
Apr 20 21:32:53 <mattb0000ne> lets see
Apr 20 21:33:02 <mattb0000ne> what did this do exactly
Apr 20 21:33:44 <zmatt> the uio_pdrv_genirq driver bizarrely has no compatible-string of its own, it needs to be given one via a module parameter
Apr 20 21:33:57 <mattb0000ne> now it owrks
Apr 20 21:34:20 <mattb0000ne> weird
Apr 20 21:34:29 <mattb0000ne> is that a bug that has been reported
Apr 20 21:34:39 <mattb0000ne> like I would never know how to figure that out
Apr 20 21:34:56 <zmatt> no it's not like an accident, it has been explicitly created like this
Apr 20 21:35:34 <zmatt> like, you can't normally assign a compatible-string to a driver via a module parameter, that mechanism is specific to the uio_pdrv_genirq driver
Apr 20 21:37:09 <mattb0000ne> not very user friendly
Apr 20 22:49:48 <kremlin> e
Apr 20 22:50:12 <mattb0000ne> ee
Apr 21 01:02:51 <Sanjeeviraja> Hi
Apr 21 01:17:22 <mattb000ne> hi
Apr 21 01:21:40 <Akristoffersen> hiya, the micro usb port on my beagle bone blue just came off with the cable, what are the chances I can solder it back on?
Apr 21 01:22:55 <Akristoffersen> i think luckily the pins are still intact, but the grounds on the sides and a little wire looks like it came off?
Apr 21 01:23:52 <mattb000ne> i think you can just solder back on if you have the equipment
Apr 21 01:24:48 <Akristoffersen> ok awesome, thank you
Apr 21 01:29:15 <MortyFell> Hello...I have done that so many times.
Apr 21 01:29:49 <MortyFell> USB on the BBBlue is not better than the black but if you use some glue, one can adhere it to itself and board a bit better than straight solder.
**** ENDING LOGGING AT Wed Apr 21 03:01:26 2021