**** BEGIN LOGGING AT Fri Oct 25 03:00:04 2019 Oct 25 05:26:35 wonder how hot do DRA752 boards run Oct 25 07:31:56 hello again Oct 25 07:32:07 yesterday i had to go: Oct 25 07:34:28 rcn-ee[m]: did you have some news for me about that image? Oct 25 07:34:49 so you flashed it and it goes well? Oct 25 07:50:53 yesterday i tried to flash bone-debian-9.9-lxqt-armhf-2019-08-03-4gb.img but my BBB stuck in a loop somewhere. rcn-ee[m] tried it a said it was good but i did'nt understand if he flashed it or just booted from a MicroSD. Oct 25 07:51:24 rcn-ee[m]: are you here? Oct 25 09:43:44 Parduz: I think that the rcn-ee[m] fellow is out or asleep. Oct 25 09:43:51 What are you doing? Oct 25 09:44:09 dang. brb. I will wait to see what you post when I get back. Oct 25 09:44:24 trying to flash that image in a BBB Oct 25 09:46:11 it runs if i boot from the MicroSD, but when i flash it, the BBB then boots, shows the penguin, then goes in a sort of loop: the screen shows the cursor blinking a couple of times and then goes black for 3 sec. Repeat forever. Ethernet port blinking, heartbeat led beating, other two blue leds blinking randomly Oct 25 09:48:14 yesterday (11:46 AM here) rcn-ee[m] tried it and said " Parduz: looks fine: https://gist.github.com/RobertCNelson/2981bd98704a61c13c8cf01cf7bb501d" Oct 25 09:48:43 i'm too much a noob to understand if he booted from the MicroSD or flashed the image. Oct 25 09:50:09 Parduz: Are you trying to flash a new image w/ etcher w/ SD Card or are you trying to compile the image? Oct 25 09:50:40 the former Oct 25 09:50:46 Oh. Oct 25 09:50:53 Please hold. I will show you a site. Oct 25 09:52:01 https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black will show you how to set up your Desktop machine and compile the image. Oct 25 09:52:29 Wedsday I flashed 8 BBB with an older one. While it was just from may, zmatt suggested to use an updated one. Oct 25 09:52:37 which i tried yesterday Oct 25 09:52:41 Oh? Oct 25 09:52:43 Okay. Oct 25 09:53:03 What OS and kernel are you using? Oct 25 09:53:34 on the PC i use to "build" the MicroSD? Oct 25 09:53:43 or on the BBB? Oct 25 09:54:08 Parduz: I may only be able to help so much b/c of me not compiling a lot. If you go to beagleboard.org/latestimages, you can just use their images and get up and running. Oct 25 09:54:14 Is this okay w/ you? Oct 25 09:54:31 that's what i've done Oct 25 09:54:36 Oh. Oct 25 09:54:37 Okay. Oct 25 09:54:44 is the "lastimages" that don't works Oct 25 09:55:06 So, you tried to set up your images from beagleboard.org/latest-images and it does not work? Oct 25 09:55:16 exactly Oct 25 09:55:27 it runs well if i boot from the MicroSD Oct 25 09:55:36 it hangs when flashed on the BBB Oct 25 09:55:39 Oh. Oct 25 09:55:41 I got it now. Oct 25 09:55:42 Okay. Oct 25 09:56:00 You may be using a 2GB BBB instead of the Rev. C? Oct 25 09:56:07 nope Oct 25 09:56:13 Okay. Oct 25 09:56:32 the exact same BBB was running fine with a 4GB image i downloaded in May Oct 25 09:56:43 So, oh. Oct 25 09:56:49 i just repeated mu usual steps witn the newest image Oct 25 09:57:04 Did you ever show them your journalctl output? Oct 25 09:57:45 Boot the board w/ the SD Card and run journalctl. Print the output to pastebin.com. Oct 25 09:57:52 Post the link. I will look at it. Oct 25 09:57:56 i don't know how to get it from a "looped" BBB: i have no serial cable, and while Eethernet led flashes, i have no ping to that address Oct 25 09:58:08 ok, i'll try Oct 25 09:59:01 Do you have a USB connection from your BBB to your desktop/laptop? Oct 25 09:59:58 nope, i usually just flash it and then SSH in Oct 25 10:00:06 going to comment the flashing line from the uEnv.txt to boot from MicroSD Oct 25 10:00:20 https://beagleboard.org/latest-images and pick the Stretch LXQT. Oct 25 10:01:57 Debian 9.9 2019-08-03 4GB SD LXQT Oct 25 10:02:05 this is what i wanted Oct 25 10:02:15 I say the "Stretch LXQT" image b/c you want a OS Desktop env. right? Oct 25 10:02:35 yep Oct 25 10:02:47 i need to run a wWidget kiosk app Oct 25 10:02:56 wxWidgets, sorry Oct 25 10:02:58 Okay. Oct 25 10:03:16 I see you already have the lXQT image I was discussing. Oct 25 10:03:31 Now, run journalctl, please. Oct 25 10:04:12 still booting., ...... here it is Oct 25 10:04:18 Okay. Oct 25 10:04:23 Use pastebin.com please. Oct 25 10:09:06 https://pastebin.com/XMwF87kR Oct 25 10:12:33 Parduz: Sorry man. I cannot tell anything just yet. Go to /opt/scripts/tools/ and paste in pastebin.com sudo ./version.sh, please. Oct 25 10:13:07 I know that was a pain to copy and paste all of that info. Oct 25 10:13:18 not at all Oct 25 10:13:22 output to file Oct 25 10:13:24 :) Oct 25 10:13:26 Oh! Oct 25 10:14:19 Parduz: I used to have trouble w/ flasher images b/c of the size of the image and/or b/c of a bootloader issue. Oct 25 10:14:32 Anyway, please run this command too: df -h. Oct 25 10:15:07 How much space does it say you have left? Oct 25 10:15:27 https://pastebin.com/vJqDDrB8 Oct 25 10:16:31 df: Oct 25 10:16:32 https://pastebin.com/RxVE2ZUj Oct 25 10:17:31 That might be it. What size SD Card do you have? Oct 25 10:17:39 4GB? Oct 25 10:17:42 8GB Oct 25 10:18:54 It says 99% used w/ only 66M left. Oct 25 10:19:18 does etcher format it just like the image is? Oct 25 10:20:20 Hmm. Do you mean if, "Does etcher turn the .img.gz file into a .img file? Oct 25 10:21:01 i mean that i've never had to look at what etcher does :) Oct 25 10:21:07 Oh. Oct 25 10:21:15 Me neither! Oct 25 10:21:18 i usually just let it do its stuffs and then flash the BBB Oct 25 10:21:25 I just know it works if I first use 7-Zip. Oct 25 10:21:49 if it format a 4GB partition even on a bigger card, then that's what we have. Oct 25 10:22:20 anyway, the BBB is 4GB so we MUST run in that size, right? Oct 25 10:22:22 Parduz: You never ran the ./grow_partition.sh script, did you? Oct 25 10:22:27 nope Oct 25 10:22:30 Okay. Oct 25 10:22:54 So, it may be that you are just out of space. And yes, we need to have 4GB or less. Oct 25 10:22:59 For eMMC. Oct 25 10:23:27 W/ 66M, that does not give too much "leg room" for comfort on the BBB. Oct 25 10:23:55 my question is: if it run from the SDCard, why it don't run on the BBB? Oct 25 10:24:01 Oh! Oct 25 10:24:02 when flashed? Oct 25 10:24:19 Good question. Oct 25 10:24:51 That would be a good question for someone who is up-to-speed on eMMC tech. and the BBB. Oct 25 10:25:12 the only thing i do after etcher is to uncomment the last line in the /boot/uEnv,txt and then boot from the SDCard. Oct 25 10:25:17 I am sure I could look up eMMC tech. and figure it out but it is the start of my day. Come back and I might have info. Oct 25 10:25:25 Right. Oct 25 10:26:01 can i read something from the eMMC while running from the card that can show what happened? Oct 25 10:26:26 Hmmm. I cannot help you w/ that info. Oct 25 10:26:27 Hey! Oct 25 10:27:00 I know. If you really want to try something, hold down the S2 button on your BBB when you boot from it after powering it back on. Oct 25 10:27:36 what this will do? Oct 25 10:28:07 Like ---> Poweroff ---> Boot ---> Hold down the S2 button ---> Wait for the LEDs to show up ---> Release S2 Button Oct 25 10:28:29 isn't the button that make it boots from the card? Oct 25 10:28:31 This should get you to boot into eMMC if there is anything on it. Oct 25 10:28:37 eMMC! Oct 25 10:28:49 wait Oct 25 10:29:00 What? Oct 25 10:29:22 if i remove the cards, it boots from the eMMC without any action from my part Oct 25 10:29:32 right? Oct 25 10:30:07 Okay, yea. But, you have to have an image on it, i.e. on the eMMC> Oct 25 10:30:36 which is the one i flashed Oct 25 10:30:46 the one that then hangs Oct 25 10:30:56 Okay. So, one is flashed to the eMMC and one is on the SD Card. Oct 25 10:31:08 is the same exact image Oct 25 10:31:17 Right, b/c of space requirements. Oct 25 10:31:21 Right. Oct 25 10:31:56 Now, if you want... Oct 25 10:32:47 You can try to flash the image to eMMC on your BBB, hold the S2 button down while booting, and see what happens. There is an actual FLasher image on the beagleboard.org/latest-images site. Oct 25 10:33:02 It is highlighted in Blue. Oct 25 10:33:17 i am thinking .... why there's an IOT flasher image on the site but not an LXQT one on the site? Oct 25 10:33:46 The image does not have LXQT but you can get another OS for visualization. Oct 25 10:33:51 GUI or whatever. Oct 25 10:33:59 THey have one. Oct 25 10:34:10 Look at the third one down. Oct 25 10:34:33 that's the Debian 9.9 2019-08-03 4GB SD LXQT Oct 25 10:34:52 (lol for the emoticon) Oct 25 10:35:21 down there's "Flasher" debian images and there's the IOT one. Oct 25 10:35:39 Yep. The Flasher image is that way b/c maybe there was no way to fit the entire image w/ LXQT on the 4GB. Oct 25 10:35:45 Hey Parduz? Oct 25 10:36:00 Did you try the console image and an update to xfce4? Oct 25 10:36:07 nope Oct 25 10:36:16 That may help your eMMC woes. Oct 25 10:36:35 i need to have an image that i can flash for our production batch Oct 25 10:37:05 i don't want to update/upgrade all the BBB that will goes out in the next years Oct 25 10:37:14 They have console images here: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots. Oct 25 10:37:21 You can try those. There are a bunch. Oct 25 10:37:29 LXQT and Flashers. Oct 25 10:37:39 Oh. Oct 25 10:37:41 I got you. Oct 25 10:38:31 my previous image worked well Oct 25 10:38:33 BBB-blank-debian-9.9-lxqt-armhf-2019-05-27-4gb.img Oct 25 10:39:25 zmatt suggested to get an updated one ('cause boot time optimization) so i tried that one, which don't boot well. Oct 25 10:39:36 You can try from that elinux.org page online and maybe you can hatch a nice egg for your project. Oct 25 10:39:52 will see.... Oct 25 10:40:06 Okay. That is the wiki for the beagleboard.org/latest-images. Oct 25 10:40:19 do you know how could i read the journal from the eMMC? Oct 25 10:40:31 No. I do not. Oct 25 10:40:39 should i mount the eMMC and the look for...... ? Oct 25 10:40:44 oh, ok Oct 25 10:41:26 Parduz: I think you are just out of space on that particular image. Oct 25 10:42:11 ok Oct 25 10:42:34 Hmmm. Those other two people you mentioned know more than I do about the BBB. Oct 25 10:42:49 They may be able to help more later. Who knows? Oct 25 10:42:58 we will see :) Oct 25 10:43:05 thanks a lot for your time Oct 25 10:43:16 No issue, sorry I could not help more. Oct 25 10:46:51 could you take a look at https://rcn-ee.net/rootfs/bb.org/testing/2019-08-03/stretch-lxqt/ ? Oct 25 10:48:09 Okay. Oct 25 10:48:53 Now what? Oct 25 10:49:03 i can't remember what's the "blank" images are for :( Oct 25 10:49:52 Me neither. I just use the elinux.org page I listed. They have a console image. It barely has anything on it. You can pick and choose what you want on your image. Oct 25 10:50:06 i mean, what's the difference between "BBW-blank" and "bone"? Oct 25 10:50:11 oh, ok :) Oct 25 10:50:27 i'll try with that images and see what changes. Oct 25 10:50:30 https://rcn-ee.net/rootfs/bb.org/testing/2019-08-03/stretch-lxqt-2gb/ try that! Oct 25 10:50:51 yep, i'll see Oct 25 10:50:54 Okay. Oct 25 10:51:17 Oh and when you type up uname -a, what happens? Oct 25 10:52:13 uh? Oct 25 10:52:39 ah, it's a command... sorry :D (i'm a windows man ;) ) Oct 25 10:52:43 Yea. Oct 25 10:52:54 dunno, i've just start to re-write the card Oct 25 10:52:58 uname -a on your BBB should show the image. Oct 25 10:53:00 Okay. Oct 25 10:53:01 No issue. Oct 25 10:53:57 I have used this dang windows system for so many years. I never learned powershell. I am just starting to learn it. Oct 25 10:54:00 It is annoying. Oct 25 10:54:16 Anyway, I found that linux commands are easier for me. Oct 25 10:54:51 me neither (powershell) :D Oct 25 10:54:59 oh. Oct 25 10:55:29 i'm an old fart.... DOS commands and batch files are still what i use if i need something Oct 25 10:55:30 One thing cool about powershell...I can use linux commands w/ wsl on the command line. Oct 25 10:55:36 Oh. Oct 25 10:56:30 otherwise i was a VB programmer, now a C++, used BorlandC++Builder for like 15 years Oct 25 10:57:13 Aw...See. I am new to the whole idea of programming, computers, and it is like I am from the '40s. Ha. Oct 25 10:57:23 now with these small PC like the BBB we HAVE to switch to Linux, g++ and wxWidgets..... Oct 25 10:57:30 Right. Oct 25 10:57:36 but i truly HATE linux ;D Oct 25 10:57:51 Oh. Too bad. It is another means to an end I guess. Oct 25 10:58:31 i hate how things that were true two years ago are obsolete and maybe not working anymore now.... Oct 25 10:58:47 Right. Things change and things stay changing. Oct 25 10:58:50 I have noticed that too. Oct 25 10:59:10 I am just upset w/ Python2 to Python3. Oct 25 10:59:15 i could list you Win95 graphic APIs and -while obsolete- they're still works now as they were 15 years ago. Oct 25 10:59:26 Hmmm. Oct 25 10:59:28 Nice. Oct 25 11:00:54 time to eat something :D Oct 25 11:01:00 Ciao :) Oct 25 11:05:25 Later... Oct 25 11:05:29 Hunger! Oct 25 11:33:06 Hi, can anybody tell me why the BeagleBoard X15 is so hard to get? Everywhere I check, stock is 0... Oct 25 11:37:09 They have switched distributors and it is taking a little time to get everything spooled up. Oct 25 11:38:36 mouser shows they have units available within a month though, so the end of shortage is in sight :) Oct 25 11:46:10 hi zmatt Oct 25 11:46:42 did you saw my previous messages? Oct 25 11:49:47 I'm not really here yet, but I'll check scrollback later today **** BEGIN LOGGING AT Fri Oct 25 12:26:49 2019 Oct 25 12:28:22 https://pastebin.com/KWnYS5k2 Oct 25 12:30:13 "Error writing X authority: Failed to write X authority /home/debian/.Xauthority: No space left on device" seems that set_ was right. Oct 25 12:30:36 what does df -f / say? Oct 25 12:30:40 df -h / Oct 25 12:31:12 0 avail Oct 25 12:31:35 "/dev/mmcblk1p1 3.7G 3.5G 0 100% /" Oct 25 12:31:54 there's really no reason to have a full desktop environment anyway... even if you want a GUI application that needs X11, you just need X11 and some minimal stuff, not a whole desktop environment complete with web browser Oct 25 12:32:13 this is sloppy though, the image being too big to fit on "4GB" (cough) eMMC Oct 25 12:32:20 it probably didn't get tested Oct 25 12:32:30 uh Oct 25 12:32:34 rcn-ee[m]: poke Oct 25 12:32:48 your last sentence is seriously sad Oct 25 12:32:53 yes it is Oct 25 12:33:47 i did'nt want to start building images on my own..... Oct 25 12:34:00 it surprises me too, I got the impression images normally get tested between well before they move from "testing" to latest-images Oct 25 12:35:57 on what the "BBBW-blank-etc" images differs from the "bone-etc" images is can see at https://rcn-ee.net/rootfs/bb.org/testing/2019-08-03/stretch-lxqt/ ? Oct 25 12:36:40 what we do is we have one system that we setup the way we want and make an image from that, and we have a flashing util (on SD card) that will wipe and configure eMMC, create the rootfs partition, writes the image and expands to fit, personalizes the image (random fsuuid and machine-id, set hostname, generate ssh keys), install the bootloader, and registers it in our database Oct 25 12:37:02 bone- are not flashers Oct 25 12:37:07 they just boot from sd card Oct 25 12:37:23 though you can turn them into flashers with a one line change in /boot/uEnv.txt Oct 25 12:37:34 ok, but what the "blank" one? Oct 25 12:37:40 those are flashers Oct 25 12:37:50 (they're for "blank" BBBs) Oct 25 12:38:32 ....confusing.... then what the "bone-eMMC-flasher-debian-9.9-lxqt-armhf-2019-08-03-4gb.img" is for? Oct 25 12:38:42 if you want a quick fix for the latest lxqt image, just get the standalone version, use apt to remove some unncessary crap (I promise you there is) to free up space, then turn it into a flasher Oct 25 12:39:16 evidently also a flasher... they didn't use to exist. in that case I don't know what the difference is between that and the "blank" ones Oct 25 12:40:17 roger about the quick fix Oct 25 12:40:57 can i see some example bout the "making a whole image" stuffs? Oct 25 12:41:03 dpkg --get-selections | grep -P 'am57|opencl|dra7' is definitely all crap Oct 25 12:41:28 though really you may want to consider the suggestion I saw from rcn yesterday about a leaner X11 environment Oct 25 12:41:46 there's just so much crap on the lxqt image you don't need Oct 25 12:41:50 oh, sweet: pls go on telling me what to remove :) Oct 25 12:43:31 as long as rules and pmount, wxWidgets app with touch cape and localhost sockets keep working Oct 25 12:43:47 wtf is pmount Oct 25 12:44:10 or "rules" Oct 25 12:44:46 the only way i've found to have the USB sticks automounted is to write a 99-automont.rule that catch the stick in event and mount it. Oct 25 12:45:31 this requires "pmount" (which is a tiny install) Oct 25 12:45:37 rcn linked to this page showing what's needed to setup X11 to run a single application on a console image => https://www.digikey.com/eewiki/display/linuxonarm/FLIR+Lepton+on+BeagleBone+Black+and+Green Oct 25 12:45:41 ew Oct 25 12:46:29 the "normal" way to mount usb sticks would be via udisks I guess Oct 25 12:47:20 for automounting sd cards I've used a simple fstab line like /dev/mmcblk0p1 /mnt/sd vfat users,uid=dev,gid=dev,fmask=0137,dmask=0027,noauto,x-systemd.automount,x-systemd.device-timeout=5s,x-systemd.idle-timeout=10s 0 0 Oct 25 12:47:42 but that requires having some way to identify the device being mounted Oct 25 12:47:54 that's the point. Oct 25 12:48:09 though I guess the first usb stick will always be /dev/sda but that seems yuck to rely on :P Oct 25 12:48:13 we will don't know what will be inserted. Oct 25 12:48:47 so you just want to first partition of the first usb stick inserted to be mounted at a fixed location? Oct 25 12:48:55 yep Oct 25 12:49:15 will there always be a stick inserted? Oct 25 12:49:21 nope Oct 25 12:49:32 so how does your application know whether or not one is inserted? Oct 25 12:49:48 the technician will come with one to update files and take back collected data Oct 25 12:50:18 ah I see, so it's insert stick, click a button or whatever, wait until it's done, remove stick Oct 25 12:50:19 when the user goes in a page, the app checks id "media/sda1" exists Oct 25 12:50:25 right Oct 25 12:50:30 right so you actually do assume it's sda1 Oct 25 12:50:47 i mount it in the rule file. Oct 25 12:50:56 wait, i'll copy here Oct 25 12:51:00 instead of automount you can also just allow a specific user to mount and unmount the filesystem in fstab Oct 25 12:51:25 you'll want to unmount it anyway (and then sync()) to ensure all data is written and no filesystem corruption can occur Oct 25 12:51:29 i want (need) no actions from the user. Oct 25 12:51:47 so how the technician know when it's safe to remove the usb stick? Oct 25 12:52:19 when my progress bar ends :) Oct 25 12:52:50 okay so that's the same thing except the "action" is inserting the stick Oct 25 12:52:53 that doesn't change anything Oct 25 12:53:15 you'll still want to unmount and sync before showing you're done Oct 25 12:54:05 i just let him remove the stick Oct 25 12:55:02 which is something he'll do after the progress bar ends, which is something you should do after your application does unmount and sync, otherwise you'll have a decent chance of random corruption Oct 25 12:55:12 here is where i started: https://www.axllent.org/docs/view/auto-mounting-usb-storage/ Oct 25 12:55:16 anyway Oct 25 12:57:06 my suggestion is to either use a simple /etc/fstab line like: /dev/sda0p1 /mnt/usb user,uid=dev,gid=dev,fmask=0137,dmask=0027,noauto 0 0 with uid/gid set to the user as which your application runs. the "user" flag gives the indicated user the right to mount and unmount the filesystem Oct 25 12:57:34 perhaps a more flexible solution is udisks, which I think can automount stuff but it also has a dbus interface Oct 25 12:59:07 i'll look at it, but it required a lot of time and research to come to the actual result. Oct 25 12:59:57 (one of the reasons i hate linux: almost no one seems to be able to tell how to do things and have it working the way he tells it :D ) Oct 25 13:00:01 this udev rule looks pretty useless since you wouldn't know the name of the mountpoint Oct 25 13:01:09 like, this is useful for humans, not for software Oct 25 13:01:33 which is probably one of the things you changed Oct 25 13:01:51 yep, i don't have the file avail now... Oct 25 13:01:58 but if you know it's going to be /dev/sda, then there's no need for such a complicated solution, a line in fstab suffices Oct 25 13:02:25 I know that udisks is how it's handled on desktop linux systems in practice Oct 25 13:02:54 it handles autodetection, mountpoint naming, mounting/unmounting, notification, and unprivileged access Oct 25 13:03:36 (by the user currently logged in locally) Oct 25 13:04:07 i'm here learning, so i'll be happy to try your solution. Oct 25 13:04:59 i have a call. b back in 10 minutes Oct 25 13:05:14 you'll still need a way to know a stick has been inserted (if you want the process to start automatically) but it's not clear to me how you'd know that currently either Oct 25 13:05:55 I'm very surprised this rule works though, it shouldn't work Oct 25 13:06:05 normally you can't mount or unmount anything in an udev rule Oct 25 13:06:26 since udev runs in an isolated namespace for security Oct 25 13:12:11 how I'd handle this would be either Oct 25 13:13:36 1. create a line in fstab for /dev/sda, use libudev to get notified when /dev/sda shows up, mount and umount it myself Oct 25 13:14:23 or 2. install udisks, use dbus to get notified of mountable filesystems showing up and use dbus to mount/umount it Oct 25 13:15:15 I'd lean towards the latter unless udisks turns out to be annoying to use or have annoying dependencies or whatever Oct 25 13:17:41 ok, copied this solution on my notes Oct 25 13:18:07 looking at the package dependencies of udisks2 it seems to recommend but not require polkit, which is good (you don't want polkit on an embedded system) Oct 25 13:18:58 the way to know the stick is in (in my way) is to look at the dir in /media/. There's nothing there when the stick is'nt in Oct 25 13:20:07 ah using inotify or such (not polling right?) Oct 25 13:21:24 these are my two lines in the .rules file: Oct 25 13:21:26 ACTION=="add", KERNEL=="sd[a-z]*", RUN+="/usr/bin/pmount --read-write --sync --umask 000 --noatime %k" Oct 25 13:21:41 ACTION=="remove", KERNEL=="sd[a-z]*", RUN+="/usr/bin/pumount %k" Oct 25 13:22:03 so did you mess with the systemd-udevd service file to get your solution to work? since it shouldn't work :P Oct 25 13:22:15 yep Oct 25 13:22:24 copied the original one in etc Oct 25 13:22:27 also why pmount? udev runs as root Oct 25 13:22:58 oh so you didn't even just override the one setting you needed to override but replaced the service file entirely :P Oct 25 13:23:16 anyway, this is... not a great solution Oct 25 13:23:48 and changed MountFlags from "slave to "shared" Oct 25 13:24:00 that how i read it should be done Oct 25 13:24:01 pmount looks like sort of a rudimentary predecessor of udisks Oct 25 13:24:51 well the higest-rated answer in https://unix.stackexchange.com/questions/330094/udev-rule-to-mount-disk-does-not-work at least shows two options for overriding settings in a system-provided service file without replacing the entire service file Oct 25 13:24:59 but a better answer would have been: "don't do that" Oct 25 13:26:28 i'll take your as a good advice and try your way Oct 25 13:28:16 turns out libudisks2 also has a C/C++ library, though it's evidently just a wrapper around the dbus interface using libgdbus... I'd personally probably be more inclined to use sd-bus (libsystemd) but that's just because I'm familiar with it and we already use it in lots of applications (and it integrates nicely with sd-event, which we also use in lots of stuff) Oct 25 13:29:49 libudisks2 is probably nice for applications that use gtk/glib Oct 25 13:30:50 checking it right now, while trying flashing the "blank" image Oct 25 13:31:16 ah, the linux version of wxwidgets is actually based on gtk? Oct 25 13:31:46 you can build it against gtk2 or 3, yes Oct 25 13:32:49 last time i tried the gtk3 was bugged as hell, though. Dunno if the widgets or the gtk itelf, was just a pain. Oct 25 13:41:22 I haven't done anything with gtk myself in ages Oct 25 13:44:09 nothing. The whole 2019-08-03 branch can't be flashed :( Oct 25 13:44:49 ? Oct 25 13:44:52 what did you just try? Oct 25 13:45:08 tried to flash also the "blank" image. Oct 25 13:45:14 that's the same image Oct 25 13:46:03 dunno. Tried the "bone" from the "latestimages" page, the flasher one and the blank from that site, this was the last one Oct 25 13:46:18 there's only one "lxqt" image for beaglebone for a specific date Oct 25 13:47:44 I'm not sure why there are two flasher images for it, but I don't really expect any difference in end result of what's flashed to eMMC Oct 25 13:48:29 like I said, if you just want a quick fix then get the standalone (non-flasher) version and remove some crap to free up space before changing it into a flasher Oct 25 13:48:38 me neither. BUT neither i'll expect to have it running on the card and hanging on the eMMC, so ... :) Oct 25 13:48:55 yup, i'll start that right now. Oct 25 13:49:00 well now that we know it doesn't really fit on eMMC it makes perfect sense Oct 25 13:49:21 I mean, it sort of fits, but doesn't leave enough free space needed to be able to actually boot properly Oct 25 13:49:32 yup Oct 25 13:49:33 so that mystery is completely resolved Oct 25 13:50:02 so I'd fully expect the same results from simply reflashing the same image Oct 25 13:50:37 and would you expect two different names for the same flashing image? :D :) Oct 25 13:50:55 joking, obviously Oct 25 13:51:06 you'd have to ask rcn Oct 25 13:51:23 yep Oct 25 13:51:55 yesterday he told me the image was fine. but i've not understood if he was booting from card or from eMMC Oct 25 13:52:14 probably sd card, or maybe an older beaglebone whose eMMC is slightly bigger Oct 25 13:52:27 the meaning of "4GB" varies depending on eMMC manufacturer Oct 25 13:53:31 its size has gone down slightly over time: Oct 25 13:53:53 3744 MB Micron MTFC4GLDEA-0M WT (bga marking: JWA06) Oct 25 13:54:00 3688 MB Kingston KE4CN2H5A Oct 25 13:54:07 3648 MB Kingston EMMC04G-S100 Oct 25 13:54:14 (these are real MB, aka "MiB") Oct 25 13:54:19 oh ... wow. Oct 25 13:54:42 this image would probably run fine on the old micron eMMC Oct 25 13:54:57 his report shows less space, anyway: Oct 25 13:54:59 just tried. I'll stay on the 2019-05-27 one, which i know is working. and meanwhile i'll try about Oct 25 13:55:07 no, sorry Oct 25 13:55:10 wrong paste Oct 25 13:55:13 yes that sounds like a fine solution too Oct 25 13:55:20 https://gist.github.com/RobertCNelson/2981bd98704a61c13c8cf01cf7bb501d Oct 25 13:55:36 here is rcn running the image yesterday Oct 25 13:56:19 that's booting from sd card Oct 25 13:57:36 there's also a stretch-lxqt-2gb image btw... that will definitely fit :P Oct 25 13:57:45 not sure what's not installed on that though Oct 25 13:57:48 i guess :D Oct 25 13:59:50 it is interesting that the image is indeed noticably smaller than even the smallest eMMC, yet it doesn't run out of space there Oct 25 14:00:04 though I wouldn't want to have only 66M free either Oct 25 14:00:51 in fact we have only a few hundred MB in use on any production beaglebone (including the ones with GUI) Oct 25 14:01:42 just by starting with a non-gui one and adding the window manager? Oct 25 14:02:28 we don't use X11, but even if you do it shouldn't take much space if you use a minimal install like the one on the wiki page linked earlier Oct 25 14:02:54 but yeah our images once upon a time derived from one of rcn's console images Oct 25 14:03:04 got it. I have so much to try and no time to do it Oct 25 14:04:26 yeah that's annoying, I've also sometimes implemented things in ways I didn't like because I didn't have time to do it better Oct 25 14:04:39 I wouldn't want to ship an image that has almost no free disk space though Oct 25 14:05:26 me neither Oct 25 14:05:36 the fact that we use less than 50% of disk space makes remote upgrades much less of a headache Oct 25 14:06:10 also i need to save data until transferred to USB, so .... Oct 25 14:06:24 zmatt: rcn-ee[m]: did you take a look at my pinmux settings for boot? Oct 25 14:06:37 jkridner: yes I made a bunch of comments about it yesterday Oct 25 14:06:47 in IRC logs? Oct 25 14:06:50 yes Oct 25 14:06:58 k, pulling it up. Oct 25 14:08:14 also, thanks to a question by ds2 I checked how the kernel currently configured mpuss power management, and it turned out to be configured to not allow any sort of lower power state while idle. changing two registers reduced the temperature of my bbx15 when idle by 10 degrees celsius Oct 25 14:08:27 zmatt: for the EHRPWM, my plan is to set the IO delay for EHRPWM, but put it in driver-off mode, unless there is a shorted conflict. Oct 25 14:08:39 iodelay is irrelevant for ehrpwm Oct 25 14:08:45 I never did find the setting in the pinmux tool for disabling pull-up/down in driver-off mode. Oct 25 14:09:11 zmatt: is there no timing relative to clocks? Oct 25 14:09:55 zmatt: cool. how do I get the "cool me down" patch? Oct 25 14:11:09 what clocks? iodelay is only relevant to line up signals belonging to the same interface that have well-defined timing relative to each other. in case of ehrpwm the only candidate is synchronization between the "a" and "b" outputs which doesn't matter unless you use ehrpwm in a mode that the kernel driver doesn't support anyway Oct 25 14:11:59 but I guess it doesn't hurt to set up that iodelay either Oct 25 14:12:22 zmatt: I agree that schematics like this would really just be better written in an HDL if they really aren't going to have structure you can follow. Oct 25 14:12:40 m Oct 25 14:12:49 zmatt: for the capes, I don't think we bring out the sync/clock signals, but the peripheral has them. Oct 25 14:13:01 well a better question is why the kernel configures mpuss prcm the way it does, since it's not for lack of support: there's a file that deals with those settings (arch/arm/mach-omap2/omap-mpuss-lowpower.c) and the kernel uses them for e.g. bringing cpu1 online/offline Oct 25 14:13:25 jkridner: that's not what I meant, and I don't think a HDL would be better than a schematic Oct 25 14:13:52 I want a schematic where I don't have to continuously chase around labels like a choose-your-own-adventure book Oct 25 14:14:25 especially when that label turns out to be a short distance away on the same page with absolutely no obstacle for just connecting them with a wire Oct 25 14:14:26 zmatt: most people don't, but I would find it easier for editing/parsing. if all we are doing is assigning net names, I don't see a reason for a schematic at all. Oct 25 14:15:03 zmatt: also, it seems many people don't use busses on schematics anymore, which is further annoying. Oct 25 14:15:52 using buses can definitely help too, though they can also already obscure things Oct 25 14:16:02 anyway, my big question is if I should put these signals in gpio mode or driver-off mode, if I can't put them in uart-tx or ehrpwm mode because they'd be driven. Oct 25 14:16:04 uhh that sentence failed Oct 25 14:16:31 readable schematics are hard and people don't like hard work. :-) Oct 25 14:16:54 I'd support gpio mode for pins that have gpio mode Oct 25 14:17:11 people expect to be able to use gpios Oct 25 14:17:27 zmatt: does the pinmux tool say what the default pull-up/down of the pin is? Oct 25 14:17:52 zmatt: +1 on expectation on gpios. Oct 25 14:18:12 * jkridner will start adding default modes to my crazy spreadsheet for consumption. Oct 25 14:18:32 no idea I don't use the pinmux tool, but I linked a spreadsheet export that shows the expansion header pins with default pull and the settings you configured in your github data Oct 25 14:18:44 they're also in my vayu-pins spreadsheet Oct 25 14:19:26 in case you can't find the link in scrollback: https://docs.google.com/spreadsheets/d/e/2PACX-1vSB0SmXxNCxdazDYFF9x55__ks2zxsuh8-AZYl7kkCSIJptsBHP02ZPD2lu-XS6JTe8-uWtnhnWOSwz/pubhtml?gid=1887626825&single=true Oct 25 14:19:46 found it Oct 25 14:19:54 ok :) Oct 25 14:20:16 btw it doesn't look like ehrpwm has iodelay anyway Oct 25 14:20:26 at least the ones you setup Oct 25 14:20:37 so that removes the last reason to setup ehrpwm in u-boot Oct 25 14:23:38 manual timing exists for vip, vout, qspi mode 0, rmii, rgmii(internal delay), mmc (some high-speed modes), and pruss Oct 25 14:26:45 k Oct 25 14:27:38 setting the timings for vout might be interesting to help with LEDs. I wonder if the iodelay really matters for GPIO mode.... so setting the iodelay for vout might make some sense? Oct 25 14:27:56 pruss will obviously only need it under very specific circumstances, and I'm not sure how useful it is on pru inputs since resynchronization can already cause 10ns jitter (including inconsistent across pins) Oct 25 14:28:02 * jkridner is filling in my big-ugly-sheet with some default modes I plan to build to. Oct 25 14:28:12 there are no iodelay settings for gpio mode Oct 25 14:28:22 16:23 <@zmatt> manual timing exists for vip, vout, qspi mode 0, rmii rgmii(internal delay), mmc (some high-speed modes), and pruss Oct 25 14:28:41 what is the standard DTB name for the framebuffer again? Oct 25 14:28:42 k. exclusively those. Oct 25 14:28:43 simplebuffer? Oct 25 14:29:03 kremlin: the framebuffer normally doesn't have a DT declaration Oct 25 14:29:09 since there's no "the" framebuffer Oct 25 14:29:13 hmm Oct 25 14:29:25 zmatt: so, does setting the iodelay for those special modes and putting the pinctrl into gpio mode make sense? Oct 25 14:29:26 framebuffers are allocated in memory by the kernel driver Oct 25 14:29:54 ic Oct 25 14:31:12 jkridner: configuring iodelay on the "LCD" pins (P8.27-46) sounds like a good idea yeah Oct 25 14:31:56 k, thanks for the validation. enabling late config can be nice. Oct 25 14:32:32 hmm, why does it have four manual timings Oct 25 14:34:25 zmatt: what is manual mode anyway? Oct 25 14:34:41 the values are all extracted from the pinmux tool. Oct 25 14:34:45 oh the datasheet actually gives four options for timing specs to chose from (tables 7-15 through 7-18 on pages 234-235 of SPRS953F) Oct 25 14:36:26 manual mode means each delay-line (each pin has a coarse and a fine delay line for each of: input, output, output-enable) is configured manually based on timing data provided by the datasheet and calibration values determined at runtime by u-boot Oct 25 14:38:48 so, thoughts on using these manual modes? Oct 25 14:41:55 it looks like the four modes available for vout interfaces just differ in delay from pixel clock edge to the remaining signals. in the default timing they line up (±2.5 ns) Oct 25 14:42:34 * jkridner wonders if there is room for alignment of VOUT to the actual board trace lengths. Oct 25 14:43:07 the alternate modes give a delay of 2.53 (±1.02) ns, 4.205 (±1.355) ns, and 5.08 (±1.53) ns Oct 25 14:44:05 TI says you've got to use the values they supply, but I don't see a good reason it would be a bad idea to use iodelay to compensate for trace lengths Oct 25 14:44:16 kinda big spread, but shifting any outliers one way or the other might be good. Oct 25 14:46:17 I think you could just add custom delay values to the ADELAY values in the datasheet Oct 25 14:46:36 to within certain limits (but iirc fairly generous) Oct 25 14:48:36 I've been meaning to see if can see iodelay in action with a scope, iirc I also noticed something odd about the calculation that I wanted to investigate, but it's been a while since I looked at it Oct 25 14:49:12 lol. removed the firmware-am57xx-opencl-monitor via ssh on my "hanged" BBB and immediatly the desktop appeared, without even rebooting Oct 25 14:49:42 yeah 0 free disk space is not good Oct 25 14:57:46 hmmmm..... pinmux warns that vddshv7 is 1.8V. Oct 25 14:58:31 why is ball AC4 on a 1.8V rail? Oct 25 14:58:55 nm.... pinmux tool has the wrong config. it is 3.3V Oct 25 14:59:02 I was about to say Oct 25 14:59:21 like I said in scrollback it also thought some other power domain was 1.8V which really is 3.3V Oct 25 15:00:31 * jkridner can't remember where the config setting is. Oct 25 15:05:09 * jkridner has to run and pick up son from school. back later. Oct 25 15:23:35 ok yeah that's why I wanted to examine iodelay on a scope... I really get a strong impression that the calculation in the TRM is wrong Oct 25 15:28:07 ok, learned what initramfs are Oct 25 15:28:23 now, how to remove them? Oct 25 15:29:09 these vout timings also don't make sense to me Oct 25 15:29:39 Parduz: for a quick test just move/rename the /etc/initrd* file Oct 25 15:30:53 that's all? It scares me when something is just "move that" :D Oct 25 15:31:48 yes removing the file is all that's required Oct 25 15:32:01 further steps are to ensure it won't get regenerated when you e.g. install packages Oct 25 15:33:13 for that you should remove the initramfs-tools package, except you can't since the kernel package (erroneously) depends on it, but a simple workaround is to replace it with this dummy version: https://liktaanjeneus.nl/initramfs-tools_1.0_all.deb which you can install with sudo dpkg -i FILE Oct 25 15:34:31 hmm ... the IOT image does'nt have any ... ? there's a /etc/initramfs-tools/ with conf files, but i can't find any /etc/initrd* file Oct 25 15:34:49 ok, great Oct 25 15:38:30 /boot/initrd* sorry Oct 25 15:52:41 rcn-ee[m]: do you upstream the patches under https://github.com/RobertCNelson/bb-kernel/tree/am33x-v5.3/patches ? Oct 25 16:11:51 First time here. Hello. Looking for a working example of PWM for the BBAI. Exhausted google. Hoping to find some leads. Oct 25 16:14:20 Anyone try the BBAI classification.cpp example and get "CMEM Error: needs driver version 0x4150002, got 0x4160000"? If so, any suggestions on how to fix it. Oct 25 16:27:00 SeanMiller: using peripherals on the bbx15/bbai is currently still a big chore... there's no overlays yet so you need to make a custom dts that e.g. #includes the standard one and adds customizations below it, e.g. to enable a pwm peripheral and setup its pin(s) ... and then put the custom dtb in /boot/dtbs or /boot/dtbs/$(uname -r) and configure /boot/uEnv.txt to use it Oct 25 16:27:15 making it as easy as it was on the BBB is still work in progress Oct 25 16:28:59 jkridner[m]: vout1 manual timings analyzer => https://docs.google.com/spreadsheets/d/1_HK0DhGM-SEDYcoLgMudWejqZZo2yBNlNTIoFP4P9TM/edit?usp=sharing Oct 25 16:30:28 jkridner[m]: I'm pretty sure timings 1 is plain wrong, it should add 2.53 ns delay to the data pins relative to the clk pins, but it actually seems to delay the clk pin relative to the data pins (by 3.1 ns) Oct 25 16:31:16 (the "differences, normalized median" set of columns is the most useful) Oct 25 16:31:51 Thanks zmatt Oct 25 16:36:36 jkridner[m]: the difference between timings 2 and 3 matches the datasheet, compared to timings 0 they seem to be of by more than the tolerances allow, and timings 1 seems nonsense Oct 25 16:36:50 *seem to be off Oct 25 16:36:59 ....where the ~/.config folder is, now? Oct 25 16:37:07 Just found that replacing 8_39 for 9_15 in the cloud examples for python will get a blink. It's due to the mismatch in mapping, but is a hack that can give me the pin. Oct 25 16:37:36 Parduz: ~/.config doesn't move, although it won't exist unless you create it or some application created it for you Oct 25 16:37:47 oh, ok Oct 25 16:37:55 thnx Oct 25 16:38:28 gpio numbers are totally different between the bbai and bbb yes Oct 25 16:38:49 that should be abstracted away by using DT and udev, but the bbai dtb currently doesn't export gpios yet Oct 25 16:39:03 which is another thing that should be fixed Oct 25 16:39:29 (and of course then software should be fixed to use the symlinks created by udev instead of using some hardcoded table of gpio numbers) Oct 25 16:41:12 jkridner[m]: and this is using G=1.02 .. the math in the TRM would yield G=0.51 which makes things even more wrong Oct 25 17:32:09 p Oct 25 20:19:23 hi all Oct 25 20:20:18 anyone having problem with TFT screen when using i2c2 bus together? Oct 25 20:20:36 btw, I'm talking about beaglebone black Oct 25 20:20:46 debian 9.5 and kernel 4.14.x Oct 25 20:20:46 rah: depends, lots of those are either abondoned, or backports.. Oct 25 20:21:13 bluePain: that's a bit too vague, i2c and the lcd interface are not intrinsically related in any way whatsoever Oct 25 20:21:34 unless you mean it's an i2c-controlled "smart" display Oct 25 20:23:17 zmatt thanks for the reply Oct 25 20:23:48 the thing is, I have 2 devices connected to i2c2 bus, one gpio extender and one rtc chip Oct 25 20:23:58 and tft is controlled by lcd pins of the beagle Oct 25 20:24:40 the problem is if the i2c2 bus connected, /dev/fb0 is not initialized Oct 25 20:49:32 are you using an off-the-shelf lcd cape or a custom solution? Oct 25 20:49:32 but when I disconnect one of the pins of i2c2 bus, tft recognized properly and /dev/fb0 device appears Oct 25 20:49:32 zmatt: complete custom solution Oct 25 20:49:32 btw, if I move devices from i2c2 to i2c1, everything works pretty well Oct 25 20:49:32 i2c2 is used for cape auto-detection which is why I was wondering Oct 25 20:49:32 i couldn't find any error messages in kernel logs or in dmesg Oct 25 20:49:32 try installing my show-pins utility: https://github.com/mvduin/bbb-pin-utils/#show-pins Oct 25 20:49:32 yea, I heard about it, but I'm not sure if it's interfering with the boot-up sequence Oct 25 20:49:32 and check sudo show-pins | sort when lcd is working vs when it isn't working Oct 25 20:49:32 hmm, i can do it tomorrow Oct 25 20:49:32 (share the output via a paste service like pastebin.com if you want my feedback on it) Oct 25 20:49:32 is there anyway to disable auto cape detection? Oct 25 20:49:32 asking for help here when you're not in the opportunity to test stuff isn't very productive **** BEGIN LOGGING AT Fri Oct 25 20:49:59 2019 Oct 25 20:49:59 trying to keep up with you ^^ Oct 25 20:50:11 just a sec Oct 25 20:50:15 pin info is on the way Oct 25 20:50:22 take your time Oct 25 20:51:22 oh I'm not sure if I said it out loud but the cape eeproms have i2c address 0x54..0x57 so it won't accidently talk to your i2c devices Oct 25 20:51:48 rcn-ee[m]: what do you mean by "abandoned", nobody is bothering to upstream them? :-) Oct 25 20:52:10 sorry Oct 25 20:52:32 web browser was sucks, need to open the chat on desktop app Oct 25 20:53:47 I can easily share a chat transcript so far if you want (since changing chat client will cause you to lose scrollback) Oct 25 20:54:28 @zmatt: would be awesome Oct 25 20:54:39 here is the show-pins output Oct 25 20:54:41 https://paste.ofcode.org/348aA2rg3sbVe8YBCf4vS6M Oct 25 20:55:37 bluePain: transcript: https://pastebin.com/8SGg1ugL Oct 25 20:56:28 and the overlay is on the way Oct 25 20:56:33 thanks! Oct 25 20:58:32 your overlay is missing pinmux for gpio 1.16 and 1.17 (it's technically optional for gpios since that's the default pinmux, but it's better to do it anyway to ensure it's right and to tell the kernel you're using those pins, and you've done so for other gpios) Oct 25 21:00:04 uhm Oct 25 21:00:05 yep Oct 25 21:00:09 I'm using libgpio Oct 25 21:00:27 so didn't care about the pinmux in the overlay Oct 25 21:00:50 how you access gpios is not really of any importance for pinmux matters Oct 25 21:01:18 actually I was thinking exactly same thing when I was writing my previous sentence Oct 25 21:01:55 I'll add them btw, but they work fine for now Oct 25 21:02:33 yeah like I said it's optional, just better to do it anyway Oct 25 21:04:27 I personally prefer the sysfs gpio interface since I can declare, name, and initialize my gpios in DT (https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi) and then use an udev rule to create symlinks (https://pastebin.com/YKW7Wcqu) so userspace can access gpios by intended use without having to know or care which gpio numbers those are, nor can userspace change a gpio to output when DT ... Oct 25 21:04:33 ...declares it to be an input Oct 25 21:04:50 I think the new interface is a major step back compared to that Oct 25 21:06:21 and here is the overlay Oct 25 21:06:27 https://paste.ofcode.org/vkFFjSpiqkRzvBvX2FR2fv Oct 25 21:06:38 sorry, it took sometime to pull it from git Oct 25 21:06:46 my internet is fluctiating Oct 25 21:07:02 i switched from sysfs to libgpio beacause of the speed Oct 25 21:07:06 ew does this paste service not have an option to view raw text Oct 25 21:07:14 can't go more than couple of hundreds mhz in sysfs Oct 25 21:07:32 *khz sorry Oct 25 21:07:59 I'm sorry for the paste service, my idiot country blocked the pastebin Oct 25 21:08:09 I'll try to find sth can show it in raw Oct 25 21:08:11 paste.debian.org ? Oct 25 21:08:17 bluePain_: teh compaitble, identifcation, exclusive-use at the start is for 3.8.x it does nothing. ;) Oct 25 21:09:08 :) Oct 25 21:09:13 bluePain_: ohhh, I confused libgpio with libgpiod Oct 25 21:09:30 you're using /dev/mem ... right Oct 25 21:10:41 not /dev/mem, you were right, libgpiod c&c++ wrappers Oct 25 21:11:13 and @rcn-ee[m]: sorry, this domain is also blocked Oct 25 21:11:19 gonna blow myself up Oct 25 21:11:31 need to run my vpn Oct 25 21:11:33 time to find a VPN .. :p Oct 25 21:11:37 then I wouldn't expect any real performance difference (assuming you just use a single call to write() or pwrite() per gpio write) Oct 25 21:11:47 bluePain_: you mean @me .. rcn didn't type the link Oct 25 21:12:11 ups, sorry, yeap @you :)) ^^ Oct 25 21:12:15 though what he says is true: the metadata in the overlay is ignored by u-boot (although it arguably shouldn't) Oct 25 21:13:17 http://bit.ly/341GRTD Oct 25 21:13:24 here is the raw version Oct 25 21:13:42 what use of gpios is performance-critical yet not timing-critical (since linux will still mess up your timing with interrupts... pru is the choice for tight timing) Oct 25 21:13:45 ? Oct 25 21:15:14 the *_pinmux { status = "disabled"; }; nodes are not needed btw since you don't have cape-universal enabled Oct 25 21:15:36 uhm, when I tried the sysfs, as I mentioned it couldn't go further than couple of hundred khz. but with libgpiod, I can go up to couple of Mhzs Oct 25 21:16:04 and I'm planning to switch some pins at around 1190 Khz Oct 25 21:16:15 from linux userspace? o.O Oct 25 21:16:19 to trigger one of our fpga boards Oct 25 21:16:29 kind of complex system ^^ Oct 25 21:16:57 bluePain_: pins thru the pru should be faster.. Oct 25 21:16:57 yeap :) from userspace. I could go up to 7 to 9 Mhz via /dev/mem Oct 25 21:17:37 pruss can toggle up to 100 MHz Oct 25 21:17:54 indeed a PRU application likely. Oct 25 21:17:55 if you use dedicate pru gpios ;) Oct 25 21:18:52 normal gpios are rate-limited by the gpio controller... I think 40 or 80 ns per write, would need to look up Oct 25 21:20:04 @rcn_ee[m]: definitely. but I've never worked with PRUs and didn't want to lose time with it Oct 25 21:20:23 why should I need to chanage my dns servers to connect to the FREE INTERNET?? Oct 25 21:20:48 gonna leave the country in next year ^^ Oct 25 21:21:09 whatever, here are the all ı have, pins, uEnv.txt and overlay Oct 25 21:24:56 And now online both mobile &desktop ^^ Oct 25 21:27:11 bluePainM: I'm really not seeing anything that could explain your problem, at all Oct 25 21:27:54 Hmm Oct 25 21:28:10 That's what I was afraid of ^^ Oct 25 21:29:51 And with the kernel 3.8.x, when I connect RTC chip on i2c2 it was not even booting Oct 25 21:30:52 you do have pull-ups on the i2c bus? Oct 25 21:31:23 I've my full debug environment in office, if you want sth in more detail, I can provide it tomorrow morning Oct 25 21:31:43 zmatt: yep, sure Oct 25 21:34:22 btw I just did a little test... calling write() with bogus args (to cause the kernel to return as early as possible) in a tight loop seems to require about 0.6 us/call, so unless libgpiod magically makes syscalls faster I don't see how it could toggle faster than that Oct 25 21:36:21 for sysfs gpio writes I'm measuring 2.7us per call Oct 25 21:36:40 I'll try that again with the oscilloscope connected to a pin tomorrow Oct 25 21:36:40 I do wonder wtf the kernel is spending those 2000 clock cycles on Oct 25 21:37:40 as for your problem with i2c2... I declare it a zmatt-certified mystery Oct 25 21:37:51 :) Oct 25 21:37:53 it's odd™ Oct 25 21:38:08 I'll reproduce it and let you know again Oct 25 21:38:26 Will you be available here tomorrow afternoon? Oct 25 21:39:07 I'm here often enough, specific times may vary depending on when I'm sleeping Oct 25 21:40:17 What's your tz btw? Asking to be able to catch you ^^ Oct 25 21:40:23 It's +3 here Oct 25 21:41:21 +2 here (CEST)... but that doesn't say much since my sleeping schedule can be pretty whack ;) Oct 25 21:41:47 you're definitely more likely to find me here at night than in the morning or early afternoon Oct 25 21:42:12 Ok then will try to catch-up with you tomorrow night ^^ Oct 25 21:42:22 Thx again! Oct 25 21:43:56 Should I use docker w/ Jenkins to find a way to test "nightly-ish" builds for source on this page: https://github.com/beagleboard/cloud9-examples/issues/11? Oct 25 21:44:50 I just did not get that much info. on that page. I am wondering exactly what is needed. Oct 25 21:55:26 Dang it. Sorry. Oct 25 22:23:40 Otay. Sorry for the go, go, go. I will have to "go" again but I can stay for now. yeh! Oct 25 22:24:11 Did anyone look at my two funny posts on github? I think I can do it but I will need more info. Oct 25 22:24:12 ... Oct 25 22:24:42 Info. = what images to test, what source to test, and what combinations and when? Oct 25 22:26:48 I can most likely test on both Win and Linux, i.e. not mac. Oct 25 22:26:50 No mac here. Oct 25 22:48:17 So, I guess I will need to use a debian/ubuntu distro and get docker/pytest/some other stuff and then deploy testing. Does anyone have any feedback to give? Oct 25 23:44:17 Up, up, and Otay! **** ENDING LOGGING AT Sat Oct 26 02:59:57 2019