**** BEGIN LOGGING AT Wed Aug 30 03:00:00 2017
Aug 30 08:56:37 <bfederau> zmatt: I have set the resolution in the video kernel parameter and the fbset command shows the correct resolution. When I set the QT_QPA_EGLFS_INTEGRATION to none Qt detects the 1366x768 (my debug output) but the QML app is painted over the  edge of the display. This means some parts on the right side of the app are not visible.
Aug 30 08:57:43 <bfederau> thanks for the link to the repo. I will have a look.
Aug 30 09:08:27 <zmatt> how sure are you that 1366x768 is really the resolution of that display?  if forcing that resolution results in clipping and 1280x720 is the auto-detected resolution, then it sounds to me like 1280x720 actually *is* the display's resolution
Aug 30 10:44:57 <cyberguy> Hi all,my platform is BeagleboneBlack i need to reponse to a GPIO input (from low to high) in 40ms , is it possible to use interrupt at user space?
Aug 30 12:12:21 <zmatt> yes, write 'rising' to the "edge" attribute of the gpio in sysfs, open the 'value' attribute and use select(), poll(), or epoll to receive the notification
Aug 30 12:13:52 <zmatt> on rising edge, a POLLPRI event gets sent to the fd
Aug 30 12:15:22 <zmatt> it is also possible to deliver irqs to userspace using uio_pdrv_genirq
Aug 30 12:16:39 <Catslab> hi here
Aug 30 12:17:42 <Catslab> what's the best kernel version from Robert's repo in order to use PRUs and Qt5 ?
Aug 30 12:18:02 <zmatt> kernel version is irrelevant for qt5
Aug 30 12:18:54 <Catslab> zmatt: yep I know
Aug 30 12:19:04 <zmatt> then why did you include it in your question?
Aug 30 12:19:38 <Catslab> because you know what I want to do and I read some distributions already included Qt
Aug 30 12:19:43 <zmatt> for prus, enabling uio-pruss or remoteproc-pru used to be a hassle for some kernel versions, but if you use a recent one + recent u-boot it has become quite easy
Aug 30 12:19:52 <zmatt> distribution != kernel
Aug 30 12:20:17 <Catslab> it's about 2 years I did not touch the BBB, last time I was compiling 3.14 and patched for prus
Aug 30 12:21:16 <zmatt> any 4.x-ti or -bone kernel should be fine.  I'm using 4.9-bone series myself currently
Aug 30 12:21:26 <Catslab> ok thanks
Aug 30 12:21:46 <Catslab> do you write code in C or asm for prus ?
Aug 30 12:22:06 <zmatt> you can get the latest debian jessie or stretch images here -> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian
Aug 30 12:22:26 <zmatt> I haven't done as much with pru yet as I'd like to actually, but I'd definitely use pru assembly
Aug 30 12:24:13 <Catslab> ok great !
Aug 30 12:24:30 <zmatt> the pru instruction set was very clearly designed for hand-written assembly, and not as target for a C compiler.  as a result, the C compiler produces really crappy code and several of its cool features are completely unusable when writing in C
Aug 30 12:24:56 <Catslab> I has started a project using prus to drive AD converters and gather the data and display it in with Qt, was working fine
Aug 30 12:25:26 <Catslab> yes I tried C but it was not exactly what I was hoping for
Aug 30 12:26:08 <Catslab> I need a precise clock, so I use interrupts and I count my instructions in asm
Aug 30 12:26:16 <Catslab> work good
Aug 30 12:26:37 <zmatt> yes, cycle-accurate timing is one of those sweet pru features that is completely lost when using C
Aug 30 12:27:11 <Catslab> I bought a bunch of sd cards, will test some images :)
Aug 30 12:30:33 <zmatt> I'd suggest trying the latest debian stretch snapshot.  you can either get the -lxqt image which includes everything and the kitchen sink, or if you have enough experience with debian you can also start with the minimalistic -console image and just install whatever packages you need
Aug 30 12:30:44 <Catslab> takes some time to get back when you put a project on hold for so long !
Aug 30 12:30:56 <Catslab> zmatt: yes, will go with console
Aug 30 12:31:09 <Catslab> I do not like fancy things
Aug 30 12:31:30 <zmatt> to enable uio-pru (which I assume you're using), you need to uncomment a line in uEnv.txt
Aug 30 12:31:49 <Catslab> Oh nice :) no need to compile the kernel
Aug 30 12:31:56 <Catslab> lol
Aug 30 12:32:27 <Catslab> in fact I'll recompile because I need to move some I/O I need that are used by the display
Aug 30 12:32:39 <zmatt> nope
Aug 30 12:32:44 <Catslab> unless there's the cape manager ?
Aug 30 12:33:00 <Catslab> I wasn't using cape manager at the time
Aug 30 12:33:05 <zmatt> you can disable hdmi (and free up the IOs) again by uncommenting one line in /boot/uEnv.txt
Aug 30 12:33:20 <Catslab> yes I do not use the hdmi at all
Aug 30 12:33:29 <Catslab> but I use a 4dsystem display
Aug 30 12:33:29 <zmatt> but you're using qt5 ... ?
Aug 30 12:33:32 <zmatt> ah
Aug 30 12:33:55 <Catslab> and they wired some navigation buttons that I remove and one is on one line I use with the pru
Aug 30 12:34:18 <zmatt> another option is making a custom DT for your overall system
Aug 30 12:34:34 <Catslab> yes I'll look that option
Aug 30 12:35:14 <Catslab> I need to check what's new for me since 3.14 :)
Aug 30 12:35:35 <zmatt> a lot, I suspect :)
Aug 30 12:35:44 <Catslab> ahaha tell me about that
Aug 30 12:36:05 <zmatt> do you intend to use qt5 in x11 or use the eglfs backend?
Aug 30 12:36:13 <Catslab> eglfs
Aug 30 12:36:40 <zeekhuge> whois Daniele
Aug 30 12:36:46 <zeekhuge> oops !
Aug 30 12:36:50 <Catslab> I was using that and was working fine except for the touch screen
Aug 30 12:36:59 <zmatt> ah, so you'll also have the fun of getting the gpu driver working
Aug 30 12:37:21 <Catslab> so I replaced the touch screen with another plugged on usb
Aug 30 12:37:29 <Catslab> zmatt: yes.....
Aug 30 12:37:32 <Catslab> fun or pain
Aug 30 12:37:39 <Catslab> we'll see :)
Aug 30 12:37:54 <zmatt> it wasn't too hard in the end
Aug 30 12:37:59 <zmatt> but not completely trivial either
Aug 30 12:38:12 <Catslab> I too some notes
Aug 30 12:38:14 <zmatt> I don't know if rcn ever got around to packaging it
Aug 30 12:38:20 <Catslab> lots of notes
Aug 30 12:38:25 <zmatt> those notes are probably no longer applicable
Aug 30 12:38:33 <Catslab> may be
Aug 30 12:38:39 <Catslab> but it can not hurt :)
Aug 30 12:40:55 <Catslab> I have to finish a few screens on another app and I'll try the 4.9-bone
Aug 30 12:41:04 <Catslab> thanks for your knowledge zmatt
Aug 30 12:41:34 <zmatt> you can also find some repos w.r.t. the gpu drivers on my github account -> https://github.com/mvduin?tab=repositories
Aug 30 12:42:11 <zmatt> omap5-sgx-* and libgbm being the most important ones
Aug 30 12:43:10 <Catslab> ok thanks
Aug 30 12:43:10 <zmatt> when attempting to get it to work, be sure no mesa packages are installed unless you want to descend into madness
Aug 30 12:43:29 <Catslab> I never installed mesa packages
Aug 30 12:43:35 <zmatt> I'd had some "fun" as a result of a mix of sgx and mesa libs getting loaded into a process
Aug 30 12:43:53 <Catslab> good to know
Aug 30 12:44:10 <zmatt> even if you don't manually install them, they tend to get pulled in as dependencies
Aug 30 12:45:44 <Catslab> Never had that trouble, I do not install a lot of things
Aug 30 12:46:01 <zmatt> well, libqt5* pulls it in
Aug 30 12:46:07 <zmatt> iirc
Aug 30 12:46:12 <Catslab> mmmm
Aug 30 12:46:21 <Catslab> I always compiled qt5
Aug 30 12:46:30 <Catslab> can't recall of mesa
Aug 30 12:46:30 <zmatt> I worked around it by building some really hacky debian packages
Aug 30 12:46:41 <zmatt> ah, if you compile it yourself then that problem goes away of course
Aug 30 12:47:01 <Catslab> well cross compiled on osx for fun
Aug 30 12:47:04 <Catslab> :)
Aug 30 12:47:47 <zmatt> fun fun fun
Aug 30 12:49:07 <Catslab> I had some trouble on debian with qt creator at the time
Aug 30 12:50:38 <Catslab> so went back on osx and with some help from Knut Welzels for the cross compiler part
Aug 30 12:50:55 <Catslab> may be some voodoo too :)
Aug 30 12:51:09 <Catslab> it worked pretty fine
Aug 30 13:09:39 <zmatt> yeah I was just too lazy and used the debian qt5 packages
Aug 30 15:53:13 <zarzar> hi can someone recommend a good tutorial for setting up UART on BBB for use with C/C++ applications?
Aug 30 15:56:19 <tbr> any linux tutorial for serial port usage will do
Aug 30 15:56:53 <tbr> the only BBB specific bit is: enable the UART pins
Aug 30 16:02:13 <zarzar> tbr, a google search found several using a cape, but i want to use headers on the board only, i haven't checked the schematic, i assume that is possible
Aug 30 16:11:21 <tbr> zarzar: yes that's possible. there might be a "virtual cape" or dtb-overlay that you can load to enable most of them on the fly
Aug 30 16:11:40 <tbr> note that those are 3.3V vref
Aug 30 16:13:21 <tbr> http://www.armhf.com/beaglebone-black-serial-uart-device-tree-overlays-for-ubuntu-and-debian-wheezy-tty01-tty02-tty04-tty05-dtbo-files/ - this looks promising
Aug 30 16:13:37 <tbr> you should check if there already is a dtbo that takes care of all this
Aug 30 16:14:34 <tbr> https://billwaa.wordpress.com/2014/10/13/beaglebone-black-enable-all-uart-ports-at-boot/
Aug 30 16:14:55 <tbr> note that on any up to date image there are likely to be some differences
Aug 30 16:30:53 <zarzar> tbr, ok that looks like it is for ftdi cable, should be fine without it for loopback testing right? (newb to BBB)
Aug 30 16:48:53 <zarzar> tbr the second on you sent changes files in uboot, the uEnv.txt file, bit that is not in uboot on my build https://billwaa.wordpress.com/2014/10/13/beaglebone-black-enable-all-uart-ports-at-boot/
Aug 30 16:52:03 <zarzar> was uEnv.txt  located in /boot/uboot/ previously but moved to /boot/ in newer versions of bbb linux distros?
Aug 30 17:32:15 <zarzar> hello can someone help with UART1 setup?
Aug 30 17:40:50 <zarzar> tbr i ran through the second link you sent but I do not get output on UART1
Aug 30 17:53:44 <tbr> zarzar: please note that under no circumstances whatsoever you should connect those pins to a RS-232 port
Aug 30 17:55:41 <zmatt> if you're using a recent enough image, all uarts should already be enabled and you just need to use config-pin to setup pinmux
Aug 30 17:56:27 <zarzar> tbr loopback
Aug 30 17:56:52 <zarzar> tbr they are 3.3v right?
Aug 30 17:59:49 <zarzar> zmatt ok not sure where to find the relevant info for setting the pins or using config-pin
Aug 30 18:00:45 <tbr> zarzar: yes, loopback is obviously fine to do
Aug 30 18:01:28 <zmatt> I think you can do something like  config-pin $pin $mode   where $mode would be "uart" in this case
Aug 30 18:04:01 <zarzar> trying to test with minicom: https://electronics.trev.id.au/2017/04/10/enable-uarts-element-14-beaglebone-black-rev-c/
Aug 30 18:04:42 <zarzar> how do i know which tty* is UART1/
Aug 30 18:04:45 <zmatt> after setting pinmux you can also double-check using my show-pins utility, which you can find here -> https://github.com/mvduin/bbb-pin-utils
Aug 30 18:04:53 <zmatt> uart1 is /dev/ttyS1
Aug 30 18:05:16 <zarzar> is it softlinked by ttyO1?
Aug 30 18:06:12 <zmatt> there might be a ttyO1 -> ttyS1 symlink... this is something that's easier to check than to ask
Aug 30 18:07:09 <zarzar> lrwxrwxrwx 1 root root 5 Aug 30 17:15 /dev/ttyO1 -> ttyS1
Aug 30 18:07:35 <zmatt> (or, well, it's easy to ask, but I can't look on your system to confirm whether or not such a symlink exists there)
Aug 30 18:07:45 <zarzar> i don't know what that even means wrt uarts
Aug 30 18:08:25 <zmatt> it just means that ttyO1 acts like an alias for ttyS1, for compatibility reasons
Aug 30 18:09:18 <zarzar> isn't one uart used by kernel for debugging or console
Aug 30 18:09:33 <zmatt> no, that's uart0
Aug 30 18:09:41 <zmatt> I mean, yes, that's uart0
Aug 30 18:09:48 <zarzar> ok
Aug 30 18:11:34 <zarzar> zmatt i installed your pin show package
Aug 30 18:12:55 <zarzar> no uart pins
Aug 30 18:13:28 <zmatt> probably because you haven't configured any pins to uart mode yet
Aug 30 18:23:15 <zmatt> you need to pick two pins with uart functionality and use  config-pin to set their mode to uart
Aug 30 18:39:39 <adugenske> Anybody install electron on a BBB?
Aug 30 18:58:58 <zarzar> zmatt config-pin -l P9_14 : default gpio gpio_pu gpio_pd pwm
Aug 30 18:59:38 <zmatt> yes?
Aug 30 18:59:48 <zarzar> uart is not listed
Aug 30 19:00:15 <zmatt> correct
Aug 30 19:00:18 <zarzar> nevermind i used the wrong number
Aug 30 19:00:21 <zmatt> :)
Aug 30 19:08:25 <zarzar> i enabled uart1,2,3,5 via optargs in uEnv.txt  but i only see ttyO0,1,2,4 via ls -l /dev/ttyO*
Aug 30 19:17:25 <zmatt> I've never seen or heard of "optargs" in uEnv.txt.  all usable uarts should be enabled automatically by default
Aug 30 19:18:13 <zmatt> uart 5 is probably disabled due to conflict with hdmi
Aug 30 19:19:09 <zmatt> uart 3 isn't fully usable on the bbb without ugly hacks since its rxd signal can't be muxed to any pin available on the expansion headers
Aug 30 19:20:30 <zarzar> optargs=capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART3,BB-UART5
Aug 30 19:20:36 <zarzar> from https://billwaa.wordpress.com/2014/10/13/beaglebone-black-enable-all-uart-ports-at-boot/
Aug 30 19:20:42 <zmatt> oh, I see the problem... you're following articles written in 2013 or 2014
Aug 30 19:21:02 <zmatt> none of that is remotely right anymore :)
Aug 30 19:21:04 <zarzar> maybe that is stale info, would be nice if there was a way tofigure that out before trying to follow the blog
Aug 30 19:21:21 <zmatt> there's nothing you need to do in uEnv.txt to enable the uarts
Aug 30 19:21:27 <zarzar> so should i remove that from uEnv.txt?
Aug 30 19:21:42 <zmatt> yes.  also, probably those docs are old enough to still have an off-by-one in the uart numbering
Aug 30 19:22:09 <zmatt> so those uarts "1,2,3,5" are actually uarts 0,1,2,4
Aug 30 19:22:25 <zmatt> maybe
Aug 30 19:22:26 <zarzar> oh ok
Aug 30 19:22:59 <zmatt> maybe not, that's just a guess
Aug 30 19:23:07 <zarzar> so remove or no?
Aug 30 19:23:10 <zmatt> yes
Aug 30 19:23:14 <zarzar> ok cool
Aug 30 19:23:50 <zarzar> so on rpi one uart is for console is that the case with BBB? i.e. is there one I should not use?
Aug 30 19:24:05 <zmatt> uart0 is the default console
Aug 30 19:24:11 <zmatt> (you already asked that)
Aug 30 19:24:27 <zarzar> i don't think i asked that, show me
Aug 30 19:25:14 <zmatt> https://pastebin.com/raw/NSiwUqhN
Aug 30 19:25:34 <zarzar> dang
Aug 30 19:25:41 <zmatt> :)
Aug 30 19:26:26 <zarzar> is this up to date: https://www.mathworks.com/help/supportpkg/beagleboneio/ug/beaglebone_black_pinmap.png
Aug 30 19:27:18 <zmatt> there isn't really any way for it to be out of date since it describes the hardware
Aug 30 19:27:33 <zmatt> it's not complete though
Aug 30 19:28:36 <zmatt> I have a spreadsheet with a fair bit of info -> https://goo.gl/Jkcg0w  the orange tabs are BBB-specific, especially the P9 and P8 tabs give a useful overview
Aug 30 19:30:17 <zarzar> so i reverted uEnv.xtt and restarted and the pins were not set for uart, so they have to be set to uart mode everytime. correct?
Aug 30 19:30:44 <zmatt> yeah, config-pin isn't persistent
Aug 30 19:31:32 <zarzar> ok\
Aug 30 19:32:05 <zarzar> was hopeful that the config-pin might be setting start up configs also...
Aug 30 19:32:48 <zarzar> at this point should i expect minicom to work on UART1 with a loopback?
Aug 30 19:33:14 <zmatt> presumably yes... I have no real experience with minicom
Aug 30 19:34:01 <zarzar> working
Aug 30 19:35:32 <zarzar> ok what would you suggest?
Aug 30 19:38:18 <zmatt> I use screen for such purposes, but that choice was probably influenced by the fact I was already familiar with using screen... so the fact it can also be used for serial communications is just a nice bonus
Aug 30 19:42:34 <zmatt> (something like "screen /dev/ttyS1 115200" , to exit press ctrl-A and then K )
Aug 30 19:47:10 <zarzar> ok cool, i should be able to run standard any linux UART programs with ttyO1 now, including c/c++ code
Aug 30 19:47:41 <zmatt> yeah
Aug 30 19:49:29 <zmatt> keep in mind the ttyO* symlinks are just for backwards compatibility with really old kernels, it may be better to use ttyS* (although an argument could be made for sticking with ttyO* since then it also works when using the omap-serial driver instead of the 8250-omap driver)
Aug 30 19:55:02 <zarzar> ok
Aug 30 19:55:31 <zarzar> do you know if i need any special compiler linker flags for this file: http://elinux.org/images/b/b7/Uart-loopback.c
Aug 30 20:01:24 <zarzar> looks like it might be working
Aug 30 20:03:23 <zarzar> working, thanks for the help zmatt and tbr
Aug 30 20:04:34 <zmatt> woop
Aug 30 20:05:40 <tbr> yay, glad you got it sorted zarzar :)
Aug 30 20:06:39 <zarzar> yep, so much old stale info out there
Aug 30 20:06:59 <zarzar> i should avoid the blogs from now on\
Aug 30 20:07:10 <zmatt> or just mind the date on articles
Aug 30 20:07:45 <zmatt> okay, I'm afk
Aug 30 20:15:06 <CruiserAbhi> I got a BeagleBone Black wireless today initially it was getting detected as Mass storage device in both of my Windows Laptop but I was unable to install the Driver the Driver kept on failing and then I installed RNDIS in Windows as Network Adapter Driver and I could browse into http://192.168.7.2/ but after disconnecting neither my BeagleBone is geeting detected as Mass  storage nor http://192.168.7.2/ is accessible anymore (Re
Aug 30 20:15:14 <CruiserAbhi> Blue Left LED Blinks periodically
Aug 30 20:15:20 <CruiserAbhi> Please guide
Aug 30 20:49:10 <zmatt> CruiserAbhi: hum, you didn't do anything else with it?
Aug 30 20:50:03 <zmatt> with blue led you mean the power led?
Aug 30 21:49:13 <FedoraUser> hi friends
Aug 30 21:49:33 <FedoraUser> I am running Fedora 26 on my bbb
Aug 30 21:49:50 <FedoraUser> and I really liked that g_ether thing that came with built-in debian
Aug 30 21:50:21 <FedoraUser> however, I am trying to replicate it with configfs to reduce overhead (kernel compilation and maintenance)
Aug 30 21:50:34 <FedoraUser> this is the guide I looked at: https://wiki.tizen.org/USB/Linux_USB_Layers/Configfs_Composite_Gadget/Usage_eq._to_g_ether.ko
Aug 30 21:51:24 <FedoraUser> I am extreme newbie with these kind of things and would just like to have bbb report as eth adapter to the host that is powering it
Aug 30 21:51:44 <FedoraUser> what I identified as a potential issue is that my /sys/class/udc is empty
Aug 30 21:52:07 <FedoraUser> I tried loading dwc2 module with 'modprobe dwc2' but result is always the same
Aug 30 21:52:35 <FedoraUser> here are exact steps I did: https://paste.fedoraproject.org/paste/pJ9XhP3fh1ek2jowOHDHsg
Aug 30 21:57:06 <zmatt> dwc2 is definitely the wrong module
Aug 30 21:57:13 <zmatt> what kernel are you using?
Aug 30 21:57:54 <FedoraUser> zmatt, 4.11.8-300.fc26.armv7hl
Aug 30 21:59:14 <zmatt> okay, so a generic armv7 kernel.  might simply not have the right drivers?  s3c-otg is for some samsung SoC btw, so not remotely right
Aug 30 22:00:40 <FedoraUser> the s3c-hsotg is just the string from that wiki page, my /sys/class/udc is empty
Aug 30 22:01:06 <FedoraUser> I can grep kernel config for specific driver, if you could tell me which one would it be :)
Aug 30 22:01:10 <zmatt> it might be worth trying one of the kernels typically used on bbb instead.  rcn's build scripts make that very easy
Aug 30 22:01:32 <zmatt> (you might need to customize the config if fedora expects specific things to be enabled, like selinux)
Aug 30 22:01:49 <FedoraUser> selinux is disabled on my installation
Aug 30 22:01:58 <FedoraUser> but I see your point
Aug 30 22:01:58 <zmatt> ok
Aug 30 22:02:59 <zmatt> https://github.com/RobertCNelson/bb-kernel  pick a branch for some kernel series, copy system.sh.sample to system.sh and adjust to taste, then run ./build_kernel.sh
Aug 30 22:03:52 <FedoraUser> what is -rt- in branch name, real time?
Aug 30 22:04:05 <zmatt> yeah, you typically don't want those
Aug 30 22:04:50 <zmatt> my suggestion would be 4.9-bone
Aug 30 22:05:09 <zmatt> (branch name am33x-v4.9)
Aug 30 22:05:23 <FedoraUser> I mean, I specifically didn't want to build and maintain kernel, so I will try to identify what driver is missing and perhaps ask for Fedora to include it by default
Aug 30 22:05:37 <FedoraUser> checking am33x-v4.9
Aug 30 22:06:22 <zmatt> sure, I think everything needed for usb should be mainline actually.  this is just a simple way to get a known good kernel
Aug 30 22:07:21 <zmatt> there are also a bunch of patches beneficial to bbb users that haven't hit mainline (yet)
Aug 30 22:08:51 <FedoraUser> zmatt, I see, but I am trying to put it in "production" with automatic updates, and directly connected to the internet, so I wouldn't want to have to keep updating kernel manually
Aug 30 22:09:09 <FedoraUser> I really appreciate your words though
Aug 30 22:09:59 <FedoraUser> I should examine pathces/defconfig in the branch to compare with Fedora, right?
Aug 30 22:10:26 <zmatt> yeah
Aug 30 22:11:42 <zmatt> and dunno... on embedded systems it seems a bit more hazarous than typical to automatically update something like a kernel.  depending on how they are deployed it can be rather problematic if something breaks
Aug 30 22:11:44 <FedoraUser> it's going to be quite a ride going through this :)
Aug 30 22:12:33 <FedoraUser> I think I am more inclined to manage incidents as it is not central unit, than to have to have regular maintenance
Aug 30 22:13:10 <zmatt> like I said, it depends on how they are deployed :)
Aug 30 22:13:39 <FedoraUser> fully agreed! :)
Aug 30 22:14:25 <zmatt> we embed them in products, so if an update breaks stuff that means that products out there in the world are now broken and need to be RMA'd
Aug 30 22:15:59 <FedoraUser> oh my, yes, that would be quite a mess
Aug 30 22:16:12 <zmatt> I also build custom kernels to optimize them for the target and avoid including unnecessary crap
Aug 30 22:16:17 <zmatt> saves considerably on boot time
Aug 30 22:16:48 <zmatt> https://liktaanjeneus.nl/boot.svg
Aug 30 22:17:40 <FedoraUser> wow, that's quite fast
Aug 30 22:18:11 <FedoraUser> for me it is 1m 34s :)
Aug 30 22:18:14 <zmatt> ouch :)
Aug 30 22:18:32 <zmatt> not acceptable for an appliance
Aug 30 22:19:32 <FedoraUser> agreed, this is more of a low powered PC than an appliance
Aug 30 22:19:50 <zmatt> customizing the kernel config cut the vmlinuz size in half iirc, and the other big timesaver was getting rid of initramfs
Aug 30 22:20:15 <zmatt> and of course disabling unnecessary services
Aug 30 22:29:24 <FedoraUser> do you really need CONFIG_OCFS2_FS in bbb? :D
Aug 30 22:41:03 <JaVi_> Hi, i download the S.O. Debian 9.1 2017-08-24 4GB SD LXQT  and i am trying to connect over SSH, but i dont know the user and password....please somebody can help me?
Aug 30 22:45:01 <zmatt> FedoraUser: I definitely don't have it enabled
Aug 30 22:45:13 <zmatt> FedoraUser: here's mine, in case you're curious -> https://github.com/dutchanddutch/bb-kernel/blob/am33x-v4.9/patches/defconfig
Aug 30 22:45:23 <zmatt> JaVi_: debian / temppwd
Aug 30 22:45:58 <FedoraUser> zmatt, sorry I missed what you don't have enabled
Aug 30 22:46:12 <zmatt> FedoraUser: <FedoraUser> do you really need CONFIG_OCFS2_FS in bbb? :D
Aug 30 22:46:52 <FedoraUser> oh :)
Aug 30 22:47:29 <FedoraUser> ok, let me compare yours
Aug 30 22:47:40 <FedoraUser> perhaps its smaller subset
Aug 30 22:48:10 <FedoraUser> i.e. easier to compare
Aug 30 22:50:14 <zmatt> for usb search for "MUSB"
Aug 30 22:51:30 <zmatt> and I spot a few relevant options under "USB Physical Layer drivers"
Aug 30 22:53:20 <FedoraUser> zmatt, this is the only thing I managed to identify that is unique to your config: CONFIG_MUSB_PIO_ONLY
Aug 30 22:53:29 <FedoraUser> (the only MUSB thing)
Aug 30 22:54:07 <zmatt> compared to the fedora kernel you mean?
Aug 30 22:54:19 <FedoraUser> these are the things you have that fedora kernel doesn't: https://paste.fedoraproject.org/paste/ORkrmpnM1ADW2mBMcEcG4g
Aug 30 22:54:21 <FedoraUser> yes
Aug 30 22:55:26 <zmatt> hmm, then maybe the problem lies with the device tree rather than the kernel
Aug 30 22:56:23 <zmatt> as for CONFIG_MUSB_PIO_ONLY ... you can try using dma.  it has a reputation of being buggy but I don't know if that's still true.  also, a while ago someone tested it and reported it was actually slower with dma than without
Aug 30 22:56:38 <zmatt> (PIO_ONLY == no DMA)
Aug 30 22:56:53 <FedoraUser> I see
Aug 30 22:57:14 <zmatt> I make very little use of usb on the bbb, so I can't really say much about it from experience
Aug 30 22:57:59 <FedoraUser> no worries, I really appreciated your brain storming with me
Aug 30 22:58:02 <FedoraUser> :)
Aug 30 22:59:37 <zmatt> the fedora kernel doesn't use CONFIG_THUMB2_KERNEL ? hum
Aug 30 22:59:52 <FedoraUser> let me double check so I didn't mess up parsing
Aug 30 23:00:30 <zmatt> can I see the full config somewhere?
Aug 30 23:00:31 <FedoraUser> no messing up, it is true: # CONFIG_THUMB2_KERNEL is not set
Aug 30 23:00:34 <FedoraUser> sure
Aug 30 23:00:36 <FedoraUser> one sec
Aug 30 23:00:56 <zmatt> there's really no good reason to not use thumb2
Aug 30 23:01:06 <FedoraUser> zmatt, https://paste.fedoraproject.org/paste/rQhOhzQanJ25RlBn4WA76g
Aug 30 23:01:58 <zmatt> (well, okay, I suppose there is a good reason if you need to support SoCs that have some old cortex-a8 revision with buggy thumb2 ...)
Aug 30 23:02:25 <FedoraUser> yeah, fedora likes to support all
Aug 30 23:03:12 <zmatt> damn this thing must be huge
Aug 30 23:04:07 <zmatt> hah, "support all" ... it's not gonna run on the beagleboard x15 though
Aug 30 23:04:09 <zmatt> # CONFIG_SOC_DRA7XX is not set
Aug 30 23:04:14 <FedoraUser> 6MiB :)
Aug 30 23:05:12 <FedoraUser> well, I am here because of such issues, so we can make Fedora even better
Aug 30 23:05:14 <FedoraUser> ;)
Aug 30 23:08:18 <zmatt> for the kernel? that's not even that horrible
Aug 30 23:09:48 <zmatt> # CONFIG_SOC_TI is not set
Aug 30 23:10:00 <zmatt> might want to check what's behind that option :)
Aug 30 23:10:44 <FedoraUser> ok, sounds inviting :)
Aug 30 23:11:09 <zmatt> still, afaict you should already have everything needed for usb
Aug 30 23:12:09 <zmatt> so it's probably a DT issue
Aug 30 23:12:51 <FedoraUser> I saw this for rpi: dtoverlay=dwc2 added to /boot/config.txt (here http://isticktoit.net/?p=1383)
Aug 30 23:13:32 <FedoraUser> but I don't have such a file and don't know if there is any hints there... or am I just seeing what I want to see :D
Aug 30 23:13:56 <zmatt> it sounds odd to me that an overlay would be needed for a piece of core functionality like that
Aug 30 23:14:47 <zmatt> regardless, that config file is fedora-specific so I can't really help you there
Aug 30 23:15:23 <FedoraUser> actually site I just quoted is for raspbian jessie, so most likely the cause why I don't have it in fedora
Aug 30 23:15:31 <zmatt> oh
Aug 30 23:15:49 <FedoraUser> it was just mentioning Device Tree same as you did... (some advanced troubleshooting on my end :D )
Aug 30 23:16:51 <zmatt> well yeah but there's no standard mechanism that consumes the option "dtoverlay=..." as far as I know, so that will be something specific to that distro
Aug 30 23:17:19 <zmatt> like I said though, something like usb really belongs in the main dt, not an overlay
Aug 30 23:17:41 <FedoraUser> understood
Aug 30 23:19:15 <zmatt> https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.9.46-bone7/arch/arm/boot/dts/am335x-bone-common.dtsi#L188   that's where the usb controller is being configured and enabled
Aug 30 23:19:18 <FedoraUser> btw, just to clarify, my USB (type A?, the big one) is working just fine, I wanted to use miniUSB for this
Aug 30 23:19:54 <zmatt> yeah, the host port, that's usb1
Aug 30 23:20:05 <zmatt> the mini-B port is usb0
Aug 30 23:20:17 <zmatt> line 206 sets its mode to peripheral
Aug 30 23:20:32 <FedoraUser> I see that
Aug 30 23:20:49 <FedoraUser> and I see line 211 is host one
Aug 30 23:21:18 <zmatt> so maybe check whether the DT you're using differs somehow
Aug 30 23:21:21 <FedoraUser> so, can I anyhow see if my fedora sees two ports?
Aug 30 23:21:29 <zmatt> explore sysfs
Aug 30 23:22:27 <FedoraUser> doesn't look promising
Aug 30 23:22:28 <zmatt> you could also check your dt directly first (by checking its source, or decompiling the dtb, or inspecting /proc/device-tree )
Aug 30 23:22:48 <FedoraUser> wow, you have to slow down for me :)
Aug 30 23:23:41 <FedoraUser> I would say it only sees host USB: https://paste.fedoraproject.org/paste/PiYhOPrgbL9EWmz-8gEP2g
Aug 30 23:24:13 <zmatt> /sys/bus/usb only concerns the host part
Aug 30 23:24:45 <zmatt> but those symlinks do show where you can look for the other port
Aug 30 23:24:51 <zmatt> namely /sys/devices/platform/ocp/47400000.usb
Aug 30 23:25:27 <zmatt> more specifically /sys/devices/platform/ocp/47400000.usb/47401400.usb/musb-hdrc.0.auto
Aug 30 23:25:45 <FedoraUser> zmatt, that looks more promising https://paste.fedoraproject.org/paste/kW5F5k1jicKVkh~UJdp7Ag
Aug 30 23:26:20 <zmatt> so, I have "gadget" and "udc" subdirectories there
Aug 30 23:26:39 <FedoraUser> I don't have that directory
Aug 30 23:26:45 <zmatt> oh wait
Aug 30 23:26:46 <zmatt> uhh
Aug 30 23:26:50 <zmatt> huh
Aug 30 23:27:00 <zmatt> oh nm, sorry, I was confused
Aug 30 23:27:11 <zmatt> can you check the 47401400.usb subdir
Aug 30 23:27:18 <FedoraUser> did that
Aug 30 23:27:21 <FedoraUser> incoming link
Aug 30 23:27:30 <FedoraUser> https://paste.fedoraproject.org/paste/ptvs9cSXAc-5kDgeCVH14Q
Aug 30 23:27:45 <zmatt> that looks unlively
Aug 30 23:28:02 <zmatt> cat of_node/status in that dir
Aug 30 23:28:06 <FedoraUser> on it
Aug 30 23:28:16 <zmatt> and perhaps of_node/dr_mode
Aug 30 23:28:25 <FedoraUser> says 'okay'
Aug 30 23:28:31 <FedoraUser> checking dr_mode
Aug 30 23:28:42 <FedoraUser> says 'peripheral'
Aug 30 23:28:59 <zmatt> okay, then everything is fine.  except for it not working that is
Aug 30 23:29:09 <FedoraUser> :D
Aug 30 23:29:57 <zmatt> I guess check kernel log for errors?
Aug 30 23:30:41 <zmatt> it looks like it failed to probe the musb-dsps driver for that device, for whatever reason
Aug 30 23:30:56 <zmatt> even though it apparently probed just fine for the host port
Aug 30 23:31:15 <FedoraUser> oh... yes, you are mind-reading my logs
Aug 30 23:31:33 <zmatt> well I'm just stating the obvious based on what you pasted
Aug 30 23:31:39 <zmatt> it doesn't have a driver symlink
Aug 30 23:31:59 <FedoraUser> zmatt, https://paste.fedoraproject.org/paste/TwMNt6A~e6xXnfXM7cgXTg
Aug 30 23:32:12 <FedoraUser> line 260 specifically
Aug 30 23:32:56 <zmatt> I'm more concerned about the stack dump above it
Aug 30 23:33:08 <FedoraUser> yeah...
Aug 30 23:33:33 <FedoraUser> well, at least I can now go back to my fellas at Fedora and at least know what is wrong
Aug 30 23:34:11 <FedoraUser> is it safe to assume that if that part worked properly my endaevours would be fruitful?
Aug 30 23:35:28 <zmatt> I see more going wrong btw
Aug 30 23:35:37 <zmatt> unrelated to usb
Aug 30 23:35:43 <zmatt> lines 345-347
Aug 30 23:36:46 <FedoraUser> oh... that sounds scary
Aug 30 23:37:08 <FedoraUser> is it at least ok to run at 720MHz?
Aug 30 23:37:15 <zmatt> well not that scary, it just suggests it has wrong OPP tables
Aug 30 23:37:29 <zmatt> it was fine running at 1 GHz
Aug 30 23:37:53 <FedoraUser> ok, I'll let them know about this as well
Aug 30 23:38:49 <FedoraUser> I can't thank you enough! you really helped me progress this project
Aug 30 23:39:05 <zmatt> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am33xx.dtsi#L73
Aug 30 23:39:45 <zmatt> that node is responsible for determining suitable voltage+frequency points in the 4.9-bone kernels anyway
Aug 30 23:40:12 <zmatt> I have no idea if this sort of stuff is mainline yet though
Aug 30 23:41:14 <FedoraUser> well, it will be eventually and my bbb will run faster after an update :)
Aug 30 23:42:20 <zmatt> oh it has always supported 1 GHz in the official kernels, the mechanism just used to be less smart
Aug 30 23:43:06 <zmatt> basically it just relied on a list of frequency + voltage pairs in the DT, instead of being able to autodetect the supported frequencies by reading SoC efuse data
Aug 30 23:46:17 <FedoraUser> well, I guess if less smart code is in mainline, advanced will be easier to add
Aug 30 23:46:33 <FedoraUser> then if it was just introduced
Aug 30 23:46:56 <FedoraUser> anyway, I'm off to bed, sorry for also keeping you up at this hour :)
Aug 30 23:47:20 <zmatt> nite!
Aug 30 23:47:41 <zmatt> don't worry, I'm typically still up at this time :)
Aug 31 00:23:05 <kumareasu> I am searching foe a USB to Ethernet converter which can work with beagleboneblack loaded with Debian
**** ENDING LOGGING AT Thu Aug 31 03:00:01 2017