**** BEGIN LOGGING AT Tue Feb 09 03:00:29 2021 Feb 09 03:06:49 Before 10! Feb 09 03:06:58 I am back on the trail, here. Feb 09 03:11:57 right so detail why things work then eliminate things that are obviously not it. IE SpaceX has nothing to do with the issue (example only). Feb 09 03:13:42 Okay. Okay. Okay! Feb 09 03:13:50 My leds are back. Feb 09 03:14:27 Obviously, I have the wrong SPI1 installed under overlays. I need to find a way to get back on the board. It will not boot just yet. Feb 09 03:14:39 I think it is about to boot again. Feb 09 03:21:48 It seems to work w/ the LCD only when I use SPI1 instead of SPI0. Feb 09 03:22:31 And...I cannot get to SPI1 b/c of using a LCD Cape b/c of i2c. Feb 09 03:28:25 so what is the i2c attached to? Feb 09 03:36:01 BBGW to LCD. Feb 09 03:36:16 so the LCD is a cape then? Feb 09 03:36:22 But...now. The board does not boot w/ the FLIR attached. Feb 09 03:36:24 Yes. Feb 09 03:36:37 The LCD is a cape but I have wires b/c i have to fit in the FLIR. Feb 09 03:38:14 set_ mind if I explain something? the reason why you write things down is so when something goes wrong you know what you changed and you can more quickly isolate why it doesn't work. Feb 09 03:38:27 I know what I changed. Feb 09 03:39:20 It is okay. I stopped using SPI CLK and MISO w/ the LCD Cape and FLIR. Feb 09 03:42:04 So, I found that from an article, the SPI1 on the BBGW is messed up. So, the remedy for this 'mess up' was to remove two resistors on the BBGW. Feb 09 03:42:11 I removed them. Feb 09 03:43:10 So, now I should be able to use SPI1 but I was not thinking b/c the SPI1 has specific pins dedicated to them. I will keep trying. I may be up late if you want to hang in there for any related info. Feb 09 03:50:35 Oh well. I guess I will try to read over the notes and pick up the pieces. Feb 09 03:52:47 hmm OK sleep is necessary as they say. Feb 09 03:53:05 Fine. Feb 09 03:53:08 Have fun! Feb 09 04:14:17 GenTooMan: I am up and running and about to test w/ MOSI/MISO real quickly. If you are up, I will tell you what happens. Feb 09 04:17:42 Forget it. You are right. sleepy time. Feb 09 10:30:41 hello. I have a problem with RS-485 (UART4 = P9_11, P9_13, P9_27). Log file: https://easyupload.io/g0xjdv Feb 09 10:35:42 Linux kernel: 4.14.108-ti-r124 Feb 09 11:05:13 Hello. is anyone here? Feb 09 11:29:36 mhanusek: sometimes.. but you haven't really described/explained a problem for anyone to respond to. Feb 09 11:35:43  @zmatt I have a problem with run rs485 communication with BBB. I have max485 (uc) connected to BBB. DI -> P9_13, RO -> P9_11, DE/RE -> P9_27. I loaded overlay BB-UART4-RS485-00A0.dtbo. But not working correct. I can read a messages, I can't write. Feb 09 11:36:25 RTS is not working correctly. Feb 09 11:42:30 looks like that overlay was written for the omap-serial driver rather than the 8250-omap driver Feb 09 11:43:34 though I think you don't even strictly need an overlay to use rs485 since it can be enabled from userspace Feb 09 11:43:56 e.g. https://pastebin.com/r1rJFUfr Feb 09 11:46:04 and it seems that doing so is actually required since my notes ( https://pastebin.com/7DKDZ0NP ) say the 8250 driver ignores the rs485 DT configuration in kernel 4.19 Feb 09 11:48:35 also, the 8250 driver doesn't support using a gpio for DE (until kernel 5.3) so you need to use the actual RTS signal Feb 09 11:49:19 * mru hates those drivers Feb 09 11:50:12 which for uart 4 is on P8.33 (requires disabling video in /boot/uEnv.txt if you haven't done so already), not P9.27 Feb 09 11:51:47 @zmatt I use Python: https://pastebin.com/V9u8bGcX Feb 09 11:54:16 mhanusek: using rtscts=True is almost certainly wrong and would conflict with rs485's usage of the rts pin Feb 09 11:54:26 but mainly, you shouldn't use this overlay Feb 09 11:55:02 and like I said, use the actual RTS pin on P8.33 Feb 09 11:55:09 @zmatt /boot/uEnv.txt  -> http://pastebin.com/7cdbbYgz Feb 09 11:55:37 uhh wtf Feb 09 11:55:44 what happened to this /boot/uEnv.txt ? Feb 09 11:56:28 cape_disable does nothing Feb 09 11:56:56 there are normally commented-out example settings, including for disabling video Feb 09 11:57:25 and you should have cape universal enabled (it is normally enabled by default) Feb 09 11:58:10 @zmatt how to disable video? Feb 09 12:00:00 uncomment the appropriate line... I don't remember the exact name but it's easy to recognize since it's named something like "disable video overlay" Feb 09 12:00:10 disable_uboot_overlay_video=1 Feb 09 12:00:10 ? Feb 09 12:00:58 and get rid of the custom overlay you enabled and reenable cape universal (which you presumably disabled yourself) Feb 09 12:01:33 you could configure the pins using an overlay instead of using config-pin, but I don't think there's any overlay that's correct for this purpose so you'd need to make one, which is more hassle than just using config-pin Feb 09 12:05:05 zmatt, ok. I disabled video in /boot/uEnv.txt Feb 09 12:05:31 zmatt I dont understand. I can't use this -> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART4-RS485-00A0.dts  ?? Feb 09 12:06:57 no, like I already said, that was written for the omap-serial driver (which is no longer in use) rather than the 8250-serial driver (which is currently in use but which currently doesn't support DT configuration for RS485) Feb 09 12:07:31 to use that overlay you'd need to reconfigure and recompile the kernel to use the omap-serial driver instead, and hope it still works Feb 09 12:07:44 however you don't really need the overlay to setup rs485 since you're doing so from userspace Feb 09 12:08:31 so you can just pick any uart, configure its rxd/txd/rts pins using config-pin, and then enable rs485 mode from userspace (like you're doing already) Feb 09 12:08:39 no need to mess with overlays Feb 09 12:12:58 @zmatt, thx. I will try config-pin. Feb 09 12:13:18 you'll need to reenable cape universal in /boot/uEnv.txt (which you appear to have disabled) Feb 09 12:14:54 zmatt, thx -> enable_uboot_cape_universal=1 Feb 09 12:15:11 and for reference, overview of uart pins: https://pastebin.com/ENCBhyui Feb 09 12:16:27 @zmatt Feb 09 12:16:33 zmatt Do I have to use P8_33 instead of P9_27? Feb 09 12:16:53 I've told you that at least twice already Feb 09 12:18:03 using an arbitrary gpio will require kernel 5.4, which is still experimental for beaglebone and not officially supported yet Feb 09 12:19:03 zmatt ok. Feb 09 12:20:20 zmatt sorry for having to repeat. My English is not the best. Feb 09 12:41:40 @zmatt how to enable RTS with config-pin ? Feb 09 12:42:43 oh wtf, cape-universal is missing the uart mode for that pin? argggh Feb 09 12:43:45 *sigh* Feb 09 12:44:36 I should probably open an issue for this since this is just a mess and I think it's not the first time I observed that, I just forgot Feb 09 12:45:51 zmatt my guess is that: config-pin P8.33 uart should work? Feb 09 12:46:56 it ought to, it doesn't since cape universal appears to be missing the uart mode definition for that pin Feb 09 12:47:29 so right now an overlay is required after all :/ Feb 09 12:48:47 I'll write an example, just not right now... ask me again later Feb 09 12:50:10 zmatt, ok. thx. I care about this. Feb 09 14:34:50 as a side note, that mess with pin modes and overlays in recent kernels was the exact reason i gave up using BBBs about a year ago. coming from an old 3.8 kernel and a working overlay using a GPIO for the RE/DE management over the omap driver, i felt quite confused trying to make my custom cape compatible with current kernels. i would really appreciate efforts for making things clearer in this matter Feb 09 14:35:52 I mean, the main problem is just the abandonment of the omap-serial driver despite its replacement 8250-omap driver not having equivalent functionality Feb 09 14:36:06 it's often easier to skip the overlay complexity and make a plain devicetree that matches your own setup Feb 09 14:36:18 no it's not Feb 09 14:36:23 yes it is Feb 09 14:36:40 That's largely what I did and I think it was simpler. (shrug) Feb 09 14:36:49 overlays do not really have complexity beyond making a normal DT, at least not if you use the recent format Feb 09 14:36:53 take the base devicetree Feb 09 14:36:54 the content is ultimately the same Feb 09 14:36:56 add your stuff Feb 09 14:36:58 done Feb 09 14:37:11 overlay is the same, except it's just "add your stuff" Feb 09 14:37:32 plus keep up with what's the "recent format" Feb 09 14:37:51 you also need code to load the overlay Feb 09 14:38:13 a single line in /boot/uEnv.txt, which you'd also need to select a custom main dtb Feb 09 14:39:05 the overlay system is probably simpler for people who buy a board and a known cape which will then Just Work™ Feb 09 14:40:50 so, for a custom dtb you'd #include the base dtb and then add some definitions below that... for an overlay you can take those exact same definitions (except if you have any / { .. }; block rewrite it as &{/} { .. };), prepend /dts-v1/; /plugin/; and any #includes needed for macros/constants Feb 09 14:41:14 so apart from boilerplate at the top, overlay and custom dts are the same Feb 09 14:41:30 (using &{/} { .. }; also works in a custom dts) Feb 09 14:41:34 you also get multiple files Feb 09 14:41:39 no Feb 09 14:41:50 no .dtbo? Feb 09 14:42:02 you'd get one custom .dtbo, instead of one custom .dtb Feb 09 14:42:23 but you need both the .dtb and the .dtbo to boot Feb 09 14:42:41 and if you have multple kernel versions you almost always use the same .dtbo for all of them instead of having to recompile the custom .dtb each time Feb 09 14:42:51 sure, but the .dtb is the standard one that comes with the kernel Feb 09 14:43:00 you still have to deploy it Feb 09 14:43:15 please stop telling me what's easier for me Feb 09 14:43:25 don't get me wrong, I use a custom dtb too, but I think for most users who use a standard kernel using an overlay makes more sense Feb 09 14:43:41 sorry, I didn't mean it like that Feb 09 14:43:55 but the "complexity" of overlay is a bit of an overstatement Feb 09 14:43:58 people who use a ready-made system with known capes may prefer the overlay route Feb 09 14:44:18 for people making their own system, it's at best equal effort Feb 09 14:45:18 the main downside of a custom .dtb is it being tied to the kernel version being used... in theory older dtbs are supposed to work with newer kernels but in practice that's often not true Feb 09 14:47:48 right, so best not to pretend that they do Feb 09 14:48:33 yep, if you have a custom dtb I would recommend recompiling for each major kernel update Feb 09 14:48:47 I always do Feb 09 15:49:35 zmatt Can U help me? Feb 09 15:49:40 with UART4-RS485 and config-pin... Feb 09 16:00:35 m Feb 09 16:21:10 @which uarts work with config-pin? uart1 and uart2? Feb 09 16:25:38 sudo config-pin P8.32 uart Feb 09 16:25:39 Invalid mode: uart Feb 09 16:29:09 setting rts via config-pin only works for uart2 (config-pin P8.38 uart) Feb 09 16:29:51 no you configured it to uart 5 rxd by doing so Feb 09 16:31:17 zmatt, ok... Feb 09 16:31:27 until cape universal is fixed to include uart rts/cts modes, using an overlay is the only option Feb 09 16:31:51 but, still doing stuff, back later Feb 09 16:37:15 zmatt, need to modify this script to fix it? https://github.com/beagleboard/bb.org-overlays/blob/master/tools/beaglebone-universal-io/config-pin#L700 Feb 09 16:37:16 need to modify this script to fix it? is it more complicated? Feb 09 17:39:51 zmatt look: https://pastebin.com/paGAsxUg Feb 09 20:28:21 hello Feb 09 23:43:48 i try to boot a black for first time. after plug in usb pwr led on, the led 0-3 all on then led 1&3 on then all 4 then a little flicker and all led go off. Feb 09 23:45:06 i have no idea what that mean Feb 09 23:48:59 never mind it works with the supplied cord Feb 09 23:49:43 it means that other cable belongs in the rubbish bin Feb 09 23:50:24 it was new cord yesterday? work with logic analyzer Feb 09 23:50:41 oh well Feb 09 23:51:59 failure to boot with a specific cable most likely means it's too thin Feb 09 23:52:08 so it has too much voltage drop Feb 09 23:52:22 oh that makes sense Feb 10 00:16:27 Is SPI0_DO MISO or MOSI on the BBG? Feb 10 00:16:40 I am having difficulty right now w/ this idea for some reason. Feb 10 00:17:20 Finger to future self, "Listen and read!" no, no, no. And yes, I am battling w/ myself now! Feb 10 00:17:41 But seriously, which is what? Feb 10 00:19:21 I seriously am lacking in the field of SPI. Sheesh. I am reading now. I figured out how to function again. Feb 10 00:19:25 ! Feb 10 00:20:52 https://elinux.org/BeagleBone_Black_Enable_SPIDEV is relevant or not? Feb 10 00:21:55 B/c I enabled the BB-SPI-xxx-xxxx.dtbo in the uboot overlays section of /boot/uEnv.txt but notta. I tried the SPI1 and SPI0 overlay so far. Feb 10 00:23:38 Okay, okay. Feb 10 00:24:12 So, w/ an overlay, I really need to understand the overlay before jumping to conclusions (like I ALWAYS do). Feb 10 00:24:26 It is not cut and paste here. Okay. Feb 10 00:27:14 Software defined! Feb 10 00:36:19 I only learn new stuff. It is so odd? Feb 10 00:37:47 Well, new to me. Gosh. Feb 10 00:38:45 bbs Feb 10 01:06:43 Phew. I amd'd it. Feb 10 01:06:44 ha. Feb 10 01:07:10 GenTooMan: I am making a short of MISO to MOSI! Feb 10 01:07:14 Get ready! Feb 10 01:20:37 Blah. Feb 10 01:32:46 spidev_test does not work on my board, i.e. from this link : https://github.com/derekmolloy/exploringBB/tree/version2/chp08/spi/spidev_test Feb 10 01:33:06 I receive extra 00 numerical values. Is that normal? Feb 10 01:41:11 depends Feb 10 01:41:21 Ha. How does it depend? Feb 10 01:41:41 I like it when you show up. Play along or else! Feb 10 01:41:42 Ha. Feb 10 01:42:51 I checked my pin configuration, the actual short from MISO to MOSI or vice versa, and overlay. Feb 10 01:44:49 oh! Feb 10 01:44:59 I just checked the source. It is only for SPI1. Feb 10 01:47:28 500 Khz! Feb 10 01:47:31 Zoom! Feb 10 01:48:14 I did some reconfig. w/out knowing much and still achieved a "success." I am waiting on the outcome. Feb 10 01:50:22 0.0 0.1 dance it off! Feb 10 01:50:58 Let me check things out here...yep. I got some funky two-digit letters. Uh? Feb 10 01:51:26 I guess it is time to figure out what those letter-digits mean. Feb 10 01:52:47 F = 16, right? Feb 10 01:53:10 Let me look it up, Dang it! Feb 10 01:54:20 yea. 16, so. Double F or FF, as some like it, means 32. Okay. Then, I have some numerical values. Feb 10 01:55:04 two words in a F. Feb 10 01:55:23 That can move very, very, very fast. Feb 10 01:56:11 F0, 17, Blah. GenTooMan, direct me on where to look for this idea or a book. Feb 10 01:57:05 I can read until my eyes bleed! Feb 10 01:57:08 Ha. Feb 10 01:58:12 Excuse me. GenTooMan, will you please direct me on where to look for an idea on my 'calculations' on the spidev_test from Dr. Molloy? Feb 10 01:58:50 Oh...guys. The 3D Printing of the violin is making headway! Feb 10 01:58:59 But. at 75%. boo! Feb 10 02:19:51 DE AD BE BE BA AD FO OD? Feb 10 02:19:52 Ha. Feb 10 02:22:42 Correction, BE BE is BE EF. Feb 10 02:25:19 Oh well. I do not have a logic analyzer. So, I am out for now. Feb 10 02:27:45 So, it sends, receives, and the terminal emulates a nice output in hexidecimal format but skipping the 0x part. **** ENDING LOGGING AT Wed Feb 10 03:04:52 2021