**** BEGIN LOGGING AT Fri Dec 18 02:59:56 2020 Dec 18 03:00:04 Ha. Dec 18 03:00:34 Anyway, I was using ubuntu instead of debian to cross-compile. Dec 18 03:00:36 Oops! Dec 18 03:01:00 libm.so is not what it was supposed to be... Dec 18 03:01:32 So, off to erase everything this ubuntu distro is about and off to install the debian distro of my state of mind. Dec 18 03:01:58 I finally figured out the dang sftp stuff. Not fun. Dec 18 03:02:10 Now, onto the fun part. "Debugging!" Dec 18 03:02:42 * boinkers mattb00000ne! Dec 18 03:03:21 mattb00000ne: Did you ever figure out that Cape stuff w/ the things and stuff? Dec 18 03:03:45 For the BBAI? Dec 18 03:22:55 took a break may mess around this weekend Dec 18 03:59:14 Oh. I finally compiled that oh-so-nice cross-comp. on the BBB. Phew. It was getting close. Dec 18 04:00:43 I think it was just the glibc_2.29 on Ubuntu. It worked fine w/ glibc_2.28 which has libstdc++.6.0.25 and not libstdc++.6.0.28 like Ubuntu. Dec 18 04:01:01 It took long enough. Dec 18 04:01:03 Sheesh. Dec 18 04:01:12 debugging up next! Dec 18 04:01:30 oops. 10:00! Dec 18 15:23:12 hmmm, my device fails here https://github.com/torvalds/linux/blob/master/drivers/mfd/tps65217.c#L122 when the USB is unplugged or plugged in whilst the device is asleep (/sys/power/state = mem) Dec 18 15:23:22 anyone any clues as to why that would fail? Dec 18 15:24:17 set_: nothing you said makes any sense. what are you cross-compiling and why? using ubuntu or debian for cross-compilation shouldn't matter much (though using a newer system than the one you're targeting might give issues unless you're using a sysroot, which you're probably not) Dec 18 15:24:59 TonyTheLion: so the usb plug/unplug triggers a wakeup from sleep? Dec 18 15:25:15 it does not, you get the error when you manually wake it Dec 18 15:25:35 hmm Dec 18 15:25:45 I want it to, but it does not. It seems to fail to read that register, and I suppose that is why it doesn't wake Dec 18 15:25:47 what's the error code? Dec 18 15:25:56 as the interrupt handler fails Dec 18 15:25:58 no, that statement makes no sense Dec 18 15:26:14 the interrupt handler never runs if it doesn't wake Dec 18 15:26:34 since nothing is running at all until it's awake :P Dec 18 15:26:54 so those are separate questions: why doesn't it wake? once it wakes, why does it fail? Dec 18 15:27:27 lets try to figure out the latter Dec 18 15:27:33 16:25 <@zmatt> what's the error code? Dec 18 15:27:33 going by what you said earlier Dec 18 15:27:43 I need to get it Dec 18 15:28:03 -13 is the error code Dec 18 15:28:10 when you ask advice about an error, you should really have included it right away in the question Dec 18 15:28:39 "tps65217 0-0024: Failed to read IRQ status: -13 Dec 18 15:28:46 is the error Dec 18 15:28:53 EACCES .. wtf Dec 18 15:30:14 ok let's see where that can come from Dec 18 15:30:36 my intuition is that it is a timing issue, irq handler running before the system is ready to perform the i2c transfer of something Dec 18 15:30:48 *or something] Dec 18 15:35:42 no results for EACCES in regmap, i2c core, or the mfd/tps65217 or i2c-omap drivers :/ Dec 18 15:36:28 the github link is the line where the driver fails Dec 18 15:36:34 I guess that's of no help here Dec 18 15:36:51 it's where I started tracing for a root cause Dec 18 15:37:00 hmmm Dec 18 15:37:27 also, just in case it's generally better to examine the source for the actual kernel version you're using rather than the mainline master branch :P Dec 18 15:38:11 e.g. https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.19.94-ti-r50/ Dec 18 15:41:45 you're absolutely sure it's -13 ? Dec 18 15:42:06 yep Dec 18 15:42:57 my kernel is built from this https://github.com/RobertCNelson/bb-kernel/tree/am33x-v5.9 Dec 18 15:43:35 oh you're running a weird kernel version, you should have mentioned that earlier :P Dec 18 15:44:01 its not my day apparently, hahah Dec 18 15:44:11 why are you running that version? Dec 18 15:44:44 because its the almost latest one Dec 18 15:45:11 and what's the benefit of that over a version that's actually stable and supported? Dec 18 15:45:19 and has all drivers needed Dec 18 15:46:02 like, I have no idea if this branch is even tested on actual beaglebone hardware.. it's almost certainly not used by anyone (or anyone else I should say) Dec 18 15:46:03 so what would you recommend I run then?# Dec 18 15:46:33 I'm open to changing Dec 18 15:46:37 what's the reason to not run the default kernel? Dec 18 15:47:10 since we've determined you don't need a custom driver in the first place (unless you were already building a custom kernel for other reasons) Dec 18 15:48:51 like, unless you really want to be an alpha-tester and/or feel confident in solving kernel-related problems yourself, I'd stick to the 4.19-ti series currently Dec 18 15:49:05 we had other hw issues, which I think is the reason we wanted to make sure were running the latest kernel Dec 18 15:49:29 the latest recommended kernel is 4.19-ti Dec 18 15:49:38 (whatever is the latest within that series) Dec 18 15:50:11 so the bb-kernel repo is an unstable untested repo Dec 18 15:50:26 the next stable series will be 5.4-ti Dec 18 15:51:26 I see Dec 18 15:51:36 the bb-kernel repo is basically mainline + custom patches, while the -ti kernel series is those same patches applied to TI's kernel repository (which only has branches for LTS releases) Dec 18 15:52:28 so possibly rcn uses the bb-kernel series to maintain and forward-port the patches to newer kernels before applying them to the TI series, but I'm not sure Dec 18 15:52:51 the -bone series (bb-kernel) used to be the default kernels a long time ago, but the -ti series has been the default fo quite a while Dec 18 15:52:52 ah, I did not kwow that Dec 18 15:52:57 know* Dec 18 15:53:42 so -bone kernels are closer to mainline while -ti kernels generally have better support for the SoCs, e.g. more power management features or drivers that haven't reached mainline yet Dec 18 15:56:46 can you retest with the latest 4.19-ti kernel? Dec 18 15:57:24 that is my plan Dec 18 16:21:16 missed your hardware as i just logged in not to long ago but can say i have 5.10 running on the black as i am creating a custom kernel and its taken a few patches to get it right and would suggest zmatt's probably right in saying its best to stick to whats tested unless you like playing around a fair bit Dec 18 16:22:03 5.4-ti is pretty good as well if your looking at the move up to 5 Dec 18 16:22:04 even when customizing it's probably safer to start with a well-tested base version Dec 18 16:22:39 ive done custom kernels for over 20 years but zmatt's definately right Dec 18 16:23:29 especially since TonyTheLion seems to be using suspend, and power management stuff has at least historically been much more limited on mainline than in the TI kernels.. dunno what the current state is, maybe it's all been upstreamed Dec 18 16:24:51 how do you know if a kernel is well tested for your SoC Dec 18 16:25:39 well, you can generally expect the default kernel on the default image that's recommended for new users to be relatively well tested Dec 18 16:26:00 but to upgrade I am assuming kernel updates faster than the images ? Dec 18 16:27:31 not really? unless you include minor updates within the same kernel series (which should generally be fine) Dec 18 16:29:03 major LTS kernel releases are about once a year Dec 18 16:29:27 ok Dec 18 16:30:58 (date of first mainline release of last few LTS kernel series: 4.9 dec 2016, 4.14 nov 2017, 4.19 oct 2018, 5.4 nov 2019, 5.9 oct 2020) Dec 18 16:34:09 but for the beagle images I have now the kernel is like 4.14 Dec 18 16:35:16 then either you're using an old image or you're using a TIDL image for the bbx15/bbai Dec 18 16:35:38 (which still require 4.14 for some reason) Dec 18 16:41:47 you are right Dec 18 16:41:51 just checked on my black Dec 18 17:01:16 I'm not sure what tag to pick from that linux-stable-rcn-ee Dec 18 17:01:23 repo Dec 18 17:01:56 4.14.209-bone41 is that a stable kernel? Dec 18 17:02:39 I'll use https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.19.94-ti-r50/ Dec 18 17:06:03 Hi Dec 18 17:06:37 What is password to access root account in beaglebone black? Dec 18 17:07:51 temppwd? Dec 18 17:08:09 that's for "debian" user. not working for root Dec 18 17:08:24 no pass i think. do sudo su Dec 18 17:08:33 no pass i think. do "sudo su' Dec 18 17:08:36 Kalpit: use sudo Dec 18 17:08:49 Konsgn: please don't use "sudo su" Dec 18 17:08:51 Cool Dec 18 17:08:58 that pointlessly opens a su session inside a sudo session Dec 18 17:09:02 'sudo su' worked Dec 18 17:09:08 use "sudo -i" Dec 18 17:09:14 to get a root login shell Dec 18 17:09:23 (or "sudo -s" to get a root shell in the current directory) Dec 18 17:09:25 haha, i use it regularly when doing things like echo "some control enable" to dynamic debug Dec 18 17:09:43 that's when i needed Dec 18 17:09:52 Konsgn: it just pointlessly creates a session inside a session Dec 18 17:09:53 thanks Konsgn Dec 18 17:10:38 hugh, didn't know of sudo -i, interactive i assume. Dec 18 17:10:48 Konsgn: sudo -s does the same as "sudo su" but without the pointless use of su Dec 18 17:11:02 though if you want a fresh login shell then -i is better Dec 18 17:11:41 (functionally similar to "su -l") Dec 18 17:22:35 comparison of the processes resulting from sudo -s/-i vs sudo su: https://pastebin.com/raw/iXjJvMSD Dec 18 17:23:20 I also noticed that a login shell (sudo -i or su -l) prints "logout" instead of "exit" when you exit it using control-D .. never noticed that before Dec 18 17:24:46 what the hell is that option for ps? Dec 18 17:25:40 f = tree output, T = select processes associated with this terminal, h = no headers, -O user = show basic info + user Dec 18 17:26:30 well thats a new use for ps I haven't seen Dec 18 17:26:34 the commandline options for ps are fairly bewildering Dec 18 17:26:36 cool! Dec 18 17:26:58 zmatt: especially when the same tool accepts both bsd and sysv options Dec 18 17:27:07 uhuh Dec 18 17:27:14 got my stripped Bq25710 driver working... now to integrate it with tcpm Dec 18 17:27:25 mru: and I think my invocation uses a mix of them ;) Dec 18 17:27:36 even more fun Dec 18 17:31:50 should I be trying to rewrite the musb code to allow it to be tied into the tcpm core, or should I just try to get control over that from userspace? Dec 18 17:32:29 namely, the BC detection of the core could be of use as the fusb302 cant detect that. Dec 18 19:31:03 also, are there user accessable ways to control the musb driver? I cant seem to find ways of forcing sessions to start though the manual seems to imply that possibility Dec 18 19:53:38 it seems that there is an srp that can be triggered to detect the id pin state and start a session? Dec 18 19:56:53 sooo from what I'm reading it seems that the srp is used to trigger session start as peripheral, and soft_connect is used to re-initalize usb devices as host port. Dec 18 20:06:52 Also it seems there is some sort of pull down on the vbus pin, it measures 4.05V with a 10k pullup to 5v, and DevCtl still shows 0x19 Dec 18 20:20:28 oooh, nother intesting question, at what point and where does g_gadget get loaded from. figured out how to reset the port by doing echo 0/1 to the sys/bus/usb2/authorized. Dec 18 21:35:46 anyone know that the typicall current drain of the usb-vbus line is? Dec 19 00:37:26 Here come the loops and arrays! Dec 19 01:35:23 life of disarray? Dec 19 01:42:27 mostly. These things are pissin' me off. Dec 19 01:42:55 I have to install some items for numpy already. They have super arrays! Dec 19 01:43:31 I was getting an issue w/ so.3 onboard the BBB b/c of the lack of it being on the board. Dec 19 01:52:43 "arrays are 0-dimensional" Dec 19 01:52:44 Blah. Dec 19 02:08:35 wtf is that quote from? Dec 19 02:09:42 Oh. Dec 19 02:09:44 That... Dec 19 02:10:09 I tried to promote an array w/ numpy and received some odd arrays are 0-dimensional as output. Dec 19 02:10:26 I figured it out, though. Dec 19 02:11:07 sounds like you're stuffing a scalar into something that wants an array (more specifically, one that isn't 0-dimensional :P ) Dec 19 02:12:36 But, all in all, the reason I received the error was b/c of the fact that some lib. was not included w/ the numpy lib. Dec 19 02:13:42 They just leave it out of their repo. when installing it. I am working in a venv right now b/c of PYTHON/PIP and I have to use pip3 to install numpy in the venv. Dec 19 02:14:24 pip3 install numpy did not have some library as an add on and the BBB did not come w/ it onboard already. Dec 19 02:15:15 just use the --system-site-packages option when creating your venv so it has access to packages already installed on the system such as numpy Dec 19 02:17:22 Oh. I thought that only works w/ pip3 installs? Dec 19 02:17:30 ?? Dec 19 02:17:31 I mean... Dec 19 02:17:43 Does it work w/ apt install some_package too? Dec 19 02:18:02 Okay. I understand now. Dec 19 02:18:08 I got you. Dec 19 02:19:50 Arrays are complicated. There are so many different options in the numpy lib. Dec 19 02:23:09 --system-site-packages gives the venv access to all packages you're able to access outside the venv (in addition to those installed inside the venv) Dec 19 02:25:07 i.e. those installed for the current user (e.g. with pip3), system-wide packages not managed by apt (e.g. the Adafruit_BBIO installed by default on the BBB IoT images), and packaged installed using apt (e.g. numpy by default on the IoT images) Dec 19 02:26:01 Nice. Dec 19 02:26:17 --system-wide-packages >>> nice! Dec 19 02:26:54 (you can also change the setting after creating the venv by modifying the pyvenv.cfg file that's in the venv's directory) Dec 19 02:27:32 Okay. Dec 19 02:27:34 Thank you. Dec 19 02:32:17 Oh, nice. Dec 19 02:32:28 I see how easy that actually is now that I checked it out. Dec 19 02:34:27 the pyvenv.cfg file is either false or true in that context. Nice. **** ENDING LOGGING AT Sat Dec 19 03:00:07 2020