**** BEGIN LOGGING AT Sat Apr 11 02:59:57 2020 Apr 11 03:01:10 GenTooMan: Did you see earlier? Apr 11 03:01:41 I got that drone up and away in the house! It banged against a wall and dropped like a can of filet of fish. Apr 11 03:19:47 So, we are using u-boot overlays. Okay. Does this mean that one cannot use a device tree overlay now? Apr 11 03:21:22 I am reading a book from 2015 and the book promotes the older way to declare pin muxing on the BBB. Apr 11 03:27:14 For instance, on the AI, pin muxing is only done via overlays, right? So, in theory, I can use the older versioning of pin muxing for that board. Apr 11 03:47:47 I don't think the BBAI u-boot supports overlays yet Apr 11 03:48:34 regardless, any pinmuxing done by the kernel (whether based on DT or done at runtime) is subject to the same glitching issue Apr 11 03:49:30 Oh. right. I just forgot that people were working on it. Apr 11 03:50:20 who is? Apr 11 03:50:52 I have an *idea* on how to fix it, I'm not aware of anyone currently working on attempting to implement that idea Apr 11 03:51:25 Oh. Apr 11 03:51:26 (and by "fix it" I mean allow u-boot to perform DT-based pinmux configuration) Apr 11 03:51:40 I thought people were working on making the pinmux work for the AI. Apr 11 03:51:47 Right. I thought that was the idea. Apr 11 03:52:02 dt-based pinmux Apr 11 03:52:39 not that I'm aware of Apr 11 03:56:24 Oh. I just thought since it was discussed once, it may have been an idea to pursue. Apr 11 03:57:02 I mean...there are many pins on the AI. It can, if the pinmuxing could start, do all sorts of stuff. Apr 11 04:07:49 How would I use the device tree compiler on a BBB for use w/ a .dts file? Apr 11 04:23:43 or... Apr 11 04:24:02 Better yet. How would I see if my .dtbo file in /lib/firmware/ is working? Apr 11 04:24:22 that's a very different question Apr 11 04:24:38 I know. I thought the dtc broke on my machine. I was mistaken. Apr 11 04:24:54 I entered in the incorrect .dts file info. Apr 11 04:25:39 So, I see $SLOTS and $PINS is no longer viable. I have known this to be true for some time now. But... Apr 11 04:25:44 What is the alternative? Apr 11 04:26:06 normally an overlay contains a snippet that identififies it by creating an entry in /chosen/overlays. you can see these in the standard overlays: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART1-00A0.dts#L33-L46 and they're also automatically inserted by my overlay-utils Apr 11 04:26:44 Right. I am on that page, i.e. the bb.org-overlays. Apr 11 04:26:53 assuming your overlay has such a snippet you can check /proc/device-tree/chosen/overlays to confirm the overlay has been applied Apr 11 04:27:02 Aw. Apr 11 04:27:42 Oh. Apr 11 04:28:03 Okay. Apr 11 04:28:04 that's the most direct way of checking which overlays have been applied Apr 11 04:28:27 AM335X-PRU-RPROC-4-19-TI-00A0 BB-ADC-00A0 BB-BONE-eMMC1-01-00A0 BB-HDMI-TDA998x-00A0 BBORG_RELAY-00A2 name Apr 11 04:28:29 Those are mine. Apr 11 04:28:48 now...I have not applied mine somehow b/c I do not know how. Apr 11 04:29:09 Do I need to jump into U-boot to handle this issue? Apr 11 04:29:11 why do you need a custom overlay? Apr 11 04:29:18 Well... Apr 11 04:29:34 I was going to make some hardware on a protoboard. Apr 11 04:29:39 Then... Apr 11 04:29:53 I was going to handle the pinmux w/ a .dts to .dtbo file. Apr 11 04:30:20 why not just use config-pin ? Apr 11 04:31:03 I mean. I could. I just figured this might be a handy notion to learn in case things change. Apr 11 04:31:42 Cycles. Things usually, like loops, run in cycles. Apr 11 04:32:19 I figured if more boards produced by beagleboard.org were no longer utilizing the config-pin source, I should learn something else. Apr 11 04:32:25 regardless, custom overlays can be configured in /boot/uEnv.txt in the dtb_overlay variable or one of uboot_overlay_addr4..7 (all are equivalent). note that any small mistake in the overlay has a high probability of causing your system to fail to boot entirely Apr 11 04:32:43 Okay. Apr 11 04:32:53 I remember that idea. Apr 11 04:33:27 So, putting my custom .dtbo needs to be loaded in /boot/uEnv.txt. Okay. Apr 11 04:33:39 and if you do intend to make overlays, you may want to look into my https://github.com/mvduin/overlay-utils which makes it easier to write overlays Apr 11 04:34:22 Okay. I will look it over. Apr 11 04:35:22 I have been studying the older/current overlays on github.com/beagleboard/bb.org-overlays for reference. Apr 11 04:35:53 I also have been searching through the elinux site but it is an enormous cycle of some faulty but some good info. Apr 11 06:07:31 Hello Everyone. Apr 11 06:07:31 I am planning to use the x15 or the BB AI (I don't have them currently). The x15 has DSPs while the AI has EVE+DSP. If I use some third party libraries like the NNPACK or Tencent's NCNN, what options do I have, to distribute the workload among these co-processors ? Apr 11 06:07:46 the x15 and the bbai have the exact same SoC Apr 11 06:08:19 P.S. I know TIDL is an option but are there other options too ? Apr 11 06:09:13 (i.e. both have four EVEs and two C66x DSPs) Apr 11 06:10:52 thanks for correcting 🙂 Apr 11 06:12:00 unfortunately I'm not particularly familiar with the tools available for them. both targets have a C/C++ compiler (and at least the C6x one is available standalone, haven't checked for arp32/eve), and OpenCL is a thing Apr 11 06:15:46 Yes, I thought of using OpenCL backend of these coprocessors after a TI representative mentioned that Apr 11 06:15:46 > The TIDL leverages OpenCL to leverage the DSP and EVE cores for deep learning inference computations Apr 11 06:15:46 But on referring to the docs, I nowhere see EVEs being referred to, when discussing OpenCL Apr 11 06:16:40 * Hello Everyone. Apr 11 06:16:40 I am planning to use the x15 or the BB AI (I don't have them currently). The x15 has DSPs while the AI has and the AI have EVE+DSP. If I use some third party libraries like the NNPACK or Tencent's NCNN, what options do I have, to distribute the workload among these co-processors ? Apr 11 06:16:56 why are you repeating yourself? Apr 11 06:18:29 I don't see anything like that... perhaps the IRC issue Apr 11 06:19:09 and yeah there seems to be an annoying amount of vagueness surrounding the EVEs. I can't find a standalone compiler (although one is included as part of TI's Code Composer Studio) and the EVEs are not properly documented in the AM572x TRM (although they are in the TDA2 TRM) Apr 11 06:23:00 I am trying to propose/validate a project surrounding these boards for GSoC this year. Getting a faster inference without using the accelerators seems difficult Apr 11 13:47:17 Hello Everybody, I'm trying to use DLP2000EVM on BBBW but i2c doesn't work. Has anyone ever tried this ? Regards Apr 11 13:53:28 find this, tr more ... https://www.element14.com/community/community/designcenter/single-board-computers/next-genbeaglebone/blog/2018/03/18/beaglebone-black-wireless-with-ti-dlp-lightcrafter-display-2000-evm Apr 11 13:53:35 try Apr 11 14:32:25 tutu no I have the old DLP for the beagleboard though. One of the often frustrating things with TI is they bang something out as a demo and not a product. That is they make it work but that doesn't mean it works correctly. Apr 11 14:53:24 I still want to try out that DLP cape Apr 11 14:53:59 dlp? Apr 11 14:54:36 I do to but Digital Light Projector micro mirror demo unit from TI Apr 11 14:57:24 that sentence looks like you started to reply to me but changed your mind halfway through :D Apr 11 14:57:48 MattB00ne: but yeah, Digital Light Projector. I'm talking about this thing: http://www.ti.com/tool/DLPDLCR2000EVM Apr 11 14:58:14 sorry it stands for Digital Light Processing actually Apr 11 15:03:50 that would be my fault. I'm still waking up .. Apr 11 15:07:16 I do wonder what strobe frequency it uses since I'm kinda sensitive to that Apr 11 15:14:27 well a good question they do modulation of the light using the mirrors I believe they are on or off so they have no sub light levels that leaves delta sigma averaging. So likely far greater than the frame rate. Apr 11 15:23:03 that doesn't really imply anything about the strobe frequency though, since you could modulate the mirrors within each strobe Apr 11 15:25:07 they sequence the light sources. So 60hz frame rate the light pulse time is at least 180hz for some reason 720hz comes to mind but that’s probably just my mind babbling. Apr 11 15:28:58 hmm http://www.ti.com/lit/pdf/dlpa059 <-- a better description of the technology than my current sluggish mental state can provide Apr 11 15:30:19 nothing useful in there afaict Apr 11 15:30:57 (I know how DLP works in general) Apr 11 15:32:43 they do get into the frequency and timing of the DLP array but it's been since 2017 so where it was I don't remember Apr 11 15:45:48 I give up. Apr 11 15:45:51 sigh Apr 11 18:21:18 short summary. they do a lot of things in just a single video frame with the DLP it's not just the DLP that's active. The light emitters are modulated (on off) and brightness control (averaging for each frame). Apr 11 19:50:25 Sucessfully installing OpenBSD 6.6 on BeagleBoard Black ... ;) serial console and microsd, http for installation sets (the .fs comes with minimum data, the userland needs to be grabed at install time through ethernet). Very happy this works so easily. Apr 11 21:19:14 It's been a while since I've done anything significant with my BBB and I seem to be having issues getting 1-wire to work. After setting "uboot_overlay_addr0=/lib/firmware/BB-W1-P9.12-00A0.dtbo" in uEnv.txt and loading the modules with modprobe (wire and w1-gpio) I'm still not seeing any devices. Looking for any tips since I'm sure this is something that's been done a million times and I'm just missing something simple. Apr 11 21:19:38 manually modprobing a driver should never be needed anyway Apr 11 21:19:42 they get autoloaded Apr 11 21:21:04 note also that for custom overlays it's recommended to use uboot_overlay_addr4..7 (since 0..3 would override overlays for autodetected capes, if any are present) Apr 11 21:21:37 two possibilities: either the overlay doesn't get applied for some reason, or there's something wrong with the overlay Apr 11 21:21:45 are you booting from eMMC or from SD card? Apr 11 21:21:50 SD Apr 11 21:22:04 just upgraded my kernel as well... 4.19 I think Apr 11 21:22:21 Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux Apr 11 21:23:27 is there an easy way to confirm what overlays are loaded? Apr 11 21:23:59 my guess is that you have an ancient system (with an ancient bootloader) on eMMC, and flashing to eMMC or at least erasing eMMC (or at least wiping its bootloader) will fix your problem Apr 11 21:24:24 a bootloader on eMMC takes precedence over one on SD, and an old one may not understand the modern directives in /boot/uEnv.txt Apr 11 21:24:33 yeah, eMMC is pretty old I think Apr 11 21:24:46 if you just want to erase it: sudo blkdiscard /dev/mmcblk1 Apr 11 21:24:55 updated the bootloader earlier but I think that just gets the sdcard? Apr 11 21:25:04 yes Apr 11 21:25:22 ok, let me wax eMMC then Apr 11 21:25:58 rebooting Apr 11 21:26:23 and typically overlays contain a fragment that adds a DT node in /chosen/overlays (e.g. https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART1-00A0.dts#L33-L46 ) Apr 11 21:26:48 ah the overlay you mentioned is a standard one Apr 11 21:26:56 it is Apr 11 21:27:16 so yeah, if it's applied then /proc/device-tree/chosen/overlays/BB-W1-P9.12-00A2 will exist Apr 11 21:27:45 it does Apr 11 21:28:06 and boom... I'm seeing devices now Apr 11 21:28:10 :) Apr 11 21:28:13 darn that eMMC! Apr 11 21:28:16 thanks for the help :D Apr 11 21:28:36 I recommend just reflashing to eMMC anyway, unless the image you're using is too fatso to fit on eMMC Apr 11 21:28:48 I _probably_ expanded it at one point Apr 11 21:29:09 that doesn't matter, flashing to eMMC will copy the contents of the filesystem Apr 11 21:29:26 since it's blanked, nothing to lose right now I suppose Apr 11 21:29:58 true. if your image is an IoT image it should fit on eMMC anyhow (unless you have a very old beaglebone that only had 2 GB of eMMC) Apr 11 21:30:37 not sure Apr 11 21:30:47 the board is older but I'm not sure how old Apr 11 21:30:49 I think the latest IoT image released a few days ago is also smaller than the previous one Apr 11 21:31:05 since I'm still in prototype stage I'll probably just work off sd for now Apr 11 21:31:16 after everything "works" I'll want to move to eMMC anyway Apr 11 21:31:28 so I'm not going to worry about it that much at the moment Apr 11 21:31:45 not sure I see the reasoning for that, but you do you :) Apr 11 21:32:14 just being lazy ;) Apr 11 21:32:34 flashing to eMMC consists of uncommenting the last line of /boot/uEnv.txt and rebooting Apr 11 21:33:52 ok ok :D Apr 11 21:34:45 oh nice, they really managed to de-crud the bone IoT image significantly: Apr 11 21:34:46 728M bone-debian-9.9-iot-armhf-2019-08-03-4gb.img.xz Apr 11 21:34:47 571M bone-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz Apr 11 21:37:24 man, maybe it's time for a new image Apr 11 21:38:11 if you're still at an early stage and aren't yet deeply invested in whatever you've done so far, it may indeed be a good moment to start anew with the latest debian buster image Apr 11 21:38:29 yeah, I think that's fair Apr 11 22:07:39 so after uncommenting that line... do I need to pop the card out and let it boot from eMMC? Apr 11 22:08:59 with that line (cmdline=init=...something about eMMC flasher) uncommented, when you "boot" from the card it should proceed to reflash eMMC and then power itself off Apr 11 22:10:01 ok, maybe I just need to chill out and let it go. I saw the 4 leds doing a night rider type chase and now it's a sync'd blink Apr 11 22:10:11 that indicates failure Apr 11 22:10:15 heh Apr 11 22:10:28 well.. I'm writing the newer image to another card Apr 11 22:10:40 I'll just scrap this and go for the new image once it's done Apr 11 22:12:39 if you want to check whether your eMMC is 2GB or 4GB, one way is by just inspecting it visually: the 2GB one will have the micron logo and BGA marking "JW896": https://photos.app.goo.gl/iFpxtrs4pMCgmd427 Apr 11 22:13:23 I wonder if the new slimmed-down IoT image fits in 2GB again or if it's still too obese Apr 11 22:18:57 that's what I have alright Apr 11 22:19:36 I'll let you know if the new image works out once it's done Apr 11 22:20:03 ok yeah that will complicate things, especially since "2GB" means only 1832 MB in reality Apr 11 22:21:32 so I don't know if even the new IoT image will fit on that.. it may be the case that your options are to either run from sd card or flash a console image (rather than an IoT image) Apr 11 22:22:22 I wonder if I have a sancloud board somewhere still Apr 11 22:24:03 looks like another fail for sure Apr 11 22:25:03 I'll just go with the 10.3 SD IoT I think Apr 11 22:25:57 that works too. in that case I recommend just wiping eMMC again (sudo blkdiscard /dev/mmcblk1) just to be sure the failed attempt at flashing didn't leave behind a bootloader that could end up biting you in the future Apr 11 22:26:25 will do Apr 11 22:27:10 might just be time for another purchase :) Apr 11 22:27:55 I realized my other BB-enhanced is sitting half way in another project so I'm for sure out of boards that have the larger flash Apr 11 22:28:56 the BBE doesn't have larger eMMC than (current) BBBs though Apr 11 22:30:21 right... I just had two BBBs from quite a while ago, 2 BBEs from when they were announced (wanted wifi), and a pocket that's running some lighting these days Apr 11 22:31:25 depending on the use case, I usually don't mind just running from SD anyway Apr 11 23:20:54 I went to Instructables online and some person asked and I quote, "How do you make wings for human flight." Apr 11 23:21:14 "I kept flapping and nothing happened!" Apr 11 23:49:19 Hi, Is anyone working for the documentation or design of the BBB present ? Apr 11 23:51:29 I'd like to notify a mistake in the manual, User LEDs are GPIO 1 pins 21...24, the manual states GPIO 1 pin 21 + GPIO 2 pins 22...24 page 56/108. That's a mistake they all are at GPIO 1. Apr 12 00:19:23 Hello. I am not but I document like I type. Not well! Apr 12 00:20:07 Are you discussing the SRM for a Rev. C? Apr 12 00:24:19 I thought GPIOs were not any longer part of sysfs but a character device w/ the ongoing kernel efforts. I have not stayed up to par on this idea but if you search character device on google, up pops some interesting facts. Apr 12 00:26:35 ... Apr 12 00:28:19 Anyway, if this is the case and the filesystem has changed, adding the /dev/"your_character_driver" is found there instead of at the previous directory and file location. Apr 12 00:30:12 https://linux-kernel-labs.github.io/refs/heads/master/labs/device_drivers.html is an idea on this reallocation of location and it seems a bit more complicated than previously thought. GPIO is not necessarily easy any longer b/c of what some have found out. Apr 12 00:30:13 ... Apr 12 00:33:56 That article or wiki is interesting for character and block devices/drivers. Apr 12 00:35:40 It gives a short lesson and some ideas circulating on this idea. jfsimon1981: I think, from what I gather, the file system has changed in the newer kernels. Now, w/ 4.19.x, it was a good idea to switch while I think, guessing here, kernel 5.4.x incorporates it. Apr 12 00:39:28 for instance on your BBB, type ls -la /dev/mmcblk0p1 /dev/ttyS? Apr 12 00:40:14 You can see that b and c are described in the front of your permissions section or first column. Apr 12 00:42:10 Also... Apr 12 00:42:29 Here: https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/devices.txt. You can find the different ideas of c and b drivers. Apr 12 00:50:53 So, I am not sure if Beagleboard.org persons incorporated the gpiochip* idea w/ kernel 4.19.x yet but I see them located at /dev/. Apr 12 00:52:54 jfsimon1981: Does that sort of anwswer things? i may have gotten off subject. Correct me if I am off base. Apr 12 01:05:32 I just went to source/include/linux/fs.h and am blown out of proportion but it is worth it! Apr 12 01:17:32 Where are the kernel headers located for Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux? Apr 12 02:41:33 Forget my question. Apr 12 02:45:37 sudo apt install linux-headers-4.19.94-ti-r42 is the answer for the current kernel I have on my BBB. Apr 12 02:46:12 Look here: https://forum.digikey.com/t/beaglebone-hello-and-kernel-headers/6168. There was a person that answered. **** ENDING LOGGING AT Sun Apr 12 03:00:14 2020