**** BEGIN LOGGING AT Sat Jul 28 02:59:59 2018 Jul 28 04:27:32 e Jul 28 05:44:19 Looking for a SW developer on the BBB wireless Jul 28 05:45:52 Seems no one is here... Jul 28 09:01:07 e Jul 28 09:10:48 hi Jul 28 09:10:57 i need to access /sys/devices/bone_capemgr.*/slots in beaglebone Jul 28 09:11:11 somehow, it works in debian 7 from bbb website, but not debian 9 Jul 28 09:11:32 i'm following https://embedded-basics.blogspot.com/2014/10/enabling-spi0-on-beaglebone-black.html here Jul 28 09:12:29 sfs: obsolete information Jul 28 09:13:03 zmatt: i figured, but how can i fix it now? Jul 28 09:14:05 on a recent image in the default configuration, spi0 is enabled by default (the spidev devices exist) and all you need to do is configure the pins to spi mode using config-pin P9.18 spi and similar for the other pins Jul 28 09:15:33 alternatively, using overlays is also still supported, but they need to be configured in /boot/uEnv.txt Jul 28 09:16:30 zmatt: do you mean i should put uboot_overlay_addr0=/lib/firmware/BB-SPI0-01-00A0.dtbo and reboot? Jul 28 09:16:34 i did that Jul 28 09:16:43 (the two methods are mutually exclusive: if overlays are loaded, either manually or due to cape auto-detection, then "cape-universal" is implicitly disabled hence runtime configuration of pinmux using config-pin won't work anymore) Jul 28 09:16:49 are you booting from sd card? Jul 28 09:16:51 yes Jul 28 09:17:23 there's a known issue where an old bootloader on eMMC can cause such problems. asssuming you don't care about the contents of eMMC, erase it with: sudo blkdiscard /dev/mmcblk1 Jul 28 09:17:36 or reflash eMMC with the latest image Jul 28 09:18:16 ok, i erased eMMC Jul 28 09:18:20 rebooting... Jul 28 09:24:15 that's a long reboot Jul 28 09:25:29 reboot is done, i needed to go out for a while :) Jul 28 09:26:00 there's still no bone_capemgr directory Jul 28 09:26:01 root@beaglebone:~# ls /sys/devices/ Jul 28 09:26:01 armv7_cortex_a8 breakpoint platform soc0 software system tracepoint virtual Jul 28 09:26:07 none is expected Jul 28 09:26:14 certainly not in that place Jul 28 09:26:52 it's actually /sys/devices/platform/bone_capemgr in 4.x kernels, but it is deprecated now and the slots file is gone when uboot overlays are functional Jul 28 09:27:13 ok, then i get it now Jul 28 09:27:27 i have in /boot/uEnv.txt: Jul 28 09:27:27 echo BB-SPI0-01 > /sys/devices/bone_capemgr.*/slots Jul 28 09:27:30 damn Jul 28 09:27:34 echo BB-SPI0-01 > /sys/devices/bone_capemgr.*/slots Jul 28 09:27:53 try copy before paste :) Jul 28 09:28:06 you probably meant uboot_overlay_addr0=/lib/firmware/BB-SPI0-01-00A0.dtbo Jul 28 09:28:11 since you already mentioned that Jul 28 09:28:24 yes Jul 28 09:28:41 it's probably preferred to use one of addr4-7, although it doesn't matter hugely Jul 28 09:29:08 i use bbb only as flashrom programmer, so as long as it works, it's ok for me :) Jul 28 09:29:15 (addr0-3 correspond to physical cape slots and will override the overlay for auto-detected capes if any were present) Jul 28 09:30:20 ok, i changed that to address 4 Jul 28 09:30:46 i can see there is /dev/spidev1.0 Jul 28 09:31:03 are you using kernel 4.9 or 4.14 ? Jul 28 09:31:07 4.14 Jul 28 09:31:24 the newest image from bbb website Jul 28 09:31:27 that's odd, I wonder if rcn deliberately made 4.14 bugwards compatible Jul 28 09:31:45 since the broken spidev numbering should be fixed in mainline 4.14 Jul 28 09:32:50 zmatt: thanks for help Jul 28 09:33:29 omg he... actually did -.- https://github.com/beagleboard/linux/commit/6f78ee10dd13 Jul 28 09:33:37 * zmatt sighs Jul 28 09:33:44 I mean, I understand it, but still *sigh* Jul 28 09:34:06 especially since it doesn't actually match old behaviour either Jul 28 09:34:50 so there should be /dev/spidev0.0 instead? Jul 28 09:35:01 in mainline 4.14 it would be spidev0.0 Jul 28 09:35:46 but rcn deliberately patched the dts to make it use (something resembling) the old broken numbering for backwards compat Jul 28 09:36:22 you could use an overlay to fix that again :P Jul 28 09:36:47 actually no, not really Jul 28 09:36:52 well maybe, not sure Jul 28 09:42:28 sfs: if you switch to a 4.14-bone kernel (sudo apt-get install linux-image-4.14.55-bone16) then it's actually also spidev0.0, lol Jul 28 09:45:05 zmatt: what's the difference between bone and ti kernels? Jul 28 09:46:15 -bone is mainline + patches, -ti is TI's kernel tree + patches. also bone is (at least intended to be) configured mostly specific to beaglebones while the -ti kernel is also used on beagleboards (hence it's an SMP kernel for example) Jul 28 15:40:53 zmatt: udev rule :P Jul 28 15:41:50 mhh, can you *rename* a non-network device rather than merely add a symlink? Jul 28 15:45:09 I was going with the rename tbh Jul 28 15:45:22 *cough* symlink Jul 28 15:45:35 ergh .. blood in caffeine stream :/ sorry Jul 28 15:46:22 regardless, there's no reason to fix this problem with a udev rule if you don't first break it in the dt :P Jul 28 15:46:52 eh its all relative Jul 28 15:47:39 the specs and docs should really be written on toilet paper the rate at which things change .. (for better or for worse...) Jul 28 15:50:21 well the old numbering was really broken... and I've used a patch to fix it for pretty much as long as I use beaglebone: 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 (which became redundant when it was fixed in mainline) Jul 28 15:51:02 still, I understand why rcn chose to keep the numbering (mostly) bugwise compatible Jul 28 15:58:14 yeah there's no good answer >,< Jul 28 15:58:36 ideally it was fixed right away when moving to 4.x (when various stuff was broken anyway) Jul 28 16:02:45 I gotta say though .. the continuous support effort is admireable .. Jul 28 17:02:19 oh definitely Jul 29 02:08:18 i am kind of stunned that the BB blue has not become the defacto robotic controller go-to. **** ENDING LOGGING AT Sun Jul 29 03:00:00 2018