nparafe has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nparafe has joined #beagle
thinkfat has quit [Ping timeout: 245 seconds]
thinkfat has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
thinkfat has quit [Ping timeout: 260 seconds]
thinkfat_ has joined #beagle
vagrantc has joined #beagle
vagrantc has quit [Quit: leaving]
AlejandroExojo[m is now known as suy|m
vd has quit [Ping timeout: 256 seconds]
ikarso has joined #beagle
otisolsen70 has joined #beagle
Shadyman has quit [Remote host closed the connection]
florian has joined #beagle
lucascastro has joined #beagle
rcn-ee_ has joined #beagle
waldo323_ has joined #beagle
nslu2-log_ has joined #beagle
renrelkha has joined #beagle
crazymax has quit [Ping timeout: 260 seconds]
djinni has quit [Ping timeout: 260 seconds]
outrageous has quit [Ping timeout: 260 seconds]
nslu2-log has quit [Ping timeout: 260 seconds]
renrelkha_ has quit [Ping timeout: 260 seconds]
rcn-ee has quit [Ping timeout: 260 seconds]
waldo323 has quit [Ping timeout: 260 seconds]
nslu2-log_ is now known as nslu2-log
djinni has joined #beagle
lucascastro has quit [Ping timeout: 268 seconds]
<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?
<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/.
<michaelo> rcn-ee_: or is the spec still a plan for improving future software releases?
<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
ikarso has quit [Quit: Connection closed for inactivity]
<michaelo> zmatt: excellent, thanks!
buzzmarshall has joined #beagle
<markand> hello
<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
<zmatt> that doesn't sound good :)
<markand> I can't see anything in the journal about a crash
<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
<markand> :(
<markand> this screen is made especially for it
<zmatt> pretty much the only things that would cause a reboot is a kernel panic or something hardware-related
<markand> yay
<markand> since it boots and runs fine without it
<zmatt> that would suggest something hardware related
<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
vd has joined #beagle
<markand> I have no freaking idea, the screen goes full white for a sec and then reboos
<zmatt> hmm
<markand> we use that one exactly
<michaelo> zmatt: exactly what I needed. Thanks again!
vagrantc has joined #beagle
<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
<markand> ah
<markand> philenotfound, and did you find what to do? their datasheet does not mention any configuration though
<zmatt> crosstalking causing filesystem corruption? that seems rather implausible given that all eMMC communications is CRC-protected
<zmatt> *crosstalk
<zmatt> so it should just detect a corrupted transfer and retry it
<philenotfound> zmatt: maybe I'm remembering it wrong..
<philenotfound> It certainly resulted in a not usable system... after cutting the mmc pins on the cape everything was fine
Guest763 has joined #beagle
Guest763 has quit [Client Quit]
<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
<zmatt> I don't know how many times it will retry but presumably not infinitely
<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)
vagrantc has quit [Quit: leaving]
<zmatt> I doubt it has anything to do with the display lines, those are not in proximity to the eMMC lines
<zmatt> ahhhh, this is the cape that puts passthrough cape headers side-by-side next to the beaglebone
<zmatt> which requires very long traces
vd has quit [Ping timeout: 256 seconds]
<zmatt> yeah that's a great way to fuck up signal integrity
troth has quit [Ping timeout: 245 seconds]
troth has joined #beagle
florian has quit [Quit: Ex-Chat]
troth has quit [Ping timeout: 240 seconds]
vd has joined #beagle
vagrantc has joined #beagle
vagrantc has quit [Client Quit]
troth has joined #beagle
russ has quit [Ping timeout: 268 seconds]
vagrantc has joined #beagle
russ has joined #beagle
vagrantc has quit [Quit: leaving]
ikarso has joined #beagle
outrageous has joined #beagle
metaGross128 has joined #beagle
<metaGross128> Hello Can you tell me how to enable SPI0 on beaglebone black ?
<set_> What is the deal w/ this 64-bit monstrosity of an AI?
<set_> Wondering minds 'must' know!
<set_> SPI0? Use SPI1.
<set_> SPI0 is linked to something else.
<set_> I think. Let me double check.
<metaGross128> can you share with me the device tree that enables SPI0 or SPI1
<metaGross128> ?
<metaGross128> spi0_pins: pinmux_spi0_pins{
<metaGross128>         pinctrl-single,pins = < 0x150 0x30 0x154 0x30 0x158 0x10 0x15c 0x10 >;
<metaGross128>     };
<metaGross128>     spi1_pins: pinmux_spi1_pins{
<metaGross128>         pinctrl-single,pins = < 0x190 0x33 0x194 0x33 0x198 0x13 0x19c 0x13 >;
<metaGross128>     };
<set_> Okay, okay.
<metaGross128> &spi0 {
<metaGross128>     status="okay";
<metaGross128>     pinctrl-names = "default";
<metaGross128>     pinctrl-0 = <&spi0_pins>;
<metaGross128>     compatible = "ti,omap4-mcspi";
<metaGross128>     spi-max-frequency = <0xf42400>;
<metaGross128>     dma-names = "tx0", "rx0", "tx1", "rx1";
<metaGross128>     };
<metaGross128> &spi1 {
<metaGross128>     status="okay";
<metaGross128>     pinctrl-names = "default";
<metaGross128>     pinctrl-0 = <&spi1_pins>;
<metaGross128>     compatible = "ti,omap4-mcspi";
<metaGross128>     spi-max-frequency = <0xf42400>;
<set_> Use pastebin for multi-lines!
<metaGross128>     dma-names = "tx0", "rx0", "tx1", "rx1";
<metaGross128>     };
<set_> !!!!!!!!!!!!
<set_> Stop.
<outrageous> Think it's just done in /boot/uEnv.txt
<set_> metaGross128: Please use pastebin for multilines.
<set_> You can just use them, i.e. as they are available. Right! /boot/uEnv.txt file. Enable a uboot-overlay.
<outrageous> Err, no I think I am misremembering
<zmatt> metaGross128: you don't need to do any of this to use spi
<metaGross128> i'm generating my own image
<metaGross128> using buildroot
<metaGross128> based on kernel (5.10.23)
<set_> This is going to get interesting!
<zmatt> you definitely shouldn't have "dma-names" in your custom overlay
<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"
<zmatt> also don't override the "compatible" property
<zmatt> keep in mind these declarations only enable the spi controllers, they don't declare any spi devices attached to them
<zmatt> why is your spi-max-frequency in hex? this looks like you grabbed some random stuff from a decompiled dtb or something
<metaGross128> exactly
<metaGross128> i decompiled the dtb from a debian image
<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)
<zmatt> why would you do such a thing? use the original source code
<metaGross128> do i need to delete the compatible field too ?
<set_> Are not the .org doing a mainline of the DeviceTrees?
<zmatt> you should not override the compatible-declaration of predeclared devices
<metaGross128> can you send me the correction of what i proposed
<metaGross128> i don't get you well
<zmatt> basically all that should be there is the status="okay" and pinctrl
<set_> b/c of the .dtsi "parameters" or declarations, right?
<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
<metaGross128> from kernel side and rootFS do i need to do something too ?
russ has quit [Ping timeout: 268 seconds]
<metaGross128> okay thanks for the link i will test this
<zmatt> let me see if I can find a pinmux example using mainline macros
<set_> yes!
<set_> cough. Sorry.
<metaGross128> X)
<set_> metaGross128: @zmatt know more of the BBB land type stuff than mere me.
<set_> So...have fun!
<metaGross128> haha Thanks !
<set_> I used to use the uboot-overlay, a .dts file.
<zmatt> I'm assuming he's not using overlays but a customized dts
<set_> This .dts file turned .dtbo worked in /boot/uEnv.txt for me.
<set_> Oh.
<set_> Okay.
<metaGross128> zmatt... exactly
<set_> I was just explaining my old way of doing it.
<set_> So, no uboot?
<metaGross128> i am using a customized dts
<set_> Oh. Of the entire am335x?
<metaGross128> the idea in the next iteration is to make the DTB buildin side by side in the kernel
<zmatt> set_: a dts describes the entire system's hardware
<set_> Oh...I got you now. You are using the .dtsi and then using the .dts.
<zmatt> (a normal dts that is)
<set_> Oh.
<set_> Okay.
<set_> Right. So, for this particular example, one would need just the SPI devices to show up in the .dts == .dtb file(s).
<metaGross128> how can i share the DTS in a pretty format :') ?
<set_> pastebin, pastebin, pastebin.com.
<set_> Sorry. MetaGross128: Use pastebin.com
<metaGross128> thanks
<set_> Well...
<set_> Forget it.
<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?
<zmatt> metaGross128: https://pastebin.com/mKUJ4rWn something like that?
<zmatt> you'll need to make sure you have the right #includes for those macros
<zmatt> also note that the declaration for the slave device is just an example, adjust it to taste
<set_> Fast mode!
<metaGross128> mmm okay thank
<metaGross128> i don't need to do anything in kernel side ?
<set_> Boot it!
<zmatt> I mean... make sure you have the relevant drivers enabled in your kernel config? :P
<set_> Oh.
<set_> So, when you make menuconfig or whatever, kconfig or whatever, make sure your SPI is enabled!
<metaGross128> yes i activated the spidev as module
<metaGross128> i think
<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
<zmatt> which allows you to declare names symlinks for devices in your device tree
<set_> Read back in pastebin your uboot print out while booting!
<set_> now.
<set_> Just kiddin'.
<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
<set_> Nice.
<metaGross128> compiling the new dts :D
<set_> @zmatt: Is that how it has always worked or is that new in these updated kernels?
<zmatt> but of course you can also just omit it and access /dev/spidev0.0
russ has joined #beagle
<zmatt> set_: neither? I just linked to the custom udev rule that _makes_ it work
<set_> Oh.
<zmatt> it has nothing to do with the kernel whatsoever
<set_> Double nice.
<zmatt> that udev rule is already installed by default on current beagleboard.org images