**** BEGIN LOGGING AT Fri Jan 06 03:00:01 2017 Jan 06 03:58:35 On the Beaglebone, Qt apps don't seem to be lightweight at all Jan 06 03:58:51 nor LXQT Jan 06 04:22:02 Openbox and LXTerminal are snappy :-D Jan 06 04:24:40 Qupzilla x_x Jan 06 13:23:27 hello. chromium is borked on my beaglebone black system after an apt-get upgrade. every time i start chromium, it loads the "aw snap" page and i am unable to browse. how can i track down the problem? Jan 06 14:13:42 Hello. I've got a PCB with a SOP8 flash memory on it. I'd like to be able to reprogram it easily without the hassle of de/resoldering it. I found some SOP->DIP adapters which would let me place it on a dataman (or clone...), but are there DIP->SOP adapters to solder on the board directly, in effect allowing me to unplug/replug the chip from the PCB ? Jan 06 15:10:25 I've got 2 BBGWs. On one, I have the default image that came with it - WiFi is working. On the other, I have an old image from a BBB that I'm trying to retro-fit (because I have a lot of work put into the image). I'm having trouble getting the wifi to work with it though. I've tried loading the bbbw-univ dtbo and then modprobing the wlcore/wl18xx modules, but i don't see a wlan0 in ifconfig. I've looked at dmesg/syslog/mess Jan 06 15:10:26 ages, but don't see much to give me a clue as to what's going on. Anyone know how I can figure out what's going on? Jan 06 18:27:37 Good day. I have a custom am5718 board that works well enough on the old MLO/u-boot/zImage Jan 06 18:27:56 but trying to use the newer X15 images I get this issue: https://groups.google.com/forum/#!category-topic/beagleboard/beagleboard-x15/PbwZx5eSUvE Jan 06 18:28:26 (well when I use the rootfs... I still have the MLO/u-Boot) Jan 06 18:28:57 Basically it starts up, I get hdmi and serial output, kernel starts.. hangs on "Waiting for root device PARTUUID=xxxxx" Jan 06 18:30:55 ... the google group response didn't help. When I try a new microsd image, I get no HDMI or serial output. Jan 06 18:32:30 so I would prefer to use the microsd images but it appears that I have to use the old MLO/uBoot method which the new images have moved away from Jan 06 18:32:34 any ideas? Jan 06 19:08:36 custom_am5718: obscure question... I hope you have patience since probably anyone who might have ideas isn't going to be around often :) Jan 06 19:08:43 but lemme see what you posted Jan 06 19:09:19 sure.. and that google groups post isn't from me Jan 06 19:09:24 but I'm having the same issue Jan 06 19:09:52 ok Jan 06 19:10:16 "well when I use the rootfs... I still have the MLO/u-Boot" Jan 06 19:10:22 using an old u-boot does not sound like a good idea Jan 06 19:11:31 true Jan 06 19:11:48 but when I burn the latest images I get nothing... no serial/hdmi/etc Jan 06 19:12:06 at least with the old mlo/uB I get some visibility in the boot process Jan 06 19:12:35 I would personally not be inclined to bring up new custom hardware without having JTAG at hand to debug issues Jan 06 19:14:24 since debugging blind is rather painful and can easily waste a lot of time :) (worth more than the $100 or so for an XDS100v2 jtag debugger) Jan 06 19:16:18 custom_am5718: but as rcn replied, ditch the use of UUIDs and patch the kernel to use stable mmc device numbering (which matches that of u-boot) Jan 06 19:16:45 alright, I'll look into that Jan 06 19:17:04 of course you'll still want to investigate why a newer u-boot isn't working Jan 06 19:17:25 especially if your old u-boot is older than a year ago or so Jan 06 19:17:57 or half a year even, iirc quite important bugfixes were committed in june or so Jan 06 19:18:16 related to setting up internal LDOs Jan 06 19:19:01 the mlo/uboot I have working is from Dec 2015 so that's probably the disconnect Jan 06 19:19:30 but isn't the mlo/uboot only needed to fire up the zImage kernel? Jan 06 19:20:35 yes and no, some of the SoC initialization it does will never be overridden by the kernel Jan 06 19:20:55 oh ok - thanks. I'm new to this environment Jan 06 19:21:45 http://lists.denx.de/pipermail/u-boot/2016-April/252489.html Jan 06 19:23:46 the omap5/dra7/am57xx SoCs are complicated beasts and have quite a bit of really obscure init stuff in u-boot Jan 06 19:24:12 (in at least one case I noticed involving control registers that aren't even documented) Jan 06 19:25:51 interesting Jan 06 19:26:21 that was on omap5 at least, don't remember if it also applied to vayu (dra7xx/am57xx) Jan 06 19:26:26 do you have any documentation on that jtag stuff - how would that help me diagnose the latest x15 images failure to boot Jan 06 19:27:32 jtag lets you debug boot right from the earliest stages, e.g. single-stepping through the MLO code or put a breakpoint on cpu exceptions Jan 06 19:29:13 (the xds100v2 debuggers also grant a free license for TI's Code Composer Studio IDE which you can use; open source alternatives exist also but I have no experience with how well they are suited for this) Jan 06 19:30:17 I'm assuming here your board has jtag accessible... if those pins are not-connected then that would complicate things obviously :) Jan 06 19:32:51 (there's still an alternative involving muxing jtag to the pins normally used for the sd card slot, which could probably be used if you insert instructions to perform the necessary pinmux setup as early as possible in MLO) Jan 06 19:34:36 ok. I'm going to reach out to the team that built this board Jan 06 19:34:58 that mux option is used to support a MIPI standard for debugging mobile devices through a microSD card slot: https://upload.wikimedia.org/wikipedia/commons/6/61/NIDNT.jpg Jan 06 19:35:43 unfortunately it happens that boards are designed without a jtag interface Jan 06 19:35:50 which I think is a painful oversight Jan 06 19:36:14 jtag is something you only need very rarely, but when you do need it you're really in a painful situation if it's not available Jan 06 19:37:34 (it is also useful later on for things like non-invasive performance monitoring, but that's a separate topic) Jan 06 19:39:40 ok Jan 06 19:40:02 well I'm mostly a software guy so I can get started on the kernel mod in that thread, see how far I get Jan 06 19:40:23 It does not appear that we have a jtag header Jan 06 19:40:32 if you're bringing up a board, you're also a hardware guy whether you want to or not ;-) Jan 06 19:40:54 my condolences Jan 06 19:41:37 you have my permission to slap the hardware guys for failing to include a jtag header Jan 06 19:45:52 I've once been in the situation of trying to debug early boot on some board using just a led... I think if you ask the hw people to imagine debugging a hardware problem by only being able to make boolean measurements (is this pin >= this voltage) and having to wait a minute for each such measurement (or whatever the compile-run cycle time is) and they'll hopefully understand why it's important to include Jan 06 19:45:58 jtag on future boards they design :P Jan 06 19:48:53 I know jtag can also be used for kernel debugging, no experience with that though Jan 06 20:04:59 I've got 2 BBGWs. On one, I have the default image that came with it - WiFi is working. On the other, I have an old image from a BBB that I'm trying to retro-fit (because I have a lot of work put into the image). I'm having trouble getting the wifi to work with it though. I've tried loading the bbbw-univ dtbo and then modprobing the wlcore/wl18xx modules, but i don't see a wlan0 in ifconfig. I've looked at dmesg/syslog/mess Jan 06 20:05:00 ages, but don't see much to give me a clue as to what's going on. Anyone know how I can figure out what's going on? Jan 06 20:10:31 how old is "old" ? Jan 06 20:11:28 i think the build date is mar 2015 Jan 06 20:11:44 came with kernel 3.18 but i just upgraded it to 4.9 Jan 06 20:11:47 you can probably find it in /etc/dogtag Jan 06 20:12:16 try the latest kernel from the 4.4-ti series (which is the current "release" series) Jan 06 20:12:21 Hi, I have trouble for burn sd card Jan 06 20:12:45 I couldn't get wifi working on my BBE with the latest 4.9 kernels while it worked right away with the 4.4-ti kernels... different driver, but still Jan 06 20:13:06 i'll give it a go. Jan 06 20:13:07 thanks Jan 06 20:13:16 (and I had to run depmod after installing the driver package) Jan 06 20:14:05 I can't do it on Windows and Linux Jan 06 20:14:50 Wicho18: tip: to get a response here, it helps to actually ask a concrete question (which you haven't yet) Jan 06 20:15:42 just saying you have trouble with something or it doesn't work for you isn't something to which anyone can really reply anything useful Jan 06 20:16:36 (see also this guide -> http://www.catb.org/~esr/faqs/smart-questions.html ) Jan 06 20:16:47 sorry, When I put the sdcard in the beaglebone, never on the 4 leds Jan 06 20:17:22 then the card isn't bootable Jan 06 20:17:42 the process never finish Jan 06 20:17:59 oh wait Jan 06 20:18:07 you mean a flasher card? Jan 06 20:18:18 what activity do you see on the leds? Jan 06 20:18:28 yes the flasher card Jan 06 20:18:46 led 0 blink and the 2 is on Jan 06 20:18:58 led 2 is on Jan 06 20:20:05 that doesn't sound like a flasher at all, more like a booting system (I hope led 2 doesn't stay on indefinitely?) Jan 06 20:21:11 yes, the led 2 stay on indefinitely Jan 06 20:21:25 that is a bit odd Jan 06 20:22:01 since I think that's either the cpu activity led or the sd card activity led Jan 06 20:22:28 it is cpu activity led Jan 06 20:23:20 needless to say, 100% cpu activity on an idle system is really odd Jan 06 20:23:42 I use win32diskimager to burn the image Jan 06 20:24:03 debian 7.8 to install libreboot on my thinkpad t400 Jan 06 20:24:20 but I can't change the os in the bbb Jan 06 20:24:26 a wrong imager shouldn't cause this, if the image were misflashed then it wouldn't boot at all Jan 06 20:25:01 I'd suggest checking the serial console during boot Jan 06 20:25:10 it's nearly impossible to debug boot issues without it Jan 06 20:25:56 you can use a standard 3.3v ftdi serial cable (other alternatives are listed here: http://elinux.org/Beagleboard:BeagleBone_Black_Serial ) Jan 06 20:26:09 Do I need conect the beaglebone on screen? Jan 06 20:26:10 The USB "hub" on my BBB dies after one or two plug/unplugs with a USB flash disk. Kernel 3.8.13-bone79, BBB Rev C with Debian 7. Known problem? Need to update? Jan 06 20:27:01 Pastebin, two replugs and no more messages in /var/log/messages: http://pastebin.com/ZFBsCjGN Jan 06 20:27:59 Dielectric: 1. kernel 3.8 is pretty ancient 2. usb is known to be fickle due to lack of output caps on usb power switch, driver ought to recover but doesn't always in practice. I see no evidence of this happening in your kernel log though Jan 06 20:28:00 ok, I going to check it Jan 06 20:28:10 dmesg shows the hub auto-suspending Jan 06 20:28:39 Dielectric: there's no hub on the BBB btw, but it's probably referring to the "root hub" (i.e. the usb controller itself) Jan 06 20:28:56 hence the quotes, I figured it's referring to the root hub Jan 06 20:28:57 you can disable autosuspend using the kernel commandline parameter usbcore.autosuspend=-1 Jan 06 20:29:48 (there's also a sysfs attribute to set it at runtime, /sys/module/usbcore/parameters/autosuspend ) Jan 06 20:30:36 I think the runtime parameter is just the default for new devices though, so it wouldn't affect the existing root hub probably Jan 06 20:31:41 still odd though, I've seen and heard of plenty of usb-related issues, but no good match to what you're describing Jan 06 20:32:30 it's pretty weird. do I use uEnv.txt for the commandline parameter? Jan 06 20:32:47 yeah, there's a cmdline= parameter there somewhere to which you'd append this Jan 06 20:33:19 normally autosuspend issues are with specific devices though (especially cams), not the whole port Jan 06 20:33:56 for a port dying due to device hotplugging I would typically expect a VBus Error or such coming from the musb driver Jan 06 20:34:20 (the most used workaround for that is a powered usb hub) Jan 06 20:34:35 really strange that I don't get any real errors, just no more activity Jan 06 20:34:51 that is very strange indeed Jan 06 20:35:40 you can enable more debug messages using: echo 'file drivers/usb/* +p' >/sys/kernel/debug/dynamic_debug/control (if I remember correctly) Jan 06 20:36:10 I'm trying to disable autosuspend, rebooting now Jan 06 20:42:01 welp, got through 3 cycles and stopped. the autosuspend parameter shows -1 now (was 2), but I'm still getting and auto-suspend message in dmesg Jan 06 20:42:15 pastebin of full log? Jan 06 20:44:10 from dmesg: http://pastebin.com/kurHHQ44 Jan 06 20:46:09 hmm Jan 06 20:46:30 so it enters auto-suspend once and resumes fine, enters auto-suspend again and becomes silent Jan 06 20:46:49 yes sir. Jan 06 20:47:33 I don't suppose you have a way to check whether the port is still powered? (e.g. a voltmeter or some dumb gadget that uses usb as a power supply) Jan 06 20:47:50 yes, let me probe it Jan 06 20:48:55 there's another question on my mind... Jan 06 20:48:59 should I order pizza or not? Jan 06 20:49:20 hmm Jan 06 20:52:08 yeah, wow, no volts on USB Vcc and D+/D- are both low so that's a fault condition Jan 06 20:52:24 I'm thinking chinese, actually Jan 06 20:53:54 ok, so port is powered down, that's an excellent reason for not detecting a device Jan 06 20:54:34 rebooted, power is back on. Jan 06 20:54:47 nothing in the kernel log indicating the driver decided to power down the port though Jan 06 20:54:48 just wanted to make sure I had it right Jan 06 20:59:46 still, it probably means a vbus error Jan 06 20:59:58 even though I'm puzzled about why it doesn't say so, loudly, in the kernel log Jan 06 21:01:17 in which case workarounds would be a powered usb hub, or adding a 100 uF capacitor on vbus Jan 06 21:01:43 or possibly a bus-powered usb hub might even help, effectively acting like a rather bulky capacitor Jan 06 21:02:04 There's a bit 'lytic lableled C31 next to RT1, that's not on VBus? Jan 06 21:02:38 would a superspeed hub be OK, or will that cause even more trouble? Jan 06 21:02:47 I'm too lazy to grab the schematic, but you're probably referring to the 100 uF cap on the input side of the power switch rather than the output side? Jan 06 21:03:17 they should be backward-compatible I guess? Jan 06 21:04:05 well, there's only one on the board so I suppose that's it. Jan 06 21:06:15 uhh, RT1, that's the 5V of the HDMI port, not usb Jan 06 21:06:43 usb is on page 4 of the schematic (I've overcome my laziness, yay me) Jan 06 21:07:19 there's C34, but it's not on the output side of the U8 power switch Jan 06 21:08:10 C35 is on the output side but not always enough to cope with the sudden current surge of plugging in a device Jan 06 21:09:02 I've got a powered superspeed hub, going to try some replugs now Jan 06 21:09:51 there is a generic way to bring the port back to life: if the musb driver is built as module, then unloading and reloading it always works in my experience Jan 06 21:10:26 which also indicates the driver ought to be able to deal with this sort of stuff, but doesn't Jan 06 21:10:35 well, it doesn't like my hub :( musb_stage0_irq 496: bogus host RESUME (b_idle) Jan 06 21:10:48 ohh, shiny, never seen that error Jan 06 21:12:32 musb must be static, lsmod doesn't show it Jan 06 21:12:52 the musbhsdrc peripheral can be obnoxiously fussy Jan 06 21:13:15 I'm using uio_pruss with the LEDscape stuff, so I had to disable HDMI. Any chance there's an interaction? Jan 06 21:13:15 yeah it is in default kernel builds... maybe unbind/bind works as alternative to unload/load Jan 06 21:13:21 no Jan 06 21:16:58 https://www.crowdsupply.com/envox/eez-h24005 Jan 06 21:17:27 for unbind/bind I'm not sure whether to do it to the musb-dsps driver or the musb-hdrc driver Jan 06 21:17:40 the former intuitively feels safer Jan 06 21:19:10 I only see bindings to musb-hdrc in /sys/bus/usb/drivers/usb/ Jan 06 21:19:28 but I really have no idea what I'm looking at... Jan 06 21:22:42 /sys/bus/platform/drivers/musb-dsps Jan 06 21:23:11 probably the device name is something like 47401c00.usb Jan 06 21:23:29 (symlink should be present in that dir) Jan 06 21:23:38 echo device name to unbind attribute, then echo it to bind attribute Jan 06 21:35:20 behaving suspiciously better now, but one of my drives pretty consistently hangs the bus Jan 06 21:35:41 it's a PNY superspeed drive, I wonder if it's trying things that aren't supported by my ancient kernel Jan 06 21:36:03 but, bind/unbind will unsnarl it so I guess that's something Jan 06 21:36:44 that PNY drive never works right but my old and slow drives are OK Jan 06 21:38:21 the usb port has always been a bit of a problem child, although it has improved over time so it would be worth trying the most recent kernel from the 4.4-ti series (this appears to be the most mature kernel series at the moment) Jan 06 21:39:09 I suspect I'll have some work to do getting LEDscape operational with the 4.x kernels, won't I? Jan 06 21:39:23 what is it? Jan 06 21:40:03 it's a PRU driver for the Neopixel-style led strings Jan 06 21:40:42 https://github.com/Yona-Appletree/LEDscape Jan 06 21:42:14 once you have uio_pruss enabled it should be the same Jan 06 21:43:04 oh, cool. I may give it a spin this weekend. I was really hoping to have users able to walk in with a USB stick and load new animations via sneaker-net Jan 06 21:43:42 oh it looks like the cape actually does something clever by providing a script that makes a custom variant of your existing main dtb Jan 06 21:44:49 I'm actually not using the cape, so I have to load the dtb at install Jan 06 21:45:15 I only need one channel, not 24 or 48 so no need for a lot of extra hardware Jan 06 21:45:16 not very confidence-inspiring though that the instructions in its readme contain a bogus modprobe and don't seem to explain what (if anything) you're supposed to be doing in the uEnv.txt Jan 06 21:46:19 anyway if you have trouble enabling uio_pruss and can't find the answer easily by searching just complain on the mailing list Jan 06 21:46:30 worked for me though! Jan 06 21:47:03 (alternatively install the latest 4.4-bone kernel instead of 4.4-ti) Jan 06 21:48:16 the problem I'm anticipating lies here (showing it in the hdmi-disabled dts but the same holds for the other variants): Jan 06 21:48:19 https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.4.40-ti-r80/arch/arm/boot/dts/am335x-boneblack-emmc-overlay.dts#L32 Jan 06 21:49:24 I think an overlay can provide the contents of that commented-out include, but I don't understand why rcn still leaves it commented out Jan 06 21:50:08 since he mentioned the alternative way to use pru (remoteproc) doesn't work when loaded by overlay, which means that it's not possible to choose between the two at runtime Jan 06 21:53:08 can I jump all the way to a 4.4 kernel or should I grab a newer image and go from there? Jan 06 21:54:14 installing a 4.4 kernel on an old wheezy image sounds... courageous Jan 06 21:54:25 possible in theory Jan 06 21:54:59 :) Jan 06 21:56:03 yeah, not gonna do it Jan 06 21:58:18 and pizza it is Jan 06 22:01:17 enjoy the pizza. thanks for the guidance! Jan 06 22:01:28 you're welcome :) Jan 06 22:06:22 welp, somehow the web interface quit on me. I was trying to get into Cloud9 to copy some stuff, connection refused. Jan 06 22:17:50 people actually use cloud9 ? :) I mean, I suppose that if noone considered it useful it wouldn't be included... Jan 06 22:23:22 I think Cloud9 falls in the "simplify the ootb experience" category. Jan 06 22:25:38 yes **** ENDING LOGGING AT Sat Jan 07 03:00:01 2017