**** BEGIN LOGGING AT Sun May 13 03:00:06 2018 May 13 05:11:36 * zmatt is working on a complicated project May 13 05:11:38 (waking up) May 13 05:14:51 good morning May 13 05:15:13 i am almost scared to ask what a complicated project for zmatt looks like :) May 13 05:15:47 waking up :P May 13 05:16:11 it was a joke May 13 05:46:48 zmatt: the wurst is, you have to do that every day May 13 05:47:13 well, most days May 13 09:46:21 seriously wtf, someone emailing me asking for help... without explaining what it is they need help with May 13 09:46:50 Y U NO HELP!?! May 13 09:59:35 at moments like these it would be really nice if you could email someone a dead fish with a note attached "please slap yourself in the face with this. thanks." May 13 16:16:09 hi May 13 16:17:00 i have problem with flashing sd card with debian 7.8 May 13 16:17:23 7.8 ?! that's really really ancient May 13 16:17:48 i need old debian for libreboot config May 13 16:18:06 ? May 13 16:18:26 spi setup May 13 16:18:43 why do you think you'd need an old debian for that? May 13 16:19:13 actually, I'm having a deja vu here, haven't I already discussed this with you some time ago? May 13 16:19:20 i want to use version which is described in docs May 13 16:19:29 yes May 13 16:19:55 can you write that again? May 13 16:21:04 just use the latest image, configure the pins to spi mode with for i in 17 18 21 22; do config-pin P9.$i spi; done May 13 16:21:16 then continue with the flashing instructions May 13 16:21:40 except the spidev is presumably called spidev0.0, not spidev1.0 May 13 16:21:42 ok May 13 16:21:43 (since it's spi0) May 13 16:22:27 if you want to do the pin-config at boot, just stick it into /etc/rc.local or May 13 16:22:35 ... or something May 13 16:23:16 alternatively you can still use the overlay, but you do so by sticking it into the right variable in /boot/uEnv.txt May 13 16:23:19 still idk why etcher says hash are not valid May 13 16:23:35 after flashing sd with 7.8 May 13 16:23:40 sounds like your sd card may be unreliable? May 13 16:24:15 sums of downloaded .img.xz are valid May 13 16:24:42 how can i check that issue with card? May 13 16:25:01 well if etcher's validation is failing I can't think of any other reason May 13 16:25:42 i will try with newest image and let you know about results May 13 16:25:58 (it reads back the contents of the card after flashing it and matches its hash against that of the image it flashed) May 13 16:26:32 i know how checksums work May 13 16:26:40 if it's a heavily used card, it may simply be worn out May 13 16:26:57 it is new and clean card May 13 16:27:01 weird May 13 16:27:16 but before i try flashing with dd method May 13 16:27:38 if you use dd, be sure to also manually validate the contents of the card after flashing it May 13 16:27:53 i will be back in 1 hour May 13 18:04:28 back May 13 18:06:23 zmatt, should i run etcher as root (on gnu/linux)? May 13 20:17:24 ive got a pocketbeagle running debian that has a SPI device attached. however, cape-universal makes everything (including the SPI pins) GPIO. at the advice of someone here, i compiled this dtb and put it in uEnv.txt as a custom cape, and that worked: https://pastebin.com/raw/37uK44mr May 13 20:17:54 but now, i need to use 3 of the GPIO pins. anyone know how i can enable those in DT? May 13 20:18:20 i think it was zmatt that helped me before (thanks btw, i know nothing about device tree) May 13 20:21:03 kernel version is 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 2017 if it helps May 13 20:22:51 darkengine: cape-universal makes all pin functions runtime-configurable May 13 20:24:05 that's the whole point of the "universal" May 13 20:24:23 also, they're not gpio by default on the pocketbeagle (oddly and unfortunately) May 13 20:26:07 (if I remember correctly) May 13 20:26:42 hm.. when i was using cape-universal, the kernel module for my SPI device couldnt grap the spi pins May 13 20:26:48 fbtft, its a display May 13 20:27:06 that status=disabled dtb you gave me fixed it May 13 20:27:17 but of course now i cant use the gpio pins, unless im mistaken May 13 20:27:43 I gave you that? I don't remember at all, and it seems like an odd thing to do May 13 20:28:29 ah May 13 20:28:32 it was a while ago May 13 20:28:48 does that fbtft thing use gpios in addition to spi ? May 13 20:28:59 yeah, it uses two gpio pins May 13 20:29:02 since disabling the cape-universal node has absolutely zero impact on spi May 13 20:29:14 okay so the issue was that those gpios were already claimed May 13 20:31:20 you can try preventing just those specific gpios from being exported, e.g. &{/cape-universal/P1_20} { status="disabled"; }; (replace P1_20 by the appropriate pin) May 13 20:31:37 I don't know whether that works, but it's worth a shot May 13 20:31:54 yeah, let me try that May 13 20:32:04 ah wait, you're recompiling the main dtb anyway? May 13 20:32:13 no, its a custom cape May 13 20:32:22 an overlay, ok May 13 20:32:59 (a "cape" is a piece of hardware, not a dtbo, although the silly name of "cape-universal" probably helped to create that confusion) May 13 20:33:53 its also commented as "Custom Cape" in uEnv.txt :P May 13 20:34:01 if customizing the main dtb you could do &{/cape-universal} { /delete-node/ P1_20; }; which would definitely work, but /delete-node/ doesn't work in an overlay May 13 20:34:38 I'm not sure whether setting status="disabled"; will work for these nodes since they're not devices, but it's worth a try May 13 20:37:04 if it doesn't your options are 1. customize the main dtb 2. disable the /cape-universal node and manually export the gpios you need 3. disable the /cape-universal node and make a replacement for the gpios you need May 13 20:38:08 so something like this? https://ghostbin.com/paste/ghdhm May 13 20:38:19 im using gpio 89, 26, and 20 May 13 20:38:30 for the LCD May 13 20:39:10 yes something like that May 13 20:41:17 gpio numbers don't mean anything to me. I don't have a quick reference for the pocketbeagle, and if I did it would use . numbering, not the sequential assignment of gpio numbers by the kernel (which is kinda iffy to use anyway since the kernel simply assigns consecutive blocks of gpio numbers to gpio controllers as it encounters them. adding or disabling a gpio controller would totally ... May 13 20:41:23 ...mess up the numbering) May 13 20:42:30 (although it seems safe enough to rely on in practice, it's mostly just conceptually iffy :P ) May 13 20:42:36 that dtbo hangs uboot May 13 20:42:44 eh? May 13 20:43:07 usr1 and usr2 are stuck on May 13 20:43:18 sorry usr0 and usr1 May 13 20:43:32 that's really weird. bug in u-boot maybe? May 13 20:44:09 last time we did this, a bad dtbo did the same thing May 13 20:44:18 overlays suck May 13 20:45:23 alternative you can try: https://pastebin.com/raw/Qz3rygFB May 13 20:47:14 this is completely equivalent to your version, but maybe u-boot has some bug in resolving "deep" target-paths (deeper than 1 level :P ) May 13 20:49:44 same thing :/ May 13 20:49:51 that's really bizarre May 13 20:50:27 did I mention overlays suck? :D May 13 20:50:49 maybe u-boot outputs useful diagnostics, if you can access the serial console May 13 20:51:03 otherwise maybe pick one of the other three options mentioned earlier May 13 20:51:20 manually exporting the gpios was what i was expecting to do May 13 20:51:54 that should work yes, just echo the gpio number to /sys/class/gpio/export May 13 20:52:27 and don't forget make sure the pin you want to use as gpio is configured as gpio (using config-pin) May 13 20:53:18 oh, i just dug through my irc logs May 13 20:53:49 oh I actually got the path wrong, it's /ocp/cape-universal ... oops. not very nice that u-boot completely bugs out on a nonexistent path, but I can't say I'm terribly surprised May 13 20:53:56 lol May 13 20:54:22 I just followed the pastebin you linked May 13 20:54:55 I don't really remember saying that, but I fully agree with my past self ;) May 13 20:55:51 why on earth did they toss these devices into /ocp ? sillybeans May 13 20:56:19 /ocp is supposed to represent the soc's interconnect, it's the wrong place for virtual devices May 13 20:58:07 unfortunately it still exports all the gpios May 13 20:58:18 with the fixed patch May 13 20:58:20 yeah I was afraid of that May 13 20:59:23 and I just checked, "breaking" those nodes in some way isn't an option either, the kernel driver doesn't merely skip subnodes if it encounters an error, it bails out entirely (i.e. no gpios will be exported) May 13 20:59:50 so you're back to the other options mentioned earlier May 13 21:03:49 echo [num] > export does it May 13 21:03:59 almost too easy May 13 21:04:01 thanks :) May 13 21:04:21 oh yeah, is there any place i can RTFM on pocketbeagle DT stuff? like a reference or something? May 13 21:05:00 no idea? I mean, besides the dts itself May 13 21:21:25 The pocket beagle schematic is available in KiCAD of which I am grateful for. May 13 21:22:22 Other than that you might get some help from octaveo systems website. https://octavosystems.com/ May 13 21:23:06 uhh, how is any of that useful as documentation on "DT stuff" ? May 13 21:24:30 good question! May 13 21:24:39 darkengine: oh actually I *do* have a reference for which pin is which gpio.. I forgot I added a tab for the pocketbeagle to my pins spreadsheet May 14 00:43:05 I'm using BeagleBone Black Wireless, and installed a debian server image. Everything is working fine, except I don't have even text output on the screen. I usually ssh onto the bone but I lost my access to it May 14 00:44:00 Does anyone have any suggestions regarding what I should setup (no X server, something less drastic please :) ) so that I don't run into this problem in future? **** ENDING LOGGING AT Mon May 14 03:00:01 2018