**** BEGIN LOGGING AT Sat Jan 16 03:00:36 2021 Jan 16 03:01:59 I remember once I had to clear the cache and ram memory. My board was already swamped w/ data and I was compiling. Oops. Jan 16 03:06:23 Did you get the armhf one w/ the Debian distro? Jan 16 03:06:35 yes Jan 16 03:06:46 Okay. Jan 16 03:08:16 Did you try to clear/clean out the cache, dentries, and inodes? Jan 16 03:08:30 not yet Jan 16 03:08:37 Okay. AI, right? Jan 16 03:08:39 i worry about messing with inodes Jan 16 03:08:40 yes Jan 16 03:08:44 I will try to real quickly. Jan 16 03:09:10 Just wait until I do it. If you want me to test specific entries once I clear it out, let me know. Jan 16 03:09:54 mattb000ne: can you share text of error Jan 16 03:10:23 sure I will post in a second need to hook it up and reproduce Jan 16 03:11:28 acutally I have it saved Jan 16 03:11:29 Failed to read cache file '/root/genicam_xml_cache/ Jan 16 03:12:21 so I was getting that message after I rebooted Jan 16 03:12:33 the very first time i tried to snap a pic I got this Jan 16 03:12:33 Image acquisition on "Basler acA4024-29um (23437639)" failed! Error: "UX Status: Libusb error: **UNKNOWN**." Jan 16 03:12:50 my brief googling said this was an out of memory thing Jan 16 03:13:16 this is the full cache error Failed to read cache file '/root/genicam_xml_cache/0x04a65e8200000000.bin' Jan 16 03:13:33 i was going to try and manually delete Jan 16 03:13:44 but when I try to do cd /root i get a permission error Jan 16 03:13:54 whoami Jan 16 03:14:04 do that say root Jan 16 03:14:33 no because I am debian Jan 16 03:14:38 lol Jan 16 03:14:41 i always use debian Jan 16 03:15:47 maybe need to reinstall the pylon without using sudo Jan 16 03:16:10 chmod? Jan 16 03:16:39 or need to run your script or program as sudo Jan 16 03:16:40 i could try that Jan 16 03:16:49 i do run pylon as sudo Jan 16 03:16:57 since i need sudo privalages for xinit Jan 16 03:17:13 sudo -s Jan 16 03:17:20 cd /root Jan 16 03:17:22 ls Jan 16 03:17:30 i could try that Jan 16 03:19:11 i just read this excerpt from middle link here, is all i know . https://docplayer.net/search/?q=genicam_xml_cache Jan 16 03:19:53 so if installed without sudo it would be in debian home directory Jan 16 03:19:57 i think Jan 16 03:20:03 instead of /root Jan 16 03:20:50 good point Jan 16 03:20:50 I have one last idea... Jan 16 03:21:00 su - root Jan 16 03:21:05 Then, type password. Jan 16 03:21:12 Then, run your command. Jan 16 03:21:30 then i am root full time Jan 16 03:21:35 i mean I can try Jan 16 03:21:36 brb Jan 16 03:21:41 You can just type exit. Jan 16 03:23:30 I mean, if you choose to not be root any longer, just type the command exit and then press enter. Jan 16 03:24:07 That will bring you back to the user debian or whatever. Jan 16 03:26:07 Anyway, renrelkha has a point. If you do not need to install pylon w/ root and it is already compiled, nice. You might not need to use sudo. Jan 16 03:26:47 What happened? Jan 16 03:31:59 what Jan 16 03:37:25 mattB00000ne: Did you try your command after being in root? Jan 16 03:38:02 It could hold your system senseless but you are the commander of your board. Jan 16 03:40:15 Command it! Jan 16 03:41:21 Also, I think the SDK might have to have an example for you to try or you need to type up your own source. Jan 16 03:49:31 Oh well...another time maybe? Jan 16 04:03:16 what are you guys doing Jan 16 04:12:02 I am trying to not get in trouble for chatting past 10:00. Rules and Regulations! Jan 16 04:12:25 MattB0ne: Good luck until tomorrow! Jan 16 04:12:48 thanks Jan 16 04:12:54 Yep. Jan 16 04:22:32 dang it, the BeagleV has registration tasks to perform. I am going to apply! Jan 16 04:23:06 lights, camera, action! Jan 16 04:37:23 mattb00ne: just noticed the chat window and was going to say there is a /root directory under the root file system that is the home user of the root user Jan 16 04:37:47 oh ok Jan 16 04:37:57 maybe I just need to delete that Jan 16 04:38:06 sudo -s should let you change into root on a system that doesn't have a root password Jan 16 04:38:26 that should change to root user and then you can enter the /root directory Jan 16 04:39:07 just type exit in the terminal window when your done and it should put back to your normal user Jan 16 04:40:07 normally under the LFS the /root directory is set as 700 so you need to be root to get into it Jan 16 04:40:52 so maybe whatever your looking for is in there Jan 16 04:42:07 buzz you kernel building still Jan 16 04:42:46 ubuntu cause it don't set the root password by default usually needs to use the sudo -s command as the normal su don't seem to work unless you go about putting a password on the root account Jan 16 04:42:53 yep Jan 16 04:43:29 today mostly still playing with the image-building git project Jan 16 04:44:35 now that i am getting a better understanding of it i can start altering it to do what i want to as far as building the rootfile system Jan 16 04:45:55 then i plan on getting back to more of the actual kernel stuff and trying to fix a few things Jan 16 04:46:43 so have you build guitars by hand? Jan 16 04:46:48 ive been looking at the differences between ti's kernels and rcn's Jan 16 04:47:30 well... i was a pro player for many years and have done a lot of work but never really built a complete one from scratch Jan 16 04:47:54 done alot of repairs and mods for others as well Jan 16 04:47:59 fretjobs Jan 16 04:48:18 cool Jan 16 04:48:23 what type of music did you play Jan 16 04:48:27 alot of floyd rose installs and scaloped neckts Jan 16 04:48:35 hard rock Jan 16 04:48:39 cool Jan 16 04:48:43 i tried guitar Jan 16 04:48:49 do not have the fingers for it Jan 16 04:49:15 i grew up on things like sabbath/deep purple and that era Jan 16 04:49:37 but played alot of van halen satriani type of stuff Jan 16 04:49:43 steve vai Jan 16 04:50:04 i was really into the 2 handed tapping stuff Jan 16 04:50:25 i played drums as well Jan 16 04:51:00 when i quit playing i built and owned a 24 track studio for a few years as well Jan 16 04:51:25 woah Jan 16 04:51:34 actually i still do some repair work for studio's on the old analog studer machines and neve consoles Jan 16 04:52:05 all this electronics and computer crap came from me and music Jan 16 04:52:25 i needed to repair all my marshalls in the old days Jan 16 04:52:39 no one around here for at least 100 miles Jan 16 04:52:53 that got me into electronics Jan 16 04:53:32 my nickname comes from those days and the deafening hum from the marshall stacks Jan 16 04:53:36 hahaha Jan 16 04:54:52 when i quite playing on the road a couple of us started up a production company and i was designing custom light systems and consoles which lead into the early computer stuff Jan 16 04:55:40 that was the early days of the apples and then the atari's which were kinda apple clones Jan 16 04:56:22 the studio had one of the 1st midi rigs here in Ontario at the time Jan 16 04:56:22 that is really cool must of had a lot fun Jan 16 04:56:40 ya it had its moments thats for sure Jan 16 04:58:21 back then it was so expensive nowadays to replicate what we had is peanuts Jan 16 04:59:04 finally i gave it up as i just lost interest in music as i wasn't out on the road anymore Jan 16 04:59:36 it became more of a job and watching others do while i sat and engineered just wasnt my thing Jan 16 04:59:59 and by that time computers and bbs were starting to appear Jan 16 05:02:04 is config-pin broken? Jan 16 05:04:44 running my program not under sudo helped Jan 16 05:04:46 sorry im not sure but im sure zmatt will help if he's here Jan 16 05:05:05 is the pin in use Jan 16 05:05:10 yeah that is a good zmatt question Jan 16 05:05:19 ya generally its a good idea to not run things as root Jan 16 05:05:52 i used to do that all the time and its not good Jan 16 05:06:05 not unless you want to get really good at fixing systems Jan 16 05:06:07 lol Jan 16 05:06:17 I'm logged in as the default debian user, but for some reason trying to use any command other then "config-pin -l p9.12" on pin P9_12 and it gives me this error: Jan 16 05:06:20 ERROR: open() for /sys/devices/platform/ocp/ocp:P9_12_pinmux/state failed, No such file or directory Jan 16 05:07:09 does the file exist? Jan 16 05:07:30 oh i have seen this before Jan 16 05:07:36 this is a simple fix Jan 16 05:07:41 but i do not know what it is Jan 16 05:07:46 do you have overlays Jan 16 05:08:28 nope, P9_12_pinmux doesn't exist for some reason. it skips over from 11 to 13 Jan 16 05:08:42 overlays? Jan 16 05:08:56 ive not played much with the pins but do know that sometimes not all the pin files are there and if not the xport command in the gpio directory will create it if you call it Jan 16 05:09:31 where is the gpio directory? Jan 16 05:09:53 hang on a sec im booting up a bbb and see if i can find what i was taling about Jan 16 05:10:06 i know its part of the sys file system Jan 16 05:10:18 i think its in the kernel gpio area Jan 16 05:10:25 give me a sec Jan 16 05:12:31 what i am talking about is under the /sys/class/gpio directory Jan 16 05:13:10 Hmm. Which folder would I use the command in? Is it gpio12? Jan 16 05:13:18 Also, what does the xport command look like? Jan 16 05:13:46 i am not sure if thats what you need but do remember the other day while reading a tutorial on pin control that had said something about if the pin's not present in the directory you can use the export command with the pin you need and it will create all the missing peices Jan 16 05:15:55 is it export p9.12 Jan 16 05:16:06 hm i am trying to remember where i see that ... Jan 16 05:16:32 yes i am just not sure if thats the exact format but it was something along them lines Jan 16 05:17:17 part of the nameing thing is what i am not sure of tho Jan 16 05:17:58 i think the way the kernel see's the pins is different then just using the actual pin# Jan 16 05:18:26 I did export p9 and nothing happened Jan 16 05:18:39 guess I'm just stuck without a p9.12 for now Jan 16 05:18:56 not sure why some pin files are missing Jan 16 05:20:51 i think when the system firmware is created theres only some known ones created and your kinda left to create the ones you need after that Jan 16 05:24:32 sorry i am just lookin around here trying to see where i seen that Jan 16 05:25:24 buzzmarshall: you should never need to export manually on current systems Jan 16 05:26:41 Zalymo: normally pin files missing are due to an overlay (either manually configured or auto-loaded for a detected cape) that uses those pins Jan 16 05:26:56 *pinmux config dirs I mean Jan 16 05:26:57 k... ya i am just recalling something i watched in a tutorial that talked about how to map the actual pin to the designators the kernel used Jan 16 05:27:18 (and pinmux and gpio are very different things anyhow) Jan 16 05:27:38 so if a pinmux is missing then it's probably reserved for a cape? Jan 16 05:28:01 Zalymo: try using my show-pins utility: https://github.com/mvduin/bbb-pin-utils/#show-pins it may yield insight into what is using the pin Jan 16 05:30:53 HA! Jan 16 05:30:57 i was close Jan 16 05:31:24 thanks I just installed it, Ima look over the output Jan 16 05:32:44 it should be noted that P9.12 has no useful functionality other than gpio, so there's not really much to pinmux in the first place.. the only thing you could change is the internal pull Jan 16 05:33:50 (but that doesn't explain why its pinmux dir doesn't exist) Jan 16 05:33:53 P9.12                             30 fast     up  7 gpio 1.28 hi >>  P9_12 (pinmux_wl18xx_pins) Jan 16 05:34:03 you're using a BBGW ? Jan 16 05:34:16 hey zmatt how can you overflow a usb Jan 16 05:34:24 yes Jan 16 05:34:24 Mattb000ne: ?? Jan 16 05:34:36 I am getting the following error Jan 16 05:34:39 "UX Status: Libusb error: **UNKNOWN**." Jan 16 05:34:53 my brief googling says i am overloading the usb Jan 16 05:35:06 this is bbai by the way. I got the other hub Jan 16 05:35:08 and it works Jan 16 05:35:20 or at least it recognizes the camera Jan 16 05:35:23 Zalymo: the BBGW sucks, it (unnecessarily) sacrifices a whole bunch of expansion header pins for the wifi/bluetooth chip Jan 16 05:35:28 though I can only snap one pic Jan 16 05:35:44 after that i get this usb error and eventually the beagle will power cycle Jan 16 05:35:59 Mattb000ne: sounds odd, but no idea Jan 16 05:36:03 ok Jan 16 05:36:09 yeah, I guess that explains why p9.12 isn't showing up.. it's being used for the wifi chip Jan 16 05:36:22 did you get it for free Jan 16 05:36:32 why would you buy that thing Jan 16 05:36:34 no I bought it :X Jan 16 05:36:36 on purpose Jan 16 05:36:37 lol Jan 16 05:36:42 dun dun dunnnnnn Jan 16 05:36:52 it really sucks that seeed doesn't warn about this Jan 16 05:37:18 (and that they designed it like this in the first place) Jan 16 05:37:25 the BBBW doesn't have the same problem Jan 16 05:38:55 at this point I'm just using it to learn, rather than for anything serious, so as long as I can use it for that then I'd say I got my money's worth Jan 16 05:39:20 comparison of pin usage by the BBB, BBBW, and BBGW: https://pastebin.com/Fi8Vh0n5 Jan 16 05:43:37 cool... i was hoping you'd spot us and come to the rescue Jan 16 05:44:02 i'll keep that all in mind when it get to capes and pins Jan 16 05:44:52 wtf now I'm trying p9.13 and it's saying no such file or directory but the directory literally exists Jan 16 05:45:17 is it saying no such file or directory, or no such device? Jan 16 05:46:01 since ENODEV (No such device) indicates the requested pinmux state doesn't exist Jan 16 05:47:03 of, it's saying no such device Jan 16 05:47:38 is there anyway to fix that? Jan 16 05:47:49 don't request a non-existent pinmux mode? Jan 16 05:49:15 how would I set the pin high? Jan 16 05:49:25 I'm looking at the modes but they're not clear Jan 16 05:49:35 that's not a pinmux mode, that's controlled via gpio Jan 16 05:49:42 i.e. you'd leave pinmux at default for that Jan 16 05:50:23 (don't select "gpio", it means "gpio with internal pull-up/down disabled", which should normally be avoided. I personally kinda hate that they named the mode like that) Jan 16 05:51:13 how would I control it via gpio? Molloy's book seems to be a tad bit outdated on this subject, since in his book config-pin is used to set the pin hi or low, along with some other config-pin commands that no longer exist Jan 16 05:52:39 yeah I somewhat recently learned the old config-pin also has gpio control shoehorned in... seems weird, not surprised it's not there anymore Jan 16 05:52:48 *had Jan 16 05:53:06 since pinmux config and gpio really have nothing to do with each other Jan 16 05:53:43 (and I don't think config-pin has an easy way to look up which gpio corresponded to a particular pin, so it probably contained a device-specific hardcoded lookup table) Jan 16 05:55:33 typically people control gpios from software via a library.. I don't know if there's any script/tool to control them from a shell script, I think people often just directly write the sysfs files in that case Jan 16 05:56:53 e.g. "echo high >/sys/class/gpio/gpio31/direction" configures gpio 0.31 (which is P9.13) to output-high Jan 16 05:57:18 is pinmux used to change the function of the pin, i.e. from gpio to uart? Jan 16 05:58:07 I personally use an udev rule to create symlinks for gpios so I can find them by name, e.g. I'd have /dev/gpio/P9_13 as symlink to /sys/class/gpio/gpio31 Jan 16 05:58:53 pinmux switches a pin between different peripheral functions on the chip, one of which is gpio Jan 16 05:59:21 each processor pin has up to 8 functions (including gpio) Jan 16 06:00:00 (and a few expansion header pins of the BBB connect to two processor pins, further extending the functions available on that pin) Jan 16 06:00:45 for an overview, see the P9 and P8 tabs of my pins spreadsheet: https://goo.gl/Jkcg0w#gid=1775283126 Jan 16 06:01:16 (not all of these modes are available via config-pin, since some of them require DT configuration to be used anyway) Jan 16 06:03:39 how were you able to map the pins to their gpio numbers? Jan 16 06:04:50 uhh you mean as listed in my spreadsheet? same as all the other information: from the SoC documentation Jan 16 06:06:36 and to map it to linux gpio number you just do bank*32+index (e.g. gpio 1.16 becomes 1*32+16=48, i.e. /sys/class/gpio/gpio48) ... this is technically not guaranteed (the kernel just sequentially assigns gpio numbers as it detects gpio controllers) but still true in practice for platform gpio controllers Jan 16 06:07:02 or, like I said, use an udev rule to create symlinks for you by name so you don't have to know or care about gpio numbers Jan 16 06:07:47 yeah I'll probably do that Jan 16 06:07:49 (this uses the names declared for the gpios in DT by the universal overlay) Jan 16 06:08:22 maybe current images already include such a rule? not sure Jan 16 06:08:26 check if /dev/gpio/ exists Jan 16 06:08:59 nah looks like I added that rule to my system myself Jan 16 06:10:04 https://pastebin.com/MMC6u7pR save that as a .rules file in /etc/udev/rules.d/ Jan 16 06:10:25 rebuild your initramfs with "sudo update-initramfs -u" and reboot Jan 16 06:10:41 then /dev/gpio/ should exist with symlink per gpio Jan 16 06:15:47 huh, why the fuck does the universal overlay of the BBB export a gpio that's not even accessible via the expansion headers ("A15", normally used as 24 MHz clock output for the HDMI framer, also connects to the emu2 pin of the JTAG header) Jan 16 06:30:28 awesome, I installed the symlink rules, but I get "permission denied" every time I attempt to modify the "direction" file unless I set give it read/write permissions. Is there a command that can be used to make all of the pin directories writable, or would I have to create a bash script for that? Jan 16 06:30:58 uhh you should have permission to write to it by default Jan 16 06:32:04 normally gpio sysfs files are group-writable and are in group "gpio", of which the default "debian" user is a member Jan 16 06:32:34 are you using the latest image? Jan 16 06:33:35 the default "debian" user is supposed to have access to pretty much anything Jan 16 06:34:19 yeah, I'm using the 10.3 image from april 2020 Jan 16 06:34:53 but if I try to do "echo "high" > direction" then it says permission denied Jan 16 06:35:59 that is really strange, I have a beaglebone running the latest image and the permissions look fine to me: https://pastebin.com/raw/XnK8s9XV Jan 16 06:37:55 those permissions are set by /etc/udev/rules.d/80-gpio-noroot.rules Jan 16 06:39:05 This seems to be the permission for all of my direction files: -rwxrwx--- 1 root gpio 4096 Jan 15 22:22 direction Jan 16 06:39:14 so for some reason only root has access Jan 16 06:39:20 by default Jan 16 06:39:27 no that's asying root and group "gpio" have access Jan 16 06:39:31 but also those permissions are garbage Jan 16 06:39:32 yes Jan 16 06:39:40 since the "x" makes no sense Jan 16 06:39:40 wtf Jan 16 06:39:51 I think x stands for "execute" or something like that Jan 16 06:39:53 user debian should be in group "gpio" Jan 16 06:39:59 yes it does, which it why this makes no sense Jan 16 06:40:48 dang there goes the chat history Jan 16 06:41:28 I completely forgot how to check groups Jan 16 06:41:59 did the april image still ship with a garbage udev rule for gpio? I thought it was fixed by then. if your bbb has internet access (i.e. plugged in via ethernet) you can try sudo apt-get update && sudo apt-get install bb-customizations to update the udev rules Jan 16 06:42:03 id Jan 16 06:43:12 the "debian" account is _definitely_ in group "gpio" on the april image Jan 16 06:43:36 how would I check that? Jan 16 06:43:42 id Jan 16 06:43:55 it's the last group listed (999) Jan 16 06:44:15 but also, I just checked the udev rules on the fresh april image (in case I updated them on my bbb) and it looks fine to me Jan 16 06:44:23 it should result in -rw-rw-r-- Jan 16 06:44:44 so I have no idea wtf is going on on your system Jan 16 06:46:13 hmm Jan 16 06:46:18 issue seems to have fixed itself Jan 16 06:46:22 like.. magic Jan 16 06:46:54 did you buy a haunted beaglebone? have you checked the delivery terms whether the product is supposed to be shipped free of ghosts? Jan 16 06:48:00 well with how many issues this thing has I wouldn't be surprised if it did ship with linux casper Jan 16 06:50:13 an another note, thank you for programs and files. this will definitely make it easier for me to learn the pins on the board Jan 16 06:57:48 you're welcome Jan 16 07:41:56 has anyone used mraa? how do you install it for use in python? can't seem to find an installation guide on the repository Jan 16 13:17:53 hello? Jan 16 13:19:11 I am finding the spi dts file of BB AI, but I can not find where is it, Anyone could help me, thank you Jan 16 13:27:49 i get it Jan 16 17:58:03 anyone good at x11 config files Jan 16 17:58:14 I want to hard code my lcd panel geometry Jan 16 17:58:37 lcd panel geometry does into DT, not your xorg conf Jan 16 17:59:09 but when I launch programs they are always small Jan 16 17:59:17 is my DT messed up Jan 16 17:59:22 "small" ? Jan 16 17:59:29 like not using the full screen Jan 16 17:59:37 i was going to install a window manager Jan 16 17:59:39 that's up to the program and/or your window manager Jan 16 17:59:48 your xorg config has nothing to do with it Jan 16 17:59:52 oh Jan 16 18:00:03 any preference on window managers Jan 16 18:00:06 what do you use Jan 16 18:00:08 programs may support a -geometry argument Jan 16 18:00:17 I've never used x11 on a beaglebone Jan 16 18:00:29 why not Jan 16 18:00:34 wayland? Jan 16 18:00:52 the only time we've used a GUI on a BBB it was a single-window-fullscreen qt5 application, no x11 or wayland Jan 16 18:01:42 (we ended up using the eglfs backend after getting the gpu drivers working, but you can also use the linuxfb backend instead to avoid having to deal with that hassle) Jan 16 18:39:01 how can i make sure secondary windows fit the screen. It appears that the program does take the geometry argument Jan 16 18:39:14 and the initial page opens to the right size Jan 16 18:39:23 but subsequent dialogs are too big Jan 16 18:41:14 if the program uses multiple windows and you need that much control over their placement your options are either to modify the program to ensure it places its window in a way that pleases you or use some highly customizable window manager to do it for you (like "awesome" which is a lua-scriptable window manager) Jan 16 18:41:44 ok thanks Jan 16 21:04:24 how come doing sudo chmod -R 777 gpio just removed my gpio69 directory? Jan 16 21:21:28 zmatt: i wanted to ask you last night but didnt want to interrupt while you were helping Zalymo, but you had said one shouldn't have to use the export command to create missing pad(pin) entries which i understand but made me want to ask Jan 16 21:23:29 in my research/learning ive come across images for various places where when going into the sysfs filesystem that under the /sys/class/gpio directory theres nothing there except the symlinks to the 4 control modules Jan 16 21:23:49 and the export and unexport files Jan 16 21:24:34 outside of the device tree or a kernel driver is there some other macros that run to create the typical entries in that gpio area Jan 16 21:24:34 buzzmarshall: are you booting from SD card or eMMC ? if you're getting this on a recent image then this may be due to the system being bootloaded by an ancient bootloader that doesn't understand a bunch of stuff in /boot/uEnv.txt Jan 16 21:25:17 /sys/class/gpio/ should be populated by a whole bunch of stuff on the default image Jan 16 21:25:34 basically i am curious as to if the image-builder tool has macros to create any of those entries Jan 16 21:25:52 yes but i have had images where theres not much in there Jan 16 21:26:00 I don't know anything about image-builder. Those entries are created when gpios are declared in DT Jan 16 21:26:03 so i realize the device tree create some of them Jan 16 21:26:51 i just wasnt sure if there were macros for creating them some place else that ive not seen yet Jan 16 21:26:55 on the default image the universal overlay (aka cape-universal) declares gpios for all expansion header pins in DT Jan 16 21:27:31 no, they're declared in DT (the base dtb or some overlay) Jan 16 21:28:31 manually exporting then (by writing gpio numbers to /sys/class/gpio/export) is an ugly hack used if DT fails to declare them Jan 16 21:29:14 ive not played with capes yet but did know the normal kernel dts held some but just wasnt sure if i was missing something someplace else Jan 16 21:29:52 note that "cape-universal" has nothing to do with capes, it's just badly named Jan 16 21:30:04 as well i assumed the cape would somehow be involved Jan 16 21:30:15 aw... that answers my next question Jan 16 21:31:02 though calling it the universal overlay also isn't quite right anymore since I think the functionality has been integrated into a variant of the base dts Jan 16 21:31:47 like I think with cape-universal disabled it uses am335x-boneblack-uboot.dtb and with cape-universal enabled it uses am335x-boneblack-uboot-univ.dtb Jan 16 21:32:05 so...based on a bad assumuption on my part... if i used the tool to build the system and exclude the cape-universal would that explain the lack of the missing entries? Jan 16 21:32:07 no idea why they switched to doing that instead of using an overlay Jan 16 21:32:33 I have no idea what the tool you mentioned produces Jan 16 21:33:28 k... let me ask you this as maybe this is another bad assumption on my part Jan 16 21:33:33 it will depend on whether the kernel package includes these dtb variants (or an overlays package is installed that includes the overlay), whether an u-boot is used that understands to load these, and whether it is configured to do so via /boot/uEnv.txt Jan 16 21:34:08 i just took it for granted that the beagleboard releases were built using the image-builder tool i found on the github Jan 16 21:34:53 which is a fork of rcn's so i just took it for granted thats how everyones been creating the firmware images Jan 16 21:35:05 all this assumes you even consider cape-universal desirable... instead of making a custom DT for your application (which is the more traditional approach, and my preference, and in some cases the only option) Jan 16 21:35:19 I've never used image-builder so I don't know anything about it Jan 16 21:36:13 I create my "master" image from a working beaglebone system that serves as prototype Jan 16 21:37:21 (which once upon a time was based on a console image by rcn, though no real resemblence has been left other than it still being a minimalist debian system) Jan 16 21:37:58 ya it seems to be full of stuff that i wasnt sure if they were just left over from old days as the tool seems to be around for along time Jan 16 21:38:23 i was going about doing the way you are by basing it off a working board Jan 16 21:38:47 but then curiosity got me looking at that tool Jan 16 21:40:21 as for gpio, I prefer not using cape-universal at all but just declaring the functionality our hardware application actually has, including declaring gpios with semantically maeningful names so userspace don't need to know or care what pins are used (hence allowing them to be relocated with any software changes), e.g.: https://pastebin.com/YKW7Wcqu Jan 16 21:41:34 or more real-world: https://pastebin.com/c9jq54wJ Jan 16 21:43:12 application-specific gpio setup in DT also ensures outputs are properly initialized during early boot and userspace is not permitted to change the direction of gpios (unless explicitly permitted by the DT declaration) Jan 16 21:47:26 normally i would do my stuff in the DT but i wasn't sure with how most in the bbb world handle this stuff Jan 16 21:47:41 i see what you posted and would agree Jan 16 21:48:03 basically cape-universal is designed for people who get scared by DT :) Jan 16 21:48:43 most of the other arm's ive messed with have been in the media box area where theres not full docs and gpio playing arounds more of a hacker thing Jan 16 21:49:17 i wasn't sure seeing as the ti stuffs niceley supported in docs if it was being done differently Jan 16 21:49:57 thats a good tip then and i'll exclude the cape-universal stuff as i would tend to agree with your way Jan 16 21:49:59 cape-universal basically just enables most peripherals, exports gpios for all pins (as input, dir-changeable), and instead of attaching pinmux to the appropriate device (like it's supposed to be), each pin has a "pinmux helper" device which allows userspace to control the pinmux state Jan 16 21:51:05 hm... makes me wonder if thats cause of the effort to make this like a arduino and isolate the user from having to know Jan 16 21:52:02 kinda yeah.. like I said, DT seems to be intimidating to new people Jan 16 21:52:25 i like the tree and am so glad to see the kernels finally gobbling that up Jan 16 21:52:50 makes things so much easier at least to my way of thinking Jan 16 21:53:03 I think DT can be fine, if written legibly... which a lot of DTs aren't :P Jan 16 21:53:18 ya for sure Jan 16 21:53:40 DT heaven compared to anything else that has ever been proposed Jan 16 21:54:15 hey I think ds2 would have preferred still using board files ;) Jan 16 21:54:28 yeah, but he's weird Jan 16 21:54:31 lol Jan 16 21:54:35 for so many years people have had to deal with vendor bsps and crappy implemenation of stuff Jan 16 21:55:07 buzzmarshall: mainline is something obnoxious too though... e.g. the stuff I showed for configuring gpios in DT... not mainline! Jan 16 21:55:26 im old and that time was done back then but for some reason gettin rid of the out of tree bsp's just wouldnt go away Jan 16 21:55:30 *sometimes Jan 16 21:55:40 ya that might be true but what you posted is logical Jan 16 21:55:51 the things that annoy me most are due to kernel maintainers insisting on doing something a particular way Jan 16 21:55:58 not because of any limitations in DT Jan 16 21:56:01 and for anyone messing around out of the trees its easy to understand Jan 16 21:56:07 mru: yeah, like the spidev bullshit Jan 16 21:56:11 for sure Jan 16 21:56:21 or indeed gpio chardev (which sucks) vs sysfs gpio Jan 16 21:56:29 thats why i would never waste my time trying to feed stuff upsteam Jan 16 21:56:58 usually if ive got something and a bud wants the hassle of trying i'll just tell him to go for it Jan 16 21:57:17 to many picky peeps Jan 16 21:57:28 I had a long rand/discussion with pdp7 about this a while back. if you want to know about gpios and pin config and my opinions about this, see: https://liktaanjeneus.nl/gpio-discussion.html Jan 16 21:57:30 i get it but just not something i'd want to waste time on Jan 16 21:58:38 thnx... that will give me something to read while i eat... Jan 16 21:58:46 yeah I still have some local patches I should probably at least attempt to get upstream Jan 16 21:59:19 i gotta run out and grab something before it gets late and were under a don't leave home order here in ontario but i will be back in a bit Jan 16 21:59:36 thanx for the answers... i appreciate them Jan 16 21:59:36 I just ordered some food Jan 16 22:00:06 we did as well but need to pop down to the store and grab some more sd-cards Jan 16 22:00:21 they close for curbside shortly Jan 16 22:00:33 biab Jan 17 00:24:58 how would i find out the usb bus bandwidth Jan 17 00:25:13 by testing? Jan 17 00:25:26 do you need special equiptment Jan 17 00:25:30 no? Jan 17 00:25:42 I mean, what do you mean by "bus bandwidth" ? Jan 17 00:26:34 how much data the usb3 port is capable of receiving Jan 17 00:27:28 I mean, the hardware limit can probably be found on wikipedia. the real-world limit will no doubt depend on what kind of usage as well as software aspects Jan 17 00:29:08 like the usb3 standards is supposed to be capable of gigabyte speeds Jan 17 00:29:30 but point taken Jan 17 00:29:34 5 giga _bit_ per second Jan 17 00:29:59 that's the slowest superspeed variant Jan 17 00:30:03 or is it 2.5? Jan 17 00:30:32 5 it is Jan 17 00:30:35 says the spec Jan 17 00:30:39 that is super speed, i.e. USB 3 Jan 17 00:30:42 3.0 Jan 17 00:30:44 i am think it is going to be due to this usb port doing both powering and data transfer as host Jan 17 00:30:50 one or two lanes at 5 or 10 Gbps Jan 17 00:30:54 each Jan 17 00:30:56 Mattb000ne: power has no relevance to data transfer speed Jan 17 00:30:59 so max 20 Gbps Jan 17 00:31:10 but that whole thing with the USB-C in host Jan 17 00:31:12 that's the raw bit rate though Jan 17 00:31:14 mru: that's usb 3.2 Jan 17 00:31:15 and negotiating Jan 17 00:31:31 Mattb000ne: either works it doesn't, it doesn't "work but slower" Jan 17 00:31:32 nobody mentioned a minor version Jan 17 00:31:44 mru: am572x supports 3.0 Jan 17 00:31:46 so I have a different issue then Jan 17 00:31:56 because the hub that jkrinder uses Jan 17 00:32:01 I am able to turn on the camera Jan 17 00:32:18 nobody mentioned am572x either Jan 17 00:32:19 but my transfer speeds suck and I get that lsusb error all the time Jan 17 00:32:45 mru: no but I know that's the context :P Jan 17 00:33:10 fair enough Jan 17 00:33:20 and makes sense in this channel Jan 17 00:33:28 Mattb000ne: *shrug* my guess is the problem is either hardware or software Jan 17 00:33:37 you think? Jan 17 00:33:48 there's one more possibility Jan 17 00:33:48 I think so yeah Jan 17 00:33:50 pebkac Jan 17 00:33:54 some other bug outside of the usb3 and the whole hub stuff Jan 17 00:35:02 Mattb000ne: yeah like I said, for that stuff I don't really expect anything other than "it works" or "it doesn't work" Jan 17 00:35:24 (per protocol, usb2 and usb3 separately) Jan 17 00:35:43 lol Jan 17 00:36:02 but there can be all sorts of other fun problems of course Jan 17 00:36:10 usb never just works Jan 17 00:36:14 lol Jan 17 00:36:15 yeah usb kinda sucks Jan 17 00:36:29 would a GigE version of the camera have less issues Jan 17 00:36:38 probably Jan 17 00:36:40 doh Jan 17 00:36:55 like, if I can avoid usb, I'd generally take that option Jan 17 00:37:00 doh Jan 17 00:37:14 lol Jan 17 00:37:23 you figure by 3.0 it would be great Jan 17 00:37:41 no usb was at its best at 1.x when it was used for mice and keyboard Jan 17 00:37:54 it's been all downhill ever since :P Jan 17 00:39:33 it's more capable but also more complex Jan 17 00:39:51 in many ways it was always too complex Jan 17 00:40:12 all that crap about muliple configurations and alternate settings is just useless Jan 17 00:40:55 I just spotted this gem in the spec: "The state of a USB device when it is detached from the USB is not defined by this specification." Jan 17 00:41:25 I mean, that seems fair enough Jan 17 01:01:19 if i want a script to run at start up how do I do that Jan 17 01:01:37 USB! Jan 17 01:02:06 Mattb000ne: Did you get your camera to work? Jan 17 01:02:25 w/ that source? Jan 17 01:02:30 kind sorta Jan 17 01:02:34 Nice. Jan 17 01:02:39 stll having n issue getting the images off Jan 17 01:02:40 well, sort of nice. Jan 17 01:02:44 Oh. Jan 17 01:02:45 something is out of sync Jan 17 01:02:51 Hmm. Jan 17 01:03:07 So, it takes the image but comes back blurred or in error? Jan 17 01:04:13 in error Jan 17 01:04:43 i will get one picture but in a stream of pics i get memory errors and then shutdown Jan 17 01:05:28 what resolution and frame rate did you configure? Jan 17 01:05:44 and format Jan 17 01:06:01 30fps Jan 17 01:06:20 Can the BBAI handle that 30fps? Jan 17 01:06:50 and the image is 4024 px x 3036 px Jan 17 01:06:53 each iamge Jan 17 01:07:04 i guess not Jan 17 01:07:06 jeez that's a lot of pixels Jan 17 01:07:18 YUYV format? Jan 17 01:08:50 assuming YUYV or any other 2 byte/pixel format, that's 699 MB/s Jan 17 01:08:51 I do not need it at 30fps Jan 17 01:09:03 i am not sure on the format Jan 17 01:09:07 which is more than even the theoretical maximum of usb 3.0, let alone the practical maximum Jan 17 01:09:12 but you are probably right Jan 17 01:09:18 ok that may explain my problem Jan 17 01:09:58 i guess I assumed since it looked ok on my laptop it was ok Jan 17 01:10:51 so how does it work when I am using a web camera Jan 17 01:11:01 how is it able to display at 30fps Jan 17 01:11:24 I mean, most web cams are not 4024 x 3036 pixels Jan 17 01:12:19 even this camera in their viewer tool Jan 17 01:12:39 i can put it on continuous shoot and I can use it like a camera Jan 17 01:12:49 Beagleboard.org is on Debian's wiki now! Jan 17 01:13:05 Under RISC-V. Jan 17 01:13:34 Mattb000ne: you mean on your laptop? if you're able to use it at that resolution and frame rate then presumably your laptop supports usb 3.1 or 3.2 Jan 17 01:13:46 or you're using a compressed format instead of raw video Jan 17 01:17:44 ok maybe it is compressed Jan 17 01:17:48 Mattb000ne: like, here's the format/resolution/fps combinations my laptop's webcam lists as supported: https://pastebin.com/raw/wBcEpAGF ... note how when using raw video (YUYV) the fps drops at higher resolutions, while using MJPEG compression it supports its max framerate (30 fps) up to its max resolution Jan 17 01:17:50 it is a small window Jan 17 01:18:29 (as reported by v4l2-ctl --list-formats-ext ) Jan 17 01:20:44 for YUYV the data rate in bytes/second is width*height*fps*2 Jan 17 01:21:09 ok Jan 17 01:21:51 (for MJPG it depends on the compression parameters so I don't know if there's an easy way to query the bandwidth for those) Jan 17 01:25:50 so probably I am at fault Jan 17 01:25:59 and trying to pull down too much too fast Jan 17 01:26:30 if you're trying to get that resolution and fps in raw format across usb 3.0 then yeah that ain't gonna happen Jan 17 01:26:51 either use a compressed format, lower fps, or lower resolution Jan 17 01:27:07 what are the chances that the camera holds more than one image Jan 17 01:27:17 ? Jan 17 01:27:33 so I cant do 30 frames without some adjustment Jan 17 01:28:19 I am wondering if there is a way to get more time Jan 17 01:28:31 to get the images to my harddrive Jan 17 01:28:40 ehm, yes that's called lowering the framerate? :P Jan 17 01:28:50 lol Jan 17 01:28:55 then you have more time per frame Jan 17 01:29:08 but I am going to be at 1 fps with this size Jan 17 01:29:17 i need to cut the image down Jan 17 01:29:33 though you do have a good point... even if you manage to transfer the data from the camera, you also need to be able to consume the data that fast Jan 17 01:30:33 how do those CV applications handle this Jan 17 01:30:36 like, how fast can you process or store these 4024 x 3036 pixel images? Jan 17 01:30:40 i guess lower resolution Jan 17 01:30:57 I am going to crop it since most of it will not be needed Jan 17 01:31:04 but still will run into a processing issue Jan 17 01:31:12 does the camera has no built-in support for cropping? Jan 17 01:31:15 *have Jan 17 01:31:40 I can define the pixels for the image it takes Jan 17 01:31:42 so there is that Jan 17 01:31:51 just not use all of them Jan 17 01:31:53 since obviously if you can crop in camera then that saves having to transfer data you're going to throw away anyway Jan 17 01:32:06 yeah Jan 17 01:32:27 this obviously requires more thought than I put into it Jan 17 01:32:37 I need to check my usb ports Jan 17 01:32:43 maybe I do have 3.1 Jan 17 01:32:52 so I never noticed that it was moving so much data Jan 17 01:36:23 I was also wondering for a moment whether memory bandwidth might be an issue, but I think that should be fine... bbai has 32-bit wide ddr3-1066, so that's nearly 4 GB/s peak bandwidth Jan 17 01:36:30 how can i tell what type of usb port I Jan 17 01:37:00 this is a good learning experience Jan 17 01:37:09 that may explain why the board gives out Jan 17 01:37:19 i get a few errors than shuts off Jan 17 01:37:31 might just gobble up all the ram Jan 17 01:38:21 for i in /sys/bus/usb/devices/usb*/version; do echo "$i = $(cat $i)"; done Jan 17 01:42:46 3,1 Jan 17 01:49:55 when I use my laptop it is doing 300 mb/s **** ENDING LOGGING AT Sun Jan 17 02:59:57 2021