**** BEGIN LOGGING AT Fri Nov 26 02:59:56 2021
**** BEGIN LOGGING AT Fri Nov 26 11:48:16 2021
Nov 26 14:31:57 <michaelo> Hi rcn-ee_ . I'm reading https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec . I believe I understand the idea, but are the bbai-bone-buses.dtsi and bbb-bone-buses.dtsi definitions already in use in production images?
Nov 26 14:34:16 <michaelo> Using the latest Debian console images from https://beagleboard.org/latest-images, I don't think they are in use, otherwise I'd see the symlinks in /dev/.
Nov 26 14:35:12 <michaelo> rcn-ee_: or is the spec still a plan for improving future software releases?
Nov 26 14:54:19 <zmatt> michaelo: the current production images are a bit dated and definitely predate this, maybe check the testing images: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots
Nov 26 15:07:02 <michaelo> zmatt: excellent, thanks!
Nov 26 15:09:45 <markand> hello
Nov 26 15:12:17 <markand> I have a 4D system cape screen which boots fine using a last fresh buster image, after a while it simply reboots by itself
Nov 26 15:13:26 <zmatt> that doesn't sound good :)
Nov 26 15:14:23 <markand> I can't see anything in the journal about a crash
Nov 26 15:15:37 <zmatt> that's kinda what you'd expect, since if the crash is mild enough to still allow logging then it's almost certainly also mind enough to not reboot the system
Nov 26 15:15:53 <markand> :(
Nov 26 15:16:05 <markand> this screen is made especially for it
Nov 26 15:16:05 <zmatt> pretty much the only things that would cause a reboot is a kernel panic or something hardware-related
Nov 26 15:16:14 <markand> yay
Nov 26 15:16:21 <markand> since it boots and runs fine without it
Nov 26 15:16:32 <zmatt> that would suggest something hardware related
Nov 26 15:17:32 <zmatt> the only thing that comes to mind that may cause it "after some time" would be if it's related to switching the backlight, e.g. if it's powered off after some idle time
Nov 26 15:29:23 <markand> I have no freaking idea, the screen goes full white for a sec and then reboos
Nov 26 15:30:34 <zmatt> hmm
Nov 26 15:32:47 <markand> https://4dsystems.com.au/products/4dcape-70t-rev1-01
Nov 26 15:32:50 <markand> we use that one exactly
Nov 26 15:36:48 <michaelo> zmatt: exactly what I needed. Thanks again!
Nov 26 15:54:24 <philenotfound> markand: maybe crosstalk? I had similar issues in the past with a similar display cape... In my case there was crosstalk between display and mmc lines causing fs corruption
Nov 26 15:55:08 <markand> ah
Nov 26 15:55:27 <markand> philenotfound, and did you find what to do? their datasheet does not mention any configuration though
Nov 26 15:55:33 <zmatt> crosstalking causing filesystem corruption?  that seems rather implausible given that all eMMC communications is CRC-protected
Nov 26 15:55:36 <zmatt> *crosstalk
Nov 26 15:56:55 <zmatt> so it should just detect a corrupted transfer and retry it
Nov 26 15:59:54 <philenotfound> zmatt: maybe I'm remembering it wrong..
Nov 26 16:02:09 <philenotfound> It certainly resulted in a not usable system... after cutting the mmc pins on the cape everything was fine
Nov 26 16:04:05 <philenotfound> Found it: https://elinux.org/BeagleBone_LCD7#Revision_A3
Nov 26 16:45:02 <zmatt> philenotfound: yeah if it hangs traces of sufficient length to the eMMC pins it may deteriorate the signal integrity and cause sufficient random errors (or worse, cause specific transfers to fail repeatedly because their data pattern consistently causes corruption) that linux gives up retrying
Nov 26 16:45:37 <zmatt> I don't know how many times it will retry but presumably not infinitely
Nov 26 16:46:26 <zmatt> (and once that happens you may indeed get filesystem corruption, though not because the actual transfer got corrupted but because linux gave up and just discarded the data)
Nov 26 16:47:58 <zmatt> I doubt it has anything to do with the display lines, those are not in proximity to the eMMC lines
Nov 26 16:48:42 <zmatt> ahhhh, this is the cape that puts passthrough cape headers side-by-side next to the beaglebone
Nov 26 16:49:01 <zmatt> which requires very long traces
Nov 26 16:49:24 <zmatt> yeah that's a great way to fuck up signal integrity
Nov 26 23:33:09 <metaGross128> Hello Can you tell me how to enable SPI0 on beaglebone black ?
Nov 26 23:33:40 <set_> What is the deal w/ this 64-bit monstrosity of an AI?
Nov 26 23:34:07 <set_> Wondering minds 'must' know!
Nov 26 23:34:20 <set_> SPI0? Use SPI1.
Nov 26 23:34:33 <set_> SPI0 is linked to something else.
Nov 26 23:34:44 <set_> I think. Let me double check.
Nov 26 23:35:37 <metaGross128> can you share with me the device tree that enables SPI0 or SPI1
Nov 26 23:35:50 <metaGross128> ?
Nov 26 23:36:19 <metaGross128> spi0_pins: pinmux_spi0_pins{
Nov 26 23:36:20 <metaGross128>         pinctrl-single,pins = < 0x150 0x30 0x154 0x30 0x158 0x10 0x15c 0x10 >;
Nov 26 23:36:20 <metaGross128>     };
Nov 26 23:36:21 <metaGross128>     spi1_pins: pinmux_spi1_pins{
Nov 26 23:36:21 <metaGross128>         pinctrl-single,pins = < 0x190 0x33 0x194 0x33 0x198 0x13 0x19c 0x13 >;
Nov 26 23:36:22 <metaGross128>     };
Nov 26 23:36:31 <set_> Okay, okay.
Nov 26 23:36:35 <metaGross128> &spi0 {
Nov 26 23:36:35 <metaGross128>     status="okay";
Nov 26 23:36:36 <metaGross128>     pinctrl-names = "default";
Nov 26 23:36:36 <metaGross128>     pinctrl-0 = <&spi0_pins>;
Nov 26 23:36:37 <metaGross128>     compatible = "ti,omap4-mcspi";
Nov 26 23:36:37 <metaGross128>     spi-max-frequency = <0xf42400>;
Nov 26 23:36:38 <metaGross128>     dma-names = "tx0", "rx0", "tx1", "rx1";
Nov 26 23:36:38 <metaGross128>     };
Nov 26 23:36:39 <metaGross128> &spi1 {
Nov 26 23:36:39 <metaGross128>     status="okay";
Nov 26 23:36:40 <metaGross128>     pinctrl-names = "default";
Nov 26 23:36:40 <metaGross128>     pinctrl-0 = <&spi1_pins>;
Nov 26 23:36:41 <metaGross128>     compatible = "ti,omap4-mcspi";
Nov 26 23:36:41 <metaGross128>     spi-max-frequency = <0xf42400>;
Nov 26 23:36:42 <set_> Use pastebin for multi-lines!
Nov 26 23:36:42 <metaGross128>     dma-names = "tx0", "rx0", "tx1", "rx1";
Nov 26 23:36:42 <metaGross128>     };
Nov 26 23:36:44 <set_> !!!!!!!!!!!!
Nov 26 23:36:46 <set_> Stop.
Nov 26 23:36:58 <outrageous> Think it's just done in  /boot/uEnv.txt
Nov 26 23:37:09 <set_> metaGross128: Please use pastebin for multilines.
Nov 26 23:37:35 <set_> You can just use them, i.e. as they are available. Right! /boot/uEnv.txt file. Enable a uboot-overlay.
Nov 26 23:37:39 <outrageous> Err, no I think I am misremembering
Nov 26 23:38:04 <zmatt> metaGross128: you don't need to do any of this to use spi
Nov 26 23:38:26 <metaGross128> i'm generating my own image
Nov 26 23:38:32 <metaGross128> using buildroot
Nov 26 23:38:50 <metaGross128> based on kernel (5.10.23)
Nov 26 23:38:54 <set_> This is going to get interesting!
Nov 26 23:38:55 <zmatt> you definitely shouldn't have "dma-names" in your custom overlay
Nov 26 23:39:26 <zmatt> also, use the pinmux macros to make pinmux declarations readable, nobody looks at those hex numbers and goes "ah right, that looks good to me"
Nov 26 23:39:56 <zmatt> also don't override the "compatible" property
Nov 26 23:40:18 <zmatt> keep in mind these declarations only enable the spi controllers, they don't declare any spi devices attached to them
Nov 26 23:41:08 <zmatt> why is your spi-max-frequency in hex?  this looks like you grabbed some random stuff from a decompiled dtb or something
Nov 26 23:41:24 <metaGross128> exactly
Nov 26 23:41:42 <metaGross128> i decompiled the dtb from a debian image
Nov 26 23:41:47 <zmatt> also, it probably doesn't make sense to override spi-max-frequency on the bus... you'd set it on individual slaves as needed (based on the max frequency supported by those slaves)
Nov 26 23:41:56 <zmatt> why would you do such a thing?  use the original source code
Nov 26 23:42:28 <metaGross128> do i need to delete the compatible field too ?
Nov 26 23:42:32 <set_> Are not the .org doing a mainline of the DeviceTrees?
Nov 26 23:42:48 <zmatt> you should not override the compatible-declaration of predeclared devices
Nov 26 23:43:59 <metaGross128> can you send me the correction of what i proposed
Nov 26 23:44:06 <metaGross128> i don't get you well
Nov 26 23:44:06 <zmatt> basically all that should be there is the status="okay" and pinctrl
Nov 26 23:45:00 <set_> b/c of the .dtsi "parameters" or declarations, right?
Nov 26 23:45:00 <zmatt> perhaps a useful example is this, from my overlay-utils: https://github.com/mvduin/overlay-utils/blob/master/spi0.dtsi#L12-L52    except it uses non-standard macros for pinmux
Nov 26 23:45:47 <metaGross128> from kernel side and rootFS do i need to do something too ?
Nov 26 23:46:20 <metaGross128> okay thanks for the link i will test this
Nov 26 23:46:47 <zmatt> let me see if I can find a pinmux example using mainline macros
Nov 26 23:46:56 <set_> yes!
Nov 26 23:47:07 <set_> cough. Sorry.
Nov 26 23:47:31 <metaGross128> X)
Nov 26 23:47:55 <set_> metaGross128: @zmatt know more of the BBB land type stuff than mere me.
Nov 26 23:48:00 <set_> So...have fun!
Nov 26 23:48:22 <metaGross128> haha Thanks !
Nov 26 23:48:29 <set_> I used to use the uboot-overlay, a .dts file.
Nov 26 23:48:46 <zmatt> I'm assuming he's not using overlays but a customized dts
Nov 26 23:48:52 <set_> This .dts file turned .dtbo worked in /boot/uEnv.txt for me.
Nov 26 23:48:54 <set_> Oh.
Nov 26 23:48:55 <set_> Okay.
Nov 26 23:49:10 <metaGross128> zmatt... exactly
Nov 26 23:49:13 <set_> I was just explaining my old way of doing it.
Nov 26 23:49:22 <set_> So, no uboot?
Nov 26 23:49:26 <metaGross128> i am using a customized dts
Nov 26 23:49:38 <set_> Oh. Of the entire am335x?
Nov 26 23:49:53 <metaGross128> the idea in the next iteration is to make the DTB buildin side by side in the kernel
Nov 26 23:50:06 <zmatt> set_: a dts describes the entire system's hardware
Nov 26 23:50:12 <set_> Oh...I got you now. You are using the .dtsi and then using the .dts.
Nov 26 23:50:13 <zmatt> (a normal dts that is)
Nov 26 23:50:13 <set_> Oh.
Nov 26 23:50:17 <set_> Okay.
Nov 26 23:50:54 <set_> Right. So, for this particular example, one would need just the SPI devices to show up in the .dts == .dtb file(s).
Nov 26 23:51:04 <metaGross128> how can i share the DTS in a pretty format :')  ?
Nov 26 23:51:20 <set_> pastebin, pastebin, pastebin.com.
Nov 26 23:51:48 <set_> Sorry. MetaGross128: Use pastebin.com
Nov 26 23:51:58 <metaGross128> thanks
Nov 26 23:52:21 <set_> Well...
Nov 26 23:52:26 <set_> Forget it.
Nov 26 23:53:17 <set_> Okay...so. I am not getting it. Why would one need to set up a complete different distro on Linux when the .org or rcn-ee.net has too many to test already?
Nov 26 23:53:51 <zmatt> metaGross128: https://pastebin.com/mKUJ4rWn   something like that?
Nov 26 23:54:03 <zmatt> you'll need to make sure you have the right #includes for those macros
Nov 26 23:54:22 <zmatt> also note that the declaration for the slave device is just an example, adjust it to taste
Nov 26 23:54:55 <set_> Fast mode!
Nov 26 23:55:01 <metaGross128> mmm okay thank
Nov 26 23:55:29 <metaGross128> i don't need to do anything in kernel side ?
Nov 26 23:55:40 <set_> Boot it!
Nov 26 23:55:49 <zmatt> I mean... make sure you have the relevant drivers enabled in your kernel config? :P
Nov 26 23:55:55 <set_> Oh.
Nov 26 23:56:23 <set_> So, when you make menuconfig or whatever, kconfig or whatever, make sure your SPI is enabled!
Nov 26 23:56:39 <metaGross128> yes i activated the spidev as module
Nov 26 23:56:42 <metaGross128> i think
Nov 26 23:56:42 <zmatt> metaGross128: btw the "symlink" property is meaningless on its own, it's meant to be used in combination with this udev rule installed into /etc/udev/rules.d/ : https://github.com/mvduin/py-uio/blob/master/etc/udev/rules.d/10-of-symlink.rules
Nov 26 23:56:58 <zmatt> which allows you to declare names symlinks for devices in your device tree
Nov 26 23:57:16 <set_> Read back in pastebin your uboot print out while booting!
Nov 26 23:57:48 <set_> now.
Nov 26 23:57:50 <set_> Just kiddin'.
Nov 26 23:58:01 <zmatt> e.g. if you have that udev rule then putting   symlink = "spi/foo";   on an spidev node will make /dev/spi/foo a symlink to its device node
Nov 26 23:58:18 <set_> Nice.
Nov 26 23:58:50 <metaGross128> compiling the new dts :D
Nov 26 23:59:05 <set_> @zmatt: Is that how it has always worked or is that new in these updated kernels?
Nov 26 23:59:11 <zmatt> but of course you can also just omit it and access /dev/spidev0.0
Nov 26 23:59:36 <zmatt> set_: neither?  I just linked to the custom udev rule that _makes_ it work
Nov 26 23:59:40 <set_> Oh.
Nov 26 23:59:42 <zmatt> it has nothing to do with the kernel whatsoever
Nov 26 23:59:44 <set_> Double nice.
Nov 26 23:59:56 <zmatt> that udev rule is already installed by default on current beagleboard.org images
Nov 27 00:00:13 <set_> I am little man on the todem pole in the udev dept. for now.
Nov 27 00:00:14 <metaGross128> https://pastebin.com/yu0EX9H9
Nov 27 00:00:16 <set_> I need to learn more.
Nov 27 00:01:04 <zmatt> metaGross128: ugh, inconsistent indenting
Nov 27 00:01:14 <zmatt> also, you seem to be missing a closing }; at the end
Nov 27 00:01:38 <set_> THere are actually three SPI devices?
Nov 27 00:01:56 <set_> For the am335x and the BBBW?
Nov 27 00:02:05 <set_> News to me.
Nov 27 00:02:27 <zmatt> metaGross128: also why do you still have the hex values for spi0_pins instead of using the macros I provided?
Nov 27 00:03:20 <set_> for hexdump and serial decoding?
Nov 27 00:03:33 <zmatt> set_: hush
Nov 27 00:03:45 <set_> Fine. I just like to learn too.
Nov 27 00:04:03 <metaGross128> i'm testing
Nov 27 00:04:06 <metaGross128> :p
Nov 27 00:05:26 <zmatt> it's probably also more readable to keep the pinmux declarations near the corresponding device (it's fine to have multiple &am335x_pinmux { .. }; blocks)
Nov 27 00:06:40 <metaGross128> works like magic
Nov 27 00:07:06 <metaGross128> ls /dev/*sp*
Nov 27 00:07:35 <metaGross128> (/dev/spidev0.0)
Nov 27 00:07:43 <metaGross128> as result
Nov 27 00:07:49 <metaGross128> awesome :D
Nov 27 00:08:43 <metaGross128> Thanks
Nov 27 00:13:34 <zmatt> metaGross128: https://pastebin.com/9WB12L3L  same for spi1
Nov 27 00:14:09 <zmatt> ugh, these ugly verbose mainline pinmux macros are such an eyesore
Nov 27 00:14:18 <metaGross128> any idea how to run autotest on SPI0 ?
Nov 27 00:14:42 <metaGross128> i installed spidev_test util already
Nov 27 00:14:49 <zmatt> and I despise the practice of naming pins after one of the functions
Nov 27 00:14:52 <metaGross128> spidev_test -D /dev/spidev0.0
Nov 27 00:14:57 <zmatt> what do you even mean by "autotest"
Nov 27 00:15:22 <zmatt> spi requires that you configure the bus exactly right for the slave device and perform transfers which the slave device understands
Nov 27 00:15:34 <set_> Use a device!
Nov 27 00:15:38 <set_> Dang it. Sorry.
Nov 27 00:15:39 <metaGross128> i don't have any external sensors for now
Nov 27 00:15:49 <zmatt> you mean a loopback test?
Nov 27 00:16:27 <metaGross128> yes
Nov 27 00:16:31 <metaGross128> that it
Nov 27 00:17:46 <metaGross128> https://gist.github.com/pdp7/308f2e3019ab48939a1012fe593e433b
Nov 27 00:17:54 <metaGross128> found it !
Nov 27 00:17:56 <zmatt> spidev_test doesn't really seem to have a loopback test... also, it's kind of annoying since it unconditionally overrides the configuration you declare in DT
Nov 27 00:18:46 <zmatt> if you want to use python, probably just use the spidev python library instead of Adafruit
Nov 27 00:19:43 <zmatt> there's an example for that at the bottom of this doc of mine: https://pastebin.com/nS6FELGH
Nov 27 00:20:01 <zmatt> don't forget to connect the two data pins (miso and mosi) with a wire if you want to do a loopback test ;)
Nov 27 00:21:49 <zmatt> on a random note, this is a really awesome-looking x-ray photo of a microSD card: https://twitter.com/mikelectricstuf/status/553659167580618753
Nov 27 00:22:31 <metaGross128> that's cool
Nov 27 00:22:38 <metaGross128> thanks
Nov 27 00:42:07 <set_> Yay! PCBs!
Nov 27 00:42:21 <set_> It is like candy but better. You can reuse them!
**** ENDING LOGGING AT Sat Nov 27 02:59:56 2021