**** BEGIN LOGGING AT Fri Jan 15 02:59:57 2021 Jan 15 03:05:43 typcically the red and black are vcc and gnd and on the 2 outside edges of the connector Jan 15 03:06:17 white and green are the data+ and data- Jan 15 03:06:57 the neg data pin on the connector will be next to the grn(black) Jan 15 03:08:38 so if you were looking down on a board mount connector from the top with plugable opening in the connector facing down Jan 15 03:09:04 it would be starting from the left black/green/white/red Jan 15 03:09:50 thats typically the way ive seen them but to be honest ive never verified if the bbb's followed the same standard tho Jan 15 03:12:25 crap... sorry thats looking at it face up so what i said above should have been red/white/green/black Jan 15 03:14:43 brb gotta reboot Jan 15 03:44:31 thanks buzz Jan 15 03:45:27 why would they have a bare copper wire in the cord as well Jan 15 03:46:40 also is data+ send? Jan 15 05:41:26 kjjj Jan 15 13:23:34 suppose you have a device that does not communicate in a certain state but is attached to the system. what would be a good way of probing it for a chip-id but being tolerant of it not responding. Jan 15 13:24:05 that question is way too vague to be meaningful Jan 15 13:24:53 hmmm not sure how to narrow it down, it's more of a best practices question. Jan 15 13:24:55 like, being tolerant is mostly a question of how software handles the error case Jan 15 13:25:14 yea, thats mainly what i was asking. Jan 15 13:25:26 then I still don't get your question Jan 15 13:26:02 like... what's a good way of being tolerant to it? .. ehm, by being... tolerant to it? Jan 15 13:26:26 alright, should I ignore chipid request, or should i pollwork requesting it until it responds? Jan 15 13:26:53 how should I know what makes sense in your application? Jan 15 13:27:13 haha k Jan 15 13:27:28 like, error handling has no generic answer Jan 15 13:31:15 is there a way to stop the _probe process while a poll_worker searches for the id...? as in, initialize up to a point, create a poll worker, keep requesting chip-id till a timeout, then if found, continue initializing? Jan 15 13:31:32 ah you're talking about a kernel driver Jan 15 13:32:35 why is your device so broken? like, why does it not respond? it doesn't make much sense for it to be "busy" since the driver hasn't even been loaded yet. is it still starting up? Jan 15 13:33:24 it uses an internal regulator to power up it's i2c core, but that regulator isn't fed until you plug in power, not just battery Jan 15 13:33:45 only an issue if the device has no power, then you put in the battery for the first time. Jan 15 13:34:58 hmm.. is there no way to get notified when power is available, instead of polling? Jan 15 13:35:56 also I assume probe isn't the only problem, if your device is going to be entirely unresponsive... maybe there's some way to make it appear to hotplug, dunno Jan 15 13:36:04 there is, but I would like to test on startup rather than waiting to be plugged in. escpecially since the battery is left in and it will only come up when replacing it. Jan 15 13:36:38 then why not just block on it Jan 15 13:36:39 :P Jan 15 13:37:18 does the kernel go off to do other things if you block a probe function? Jan 15 13:37:30 or maybe you can use EPROBEDEFER and then later trigger whatever mechanism causes devices that use that to get reprobed Jan 15 13:37:54 EPROBE_DEFER I mean Jan 15 13:38:37 in returning that, how could I reschedule it? Jan 15 13:41:08 normally it gets rescheduled when any other device has been successfully probed Jan 15 13:41:50 if you want to dig around in its implementation to see if you can abuse it for this purpose check drivers/base/dd.c I guess Jan 15 13:41:56 hmm, so being plugged in to power an hour after startup may not trigger it? Jan 15 13:43:16 but, if your device is non-responsive any time power isn't plugged in, presumably your driver needs to cope with that anyway, i.e. it just shouldn't require the device to be responsive Jan 15 13:43:27 I think then I will ignore the detection, but callout hw init routines on successfull read within the poll worker. till that point have all values from the device read back 0 Jan 15 13:44:05 (and ideally use some kind of notification to know when power is plugged in or removed rather than polling) Jan 15 13:44:34 like, do you not communicate with the device at all anymore after initialization? that seems implausible to me Jan 15 13:45:06 that functionality is from a different driver, so i think i will just have the poll loop with long times until it gets a response Jan 15 13:45:27 then reduce poll time to once a second Jan 15 13:45:37 or if you need this identification to proceed, can't you put it in DT instead? Jan 15 13:45:43 it's a battery charger so not that important Jan 15 13:45:48 okay, well I have no idea what you're doing but it sounds like a mess :) Jan 15 13:46:10 its that whole rewrite of the terrible bq25700 driver Jan 15 13:49:19 so why are you not able to communciate with it? that doesn't make sense, it should be reachable via i2c when battery OR input power is present Jan 15 13:50:53 in fact the data sheet makes it clear that that's the case Jan 15 13:51:12 e.g. you can monitor battery discharge current via i2c Jan 15 13:52:09 and enable OTG etc Jan 15 13:52:57 im working on the bq25710 Jan 15 13:53:23 it's in some sort of deep sleep i think until connected to AC Jan 15 13:53:38 sorry AC-> Vin Jan 15 13:54:37 you mean its VBUS input? Jan 15 13:55:02 anyway, it supports OTG which requires the ability to communicate with it while on battery power Jan 15 13:55:18 sorry but you must be missing something Jan 15 13:56:20 yes, what i was trying to say is that when it is completely off, and you first plug in the battery it is in a low power state where it's internal ldo is off. it will get out of this state once connected to vbus. Jan 15 13:57:00 yet it powers the device in this state? Jan 15 13:57:21 yes, there is a fet with a body diode passing the current Jan 15 13:57:28 no ldo required Jan 15 14:00:36 I don't see anything in the datasheet about i2c being unavailable in that mode though.. if true it sounds deeply braindead Jan 15 14:03:08 hmm, time to break out the scope Jan 15 14:03:47 looking at the driver in chromiumos, it seems to keep the chip in low-power mode unless it needs performance mode for something Jan 15 14:04:02 https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/master/driver/charger/bq25710.c Jan 15 14:04:15 I don't see any hint of the behaviour you're describing Jan 15 14:05:58 I'm pretty sure i2c is supposed to work even in low power mode.. it would be completely outrageous if it didn't Jan 15 14:07:01 now that doesn't say everything, chips can and sometimes do have outrageous behaviour, but then I'd expect a big warning in the datasheet and/or a dozen posts about it on E2E Jan 15 14:07:04 :P Jan 15 14:08:06 yea, gunna probe into that now. i do have a lot of devices on that line Jan 15 14:08:23 4 seperate chips Jan 15 14:10:36 btw, if i recompile kernel and modules, is there something that happens on first startup that causes module drivers not to load the first time. as in, i have to reboot before the drivers come up. Jan 15 14:10:58 uhh no, never heard of that Jan 15 14:12:12 you should run depmod and rebuild your initramfs (if you use that) after replacing kernel or updating modules (if you're building a .deb and installing that then that should happen automatically) Jan 15 14:12:24 but failure to do so wouldn't be fixed by a reboot Jan 15 14:12:46 you have the strangest problems :P Jan 15 14:13:14 nagh, i have make, make modules-install, make dtbs-install and copy zimage to sd card going Jan 15 14:13:28 ugh Jan 15 14:13:45 sounds annoying Jan 15 14:13:57 It's a specialty. also since compile takes a while, i added ;paplay sometrack.wav to alert me, that part works great. Jan 15 14:14:23 I mean, normally it'll of course only recompile files you modified Jan 15 14:15:05 yea, still a few minutes though Jan 15 14:15:31 o.O Jan 15 14:15:33 why? Jan 15 14:15:37 ohh its in a vm on a i5... also think i haven't turned on multiple core compile Jan 15 14:16:30 if you'd use rcn's build repo that would be taken care of... and minutes still sounds like an unreasonably long time to recompile the kernel after a small change Jan 15 14:17:09 i actually am not tweaking the kernel, its to the driver included as a module Jan 15 14:17:56 i.e. even less time to take.. and you could just rsync the module, depmod, and reboot (get rid of initramfs to avoid having to rebuild it) Jan 15 14:18:51 hmmm, i may try that next. Jan 15 14:19:06 could i chroot, then depmod? Jan 15 14:20:38 I normally just transfer to the running system and reboot it, I basically never boot from sd card. when I was doing some work in the kernel I nfs-exported the output dir where rcn's build scripts put the .deb and had an automount for that on the beaglebone so I could just dpkg -i /path/to/kernel.deb && reboot Jan 15 14:21:22 cd et Jan 15 14:21:30 hahha, oops wrong window Jan 15 14:24:52 so to make just the module it would be "make module.o" ? Jan 15 14:30:16 or is it .ko.. i think it's ko Jan 15 14:47:42 jkridner[m], any recommendations on the type C supply used for beaglev ? Jan 15 16:16:08 this depmod approach is so much faster, Thank you! Jan 15 16:37:16 say i have a regmap that has lots of individual bits in the same register. is there a way to pull values for each named map point without reading the same register over-and over? Jan 15 19:37:14 alright, now i'm confused. How the hell do you reference a interrupt= <> in the dt from a kernel driver? Jan 15 19:37:40 I keep finding examples that work, but seem to reference custom named pins. Jan 15 21:22:19 Konsgn: platform_get_irq() Jan 15 21:23:24 or platform_get_irq_optional if it is not desired to have an error in the kernel log if the irq is missing Jan 15 21:23:38 not irq_of_parse_and_map()? Jan 15 21:24:06 if you have multiple irqs then looking them up by name is recommended, platform_get_irq_byname() or its _optional variant Jan 15 21:24:09 never heard of that function Jan 15 21:24:13 alright, lemme try that Jan 15 21:26:09 would platform device be the driver device? Jan 15 21:27:04 oh right you're an i2c device, not a platform device.. uhh, hmm.. Jan 15 21:28:15 looks like the i2c layer will do the lookup for you and stick it into the struct i2c_client * passed to your probe Jan 15 21:28:39 client->irq Jan 15 21:28:54 (which you then request with devm_request_threaded_irq() typically) Jan 15 21:32:25 what about the IRQ flags, can i say null if they are defined in DT? Jan 15 21:34:11 iirc threaded irq handlers should pass IRQF_ONESHOT but I don't think other flags are needed Jan 15 21:35:49 (of course if you don't need a threaded irq don't use it, but if you want to do i2c transfers in response to the irq you'll have to) Jan 15 21:37:02 yup, thats what i'm tryin to do, thanks for the help Jan 15 21:42:49 whelp with how quickly it recompiles, the paplay is not very helpful now. Jan 15 21:43:05 lol Jan 15 21:48:14 do i need a workqueue allocated before requesting threaded irq? Jan 15 21:48:20 no Jan 15 21:49:23 cool Jan 15 22:00:51 Thanks for all the help zmatt, irq is working... i think at least there's no kernel panic woo! Jan 15 22:46:38 oooh i need to make more educational material Jan 15 22:46:43 wanna do something with device tree, maybe tomorrow Jan 15 22:46:48 then do a post on file system Jan 15 22:46:56 then we do py-uio!.. but i'm gonna have to prepare for that Jan 15 23:11:58 Nice...I hope it goes well. **** BEGIN LOGGING AT Fri Jan 15 23:21:53 2021 Jan 15 23:58:04 TGIF Jan 15 23:58:18 every week in the US feels like 6 months LOL Jan 16 00:18:26 what is /root Jan 16 00:20:13 the homedir of all evil Jan 16 02:40:41 back Jan 16 02:41:04 anyone ever heard of a /root/ directory Jan 16 02:41:07 ? Jan 16 02:42:18 * vagrantc blinks Jan 16 02:42:33 I have heard of the root/ dir! Jan 16 02:43:00 well, there's /root, which is the same as /root/, although the "/" directory is sometimes called "the root directory" Jan 16 02:43:26 i ask because apparently my camera has one Jan 16 02:43:34 some back story Jan 16 02:43:42 i am using a basler camera Jan 16 02:43:47 with the bbai Jan 16 02:44:12 got it working or at least recognized by the pylon software Jan 16 02:44:43 so when I try to snap a pic i get this error about a file in the /root/ directory being corrupted Jan 16 02:44:57 i could not find the file on the beagle Jan 16 02:45:10 that is why i am confused and posted such a rediculous question Jan 16 02:45:33 usually if it is root it is just / but this was saying /root/filename is corrupted Jan 16 02:46:22 mount it! Jan 16 02:47:13 hmmm Jan 16 02:47:19 i can try i guess Jan 16 02:48:39 Now, I am obviously not messing w/ pylon or a basler camera. Jan 16 02:48:57 I know nothing of either. Jan 16 02:49:02 Off to research. Jan 16 02:50:15 thanks set Jan 16 02:50:17 So, it takes photos of CMOS up close. Nice. Jan 16 02:50:29 yeah it is a sweet computer vision camera Jan 16 02:50:33 Oh. Jan 16 02:50:44 so perfect for the ai Jan 16 02:50:58 but this whole no screen no usb3 thing was an issue Jan 16 02:51:55 Right...I am on a site, digikey, and they are showing basler cameras. I will pop open a datasheet and see what they say about one or another. Jan 16 02:52:15 Does the AI recognize the camera? Jan 16 02:52:25 yes Jan 16 02:52:51 first i got an error about my usb running out of memeory Jan 16 02:53:05 then this new error about a cache file being corrupted Jan 16 02:53:14 in that /root/ directory Jan 16 02:54:55 BCON or Dart? Jan 16 02:55:23 Oh. clear the cache. It may be using too much memory. Jan 16 02:57:05 how do you do that Jan 16 02:58:26 I do not remember. Let me go and check again. Jan 16 03:00:06 mattb000ne: Here >>> https://www.tecmint.com/clear-ram-memory-cache-buffer-and-swap-space-on-linux/ <<< easy to read **** ENDING LOGGING AT Sat Jan 16 03:00:36 2021