**** BEGIN LOGGING AT Wed Jul 18 03:00:02 2018 Jul 18 08:49:42 Hi. I'm trying to work with SPI devices on the Beaglebone black, running Debian with the 4.9.82 kernel. Can I ask a question about it here? Jul 18 08:50:50 so far you've already successfully asked a question here, so yes I have full confidence that you'll be able to do it again Jul 18 08:51:00 ;) Jul 18 08:51:06 Thanks :) Jul 18 08:53:36 It is with regards to SPI, pin assignment and device tree overlays. I'm trying to use/enable the SPI 1 device. I've managed to make it show up in the slots, but it is still not present in /dev/. I think it might be because the pins are occupied by the HDMI. I've tried to disable that, but it seems like a lot of information on this outdated at various sites/forums. How would I go about checking if the pins are actually configure Jul 18 08:54:05 And what else might be the reason why it is not showing up as /dev/spidev*.* Jul 18 08:54:12 if you're using the latest image you don't need to mess with overlays at all actually Jul 18 08:54:18 SPI0 is showing up and working fine Jul 18 08:54:54 I believe I'm using the latests, yes, maybe I should upgrade, just to be sure. Jul 18 08:55:22 But I haven't edited any overlays Jul 18 08:55:50 if you don't enable any custom overlays, the /dev/spidev* devices will be there and all you need to do is use config-pin to configure the pins. using overlays is still supported too, although they're now applied to the main DT by u-boot before it passes the DT to the kernel, rather than applying it at runtime Jul 18 08:56:07 hmm Jul 18 08:56:14 (configuring any custom overlay will implicitly disable "cape-universal" hence config-pin won't work then) Jul 18 08:56:45 spi1 conflicts with hdmi-audio, so you need to disable that if you want to use it Jul 18 08:57:14 on a modern image you can do that by uncommenting the disable_uboot_overlay_audio=1 line in /boot/uEnv.txt Jul 18 08:57:32 though if you still have a 'slots' file that means you're using an older system Jul 18 08:57:33 @zmatt : great, I got the last part :) Jul 18 08:58:36 I think, believe, the iamge is fairly recent. May Jul 18 08:58:44 are you booting from eMMC or SD ? Jul 18 08:58:48 eMMC Jul 18 09:00:16 huh, but you have a /sys/devices/platform/bone_capemgr/slots file? Jul 18 09:00:41 yep Jul 18 09:01:11 did you remove or comment out the enable_uboot_overlays=1 Jul 18 09:01:12 Using uname the version is listed as 4.9.82-ti-r102 -- but that is ofc only the kernel Jul 18 09:01:16 line in /boot/uEnv.txt ? Jul 18 09:03:33 No the line enable_uboot_overlays=1 is intact ... however the line `cmdline=coherent_pool=1M net.ifnames=0 quiet` does not have `cape_universal=enable` Jul 18 09:03:42 It is mentioned at https://elinux.org/Beagleboard:BeagleBone_Debian_Image_Migration Jul 18 09:03:50 that's old info Jul 18 09:04:02 that was for 3.8 -> 4.1 migration Jul 18 09:04:12 good to know :) Jul 18 09:04:53 it would probably be useful to have documentation of the various iterations of "how things were done" to be able to put information floating around on the internet in context Jul 18 09:05:54 Yeah, it seems like there has been at least 5 different directions since the beginning of beaglebone Jul 18 09:06:33 So your best advice would be to update the kernel image and start from there? Jul 18 09:06:38 I'm confused though, if the slots file exists then u-boot overlays isn't working... that usually happens when people boot from SD card due to the presence of an old (pre-uboot-overlays) u-boot version on eMMC... but you said you're already booting from eMMC Jul 18 09:06:43 this isn't kernel-related Jul 18 09:06:51 it's a bootloader issue Jul 18 09:07:14 I can upload my uEnv.txt file it that is a help? Jul 18 09:07:22 I can take a look Jul 18 09:07:28 but enable_uboot_overlays=1 Jul 18 09:07:45 should already be sufficient to enable u-boot overlays, hence make the slots file disappear Jul 18 09:07:55 what does cat /proc/cmdline say? Jul 18 09:09:27 also, do you still have the exact name of the image you flashed to eMMC/ Jul 18 09:09:30 @zmatt: https://pastebin.com/wZM75ZgJ Jul 18 09:10:19 that uEnv.txt looks fine, apart from that you need to disable audio to get spi1, not video Jul 18 09:11:02 Doesn't it disable both? (I don't need HDMI either) Jul 18 09:11:24 oh I guess disabling video will probably implicitly disable audio yeah Jul 18 09:11:49 Worth keeping in mind Jul 18 09:11:57 but anyway, as long as u-boot overlays aren't working, none of the uboot_overlay config vars will have any effect Jul 18 09:12:07 `cat /proc/cmdline` gives: console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet Jul 18 09:12:29 ehh, that's saying you're booting from SD card, not eMMC Jul 18 09:12:49 Ahh Jul 18 09:14:13 So there is an old uboot in the eMMC on the device and it is taking precedence over what is on the SD card? Jul 18 09:14:51 yes. this is something that trips up people all the time, which is why I asked 10:58 < zmatt> are you booting from eMMC or SD ? Jul 18 09:14:55 but you said eMMC :/ Jul 18 09:15:31 if you're booting from SD, simply wiping eMMC (sudo blkdiscard /dev/mmcblk1) suffices to fix the problem Jul 18 09:15:46 reflashing eMMC works too of course Jul 18 09:17:45 Is there a risk of bricking it by wiping the eMMC? Jul 18 09:17:53 none whatsoever Jul 18 09:18:55 okay -- eMMC wiped -- rebooting :) Jul 18 09:19:00 the only way to brick a beaglebone is by damaging the hardware (physically or electrically) Jul 18 09:22:42 Something definitely changed, because now the SSH server hasn't started :P brb. getting the serial connection Jul 18 09:22:50 lol Jul 18 09:23:27 is there any led activity at all during boot apart from the power led? Jul 18 09:23:49 Plenty Jul 18 09:24:04 And it shows up as a thumb drive Jul 18 09:24:20 oh so it actually boots, but borked Jul 18 09:24:21 that's weird Jul 18 09:24:33 ahh Jul 18 09:24:46 it works now -- it guess it was just much, much slower than usual Jul 18 09:25:20 oh yeah, that's another reason I personally really don't like cape-universal, it slows down boot quite significantly Jul 18 09:25:50 mainly due to inefficient udev rules I think, but I haven't really dug into it since I don't use cape-universal myself Jul 18 09:26:14 just checked: /sys/devices/platform/bone_capemgr/slots is not present Jul 18 09:26:25 as expected Jul 18 09:26:47 And both the SPI devices are there! Jul 18 09:27:06 if you want to try to identify the culprit for the slow boot, a useful tool is 'systemd-analyze plot >boot.svg' Jul 18 09:27:48 Oh! I'll write that down :) for now it is okay though. I have to get started on writing some user level drivers :) Jul 18 09:28:10 (if you trim enough fat it can look something like: https://liktaanjeneus.nl/boot.svg ) Jul 18 09:28:39 Is there a place where I could/can document what you just told me? I don't know if it is already documented somewhere? Jul 18 09:30:45 beware: spidev numbering is kinda broken in many kernel versions. I fixed it in my own kernel builds with a one-line patch but I don't think rcn ever applied it (at least to 4.9-ti). if you upgrade to a newer kernel (e.g. 4.14-ti or 4.14-bone) then spi0 should be /dev/spidev0.* and spi1 should be /dev/spidev1.* Jul 18 09:32:10 Good to know Jul 18 09:32:26 dunno of a specific documentation to point to. it's just an unfortunate result of the fact that bootrom prefers loading u-boot from eMMC over loading it from SD Jul 18 09:33:13 which is often overlooked because u-boot (regardless of how it was loaded) prefers booting linux from SD over booting it from eMMC Jul 18 09:35:57 yeah the spidev numbering thing... this patch (which fixes it) shows how spi bus numbering was being "handled" in 4.9 and older kernels: https://github.com/dutchanddutch/bb-kernel/blob/am33x-v4.9/patches/drivers/ti/spi/0001-spi-omap2-mcspi-leave-bus_num-allocation-to-spi-core.patch Jul 18 09:36:45 (the mcspi driver is overriding the bus numbering here. removing those two lines leaves the bus numbering to the spi core, which does the Right Thing) Jul 18 09:36:56 Yeah, so it depends on ordering Jul 18 09:37:32 So a newer kernel would make this consistent with the hardware -- guess I'll look into updating the kernel Jul 18 09:39:06 you can just install a kernel with apt, and there's also a script somewhere in /opt/ that can do it for you (it checks online what the latest kernel is in the series selected) Jul 18 09:39:31 Neat, thanks Jul 18 09:40:18 and yeah before it was fixed the numbering was indeed not even fixed: if only one of the two spi peripherals is enabled, it always used to be spidev1 Jul 18 09:40:27 ehh Jul 18 09:40:53 that sentence looks weird even though it's correct Jul 18 18:43:28 Hi I need help with Python. I am using Python TKinter GUI and I am trying to pipe the print statement from the console to the GUI. Here is my function: for path in execute(["C:/file.bat", "a"]): print(path, end="") text.insert(END, path) Is there an easy way to do this? Jul 18 19:11:33 I recently bought a beaglebone black and was trying to boot it with an older image of bone debian [7.5]. I made several attempts to make BBB boot from the sd card but it didn't work. I am not getting the DHCP IP. This happens only when I try to boot with an older version of OS from the SD card. Newest versionbs work just fine. 35877ce21e8ed0eb1bdc6819ad71c317 is the mdfsum expected for Debian 7.5 (BeagleBone, BeagleBone Black - 2GB Jul 18 19:12:58 ron__: first thought: "why omg why would you even try to run such ancient images?!?" Jul 18 19:13:34 ron__: second thought: sufficiently ancient kernels don't support the newer eMMC chips Jul 18 19:14:49 although I thought rcn had patched the 3.8 kernels (it's a pretty trivial patch). are you using the latest debian 7.5 image? Jul 18 19:15:26 or if you're using a custom image, try upgrading the kernel to the latest 3.8-bone kernel Jul 18 19:15:33 @zmatt The reason is that I am trying to make an ancient project work on it. Jul 18 19:15:38 https://gimx.fr/wiki/index.php?title=Bbb_sniffer Jul 18 19:15:53 tried this with the newer images and I was running into so many issues Jul 18 19:18:18 oh these instructions are actually even using a custom kernel Jul 18 19:18:37 then just like I said, try using the latest 3.8-bone kernel Jul 18 19:19:30 tried that, patched and yet it was not booting from the card Jul 18 19:19:45 i am trying to understand if there was something trivial i missed in the process Jul 18 19:20:07 are you holding down the S2 button during power-on to bypass the bootloader on eMMC? Jul 18 19:20:26 the button next to the sd card slot? yes Jul 18 19:20:39 and it works only when i am using the newest image Jul 18 19:21:03 (or alternatively, erase eMMC using "sudo blkdiscard /dev/mmcblk1" when booted from a recent image to ensure there's no bootloader on eMMC that needs to be bypassed to begin with) Jul 18 19:22:03 do note the S2 button needs to be held down while you're connecting power (you can let go once the power led turns on) Jul 18 19:23:06 let me try that once. Jul 18 19:24:02 if these two things don't help then you'll really need to check the serial debug console to figure out what's going on instead of having to guess blindly Jul 18 19:25:53 I just checked, rcn patched in eMMC 5.1 support for release 3.8.13-bone80. latest release is 3.8.13-bone86 Jul 18 19:26:40 anyway, that's enough archeology for me right now, need to do some shopping Jul 18 20:46:09 zmatt: I don't get a /dev/uio/pwmss1/qep node when I add 'compatible = "uio"' and 'symlink = ...' to &eqep1 Jul 18 20:46:37 do I need the 'module' stanza in &epwmss1 like you do in py-uio? Jul 18 20:46:48 or am I barking up the wrong tree? Jul 18 20:48:35 have you also installed the etc/modprobe.d/uio.conf file from my repo (alternatively, I recently realized that it may actually work to write compatible="uio_pdrv_genirq" in DT instead of setting the driver's of_id parameter, but I haven't tested that theory yet) Jul 18 20:48:48 and etc/udev/rules.d/10-of-symlink.rules Jul 18 20:50:14 oh right, you do actually need an uio device for the whole pwmss too Jul 18 20:50:35 the reason is that the subdevices have register spaces that are smaller than a page, hence cannot be mmap()ed Jul 18 20:50:57 in fact the whole pwmss is only one page Jul 18 20:51:48 lol, I said exactly that in comments in the DT example... https://github.com/mvduin/py-uio/blob/master/dts/pwmss2.dtsi#L39-L46 Jul 18 20:54:12 also, beware that the default declaration for the pwmss instances don't use ranges to translate subsystem-relative addresses to global addresses, so if you're not changing the pwmss's properties then you should use global addresses for the subdevices Jul 18 20:54:42 I should probably just do that too to mimize the differences Jul 18 21:00:13 (okay compatible="uio_pdrv_genirq" does in fact *not* work, so ignore that remark earlier) Jul 18 21:08:04 zmatt: thanks, I now have a device node. Jul 18 21:10:18 also it looks like you actually *need* to override the 'ranges' property of the parent pwmss since the default one doesn't span the entire 4K, which is required for the 'module' subdevice Jul 18 21:15:47 there, I've changed pwmss2.dtsi in py-uio to use absolute addresses just like the default declarations do Jul 18 21:26:07 zmatt: wut? that... works... thanks! Jul 18 21:26:22 why the surprise? Jul 18 21:28:55 zmatt: I was suprised that we were able to get this far in this number of attempts.. Jul 18 21:34:10 well the whole goal of py-uio was to make it easier for people to directly interact with peripherals from userspace Jul 19 02:12:25 hi there, I am using beaglebone black wireless for my work. I am having triouble in using P9_42 as SPI cs1. Can you help me in this regards? Jul 19 02:13:21 hmm Jul 19 02:13:39 * zmatt checks pins spreadsheet Jul 19 02:14:16 * zmatt checks universal overlay Jul 19 02:16:51 oh they solved it that way... that's kind of ugly Jul 19 02:17:07 I would like to know how Jul 19 02:17:12 Guest48760: so, the source of your confusion is the fact that P9.42 connects to *two* processor pins Jul 19 02:18:07 they could have (mostly) hidden that from users by making the config-pin setting for P9.42 configure both processor pins at the same time, but they didn't Jul 19 02:19:00 oh actually never mind, I'm not sure why you'd have trouble since the spi_cs option is on the first pin (the one actually called P9_42) Jul 19 02:19:23 config-pin P9_42 spi_cs should just work fine Jul 19 02:19:50 Actually I have tailored the uboot file in such a way that spi0 is disabled for LCD cape and spi1 is enabled by disabling HDMI pin. After that config pin command did not work Jul 19 02:20:27 please include such rather important information right away when asking a question Jul 19 02:20:48 so people don't have to guess what your problem actually is Jul 19 02:21:51 so you're using a custom overlay and want to know how to set it up for spi1 or.. ? Jul 19 02:22:12 Sorry, it read in a different way. Here is my editied questionActually I have tailored the uboot file in such a way that spi0 is disabled and those pins are used for LCD cape and spi1 is enabled to drive a LED board (by disabling HDMI pin). After that change config pin command did not work" Jul 19 02:22:42 yes. I am using a custom overlay for my work. Jul 19 02:23:16 any cape or custom overlay will automatically cause the universal overlay to be disabled, hence config-pin will not work Jul 19 02:23:36 so if you use overlays for any of your pin setup, you have to use overlays for all your pin setup Jul 19 02:25:16 I have a project that makes overlays less verbose and easier to read and write: https://github.com/mvduin/overlay-utils Jul 19 02:25:31 it includes an example for spi1 with support for cs1 commented out Jul 19 02:26:43 Yes, I saw that. If you could let me know the procedure, that would be helpful. Jul 19 02:27:59 Kindly advise me the next steps in order to use your dtsi file Jul 19 02:28:38 comment line 10, uncomment lines 11, 21, and 22 Jul 19 02:29:16 also, assuming you want an 'spidev' device in userspace, add a child node to &spi1 { .. }; that looks something like this: https://github.com/mvduin/overlay-utils/blob/master/spi0-gpio-cs.dtsi#L46-L56 Jul 19 02:29:47 then run 'make spi1.dtbo' to build the overlay Jul 19 02:30:16 copy the dtbo to /lib/firmware and enable it in /boot/uEnv.txt Jul 19 02:30:19 Actually, I could see spidev1.0 and spidev 1.1 in /dev folder Jul 19 02:30:28 which kernel version? Jul 19 02:30:43 kernel 4.9 and older have broken numbering of spidev devices Jul 19 02:32:12 it uses 1-based numbering assigned in the order the kernel counters the peripherals, so if only one of the two spi buses is enabled, it will be called "spidev1" regardless of whether it's spi0 or spi1 Jul 19 02:32:25 if you upgrade to kernel 4.14 this problem should be fixed Jul 19 02:32:47 (then spi0 always becomes spidev0 and spi1 always becomes spidev1) Jul 19 02:44:54 .... you're welcome Jul 19 02:56:15 Hi there, I am using a BBB wireless for my project. The boot file has been tailored to work in a way that my spi0 pins are disabled and they are used as I2C pins for LCD cape. My spi1 pins 28, 30, 31 are used by LED board. I want to use pin 42 as CS1 for another device. Can you guide me in doing that. PS: I have spidev 1.0 and 1.1 in /lib folder but no pinmux files. Jul 19 02:57:25 https://pastebin.com/tELx8HPE Jul 19 02:57:50 it sounds to me like you already have things configured right, what makes you think it's not? Jul 19 02:58:16 also, please don't send private messages Jul 19 02:58:56 if you have any doubts about whether your pinmux setup is right, use my show-pins utility to check the pin configuration: https://github.com/mvduin/bbb-pin-utils/#show-pins Jul 19 02:59:21 Hi zmatt, the chat broke at that time. My apologies for sending the private message. **** ENDING LOGGING AT Thu Jul 19 03:00:02 2018