**** BEGIN LOGGING AT Fri Mar 05 02:59:57 2021 Mar 05 03:43:49 again? Mar 05 03:45:36 Bingo! Mar 05 03:56:03 Not bingo. Mar 05 04:01:25 GenTooMan: Do you have a minute or three thousand of them? Mar 05 04:01:58 OF: graph: no port node found in /ocp/lcdc@4830e000 is my issue when running linuxcnc/emcapplication. I am not sure what it means... Mar 05 04:03:53 I found a write-up, https://cospandesign.github.io/linux,am335x/2018/10/16/am335x-lcd-panel.html, that seems promising. Mar 05 04:04:08 But, this is a BBG and not a hand-made board. Mar 05 10:15:21 hi Mar 05 10:16:03 https://www.mouser.in/ProductDetail/BeagleBoard/BBONE-AI?qs=%252B6g0mu59x7 Mar 05 10:16:04 IfEw1Zb81%252B%252BQ== Mar 05 10:16:04 Please confirm if you have complete kit of all the 3 items ( ITEM1- above Mar 05 10:16:05 shared link board, ITEM 2- its compatible LCD of 7 inch size- resistive Mar 05 10:16:05 touch & ITEM 3- its respective camera cape) Mar 05 10:16:57 https://www.mouser.in/ProductDetail/BeagleBoard/BBONE-AI?qs=%252B6g0mu59x7IfEw1Zb81%252B%252BQ== Mar 05 10:21:39 Venu: I don't think a camera cape for the beaglebone AI exists yet, let alone one + a non-conflicting lcd cape, let alone a kit thereof Mar 05 10:23:04 I'm not even sure a camera cape for the AI is possible (i.e. if a video input interface is pinned out on its expansion headers) Mar 05 10:25:19 there isn't Mar 05 10:26:41 sdio would be the only option, which has rather limited bandwidth Mar 05 10:27:04 usually people use usb for a camera, not a cape Mar 05 10:29:49 ok Mar 05 10:30:45 Good day, Mar 05 10:30:46 I bought a BeagleBone Black this week to test it. Mar 05 10:30:46 So far everything is working fine. I followed the Getting Started guide and successfully installed the latest Debian OS on the BeagleBone. Mar 05 10:30:47 But now to my problem I am trying to run a Linux Node server, but when copying the project and installing packages to the EMMC flash, the memory is apparently not enough. Mar 05 10:30:47 Did I do something wrong or is the free memory on the EMMC really that low? Mar 05 10:30:48 I would hate to use an SD card. Maybe there are a few hundred MB left somewhere. Mar 05 10:30:48 Thanks for your help in advance. Mar 05 10:31:16 cocrea: the IoT image includes a lot of stuff, including nodejs and nginx Mar 05 10:31:52 if you want a barebones system to start from scratch and only install what you want/need, start with a console image: https://elinux.org/Beagleboard:Latest-images-testing#Debian_10_.28Buster.29_Console Mar 05 10:32:31 the eMMC is 4GB, which is plenty of space for most uses Mar 05 10:34:07 you could also try to remove unnecessary packages, but my experience is that determining which packages are superfluous and removing them takes more time and effort than starting with a clean image and only installing what you need Mar 05 10:36:27 Thanks alot, i will try that out:) Mar 05 10:36:35 (even the console image has some unnecessary packages you can remove, e.g. because it's also for the wireless beaglebone variants it includes wifi/bluetooth-related packages and firmware/modules for various wifi chips) Mar 05 10:57:10 cocrea: to free up 143 MB of wireless-related stuff from the 2020-08-25 debian buster console image: sudo apt-get purge firmware-iwlwifi rtl8723bu-modules-4.19.94-ti-r50 firmware-brcm80211 firmware-atheros firmware-libertas firmware-ti-connectivity bluez rtl8821cu-modules-4.19.94-ti-r50 wpasupplicant firmware-realtek bb-bbai-firmware iw crda wireless-tools bb-wl18xx-firmware bluetooth firmware-zd1211 ... Mar 05 10:57:16 ...libiw30 wireless-regdb Mar 05 11:01:07 zmatt okay i will try that out:) Mar 05 11:01:26 looks like firmware-misc-nonfree can also go on that list, unless it happens to include firmware for some obscure usb device you want to use... based on a quick scan of the devices listed (apt-cache show firmware-misc-nonfree) it mostly seems wifi and adsl/cable modems Mar 05 11:01:52 which is another 14.9 MB Mar 05 11:02:40 with those removed the console image has 368 MB of space in use, leaving most of the eMMC free for your own use Mar 05 11:03:03 zmatt on the console image there will be almost 3gb from the beginning ? Mar 05 11:03:18 of free space? Mar 05 11:03:24 yes ? Mar 05 11:03:58 something like that yeah Mar 05 11:04:36 do you know by any chance what the free space of the iot image is ? by default ? Mar 05 11:04:52 "4 GB" of eMMC is more like 3.5 GB in reality Mar 05 11:07:27 the bone-debian-10.3-iot-armhf-2020-04-06 image has 1.9G in use, so that should still leave more than 1 GB of free space after flashing to eMMC Mar 05 11:07:34 so not sure how you managed to fill that up so fast Mar 05 11:09:07 I have that image installed on a beaglebone here (albeit on sd card because it has 2GB eMMC) and I've also installed a bunch of stuff onto it myself, and it has 2.3G in use Mar 05 11:25:31 Hello, I have a question regarding CAN setting on pocket beagle. I use an ATA6563 PHY (on mikroelectronika board) attached. If I execute the following commands https://pastebin.com/ZK6yRQFC, nothing is sent or received. Any idea why? Mar 05 11:26:44 the pin setting was confirmed OK, Current mode for P1_30 is:     can  AND Current mode for P1_32 is:     can Mar 05 11:27:11 is this the only thing to switch the pins to the can function? Mar 05 11:55:50 hm Mar 05 11:57:12 I don't know much about can, but I'd presume "listen-only on" would explain why you can't send Mar 05 11:57:50 good point, i will verify with the logic analyzer again Mar 05 11:58:36 I presume once transmission will be working, the reception will as well Mar 05 12:00:09 and of course check you're not accidently keeping the phy in standby Mar 05 12:00:48 thanks, i just confirmed that is on the mikroelektronika board set by default to stay on Mar 05 12:00:56 (if there's any doubt about the hardware part you could verify it in gpio mode first) Mar 05 12:02:56 ah never mind that would trigger a safety mode in the phy Mar 05 12:03:23 well, you'd still see a pulse at least Mar 05 12:17:52 i just rebooted, set up the pins an interface again, put a logic analyzer on RX/TX (before the PHY), but cansend doesn't do anything Mar 05 12:18:20 not sure then... I've used can only once many years ago Mar 05 12:18:42 i still suspect the pins need something more to setup Mar 05 12:19:06 or is it really that simple to switch the gpio functionality with the config-pin command? Mar 05 12:19:18 yes it really is Mar 05 12:19:43 hmm, it seems I never made a pocketbeagle version of my show-pins script Mar 05 12:20:51 ok, what confused me is that i found earlier tries of other people doing something with the device tree (which is something I have never done before) Mar 05 12:21:31 yeah that's usually not needed, though you can still use an overlay if desired Mar 05 12:21:31 so I am greateful for an easy way Mar 05 12:22:10 maybe the can peripheral gets confused because it sees continuous dominant state prior to the pins being muxed correctly, though I don't think it should matter while the link is still down Mar 05 12:23:18 try using P1.26 (tx) + P1.28 (rx) instead Mar 05 12:23:29 ok Mar 05 12:23:30 since P1.30/32 is normally used for the serial console Mar 05 12:23:50 I know, I used this because it fits the mikroelektronika click board perfectly Mar 05 12:24:22 yeah but it means you have a drive conflict between uart 0 txd and can rx Mar 05 12:24:22 and I couldn't solder headers to the pocketbeagle, because there is not enough space between the SiP and the pin headers Mar 05 12:24:26 which could damage the pin Mar 05 12:24:38 so I soldered the board directly to the pocketbeagle Mar 05 12:24:48 (if connected to the phy while the pins are still muxed to console) Mar 05 12:24:52 ew Mar 05 12:24:56 oh Mar 05 12:25:11 ok, I hope I haven't damaged the HW Mar 05 12:26:36 (I never solder things before I try the device, then I do this once and... bad luck happens :( ) Mar 05 12:30:29 and agreed the headers do seem a bit close to the SoC.. I'm sure my colleague who does electronics stuff here wouldn't have a problem with it, but I'd be nervous :P Mar 05 12:32:06 not sure why they didn't just make the pcb a bit bigger... being able to fit in some tin can seems like it doesn't have much if any real-world benefit Mar 05 12:34:43 it would be ok if the header were sanded off a bit Mar 05 12:34:49 good news Mar 05 12:35:04 what do you mean? the SoC-side is where you solder, the header goes on the other side where the labels are Mar 05 12:35:05 pins 26 and 28 do something on the analyzer Mar 05 12:35:31 oh, I wanted to solder them from the SoC side Mar 05 12:35:41 because of the mikroelektronika board (it would be mirrored Mar 05 12:35:44 )because of the mikroelektronika board (it would be mirrored Mar 05 12:36:34 this means I need to desolder the headers now and connect the PHY to 26 and 28 Mar 05 12:36:51 but better than nothing Mar 05 12:37:38 soldering headers on the wrong side sounds like a bad idea, you wouldn't be (easily) be able to use the labels, it would be incompatible with any pocketbeagle cape out there, and like you observed there isn't really enough space Mar 05 12:37:45 hey, i think the tin can arbitrary case idea was wonderfull, sticks with the branding and easy to source... also easy to short out pins if you don't insulate those walls Mar 05 12:38:00 :P Mar 05 12:38:27 I know, I just wanted to do something quickly that would help me in work Mar 05 12:38:42 I'm actually working on a usb3.0+ice40 multitool that took direct inspiration from the mini tin idea. Mar 05 12:38:44 but the mikroelektronika board layout is just semicompatible Mar 05 12:38:55 I can understand the temptation when something happens to fit in some particular way without needing wires Mar 05 12:39:12 anyway, thank you, I will resolder it and use wires now Mar 05 12:39:35 and report back if my setup worked to say thanks thousand times more Mar 05 12:42:20 Going by the jist of the conversation I dropped in on, are you looking to flip a mikroelectronica board upside down? if so, what about plugging only one of the pin rows in to their correct position, and using male-female jumpers for the other row? Mar 05 12:43:36 that would be an option, too Mar 05 12:43:51 or just desolder the headers completely and use 5 wires Mar 05 12:44:16 I have to go now to return a borrowed car, but I will think about it on the road Mar 05 12:44:26 good luck Mar 05 12:44:34 haha, be careful of the smoking charge! Mar 05 12:44:38 thank you both, it has been a pleasure Mar 05 12:44:57 oh, I can now mirror the mikroelektronika board Mar 05 12:45:08 the two can pins are now 2 pins shifted Mar 05 12:45:13 can> can't Mar 05 12:45:26 so the wires will win :) Mar 05 12:59:07 woot, time for some more excel, this time to make a backlight curve! Mar 05 13:11:33 anyone know about musb dma Mar 05 13:11:43 I trying to find the option in the kernel to enable it. Mar 05 13:12:05 or maybe i can see if it is enabled or not Mar 05 13:13:58 I think i found it though Mar 05 13:14:42 it's disabled in rcn's kernel... something CONFIG_MUSB_PIO_ONLY or something like that Mar 05 13:35:46 there's a special level in hell for the creators of musb Mar 05 13:39:13 lol Mar 05 13:40:52 mru: why Mar 05 13:41:03 because they made musb Mar 05 13:41:34 any way for me to see if it is enabled? normaly on a beaglebone i can find it in /boot/config-'kernel version' Mar 05 13:41:42 but on this board i do not have that option :) Mar 05 13:41:50 mru: why Mar 05 13:42:10 because it's such a nightmare to make it "work" Mar 05 13:42:26 zcat your config file in /proc/config? Mar 05 13:42:34 not sure how much of it is musb's fault and how much is just a crappy driver Mar 05 13:42:59 some of it could be the soc integrators' fault Mar 05 13:43:04 Konsgn: i have that! :) Mar 05 13:43:06 also possible yes Mar 05 13:43:12 zcat /proc/config.gz | grep MUSB Mar 05 13:43:21 dma issues in particular could be Mar 05 13:43:25 zgrep MUSB /proc/config.gz Mar 05 13:43:36 oooooh Mar 05 13:43:59 nice Mar 05 13:44:04 I don't think those can be blamed on the driver Mar 05 13:44:09 I think I made a oopsie Mar 05 13:44:15 big oopsie xD Mar 05 13:44:42 "sudo rm -rf /" big? Mar 05 13:45:03 uh no not that Mar 05 13:45:17 mru: dunno, usb dma has 1 erratum as far as I can tell and that only applies to am335x 1.0, it was fixed in 2.x Mar 05 13:45:23 I enabled DMA option on production devices and the could very well explain why it's not stable Mar 05 13:45:29 Konsgn: I heard of someone once doing that on a machine with lots of nfs mounts Mar 05 13:45:48 zmatt: that is very interesting Mar 05 13:46:12 zmatt: there was some version of some chip where dma would only work in one direction Mar 05 13:46:18 haha, wait... woa, that propogates to fs mounting into sub-directories? Mar 05 13:46:30 mru: but again, is that the hardware's fault or the driver's? Mar 05 13:46:41 I'm pretty sure it was hardware Mar 05 13:46:45 the driver isn't _that_ bad Mar 05 13:47:13 I honestly have no idea, I'd need to work with the hardware myself to determine that Mar 05 13:47:20 zmatt: where can i find that errata ? Mar 05 13:47:34 that might have been on omap3 Mar 05 13:48:07 Duality: TI links to the errata prominently at the top of the product page: https://www.ti.com/product/AM3358 Mar 05 13:48:12 (for which they get my respect) Mar 05 13:49:47 is there a way to see what silicon version i have ? maybe a register somewhere with a tracking number? Mar 05 13:49:59 those aren't bugs, they're features! Mar 05 13:51:00 mru: musb on omap3 used mentor's own dma controller, not TI's Mar 05 13:52:23 Duality: it's marked on the SoC and can also be fished out of a register Mar 05 13:52:45 yes, and it was broken Mar 05 13:53:07 someone came up with a workaround using the sdma for one direction Mar 05 13:53:38 Duality: e.g. AM3358ZCZ = 1.0, AM3358AZCZ = 2.0, AM3358BZCZ = 2.1 Mar 05 13:53:53 mru: okay so it wasn't the integrator's fault :P Mar 05 13:54:05 oh i see Mar 05 13:54:32 the whole musb block could have been poorly integrated in the rest of the chip Mar 05 13:54:52 Duality: the register is at 0x44e10600 Mar 05 13:55:41 the top 4 bits thereof specifically; 0 = 1.0, 1 = 2.0, 2 = 2.1 Mar 05 14:00:13 Duality: note however that rcn's kernels disable musb dma due to stability issues even on the BBB, which uses am335x 2.1 Mar 05 14:00:27 so those issues may not be related to this specific erratum Mar 05 14:00:47 *are not Mar 05 14:06:02 oh oke Mar 05 14:14:11 ahh man, history -a works great when you're testing dts settings for a driver. no need to wait for history to save your frequently used commands. Mar 05 14:29:35 one more question: is there a ready made BBB or pocketbeagle image without nodered, cloud9, nodejs optimized for a fast boot time? Mar 05 14:29:50 my current time according to systemd is 45 - 65 seconds Mar 05 14:30:24 if you want a pretty basic system to start with try a console image: https://elinux.org/Beagleboard:Latest-images-testing#Debian_10_.28Buster.29_Console Mar 05 14:30:33 I have read about the impact of the USB drivers, but I need at least the network interface to connect via ssh Mar 05 14:30:57 well the usb networking itself isn't that slow, the script that sets it up is :P Mar 05 14:31:21 thank you, I completely missed these images on beagleboard.org Mar 05 14:31:21 you can just replace it with g_ether in /etc/modules and a network manager that doesn't suck (I use systemd-networkd) Mar 05 14:31:40 yeah the official latest-images page doesn't have console images, dunno why Mar 05 14:32:18 getting a bbb to boot fast is definitely possible if you put in the effort: https://liktaanjeneus.nl/boot.svg Mar 05 14:33:51 oh, wow Mar 05 14:34:23 I will see where I get with the console image Mar 05 14:36:30 5 seconds you show look like magic :) Mar 05 14:37:23 this excludes bootloader time, but I streamlined that too Mar 05 14:37:31 (to less than a second I think) Mar 05 16:52:31 Can any one tell me if Beagleboard 102110420 which has debian Stretch be reloaded with Debian Jessie? Mar 05 17:54:30 yikes Mar 05 17:54:45 and what even is that number Mar 05 18:25:17 it was clearyl compiled in the year 1021 on 20th of the 104th month Mar 05 18:26:04 ohh wait, someone was stoned, the compiled on the 420th of november Mar 05 18:26:17 bah, october Mar 05 19:56:27 Did anyone read my ramblings? Mar 05 19:57:00 ... Mar 05 19:57:26 From yesterday...I was discussing the LCD Cape, machinekit-hal/emcapplication, and the BBG. Mar 05 19:58:04 Anyway, do you think the issue w/ my Cape config. is not the Cape config. b/c of it showing the display? Mar 05 19:58:37 Forget it. It is the emcapplication and machinekit-hal. I need to build it better this time. Mar 05 19:58:44 Sorry. **** ENDING LOGGING AT Sat Mar 06 02:59:57 2021