**** BEGIN LOGGING AT Wed Feb 08 03:00:03 2017 Feb 08 08:25:08 Anyone knowledgeable on OMAP3530 reboot? I added the twl4030 power scripts to my kernel to make sure that the twl4030 is properly reset on reboot, but just noticed that the board is always rebooted with a cold reset. Feb 08 08:28:17 doesn't "resetting" the pmic generally imply it will power cycle? Feb 08 09:27:40 zmatt: yes, but I think it varies with reset method how it resets. I have an issue where musb/smsc95xx "disappears" in a reboot test. Feb 08 09:28:18 when gone, no amount of reboot will bring it back. I have to "turn it off and on again" **** BEGIN LOGGING AT Wed Feb 08 09:36:32 2017 Feb 08 12:46:53 tomba: I got Qt5 with eglfs_kms backend working on the beaglebone with the new sgx drivers \o/ Feb 08 12:47:09 it required patching the eglfs_kms backend /o\ Feb 08 12:50:04 (a fairly trivial patch, but still... https://gist.github.com/mvduin/ed24141e5bec6a42a00ccdaaf812d6a3 ) Feb 08 12:58:14 zmatt: hmm are you saying XR24 doesn't work? it should work just fine. Feb 08 13:06:30 tomba: the beaglebone is wired "straight" (http://lxr.free-electrons.com/source/drivers/gpu/drm/tilcdc/tilcdc_drv.c#L38) Feb 08 13:12:24 ah, right. yeah, there are a lot of userspace apps that just use XR24, and that's it. Feb 08 13:13:41 it could support RX24 by using the endianness-swapping feature Feb 08 13:15:05 problem is that this Qt5 backend still uses drmModeAddFB instead of drmModeAddFB2 Feb 08 13:15:25 and other code also.. https://github.com/mvduin/kmscube/commit/0774c0838aa52e7a67887f49ec079c0fa22df06d Feb 08 13:15:30 with "it" you mean the driver? and with RX24, you mean XR24? and with swapping, you mean the hdmi encoder's feature? Feb 08 13:15:53 with "it" I mean tilcdc, and with swapping I meant lcdc supports this Feb 08 13:16:27 ok. because the bb's hdmi encoder can swap the bytes, and thus support XR24 Feb 08 13:16:54 the hdmi encoder can indeed do a lot also, but we're using lvds Feb 08 13:17:17 ok Feb 08 13:17:48 is RX24 any better than XB24? Feb 08 13:18:11 I have no idea widespread app support for it is Feb 08 13:19:17 I don't *really* care other than out of curiosity since 16-bit framebuffers work, higher depth is not useful when you only have a 16-bit connection anyway, and it reduces bandwidth requirements on the memory bus Feb 08 13:20:37 yes, I agree Feb 08 13:20:38 the pixel format enum for SGX includes XRGB-8888 and XBGR-8888, but not RGBX nor BGRX Feb 08 13:30:07 hi everyone! Feb 08 14:15:48 I am back :) Feb 08 14:15:52 what's an easy way to setup an LCD/OLED character display on the bbb? Feb 08 14:16:15 sgflt, I dunno : \sorry Feb 08 14:16:43 basically it seems to boil down whether i2c or spi is easier to setup on a linux system; or if serial is the way to go Feb 08 14:39:18 hi, i'm wondering if os images built for the beaglebone black will work on the beaglebone green, and vice versa? Feb 08 14:40:51 dunx, it seems so: http://beagleboard.org/latest-images Feb 08 14:41:11 at least for the offical linux distro Feb 08 14:41:16 *official Feb 08 14:41:22 ok, thanks Feb 08 14:42:08 Hello Feb 08 14:43:40 hi Feb 08 14:46:19 hey Feb 08 14:47:44 i cant connect to 192.168.7.2 using usb connection to my bbb Feb 08 14:48:12 ive installed both drivers Feb 08 14:51:46 latest versions of horndis and ftdi Feb 08 15:24:17 sgflt: note that lcdc also natively speaks a few bus protocols commonly used for character displays Feb 08 15:24:57 zmatt: lcdc? Feb 08 15:25:02 the lcd controller Feb 08 15:25:12 there's one on the board? Feb 08 15:25:37 in the SoC, yes it's normally used for its display output (e.g. hdmi0 Feb 08 15:25:46 ) Feb 08 15:26:02 oh. i was going to hook up an i2c display, but that seems a viable option as well Feb 08 15:26:12 depending on how hard it is to set up though Feb 08 15:26:17 (and how stable) Feb 08 15:30:03 i2c is probably also by far the slowest protocol of the ones you mentioned Feb 08 15:30:19 too slow to display 4x40 characters of text? Feb 08 15:30:49 no probably not :) Feb 08 15:31:14 that'd still be almost 80 "fps" at 100kbit Feb 08 15:31:15 =) Feb 08 15:31:56 what's more important is that very little CPU time is used -- i'm driving other displays in a soft-realtime application with the device and i can't have the display take up time there due to bitbanging or similar Feb 08 15:38:26 the i2c peripheral is relatively more hassle than the other two options Feb 08 15:38:57 don't i just connect three pins for i2c and then use the linux i2c drivers? Feb 08 15:39:07 to send a few bytes? Feb 08 15:40:15 maybe i should phrase that differently: i fully intend to make a custom pcb for the project, as an LCD display is only part of it. i do need a stable way to drive the display efficiently without hacks from a C-like language Feb 08 15:41:18 which way is easiest then? i've seen some C libraries to drive LCD displays with similar chipsets (like the SSD1306), which were just a few lines on top of generic i2c functions, which i assume already come in some form? Feb 08 15:42:00 yes I meant it's more hassle at a lower level, which is handled by the i2c driver, but that can still impact application performance etc Feb 08 15:42:02 the only thing i'm fairly sure i do not want is the "parallel"-method for connecting LCD displays Feb 08 15:42:13 that would be what lcdc supports Feb 08 15:42:21 oh Feb 08 15:42:26 is that the same protocol? Feb 08 15:43:17 so you're saying i can just hook up the "parallel" protocol type LCDs (i've been looking at MIDAS ones) to the onboard lcdc and have it working Feb 08 15:43:19 ? Feb 08 15:44:12 lcdc (in bus protocol mode) supports three bus protocols: motorola 6800, intel 8080, and hitachi Feb 08 15:45:10 phew, now i wonder how i can find out which protocol my display supports.. Feb 08 15:45:31 if it says 68XX-series, i assume that's motorola 6800? =) Feb 08 15:45:53 I don't know if there's a driver for lcdc in this mode, although it's really easy to use Feb 08 15:46:09 yeah Feb 08 15:46:16 awesome Feb 08 15:46:18 thanks Feb 08 15:46:53 my pins spreadsheet ( https://goo.gl/Jkcg0w ) has an LCDC tab which shows the pinout of lcdc in its various modes Feb 08 15:47:24 zmatt: thanks a lot. that's going into my bbb reference library =) Feb 08 15:48:24 but yeah, lots of options Feb 08 15:48:45 these parallel buses are probably overkill for such a tiny display Feb 08 15:58:53 zmatt: thanks! Feb 08 16:30:20 bye bye folks ;) Feb 08 17:01:42 Hi all.. Feb 08 17:19:08 hi Feb 08 17:19:23 is there a beagle board sales person here that i am chatting with? Feb 08 17:20:05 aglick: a founder of the open source project, yes, but no sales person. Feb 08 17:20:21 I am an engineer with Xzeres wind, a distributed wind turbine manufacturer in the United States. We are looking for a small single board computer for our network connectivity and data acquisition. We are looking for a board with the following specifications: 1. Temperature range of -40C to 85 deg C 2. Real Time Clock with battery 3. Removable primary storage (transflash, or similar) 4. 1X Ethernet Port 5. 1 GB RAM or better 6. 1 GHz o Feb 08 17:20:26 aglick: you'd have to contact Element14, Mouser, Digi-Key, Arrow, etc. to talk to a sales person. Feb 08 17:20:59 i think the beaglebone has most of this, but not the removeable primary storage or real time clock.. is that the case? Feb 08 17:21:09 aglick: see http://bbb.io/logo and e-mail me (my e-mail address is at http://bbb.io/about) to put you in touch with someone who can meet your product requirements. Feb 08 17:22:22 will do! Feb 08 17:22:24 thanks Feb 08 18:10:38 does anyone have experience powering a BBB with 12V ? Feb 08 18:11:08 i need a waterproof solution and i can only find waterproof power bricks in the form of 12 V led AC/DC adapters =/ Feb 08 18:19:01 Can I flash an image directly to the NAND flash of my beagle bone green instead to the sd card? Feb 08 18:33:16 i'm running into a problem with kernel 4.4 - I'm running a small daemon program that launches at boot, the program uses tcgetattr to get the current settings of /dev/ttyO2 but when the program runs, tcgetattr is returning ENOTTY. If I run the program from a terminal, it run fine without an error. How can I convice the program that the tty exists at boot? Feb 08 20:32:41 clockman: delay the start of the program a bit, until /dev is populated? Feb 08 20:46:14 I've tried delaying it 4 seconds. I guess I could try like 20 seconds to see if that works. Feb 08 20:50:45 i'll be damned. I think that was it Feb 08 20:50:50 thanks sgflt Feb 08 20:51:13 clockman: if you can figure out a way to detect that the terminal is ready (such as /dev/ttyO2 showing up?), systemd will have your back Feb 08 20:51:27 clockman: it might be sufficient to find a proper .target and delay until then Feb 08 20:52:07 excellent. will do. thanks again Feb 08 21:23:21 you can actually have systemd *spawn* the daemon for you when the serial port appears Feb 08 21:26:44 in any case you can use "dev-ttyO2.device" as unit name for ordering purposes (you'll want BindsTo= and After=) Feb 08 21:28:41 it sounds really strange though that you're getting ENOTTY from tcgetattr()... if the tty didn't exist yet I'd expect an ENOENT from open() instead Feb 08 21:37:46 this is so weird, I'm suddenly seeing frequent mmc lockups on two recent BBBs... mmc1 activity led goes steady-on, system sort of continues running although pretty much anything just locks up (but ctrl-C gets you back to the shell) Feb 08 21:38:11 nothing reported in dmesg Feb 08 23:29:28 hi, whats the proper way to enable spi on debian 4.4 (pretty much latest feb 2017 release) Feb 08 23:33:14 * vagrantc suspects that's the kernel 4.4.x, not debian 4.4 **** ENDING LOGGING AT Thu Feb 09 03:00:02 2017