**** BEGIN LOGGING AT Sat Feb 01 03:00:26 2020 Feb 01 06:15:29 Ooh. I got the video recorder to work. I just know nothing about avi or XVID. Feb 01 17:58:13 avi xvid .. yikes umm AVI is ancient and a POC by MS look at MKV or mp4 much better container formats Feb 01 18:20:23 and xvid is just an (encoder for) an mpeg-4 profile Feb 01 18:36:18 x264 better use ffmeg' Feb 01 18:58:08 Okay. Feb 01 20:29:15 look up mkv it has some great features' Feb 01 21:04:41 While I wait for my Google Groups post to be approved by the mods, thought I'd ask in here, too: I've a PocketBeagle running the most recent Debian 9.9 IoT, and updated according to bbb.io/upgrade. I've breadboarded a USB A host port onto USB1, and I can't seem to get any devices recognized at all. Feb 01 21:05:06 High-speed USB devices like wifi and ethernet report e.g.: [ 170.215041] musb-hdrc musb-hdrc.1: VBUS_ERROR in a_wait_bcon (89, probably you hooked it up wrong? Feb 01 21:05:23 Low-speed ones like keyboards report e.g.: [ 232.250630] usb 2-1: new low-speed USB device number 6 using musb-hdrc [ 232.378692] usb 2-1: device descriptor read/64, error -71 [ 232.618628] usb 2-1: device descriptor read/64, error -71 Feb 01 21:05:35 and/or the signal integrity is just too poor Feb 01 21:05:40 usb is not meant for breadboarding Feb 01 21:06:10 zmatt: yeah that's what I was wondering. The first time I wired it up, I did wire it up backwards, GND to VCC, D- to D+ etc., and I was wondering if I could have fried anything Feb 01 21:06:12 weird though that you're getting a vbus error in one case but not the other Feb 01 21:06:30 But also, yeah, there's like six inches of wire and breadboard between the PB and the USB port as well Feb 01 21:07:18 have you tested whether that device (the one you hooked up with VCC and GND swapped) still works in other hosts? Feb 01 21:08:03 yeah, all the devices continue to work in other hosts. the other weird thing is a powered USB hub doesn't register at all. no errors, nothing, it's like I'm not plugging anything in at all. Feb 01 21:10:58 lemme check again which pocketbeagle pin is what Feb 01 21:13:29 I'm wired up like this: https://i1.wp.com/www.teachmemicro.com/wp-content/uploads/2018/03/pocketbeagle-usb-type-a.jpg Feb 01 21:28:38 yeah that should work, or at least jkridner said it did and musb indeed seemed to be okay with lack of 5v power switch these days (I'm pretty sure it wasn't a few years ago).... though I personally disagree with using P1.07 as 5V supply, I would recommend using VOUT (P1.24 or P2.13) instead of P1.07 Feb 01 21:31:17 Vito`: so, just to elaborate on the potential for signal integrity issues, TI has a document on how to design the connection from AM335x to USB connector: http://www.ti.com/lit/an/sprabt8a/sprabt8a.pdf Feb 01 21:31:24 you should read it for fun ;) Feb 01 21:31:54 of course that doesn't mean it can't be made to work with a more questionable setup, but it may be luck-dependent Feb 01 21:32:37 I would definitely try to minimize the amount of crap between the connector and the pocketbeagle Feb 01 21:33:10 okay, so if I want to try the first thing you said, I'd instead jump a VOUT to P1.05 and use that as my VCC line? Feb 01 21:33:42 and then I can see about wiring the USB port directly in Feb 01 21:34:25 yeah, but that recommendation is kinda independent of the issues you reported, I don't expect it to improve things for you Feb 01 21:34:57 ah, okay Feb 01 21:35:32 alright, well, if you don't think I fried my USB1 entirely, I'll try directly attaching the USB port Feb 01 21:35:33 the main reason to use VOUT instead of P1.07 is to ensure the 5V is cut if you shutdown the pocketbeagle (without disconnecting it from its 5V supply) Feb 01 21:35:52 it is entirely possible you did Feb 01 21:36:05 oh Feb 01 21:36:30 well I guess I should order another PocketBeagle to be safe then as well Feb 01 21:37:12 swapping 5V and GND may have exposed the D+/D- pads to basically any voltage between 0V and 5V when you connected a device, due to protection diodes Feb 01 21:37:33 and needless to say, exposing them to 5V would be bad Feb 01 21:39:26 if you do use P1.07, I recommend avoiding shutting down the pocketbeagle, just cut power instead (which unfortunately isn't great advice for the health of your SD card) Feb 01 21:40:19 (regardless of what 5V supply is used, P1.05 needs to be connected to monitor it) Feb 01 22:02:15 ah hm Feb 01 22:03:11 welp, guess I'll find out for sure when the new one gets here Feb 01 22:03:23 thanks for sharing that about power, I hadn't seen that written up anywhere else Feb 01 22:05:26 yeah the problem with using P1.07 (which is just the 5V input directly from the micro-USB connector) is that it's "always-on", it won't get cut if you shut down the pocketbeagle Feb 01 22:07:05 so if you'd shut down the pocketbeagle, your downstream device will continue to see VBUS, hence it will continue to pull D+ or D- up, which exposes the corresponding pin of the AM335x to overvoltage Feb 01 22:09:26 (note that some crappy self-powered devices such as cheapass hubs will do so regardless of whether VBUS or present or not, in violation of the USB specifications. such devices will always pose a risk if connected to a host that's shut down. see also the case of some macbooks getting fried if you put them into suspend while having a particular brand of crappy usb hub attached to them) Feb 01 22:16:00 noted Feb 01 22:16:13 appreciate the advice! Feb 01 22:18:16 (in that case it was also combined with backpowering 5V via vbus to the host, which 1. is absolutely forbidden 2. makes vbus detection impossible hence guarantees it will also continue to pull up D+ (or D-) even if the host is powered off) Feb 01 22:21:51 GenTooMan: I wonder if the BBAI image includes the necessary stuff for the hardware video en-/decoding Feb 01 22:34:52 how would you know? it would be in the kernel compile details correct? Feb 01 22:35:46 ehh, I guess there's probably *some* kernel component to it, not sure Feb 01 22:37:46 but if there is, including that would be the trivial part and doesn't really mean anything Feb 01 23:33:00 well it would have to have kernel supported no? http://www.ti.com/processors/digital-signal-processors/libraries/am57x-video-codecs.html thats all I could find Feb 01 23:36:43 http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_Multimedia_IVAHD.html is the main documentation Feb 01 23:37:34 like, the only kernel components are those used for IPC, and I know those are included with the bbai image since they're also used for TIDL Feb 01 23:38:45 it also includes an ipu2 firmware image, so assuming that's the one for iva-hd support, the only question would be the userspace components Feb 01 23:39:19 and possibly the codecs if those are not embedded in the firmware image Feb 01 23:47:25 I remember no drivers were released for Linux at first for the first beagle board because of the DSP and video CODEC. Then only a TI built kernel had support for CODEC. Feb 01 23:49:28 I don't know anything about those old drivers Feb 01 23:51:31 but I don't see any reason for the kernel nowadays to have a special driver for them, nor does the documentation available suggest that this is the case Feb 01 23:53:12 or maybe some tiny component that mostly has to do with memory mapping (dma-buf) and message passing via rpmsg, but that would presumably be part of TI's linux kernel branch (if not mainline), which is what rcn's -ti series kernels are based on Feb 01 23:56:13 https://cateee.net/lkddb/web-lkddb/OMAP_REMOTEPROC.html yeah, that one (it depends on "ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX" in TI's kernel but I guess the "|| SOC_DRA7XX" hasn't hit mainline yet) Feb 02 00:09:34 interesting... Feb 02 02:08:29 Hello, I want to find a specific Linux 4.4.10 and load the official released (if available) on a beaglebone black. Can someone give me a good pointer to begin with? Feb 02 02:09:28 I already looked through the list at https://beagleboard.org/latest-images and most look either 3.8 or 4.9 (unless I am mistaken!) Feb 02 02:28:18 Found github tree at https://github.com/beagleboard/linux/tree/4.4 Feb 02 02:30:06 Last update on that around June 2019. That may be better than 4.4.10! Now looking for kernel upgrade instructions. Most likely, will begin with 3.9 and then upgrade. Hope there are no gotchas there.. :-) **** ENDING LOGGING AT Sun Feb 02 02:59:57 2020